Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Сб июн 24, 2017 8:24 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 19 сообщений ]  На страницу 1 2 След.
Автор Сообщение
 Заголовок сообщения: Соображения по поводу GUI
СообщениеДобавлено: Пн фев 19, 2007 12:04 pm 
Не в сети

Зарегистрирован: Чт фев 08, 2007 10:17 am
Сообщения: 54
Позвольте мне опять высказать свои соображания :-)

GUI на мой взгляд это одно из самых узких мест любой системы (причем я думаю мало кто будет возражать)

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

Посему предлагаю вынести GUI за пределы ядра, оставив только основные функции работы с графикой, типа "создать графическое окно размерами такими и такими" и минимум графических функций по созданию примитивов, таких как нарисовать пиксел, линию, треугольник +низкоуровневыйOpenGL и т.п.
Тогда GUI можно оформить как отдельную библиотеку исходников или сделать GUI Server/Driver
А любители творить своими руками могут сами написать что им нужно не используя ни то ни другое.

P.S.
Если назвать выше изложенные причины граблями :-) то Windows наступила на грабли описанные под номером 2. Она сначала начала неимоверно усложнила GUI на "уровне ядра", тем самым потеряв быстродействие системы, а затем начала обходить свои навароты за счет DirectX и т.п. тем самым более усложняя систему.

Ваше мнение ???


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 12:17 pm 
w-tools
Цитата:
Посему предлагаю вынести GUI за пределы ядра, оставив только основные функции работы с графикой, типа "создать графическое окно размерами такими и такими" и минимум графических функций по созданию примитивов, таких как нарисовать пиксел, линию, треугольник +низкоуровневыйOpenGL и т.п.

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


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 12:22 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
w-tools
Опоздал :) Уже предлагалось и немного обсуждалось. Есть небольшие наработки. Всё упирается в недоделанные события.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 12:25 pm 
Не в сети
Kernel Optimizer
Аватара пользователя

Зарегистрирован: Пн янв 16, 2006 7:58 pm
Сообщения: 657
На сегодня уже реализованы разлиные GUI компоненты:
edit_box
check_box
radio_button
....
Все они используют минимум фунций ядра:
Нарисовать полосу, нарисововать линию, нарисовать точку. Все остальное они реализуют самостоятельно.
Для использования этих компонентов достаточно добавить в код своей программы вызовы этих компонентов.
Я не против, что бы сделать библиотеку с этитими функциями и предоставлять любой программе работать с этими компонентами.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 1:15 pm 
Не в сети

Зарегистрирован: Ср май 18, 2005 7:27 pm
Сообщения: 1001
Andrew_programmer тоже какие-то компоненты ваяет.


Последний раз редактировалось Wildwest Пн фев 19, 2007 1:26 pm, всего редактировалось 1 раз.

Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 1:19 pm 
Не в сети

Зарегистрирован: Чт фев 08, 2007 10:17 am
Сообщения: 54
Товарисчи !!! Товарисчи !!!

Я просто "подбиваю" начать параллельно еще один но "микроядерный проект", а Колибри использовать как платформу для отладки и эксперементов не трогая ее сущности. Проблема в том что на данном этапе я еще не совсем въехал в тонкости защищенного режима i386, посему не могу организовать грамотный менеджер задач!!!
Если микроядерный проект 'пойдет' это будет ГУД !!!


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 2:21 pm 
Не в сети
Kernel Optimizer
Аватара пользователя

Зарегистрирован: Пн янв 16, 2006 7:58 pm
Сообщения: 657
Это хорошая идея, но программистов, хорошо знающих тонкости защищенного режима i386 не так много, к тому же у остальных не так много времени. Эта основная проблема. Каждый прилагает все усилия чтобы улучшить ту или иную часть кода программ, ядра и т.д. Если тебе нужно мое согласие на жизнь этого проекта, я за, но я совершенно не знаю что и как нужно делать + у меня не так много времени на это.
Скорее всего тебе придется начать этот проект самостоятельно, и если ты сам не разочаруешься, к тебе начнут присоединяться люди, которые будут улучшать и дописывать код.
Надеюсь на твое понимание, но сейчас я, как и многие помочь тебе не сможем.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 2:56 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
w-tools
Колибри давно нуждется в хорошем планировщике задач. Сейчас все процессы организованы в простое кольцо, кажется такая схема называется round-robin. Вся работа планировщика сводится к тому чтобы не передавать управление потоку для которого нет событий (поток блокируется sys_waitforevent() )
Планировщики обсуждались в одном из форумов sysbin.com и там упоминался алгоритм адаптивных приоритетов разновидность которого есть в NT. В QNX реализовано три разных планировщика, которые может выбирать программа, ясно что не от хорошей жизни.
Если у тебя есть идеи на этот счёт то они могли бы очень пригодиться.

