переделать оконную систему...

Kernel-side graphics support
  • >Преимуществ достаточно. Минусы: полная не совместимость!!!!

    Этот минус перекрывает все большие плюсы. Переписывать все программы на новый GUI никто не кинется. Так что даже тестить неначем будет. Делать поддержку для старых программ всё равно придётся.

    >стоит ли оконный менеджер выносить из ядра???
    Надо определиться чем занимается оконный менеджер. ИМХО он должен только управлять областями на экране и быть частью ядра,а все элементы управления должна делать user mode ДЛЛ, как libGUI. Расшаренные ДЛЛ будут, всему своё время.
  • Serge wrote: Переписывать все программы на новый GUI никто не кинется.
    Я это прекрасно понимаю. А что делать? тянуть тяжелое бремя менуэта за собой? На самом деле программ не так уж и много, чтобы оставить совместимость, да и то, никто ж не говорит о глобальных изменениях. Если программа составлена грамотно, где достаточно отделена графика от самой логики, то переписывание не составит особого труда.
    Serge wrote: Делать поддержку для старых программ всё равно придётся.
    к сожалению да...хм...а что если в виде эмулятора???
    Serge wrote: ИМХО он должен только управлять областями на экране и быть частью ядра,а все элементы управления должна делать user mode ДЛЛ, как libGUI.
    да-да-да, я про то же (если к элементам управления отнести заголовок, границы окна и т.п.)

    Просто я себе представить не могу, как реализовать рисование в этих областях :(
  • k@sTIg@r
    Идея хорошая, но возникает вопрос со скоростью - если будет сильная потеря скорости, то ИМХО овчинка выделки не стоит. А так можно все переписать. Главное начать - покажи первый результат, тем более ты все равно будешь делать - а это очень хорошо, учитывая разброд мнений пользователей данного форума.
    Если существенных потерь скорости не будет (Linux в этом плане не лучший пример), то я одним из первых перепишу свой KFM под новую систему.
  • Потерь скорости быть не должно, а вот программ не так и мало. Если собрался делать оконную систему то стоит начать с десктоп менеджера. Собрать вместе Icon, Panel, Rb (меню на правой кнопке мыши) в одну программу и добывить туда переключение окон по Alt-Tab
  • Serge
    Собрать вместе Icon, Panel, Rb (меню на правой кнопке мыши) в одну программу
    ИМХО вот как раз этого делать не надо - печальный пример Винда: слетел Explorer и все облом, по крайней мере, в 9х.
    А вот Alt+Tab действительно нужная вещь.
  • Насчет потерь в скорости - ничего не скажу, так как не знаю. Теоретически не должно, т.к. всего лишь выносятся оконные элементы. Правда потеря может случится из-за мультиоконности, т.к. до конца не продумал события. Ясно что события нажатие клавиши, мышь, перерисовка будут идти именно окну, а приложение будет проверять уже не свои события, а события окна(доп. параметр в теперешних функциях). А вот остальные события (IPC, сетвое событие, отладочное событие, IRQs) по идее нужно слать именно приложению, т.к. они ни каким макаром не связаны с окном. Разве что оставить как есть, только задача приложения, в дополнение, определить какому из его окон(точнее областей) пришло событие....

    Я и думал начинать с десктоп менеджера, для начала хотябы простого. То есть приложение, которое создаст 2 области. Одно фон с иконками(ниже всех), другое панель(выше всех).
    Но опять же повторюсь, как реализовать рисование в этих регионах, я понятия не имею. Вот от этого вопроса и будет зависить скорость работы. Если сейчас само окно, без клиентской области, рисовалось в ядре, то сейчас это будет делать пользовательское приложение....
    Вобщем, сначала реализую первые шаги, а потом может кто подключится по поводу "рисования в областях"

    PS еще вопрос. Как можно дебажить ядро %-)
  • ИМХО вот как раз этого делать не надо - печальный пример Винда: слетел Explorer и все облом, по крайней мере, в 9х.
    Почему??? В винде действительно дебильная система. То что предлагает Serge не одно и тоже.
    Desktop Manager сам по себе, остальные приложения сами по себе. И пусть они себе слетают, десктоп манеджер будет жить пока сам по себе не слетит(мало ли, идеального софта не бывает).
  • Mario79

    А чем плох такой менеджер ? Разве это дело держать отдельный поток для каждой иконки ? В 9х действительно облом а в ХР падал несколько раз и сразу автоматом перезапускался. Прямо сервер реинкарнаций из Minix. Такую вещь можно и для Колибри сделать
  • k@sTIg@r wrote:PS еще вопрос. Как можно дебажить ядро %-)
    Есть два метода. Первый - отладочный вывод на board (макросы из fdo.inc в помощь). Второй - отладчик Bochs (bochsdbg.exe), я пользуюсь именно им.
  • Что действительно не помешало бы сделать, так это возможность создания нескольких окон для каждого приложения. Чем отличается регион от окна – тем, что ядро рисует скин по краям окна. Но это не всегда, только если приложение само попросит. Можно ведь создать окно и без всяких рамок.

    А так пусть у каждого приложения будет одно окно по умолчанию, а при необходимости оно сможет создать дополнительные. При оконных событиях, в каком либо регистре будет дополнительно передаваться дескриптор окна. Старые приложения имеют только одно окно, и им этот новый параметр будет не нужен, но и не помешает. Только для рисования понадобятся новые функции, которые будут рисовать в конкретное окно. Старые же функции, как и раньше, будут рисовать в главное окно приложения

    И уже потом от нечего делать можно будет вынести всё это добро в дллку, вместо размещения в ядре
  • Так и при текущем API это можно сделать. Просто создавать дополнительные потоки: каждый поток имеет своё окно.
  • diamond
    В текущем ядре тратится память для окна, даже если его нет. Здесь предполагается экономия памяти или я чего-то недопонял.
  • Sаsh

    %) та не, так сложнее будет. Хранить отдельно окна по умолчанию, дополнительные окна.... моя идея заключалась в том чтоб разделить приложения и окна. Может быть много программ, которым окна и подавно не нужны (демоны разные). да, не спорю, так бы совместимость оставалась...хотя...я еще подумаю, возможно неплохая идея.....но все равно, это только тормозов добавит, едва заметных, но там по чуть-чуть, там по чуть-чуть.....

    diamond

    точно, а я и забыл что у Bochs есть отладчик. Вот только думаю проблем не будет??? Просто я пускал колибри в bochs, впринципе все ок, вот только приложения которые с таймером работали(pipes и еще какие-то), работали не правильно, таймер быстро тикал....возможно его обновить нужно, у тя проблем с таймером нет???
  • У меня проблемы с таймером есть. Еще в Bochs очень медленный вывод растра (как в QEmu не знаю, а вот в VMware все летает).
    Нужна именно оконная система, а регионов и пр. У оконных объектов (кнопки все пр.) должны быть родители и дочернии объекты, так же хозяева и пр. атрибуты. При обновлении состояния экрана, должно требоваться обновление (перерисовка) только тех объектов которые в этом нуждаются и только тех участков объектов которые были затронуты (т.е. должны быть регионы для контроля перерисовки, вот уже и ничего не мерцает). Должен быть один API для вывода геометрии (и контекст устройств, пусть хотя бы один дисплей пока работает). Так же работа клавиатуры и мыши тоже относятся к GUI (и оконной системе). Т.е. мышь монопольно используется оконным объектом, а не регионом :-).
    Заметьте, я не говорил кто должен заниматься самой отрисовкой (так это на самом деле второстепенный вопрос). И не думаю что сейчас на этом стоит делать акцент. Пусть система позволяет пользователю использовать своё стилевое оформление оконного объекта, но она точно не должна запрещать приложению контролировать визуальную поверхность всего окна (а так же хотелось бы что бы окна могли иметь произвольную форму, т.е. занимаемая ими поверхность вывода определеялась регионом, а не прямоугольником).

    ..bw
  • Who is online

    Users browsing this forum: No registered users and 5 guests