Page 1 of 3

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

Posted: Wed Mar 28, 2007 12:45 pm
by k@sTIg@r
Решился переписать оконную систему на что-то вроде. Ядро про само окно ничего знать не будет, будут так называемые регионы.
То есть ядро будет выделять прямоугольную область на которой можно будет рисовать. Эту область можно будет разворачивать на весь экран, сворачивать, с помощью функций ядра перемещать и изменять размеры "региона", а также по клику мыши делать область активной. Плюс ко всему этому: область привязана к приложению не 1 к 1, то есть одно приложение сможет создать несколько регионов, а значит сразу получим выпадающие меню, алерты, tips, модальные окна и т.д. А также уровни, 3 уровня (ниже всех, нормальное, выше всех).
Преимуществ достаточно. Минусы: полная не совместимость!!!!

Столкнулся с проблемами. В идеале вижу так. Есть библиотека(возможно несколько), которая содержит в себе оконный менеджер(собсно и скины) и основные компоненты(алерты, меню, кнопки и т.п.). Так же эта библиотека отвечает за минимизирование, максимизирование, закрытие, перемещение и ресайзинг окон.
1) как реализовать библиотеку? в виде DLL??? думаю тяжело будет, dll сейчас на низком уровне, если каждое приложение будет такую библиотеку загружать......В идеале конечно DLL будет (я надеюсь) загружаться один раз, тогда можно будет просто загрузить либу при старте и пусть весит... думал еще про драйвер, но что-то не нравится мне эта идея....
2) рисование в этой области. Реализовывать примитивы??? функций не напасешся (тут тебе и точка и линия, прямоугольник, круг/овал/дуга, многоугольники и прочая гадость). Вообщем работа с графикой не мой конек, поэтому и прошу помощь.

К чему я это все. Реализовывать только начал, и понял, что пока не будет картины в целом продолжать бессмыслено, поэтому советуюсь. На самом деле мне все равно примет ли это сообщество, я в любом случае буду продолжать (для себя), но все же вопрос, стоит ли оконный менеджер выносить из ядра??? Почему я считаю что нужно... графика это дело такое, поэтому если ченить упадет, то подвесится ядро, собственно вся система. Система регионов слишком примитивна чтоб упасть, поэтому если вешается либа, то всегда есть Ctrl+Alt+Del который вызовет приложение(тот же CPU) которому плевать на все либы(сам по себе), а через него что надо убить/перегрузить...

Posted: Wed Mar 28, 2007 1:37 pm
by Serge
>Преимуществ достаточно. Минусы: полная не совместимость!!!!

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

>стоит ли оконный менеджер выносить из ядра???
Надо определиться чем занимается оконный менеджер. ИМХО он должен только управлять областями на экране и быть частью ядра,а все элементы управления должна делать user mode ДЛЛ, как libGUI. Расшаренные ДЛЛ будут, всему своё время.

Posted: Wed Mar 28, 2007 2:19 pm
by k@sTIg@r
Serge wrote: Переписывать все программы на новый GUI никто не кинется.
Я это прекрасно понимаю. А что делать? тянуть тяжелое бремя менуэта за собой? На самом деле программ не так уж и много, чтобы оставить совместимость, да и то, никто ж не говорит о глобальных изменениях. Если программа составлена грамотно, где достаточно отделена графика от самой логики, то переписывание не составит особого труда.
Serge wrote: Делать поддержку для старых программ всё равно придётся.
к сожалению да...хм...а что если в виде эмулятора???
Serge wrote: ИМХО он должен только управлять областями на экране и быть частью ядра,а все элементы управления должна делать user mode ДЛЛ, как libGUI.
да-да-да, я про то же (если к элементам управления отнести заголовок, границы окна и т.п.)

Просто я себе представить не могу, как реализовать рисование в этих областях :(

Posted: Wed Mar 28, 2007 3:25 pm
by Mario79
k@sTIg@r
Идея хорошая, но возникает вопрос со скоростью - если будет сильная потеря скорости, то ИМХО овчинка выделки не стоит. А так можно все переписать. Главное начать - покажи первый результат, тем более ты все равно будешь делать - а это очень хорошо, учитывая разброд мнений пользователей данного форума.
Если существенных потерь скорости не будет (Linux в этом плане не лучший пример), то я одним из первых перепишу свой KFM под новую систему.

Posted: Wed Mar 28, 2007 3:33 pm
by Serge
Потерь скорости быть не должно, а вот программ не так и мало. Если собрался делать оконную систему то стоит начать с десктоп менеджера. Собрать вместе Icon, Panel, Rb (меню на правой кнопке мыши) в одну программу и добывить туда переключение окон по Alt-Tab

Posted: Wed Mar 28, 2007 3:53 pm
by Mario79
Serge
Собрать вместе Icon, Panel, Rb (меню на правой кнопке мыши) в одну программу
ИМХО вот как раз этого делать не надо - печальный пример Винда: слетел Explorer и все облом, по крайней мере, в 9х.
А вот Alt+Tab действительно нужная вещь.

Posted: Wed Mar 28, 2007 3:58 pm
by k@sTIg@r
Насчет потерь в скорости - ничего не скажу, так как не знаю. Теоретически не должно, т.к. всего лишь выносятся оконные элементы. Правда потеря может случится из-за мультиоконности, т.к. до конца не продумал события. Ясно что события нажатие клавиши, мышь, перерисовка будут идти именно окну, а приложение будет проверять уже не свои события, а события окна(доп. параметр в теперешних функциях). А вот остальные события (IPC, сетвое событие, отладочное событие, IRQs) по идее нужно слать именно приложению, т.к. они ни каким макаром не связаны с окном. Разве что оставить как есть, только задача приложения, в дополнение, определить какому из его окон(точнее областей) пришло событие....

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

PS еще вопрос. Как можно дебажить ядро %-)