P.S.
Начинать новый микроядерный проект просто некому. Плотно ядром занимаются всего два человека и оба заняты. А сущность Колибри в том что она постоянно меняется и микроядерные идеи этой сущности совсем не противоречат. Многие идеи можно реализовать не вникая в защищённый режим, достаточно знания команд общего назначения.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 5:12 pm 
Не в сети

Зарегистрирован: Чт фев 08, 2007 10:17 am
Сообщения: 54
Serge
Я планировал сделать планировщик задач следуещего типа (незнаю поможет ли он чем нибудь):

В памяти локализовано сидят приложения и драйвера причем они обсалютно равноправны. В ядре находится обработчик прерывания по таймеру который имеет свою таблицу векторов (адреса перехода) на соответствующие приложения. Любое приложение может зарегитрироваться в этой таблице (через функцию ядра конечно) обрекая себя на выполнения по таймеру в порядке очередности. Так же может поступить любой драйвер (драйвера и приложения равноправны).

В ядре также находиться регистратор аппаратных и программных прерываний. Причем регистратор только регистрирует эти прерывания. Кода в системе происходит какое либо аппаратное или программное прерывание (кроме прерывания от таймера) Регистратор смотрит в таблицу и передает управление по этой таблице. В таблице размещены вектора на зарегистрированные в ядре драйвера. Любое приложение или драйвер могут застолбить(зарегистрироваться) в этой таблице указывая переход на себя, или наоборот освободить этот вектор.

Таким образом получаем двойной механизм переключения задач
Первый механизм - переключение по таймеру
Второй механизм - переключение по прерываниям
Естественно по приоритету выполнения второй механизм будет выше, такак он будет прерывать выполнение задач по таймеру и кратковременно передавать управление на драйверы. Драйверы будут заполнять/очищать соответствующие буферы (описанные в предыдущих постах).

Таково поверхностное описание механизма переключения задач, конечно это планировалось под микроядро + куча всяких драйверов и приложений.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 7:56 pm 
Не в сети

Зарегистрирован: Пн май 01, 2006 10:12 pm
Сообщения: 349
Из сказанного тобой не вижу разницы между приложениями и драйверами (разве что только по выполняемым функциям...).
Я думал, что планировщик занимается только планированием времени процессора.
И в общем эта модель напоминает что-то до боли знакомое...


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 8:42 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
w-tools
Первое в Колибри уже реализовано и второе тоже. Обработка проерываний от клавиатуры и AC97 идёт подобным образом. При желании можно сделать каскадный вызов обработчиков если это расшаренное PCI прерывание. Пока установливать обработчики можно только для кода в памяти ядра но в принципе можно сделать и для приложений. Сама схема заимствована из документации по QNX с неизбежной адаптацией.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пн фев 19, 2007 10:23 pm 
ниосилил... про меос/коос (были такие времена...) были такие случаи... какой-то конкурс на котором один человек выдал себя за осеписателя, хотя там исходники были кооси/меоси, но без гуи... про вынесения вроде кто-то высказался, но... про простую функцию вывода точки или линии... ее же тоже можно ускорить! т.е. простые ф-ии будут ссылаться на "драйвер"... а так выносить можно до бесконечности...


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Вт фев 20, 2007 8:06 pm 
Не в сети

Зарегистрирован: Чт фев 08, 2007 10:17 am
Сообщения: 54
Victor
Насчет драйверов и приложений ты абсолютно прав, они равнопрвны и между ними принципиалной разници нету. Разница в том, кто-то встает в очередь по таймеру, кто-то цепляется за аппаратные или программные прерывания. Хотя впринципе одно и тоже приложение может прицепиться обоими способами. Замечу что то приложение которое цепляется за программное прерывание может еще через него реализовать какой нибудь свой API. Но все это лиш мое личностное мнение и не более того :-)

