Решился переписать оконную систему на что-то вроде. Ядро про само окно ничего знать не будет, будут так называемые регионы.
То есть ядро будет выделять прямоугольную область на которой можно будет рисовать. Эту область можно будет разворачивать на весь экран, сворачивать, с помощью функций ядра перемещать и изменять размеры "региона", а также по клику мыши делать область активной. Плюс ко всему этому: область привязана к приложению не 1 к 1, то есть одно приложение сможет создать несколько регионов, а значит сразу получим выпадающие меню, алерты, tips, модальные окна и т.д. А также уровни, 3 уровня (ниже всех, нормальное, выше всех).
Преимуществ достаточно. Минусы: полная не совместимость!!!!
Столкнулся с проблемами. В идеале вижу так. Есть библиотека(возможно несколько), которая содержит в себе оконный менеджер(собсно и скины) и основные компоненты(алерты, меню, кнопки и т.п.). Так же эта библиотека отвечает за минимизирование, максимизирование, закрытие, перемещение и ресайзинг окон.
1) как реализовать библиотеку? в виде DLL??? думаю тяжело будет, dll сейчас на низком уровне, если каждое приложение будет такую библиотеку загружать......В идеале конечно DLL будет (я надеюсь) загружаться один раз, тогда можно будет просто загрузить либу при старте и пусть весит... думал еще про драйвер, но что-то не нравится мне эта идея....
2) рисование в этой области. Реализовывать примитивы??? функций не напасешся (тут тебе и точка и линия, прямоугольник, круг/овал/дуга, многоугольники и прочая гадость). Вообщем работа с графикой не мой конек, поэтому и прошу помощь.
К чему я это все. Реализовывать только начал, и понял, что пока не будет картины в целом продолжать бессмыслено, поэтому советуюсь. На самом деле мне все равно примет ли это сообщество, я в любом случае буду продолжать (для себя), но все же вопрос, стоит ли оконный менеджер выносить из ядра??? Почему я считаю что нужно... графика это дело такое, поэтому если ченить упадет, то подвесится ядро, собственно вся система. Система регионов слишком примитивна чтоб упасть, поэтому если вешается либа, то всегда есть Ctrl+Alt+Del который вызовет приложение(тот же CPU) которому плевать на все либы(сам по себе), а через него что надо убить/перегрузить...
переделать оконную систему...
>Преимуществ достаточно. Минусы: полная не совместимость!!!!
Этот минус перекрывает все большие плюсы. Переписывать все программы на новый GUI никто не кинется. Так что даже тестить неначем будет. Делать поддержку для старых программ всё равно придётся.
>стоит ли оконный менеджер выносить из ядра???
Надо определиться чем занимается оконный менеджер. ИМХО он должен только управлять областями на экране и быть частью ядра,а все элементы управления должна делать user mode ДЛЛ, как libGUI. Расшаренные ДЛЛ будут, всему своё время.
Этот минус перекрывает все большие плюсы. Переписывать все программы на новый GUI никто не кинется. Так что даже тестить неначем будет. Делать поддержку для старых программ всё равно придётся.
>стоит ли оконный менеджер выносить из ядра???
Надо определиться чем занимается оконный менеджер. ИМХО он должен только управлять областями на экране и быть частью ядра,а все элементы управления должна делать user mode ДЛЛ, как libGUI. Расшаренные ДЛЛ будут, всему своё время.
Я это прекрасно понимаю. А что делать? тянуть тяжелое бремя менуэта за собой? На самом деле программ не так уж и много, чтобы оставить совместимость, да и то, никто ж не говорит о глобальных изменениях. Если программа составлена грамотно, где достаточно отделена графика от самой логики, то переписывание не составит особого труда.Serge wrote: Переписывать все программы на новый GUI никто не кинется.
к сожалению да...хм...а что если в виде эмулятора???Serge wrote: Делать поддержку для старых программ всё равно придётся.
да-да-да, я про то же (если к элементам управления отнести заголовок, границы окна и т.п.)Serge wrote: ИМХО он должен только управлять областями на экране и быть частью ядра,а все элементы управления должна делать user mode ДЛЛ, как libGUI.
Просто я себе представить не могу, как реализовать рисование в этих областях
k@sTIg@r
Идея хорошая, но возникает вопрос со скоростью - если будет сильная потеря скорости, то ИМХО овчинка выделки не стоит. А так можно все переписать. Главное начать - покажи первый результат, тем более ты все равно будешь делать - а это очень хорошо, учитывая разброд мнений пользователей данного форума.
Если существенных потерь скорости не будет (Linux в этом плане не лучший пример), то я одним из первых перепишу свой KFM под новую систему.
Идея хорошая, но возникает вопрос со скоростью - если будет сильная потеря скорости, то ИМХО овчинка выделки не стоит. А так можно все переписать. Главное начать - покажи первый результат, тем более ты все равно будешь делать - а это очень хорошо, учитывая разброд мнений пользователей данного форума.
Если существенных потерь скорости не будет (Linux в этом плане не лучший пример), то я одним из первых перепишу свой KFM под новую систему.
Потерь скорости быть не должно, а вот программ не так и мало. Если собрался делать оконную систему то стоит начать с десктоп менеджера. Собрать вместе Icon, Panel, Rb (меню на правой кнопке мыши) в одну программу и добывить туда переключение окон по Alt-Tab
Serge
А вот Alt+Tab действительно нужная вещь.
ИМХО вот как раз этого делать не надо - печальный пример Винда: слетел Explorer и все облом, по крайней мере, в 9х.Собрать вместе Icon, Panel, Rb (меню на правой кнопке мыши) в одну программу
А вот Alt+Tab действительно нужная вещь.
Насчет потерь в скорости - ничего не скажу, так как не знаю. Теоретически не должно, т.к. всего лишь выносятся оконные элементы. Правда потеря может случится из-за мультиоконности, т.к. до конца не продумал события. Ясно что события нажатие клавиши, мышь, перерисовка будут идти именно окну, а приложение будет проверять уже не свои события, а события окна(доп. параметр в теперешних функциях). А вот остальные события (IPC, сетвое событие, отладочное событие, IRQs) по идее нужно слать именно приложению, т.к. они ни каким макаром не связаны с окном. Разве что оставить как есть, только задача приложения, в дополнение, определить какому из его окон(точнее областей) пришло событие....
Я и думал начинать с десктоп менеджера, для начала хотябы простого. То есть приложение, которое создаст 2 области. Одно фон с иконками(ниже всех), другое панель(выше всех).
Но опять же повторюсь, как реализовать рисование в этих регионах, я понятия не имею. Вот от этого вопроса и будет зависить скорость работы. Если сейчас само окно, без клиентской области, рисовалось в ядре, то сейчас это будет делать пользовательское приложение....
Вобщем, сначала реализую первые шаги, а потом может кто подключится по поводу "рисования в областях"
PS еще вопрос. Как можно дебажить ядро %-)
Я и думал начинать с десктоп менеджера, для начала хотябы простого. То есть приложение, которое создаст 2 области. Одно фон с иконками(ниже всех), другое панель(выше всех).
Но опять же повторюсь, как реализовать рисование в этих регионах, я понятия не имею. Вот от этого вопроса и будет зависить скорость работы. Если сейчас само окно, без клиентской области, рисовалось в ядре, то сейчас это будет делать пользовательское приложение....
Вобщем, сначала реализую первые шаги, а потом может кто подключится по поводу "рисования в областях"
PS еще вопрос. Как можно дебажить ядро %-)
Почему??? В винде действительно дебильная система. То что предлагает Serge не одно и тоже.ИМХО вот как раз этого делать не надо - печальный пример Винда: слетел Explorer и все облом, по крайней мере, в 9х.
Desktop Manager сам по себе, остальные приложения сами по себе. И пусть они себе слетают, десктоп манеджер будет жить пока сам по себе не слетит(мало ли, идеального софта не бывает).
Mario79
А чем плох такой менеджер ? Разве это дело держать отдельный поток для каждой иконки ? В 9х действительно облом а в ХР падал несколько раз и сразу автоматом перезапускался. Прямо сервер реинкарнаций из Minix. Такую вещь можно и для Колибри сделать
А чем плох такой менеджер ? Разве это дело держать отдельный поток для каждой иконки ? В 9х действительно облом а в ХР падал несколько раз и сразу автоматом перезапускался. Прямо сервер реинкарнаций из Minix. Такую вещь можно и для Колибри сделать
Есть два метода. Первый - отладочный вывод на board (макросы из fdo.inc в помощь). Второй - отладчик Bochs (bochsdbg.exe), я пользуюсь именно им.k@sTIg@r wrote:PS еще вопрос. Как можно дебажить ядро %-)
Что действительно не помешало бы сделать, так это возможность создания нескольких окон для каждого приложения. Чем отличается регион от окна – тем, что ядро рисует скин по краям окна. Но это не всегда, только если приложение само попросит. Можно ведь создать окно и без всяких рамок.
А так пусть у каждого приложения будет одно окно по умолчанию, а при необходимости оно сможет создать дополнительные. При оконных событиях, в каком либо регистре будет дополнительно передаваться дескриптор окна. Старые приложения имеют только одно окно, и им этот новый параметр будет не нужен, но и не помешает. Только для рисования понадобятся новые функции, которые будут рисовать в конкретное окно. Старые же функции, как и раньше, будут рисовать в главное окно приложения
И уже потом от нечего делать можно будет вынести всё это добро в дллку, вместо размещения в ядре
А так пусть у каждого приложения будет одно окно по умолчанию, а при необходимости оно сможет создать дополнительные. При оконных событиях, в каком либо регистре будет дополнительно передаваться дескриптор окна. Старые приложения имеют только одно окно, и им этот новый параметр будет не нужен, но и не помешает. Только для рисования понадобятся новые функции, которые будут рисовать в конкретное окно. Старые же функции, как и раньше, будут рисовать в главное окно приложения
И уже потом от нечего делать можно будет вынести всё это добро в дллку, вместо размещения в ядре
Так и при текущем API это можно сделать. Просто создавать дополнительные потоки: каждый поток имеет своё окно.
diamond
В текущем ядре тратится память для окна, даже если его нет. Здесь предполагается экономия памяти или я чего-то недопонял.
В текущем ядре тратится память для окна, даже если его нет. Здесь предполагается экономия памяти или я чего-то недопонял.
Sаsh
%) та не, так сложнее будет. Хранить отдельно окна по умолчанию, дополнительные окна.... моя идея заключалась в том чтоб разделить приложения и окна. Может быть много программ, которым окна и подавно не нужны (демоны разные). да, не спорю, так бы совместимость оставалась...хотя...я еще подумаю, возможно неплохая идея.....но все равно, это только тормозов добавит, едва заметных, но там по чуть-чуть, там по чуть-чуть.....
diamond
точно, а я и забыл что у Bochs есть отладчик. Вот только думаю проблем не будет??? Просто я пускал колибри в bochs, впринципе все ок, вот только приложения которые с таймером работали(pipes и еще какие-то), работали не правильно, таймер быстро тикал....возможно его обновить нужно, у тя проблем с таймером нет???
%) та не, так сложнее будет. Хранить отдельно окна по умолчанию, дополнительные окна.... моя идея заключалась в том чтоб разделить приложения и окна. Может быть много программ, которым окна и подавно не нужны (демоны разные). да, не спорю, так бы совместимость оставалась...хотя...я еще подумаю, возможно неплохая идея.....но все равно, это только тормозов добавит, едва заметных, но там по чуть-чуть, там по чуть-чуть.....
diamond
точно, а я и забыл что у Bochs есть отладчик. Вот только думаю проблем не будет??? Просто я пускал колибри в bochs, впринципе все ок, вот только приложения которые с таймером работали(pipes и еще какие-то), работали не правильно, таймер быстро тикал....возможно его обновить нужно, у тя проблем с таймером нет???
У меня проблемы с таймером есть. Еще в Bochs очень медленный вывод растра (как в QEmu не знаю, а вот в VMware все летает).
Нужна именно оконная система, а регионов и пр. У оконных объектов (кнопки все пр.) должны быть родители и дочернии объекты, так же хозяева и пр. атрибуты. При обновлении состояния экрана, должно требоваться обновление (перерисовка) только тех объектов которые в этом нуждаются и только тех участков объектов которые были затронуты (т.е. должны быть регионы для контроля перерисовки, вот уже и ничего не мерцает). Должен быть один API для вывода геометрии (и контекст устройств, пусть хотя бы один дисплей пока работает). Так же работа клавиатуры и мыши тоже относятся к GUI (и оконной системе). Т.е. мышь монопольно используется оконным объектом, а не регионом .
Заметьте, я не говорил кто должен заниматься самой отрисовкой (так это на самом деле второстепенный вопрос). И не думаю что сейчас на этом стоит делать акцент. Пусть система позволяет пользователю использовать своё стилевое оформление оконного объекта, но она точно не должна запрещать приложению контролировать визуальную поверхность всего окна (а так же хотелось бы что бы окна могли иметь произвольную форму, т.е. занимаемая ими поверхность вывода определеялась регионом, а не прямоугольником).
..bw
Нужна именно оконная система, а регионов и пр. У оконных объектов (кнопки все пр.) должны быть родители и дочернии объекты, так же хозяева и пр. атрибуты. При обновлении состояния экрана, должно требоваться обновление (перерисовка) только тех объектов которые в этом нуждаются и только тех участков объектов которые были затронуты (т.е. должны быть регионы для контроля перерисовки, вот уже и ничего не мерцает). Должен быть один API для вывода геометрии (и контекст устройств, пусть хотя бы один дисплей пока работает). Так же работа клавиатуры и мыши тоже относятся к GUI (и оконной системе). Т.е. мышь монопольно используется оконным объектом, а не регионом .
Заметьте, я не говорил кто должен заниматься самой отрисовкой (так это на самом деле второстепенный вопрос). И не думаю что сейчас на этом стоит делать акцент. Пусть система позволяет пользователю использовать своё стилевое оформление оконного объекта, но она точно не должна запрещать приложению контролировать визуальную поверхность всего окна (а так же хотелось бы что бы окна могли иметь произвольную форму, т.е. занимаемая ими поверхность вывода определеялась регионом, а не прямоугольником).
..bw
Who is online
Users browsing this forum: No registered users and 1 guest