Posted: Wed Mar 28, 2007 4:05 pm
by k@sTIg@r
ИМХО вот как раз этого делать не надо - печальный пример Винда: слетел Explorer и все облом, по крайней мере, в 9х.
Почему??? В винде действительно дебильная система. То что предлагает Serge не одно и тоже.
Desktop Manager сам по себе, остальные приложения сами по себе. И пусть они себе слетают, десктоп манеджер будет жить пока сам по себе не слетит(мало ли, идеального софта не бывает).

Posted: Wed Mar 28, 2007 5:08 pm
by Serge
Mario79

А чем плох такой менеджер ? Разве это дело держать отдельный поток для каждой иконки ? В 9х действительно облом а в ХР падал несколько раз и сразу автоматом перезапускался. Прямо сервер реинкарнаций из Minix. Такую вещь можно и для Колибри сделать

Posted: Wed Mar 28, 2007 7:52 pm
by diamond
k@sTIg@r wrote:PS еще вопрос. Как можно дебажить ядро %-)
Есть два метода. Первый - отладочный вывод на board (макросы из fdo.inc в помощь). Второй - отладчик Bochs (bochsdbg.exe), я пользуюсь именно им.

Posted: Wed Mar 28, 2007 8:17 pm
by Sаsh
Что действительно не помешало бы сделать, так это возможность создания нескольких окон для каждого приложения. Чем отличается регион от окна – тем, что ядро рисует скин по краям окна. Но это не всегда, только если приложение само попросит. Можно ведь создать окно и без всяких рамок.

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

И уже потом от нечего делать можно будет вынести всё это добро в дллку, вместо размещения в ядре

Posted: Wed Mar 28, 2007 8:38 pm
by diamond
Так и при текущем API это можно сделать. Просто создавать дополнительные потоки: каждый поток имеет своё окно.

Posted: Thu Mar 29, 2007 7:20 am
by Mario79
diamond
В текущем ядре тратится память для окна, даже если его нет. Здесь предполагается экономия памяти или я чего-то недопонял.

Posted: Thu Mar 29, 2007 9:42 am
by k@sTIg@r
Sаsh

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

diamond

точно, а я и забыл что у Bochs есть отладчик. Вот только думаю проблем не будет??? Просто я пускал колибри в bochs, впринципе все ок, вот только приложения которые с таймером работали(pipes и еще какие-то), работали не правильно, таймер быстро тикал....возможно его обновить нужно, у тя проблем с таймером нет???

Posted: Thu Mar 29, 2007 10:20 am
by bw
У меня проблемы с таймером есть. Еще в Bochs очень медленный вывод растра (как в QEmu не знаю, а вот в VMware все летает).
Нужна именно оконная система, а регионов и пр. У оконных объектов (кнопки все пр.) должны быть родители и дочернии объекты, так же хозяева и пр. атрибуты. При обновлении состояния экрана, должно требоваться обновление (перерисовка) только тех объектов которые в этом нуждаются и только тех участков объектов которые были затронуты (т.е. должны быть регионы для контроля перерисовки, вот уже и ничего не мерцает). Должен быть один API для вывода геометрии (и контекст устройств, пусть хотя бы один дисплей пока работает). Так же работа клавиатуры и мыши тоже относятся к GUI (и оконной системе). Т.е. мышь монопольно используется оконным объектом, а не регионом :-).
Заметьте, я не говорил кто должен заниматься самой отрисовкой (так это на самом деле второстепенный вопрос). И не думаю что сейчас на этом стоит делать акцент. Пусть система позволяет пользователю использовать своё стилевое оформление оконного объекта, но она точно не должна запрещать приложению контролировать визуальную поверхность всего окна (а так же хотелось бы что бы окна могли иметь произвольную форму, т.е. занимаемая ими поверхность вывода определеялась регионом, а не прямоугольником).

..bw