Соображения по поводу GUI

Kernel-side graphics support
  • м-да.....согласен...да не подумал что может быть 10 окон по 100 компонентов (и того больше)
    а насчет специальных вызовов, зачем? все работает как с обычными кнопками, ядро только событие возвращает клик по компоненте с id таким-то или мышь зашла/ушла на/с компонеты с таким-то id.....но уже неважно

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

    Ничего не решили. Для этого надо весь GUI переписать и ещё добрую часть ядра. Или не добрую :(
  • Полностью поддерживаю идею выноса 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 реально доказано что работает.
  • Who is online

    Users browsing this forum: No registered users and 5 guests