Serge
Сама идея выше описанного менеджера памяти/задач, планировщика (кому как удобно пусть так его иназывает) стара как MS-DOS (если не старше :-) ). Просто на старых процессорах в то время не было там всяких шлюзов, симафоров, защиты памяти и т.п. А суть была та-же, тот-же таймер , те-же прерывания и полный творческий беспредел для программиста :-) Так что QNX и прочие системы сдесь непричем :-)

В Колибри нет четкого механизма (ставлю ударение на слово четкий механизм) который реализует самые необходимые функции:

1 - Выделить кусок памяти с двумя свойствами, по другому говоря создать буфер:
а - доступный для всех (+r или +rw)
б - приватный (доступный только для того кто запросил этот кусок)
2 - Обратная функция которая уничтожает выделенный кусок

3 - Пара сервисных функци которые меняют свойства выделенного куска памяти (для удобства программиста)

4 - Запустить выделенный кусок памяти на выполнение (короче создать задачу/поток/нить кому как удобно )
6 - Обратная функция, остановить выполнение куска памяти
7 - Сопутствующие сервисные функции

8 - Зарегистрировать приложение/драйвер в очереди на выполнение по таймеру(проще говоря поставить в очередь, установив вектор)
9 - Обратная функция

10 - Зарегестрировать приложение/драйвер в таблице на аппаратное прерывание (не таймер)
11 - Обратная функция
12 - Функция возврата из задачи (типа Return)

13 - Различные сервисные функции, (для удобства) типа вернуть свободное количество памяти, версю процессора, версию ядра, временно остановить/запустить/перескачить через приложение, и т.п.

Пока в OS не реализованы (и не отпалированы) описанные выше или подобные механизмы, программисты обречены 'чуть что' каждый раз переписывать драйвера и их взаимодействия. Про встроенный GUI на таком этапе вообще нечего говорить, иначе GUI начнет тормозить процесс доводки ядра. А восклицания об обратной совместимости тестовых приложений - это вообще глупо :-)

Теперь о грустном: :-(
Я так понял что реальных помощников для реализации микро ядра на i386 катастрофически нехватает :-) И пока мне не удасться самому детально разобраться совсякими GDT, LDT, TSS и прочими премудростями i386, микроядерный проект обречен :-(


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср фев 21, 2007 5:51 pm 
Не в сети
Kernel Optimizer
Аватара пользователя

Зарегистрирован: Пн янв 16, 2006 7:58 pm
Сообщения: 657
Проект не обречен, он отложен, не вожможно начать что -либо не имея почвы под ногами (знаний в этой области). Если у тебя возникнут вопросы, тебе ответят на этом форуме, но в основном это свободное плавание каждого, и нас всех объединяет одна идея. Начни работу, и ты сам увидишь как начнет меняться все. Помоги себе сам! Только не подумай, что все от тебя отвернулись, я не знаю как тебе помочь!


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Пт фев 23, 2007 6:52 pm 
Не в сети

Зарегистрирован: Ср фев 21, 2007 3:03 pm
Сообщения: 188
А если такая система.
Вот у нас есть элемент кнопка, который обрабатывается ядром. А если нам выкинуть его, а точнее расширить.
Вместо элемента кнопка будет элемент компонент. Вместо одного события сделать 3: mouse_click, mouse over, mouse_out.....или клик расширить на up и down. То есть минимум событий которые обрабатываются ядром.
А все остальное (рисование компонента, расширение событий такие как фокус, потеря фокуса, нажатие клавиши и т.п) берет на себя приложение.
То есть получаем ту же кнопку но с расширеными возможностями ( а ведь тот же чекбокс, радиопедаль и подобные это те же кнопки) мы можем рисовать свое и получать дополнительные события.

А приложение само реализует переключение фокусов, рисование компонентов. Одни компоненты смогут получать фокус по клику, другие при наведении мыши...ну вообщем как фантазия программиста захочет.

Не пинать, а обьяснить почему так лучше не делать. Я конечно еще не разобрался до конца в ядре, но помоему эти 3/4 события висящих на ядре не сделают ничего страшного.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 19 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB