Board.KolibriOS.org

Official KolibriOS board
It is currently Wed May 22, 2019 7:59 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 19 posts ]  Go to page Previous 1 2
Author Message
 Post subject:
PostPosted: Fri Feb 23, 2007 7:07 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Все эти внутриядерные объекты сплошное мучение. Создаст программа кучу таких компонентов а потом упадёт ядро должно все эти компоненты убрать. Они располагаются в памяти ядра значит прямого доступа к ним у программ нет надо делать специальные вызовы. Те кнопки что сейчас есть в ядре остались от МеОС и нужны для совместимости со старыми программами и число их ограничено.


Top
   
 Post subject:
PostPosted: Mon Feb 26, 2007 6:40 pm 
Offline

Joined: Wed Feb 21, 2007 3:03 pm
Posts: 188
м-да.....согласен...да не подумал что может быть 10 окон по 100 компонентов (и того больше)
а насчет специальных вызовов, зачем? все работает как с обычными кнопками, ядро только событие возвращает клик по компоненте с id таким-то или мышь зашла/ушла на/с компонеты с таким-то id.....но уже неважно

тут где-то вопрос пролетал, насчет нескольких окон для приложения....как продвигается? или решили что не нужно?


Top
   
 Post subject:
PostPosted: Mon Feb 26, 2007 7:45 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
>ут где-то вопрос пролетал, насчет нескольких окон для приложения....как продвигается? или решили что не нужно?

Ничего не решили. Для этого надо весь GUI переписать и ещё добрую часть ядра. Или не добрую :(


Top
   
 Post subject:
PostPosted: Tue Apr 03, 2007 3:36 pm 
Offline

Joined: Thu Dec 21, 2006 10:51 am
Posts: 88
Полностью поддерживаю идею выноса GUI из ядра системы. Я считаю что ядро системы должно предоставлять только базовые функции по управлению аппаратурой, проще горворя реализовыать нечтно на подобие GDI Windows но только без реализаций виджетов (конторлов).

Думаю что эта штука должна работать сл. образом

Обеспечивать ввод в виртуальной системе координат (как в драйвере мыши), т.е. допустим есть матрица (виртуальный
экран) размером скажем 800Х600. Интерфейсные функции позволяют рисовать точки, линии и т.д. в координатах этой
матрицы, т.е. заполнять ее, затем GUI из ядра осуществляет пересчет в координаты которые использует оборудование и
выводит это все на экран. (В общем походу это так и делается). Обновление реального экрана осуществляет демон
(фоновый процесс, служба ...) через некоторое незначительное время, или по команде - функции API . Все это
естественно лучше делать в асме.

Все остальное реализует некий GUI API, который естесвенно проще и лучше реализовать скажем на С++ и положить в
некие DLL что бы все могли юзать в своих программах. Доустим для создания скажем кнопки достаточно было бы вызвать
некоторую функцию или макрос типа void pascal createButton(int left, int top, int width, int height, char *caption, Image img);
Чтоб остаться в приделах дискеты (хотя ИМХО, последний завод в мире по производству дискет 3.5 уже закрыт с чем и
поздравляю вас товарищи) все это API можно запаковать, а программа обращающаяся к каким то из частей API
распаковывает и кладет в некую tempdll директорию, естестно предварительно проверив нет ли такой либы уже там.

Какое это преимущество дает перед GUI намертво зашитым в ядро? Очевидно что следующие:

1. Относительная независимость от оборудования прикладных программ.
2. Возможность создания нескольких видов Шелов с GUI, например Light GUI Shell или Full Power GUI Shell основанных
на разных GUI API. Первая из которых допустим написанна на ASM вторая на C++.

Недостатки

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

Все это должно снизить общую производительность системы (хотя нахрен кому нужна сверхпроизводительность если
нет должной функциональности, кстати за что я и уважаю минуэт и колибри в частности так это за должный уровень
функциональности при минимальном размере но до действительно полезной системы еще очень далеко допустим нет
ODBC и вобще каких либо средств для нормальной работы с БД, нет ни COM ни CORBA и RPC и т.д. ...).

Короче идея эта не новая, подсказаная сервером XWindow и GDI Windows реально доказано что работает.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 19 posts ]  Go to page Previous 1 2

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited