Можно, но это будет не Колибри, а Линукс.johnfound wrote:А можно заменить ядро на Линукс и использовать X сервер как нормальные люди.
Опять про X и Linux
Serge
- произвольное количество окон-- давно пора. 255 - слишком много, надо работать с хэндлами в списке, а не в массиве. Причем резать придется по живому; задача гораздо легче решается именно "внутри" ядра, чем "снаружи".
- отрисовка элементов GUI в user-mode-- это еще зачем? юзер должен только сформировать и отправить ядру GUI-запрос (лучше - готовую очередь запросов), остальное не его дело.
- отрисовка в битмап-- а сейчас с этим какие-то проблемы? если да - то чем модульность поможет?
- использование акселерации-- тут без плотной работы с ресурсами ядра точно не обойтись. Только внутри, однозначно.
- тайловая архитектура-- лучше чем пиксельная, согласен. И что? Если уж переходим на новую архитектуру - так все вместе. Иначе нужно будет разрабатывать 2 совершенно разных и несовместимых графических подсистемы.
- композитный менеджер-- ?
Вот-вот, именно к этому и придём.johnfound wrote:А можно заменить ядро на Линукс и использовать X сервер как нормальные люди.
Максим плодовит на офтопы. К сожалению это все на что он плодовит. Потому пришлось снова выдрать кусок из оригинальной темы Масштабируемые шрифты
art_zh
GUI отлично рисуется в user-mode. Ещё лучше делать это в битмап. Вопрос стоит так: зачем делать в режиме ядра то, что можно сделать в приложении ? Перетаскивание и изменение размеров окна тоже реально делать в user-mode. Менять размер в самом приложении можно и сейчас. С перетаскиванием проблема - мешает обработчик в ядре. В этом случае нельзя сделать нестандартное окно с холдером справа/слева/снизу/в центре. В итоге имеем в ядре код, без которого легко обойтись -
GUI отлично рисуется в user-mode. Ещё лучше делать это в битмап. Вопрос стоит так: зачем делать в режиме ядра то, что можно сделать в приложении ? Перетаскивание и изменение размеров окна тоже реально делать в user-mode. Менять размер в самом приложении можно и сейчас. С перетаскиванием проблема - мешает обработчик в ядре. В этом случае нельзя сделать нестандартное окно с холдером справа/слева/снизу/в центре. В итоге имеем в ядре код, без которого легко обойтись -
- изменение размеров, сворачивание в заголовок и перетаскивание окон мышкой
- поддержка разных стилей окон, учёт размеров клиентской области
- отрисовка окон
- отрисовка и обработка кнопок.
art_zh wrote: отрисовка элементов GUI в user-mode-- это еще зачем? юзер должен только сформировать и отправить ядру GUI-запрос (лучше - готовую очередь запросов), остальное не его дело.
Рисовать надо либо в драйвере видеокатрты либо на CPU(user mode прекрасно подходит) либо на любом другом подходящем устройстве которое в данный момент присутствует и поддержка которого тоже есть.Serge wrote:GUI отлично рисуется в user-mode. Ещё лучше делать это в битмап. Вопрос стоит так: зачем делать в режиме ядра то, что можно сделать в приложении ?
Вы одно не понимаете, самое главное - надо дать програмисту Стабильный API чтобы програмисту не пришлось ничего переписовать пару десятилетий. А то прям ничего писать нехочется зная что придётся переписывать частично, полностью или забрасывать kolibri.
Art_zh правильно предложил делать список, а какому устройству этот список скармливать зависит от того какая железка список лучше обработает. Вызываються API функции и делают новые записи в списке (потом даже, можно запросы на разные процессоры послать для отрисовки)
А если времени нету возиться со списками запросов и оптимизацией то хотябы "заверните" системные вызовы в user-mode функции как например call dword [Rectangle] call dword [LineTo] ...
ilya
я хочу реализовать GUI-буфер в динамической памяти приложения в виде односвязного списка с известной ядру точкой входа (возможно, с дополнительными перекрестными связями для перехода между отдельными элементами управления по клавише Tab).
Serge
Совершенно не представляю себе, как можно замутить такую штуку в 3-м круге. У ядра-то есть доступ к памяти приложения; а как будет твой менеджер отрабатывать, скажем, 50-ю функцию (чтоб ей, кстати, провалиться)?
Через буфер обмена?
Или будет хранить локальные фреймбуферы (битмапы) всех окон в себе?
я хочу реализовать GUI-буфер в динамической памяти приложения в виде односвязного списка с известной ядру точкой входа (возможно, с дополнительными перекрестными связями для перехода между отдельными элементами управления по клавише Tab).
Serge
Совершенно не представляю себе, как можно замутить такую штуку в 3-м круге. У ядра-то есть доступ к памяти приложения; а как будет твой менеджер отрабатывать, скажем, 50-ю функцию (чтоб ей, кстати, провалиться)?
Через буфер обмена?
Или будет хранить локальные фреймбуферы (битмапы) всех окон в себе?
Который плотно склеен не только с перебором стека, но и с чисто ядерными службами - списком переключения задач и очередью событий. И само собой - с HID-драйверами.С перетаскиванием проблема - мешает обработчик в ядре.
Давайте сделаем блок-схему. Я конечно понимаю, что ни у кого нет желания, и тд и тп, но все понимают что это правильный путь. А потом, после баталий на поле схем и на поле блоков, можно переходить к воплощению.
Шучу, шучу. Я Х терпеть не могу!
art_zh
Совсем не понял твою идею GUI буфера. Можно подробнее ?
ф.50 делали в те времена, когда в ядре не было менеджера памяти и давно хотели удалить за тормоза. Так что надо хранить в ядре локальную копию или замапить буфер в пространство ядра.
Самый простой вариант без композитного менеджера. Вся отрисовка производится программой в битмап. Функция Blit() немедленно отправляет результат на экран. Если хотим акселерацию, битмап должен создаваться системным вызовом. Оконный менеджер управляет прямоугольными областями на экране. От него требуется
Совсем не понял твою идею GUI буфера. Можно подробнее ?
ф.50 делали в те времена, когда в ядре не было менеджера памяти и давно хотели удалить за тормоза. Так что надо хранить в ядре локальную копию или замапить буфер в пространство ядра.
Самый простой вариант без композитного менеджера. Вся отрисовка производится программой в битмап. Функция Blit() немедленно отправляет результат на экран. Если хотим акселерацию, битмап должен создаваться системным вызовом. Оконный менеджер управляет прямоугольными областями на экране. От него требуется
- создание и удаление окна
- установка размеров окна
- управление z-ордером окна и областями отсечения
- определение событий активации и деактивации окна
- отслеживание клавиатурного фокуса
- отслеживание событий мыши
- захват мыши окном
- отрисовка курсора
Не, по вкусу GUI это хорошо, но Колибри все-таки маленькая система. И надо как-то его унифицировать, имхо.
Щас нарисую.Serge wrote:art_zh
Совсем не понял твою идею GUI буфера. Можно подробнее ?
Твоя схема вполне понятна. Кстати, ядерные элементы в ней-таки присутствуют
Один только вопрос:
это очень важный момент: как думаешь реализовать экранную карту (отсечения)? Надеюсь, не на битовом поле?Serge wrote:Оконный менеджер управляет прямоугольными областями на экране. От него требуется ... управление z-ордером окна и областями отсечения
art_zh,
Однако генеральную линию в основной ветке Вы сможете пилить только тогда, когда остальные признают, что то, что Вы сделали - лучше чем то, что имеется.
Кстати я лучше форканусь (если, конечно, буду уже что-либо более-менее программировать под КОС), чем соглашусь участвовать в написании жесткого монолитного ядра, собираемого из исходников под каждую конкретную машину (к чем, как я понял из общения с Вами ранее Вы и стремитесь).
инужно выстроить генеральную линию
не соотносятся между собой. Вы самолично хотели бы выстроить генеральную линию? Тогда я процитирую другое:я не соглашался
Вы можете самолично сделать в своем бранче то, что Вы задумали, также, как я сейчас пилю рабочий стол и иже с ним (когда мне примерно в том же духе сказал mike.dld о том, что если мне хочется - делай и показывай).Каждый может делать свой вариант, а уже потом будет видно у кого лучше и стоит ли овчинка выделки.
Однако генеральную линию в основной ветке Вы сможете пилить только тогда, когда остальные признают, что то, что Вы сделали - лучше чем то, что имеется.
Кстати я лучше форканусь (если, конечно, буду уже что-либо более-менее программировать под КОС), чем соглашусь участвовать в написании жесткого монолитного ядра, собираемого из исходников под каждую конкретную машину (к чем, как я понял из общения с Вами ранее Вы и стремитесь).
art_zh
Текущая байтовая карта подходит для аппаратной акселерации. Так что это не самый плохой вариант. Другой вариант взять из X операции с регионами. У каждого есть свои недостатки и достоинства.
XVilka
Унифицированный API очень хорошо. У нас пока нет ни одной полновесной библиотеки контролов. Нужна одна такая системная.
Текущая байтовая карта подходит для аппаратной акселерации. Так что это не самый плохой вариант. Другой вариант взять из X операции с регионами. У каждого есть свои недостатки и достоинства.
XVilka
Унифицированный API очень хорошо. У нас пока нет ни одной полновесной библиотеки контролов. Нужна одна такая системная.
Кстати, я работаю над FreshLib, которая должна иметь полную библиотеку контролов, причем полностью портируемой. Дело идет медленно, но все-таки идет. Пока есть только порты для Win32 и Линукс, но безусловно будет и версия для Колибри.Serge wrote:У нас пока нет ни одной полновесной библиотеки контролов. Нужна одна такая системная.
Сверху - как сейчас.
Снизу - что предлагается.
Снизу - что предлагается.
- Attachments
-
-
GUI diagram.png (26.24 KiB)Viewed 8291 times
-
Who is online
Users browsing this forum: No registered users and 1 guest