Board.KolibriOS.org
http://board.kolibrios.org/

переделать оконную систему...
http://board.kolibrios.org/viewtopic.php?f=36&t=693
Page 3 of 3

Author:  Mario79 [ Wed Sep 05, 2007 9:34 pm ]
Post subject: 

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

Зачем? Все гораздо проще - запускается приложение, рисует окно и запускает второй поток, который занимается непосредственно архивацией. Обмен между потоками, для получения данных о прогрессе выполняемой операции и о ее завершении осуществляется либо через глобальные переменные, либо через оговоренную область памяти.

Author:  Alver [ Wed Sep 05, 2007 11:17 pm ]
Post subject: 

Mario79
Quote:
Зачем? Все гораздо проще - запускается приложение, рисует окно и запускает второй поток, который занимается непосредственно архивацией.

Это верно, но приложений не использующих второй поток, тоже хватает, сюда же кривые и зависшие проги. Я лично за то чтобы при событии перерисовки окна, имеющего рамки, рамки рисовались ядром, так окно не потеряется. А внутренние обьекты это дело приложения.
Maxis
Quote:
А что если программа(сервер окон) вызывает(один раз) некую системную функцию, которая делает так что бы ядро перенаправляло все события клавиатуры и мыши этому приложению и только ему. Это приложение создает и перемещает окна(или регионы), а так же их перерисовывает через селектор gs. Обычное приложение через IPC создает обьекты этого сервера и получает события от мыши и клавиатуры также через IPC.

ИМХО Возможно через специальное приложение и IPC можно попробовать реализовать такие фишки как перетаскивание обьектов (файлов, текстов и т.п.). Возможно единственное что потребуется от ядра, присваивать специальным программам - системным сервисам фиксированные PIDы, для обращений, ну может улучшить(ускорить) функции IPC.

Author:  Gluk [ Wed Sep 05, 2007 11:33 pm ]
Post subject: 

Alver
Quote:
Это верно, но приложений не использующих второй поток, тоже хватает, сюда же кривые и зависшие проги.

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

Author:  Freeman [ Wed Sep 05, 2007 11:43 pm ]
Post subject: 

Нужно концептуально вынести интерфейс в отдельный поток. Создал окно - получил поток. И сразу все проблемы снимутся. Чем тупо копировать существующие решения, лучше один раз подумать головой.

Author:  bw [ Thu Sep 06, 2007 2:23 am ]
Post subject: 

> И сразу все проблемы снимутся.
Не смеши. Если код приложения кривой, то, например, при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.

Это был оффтом. А по теме я думаю мое мнение известно. Я за то, что бы был отдельный сервер WM и быстрый IPC :-).

..bw

Author:  Mario79 [ Thu Sep 06, 2007 7:22 am ]
Post subject: 

bw
Quote:
при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.

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

Author:  Serge [ Thu Sep 06, 2007 12:02 pm ]
Post subject: 

Maxis

Похожим образом работает Х в *никсах и без особых тормозов.
Видеопамять начинается с 0xFE000000 и у любого приложения есть доступ к этим адресам и без селектора gs.

Кстати в WinXP если программа надолго зависает система прячет её окно и подменяет его своим с такими же характеристиками чтобы пользователь мог его перемещать. В документации оно называется ghost window. Это потому что отрисовка рамок окна и код перемещения и изменения размеров выполняется программой где-то в глубинах DefWindowProc() - обработчиками сообщений WM_NCPAINT WM_NCACTIVATE WM_SIZING и т.д. Разница с Х только в том что там весь код работает в user mode а в Win частично в ядре. В Kолибри можно сделать ещё один поток в контексте ядра который будет работать как оконный сервер. Даже не обязательно писать его на асме. elf или pe dll модули очень хорошо подходят для разных экспериментов.

Author:  Maxis [ Thu Sep 06, 2007 3:20 pm ]
Post subject: 

Mario79
Quote:
Зачем? Все гораздо проще

А не выльется ли такая простота в проблемы для разработчика программы? Не знаю на сколько проблематично было делать Tinypad.

Тогда может рекомендации какие-нибудь писать? Типа не стоит в одном потоке устраивать циклы потребляющие большие ресурсы или доступ к cdromy.

Gluk
Quote:
чтобы бедненькие кривые программки окна не растеряли?

Кфар, КФМ, ТиниПад это не бедьненькие и кривые программки, но и они тоже окна теряют если например попробовать обраться к cdromу

Serge
Quote:
в контексте ядра который будет работать как оконный сервер

в контексте ядра сцуко апасна.:)

Author:  Serge [ Thu Sep 06, 2007 3:29 pm ]
Post subject: 

Maxis

Cейчас работает в ядре и ничего...

Author:  Mario79 [ Thu Sep 06, 2007 3:34 pm ]
Post subject: 

Maxis
Quote:
А не выльется ли такая простота в проблемы для разработчика программы? Не знаю на сколько проблематично было делать Tinypad.

Все проблемы находятся в мозгу программиста. У меня таких проблем нету.
Quote:
Кфар, КФМ, ТиниПад это не бедьненькие и кривые программки, но и они тоже окна теряют если например попробовать обраться к cdromу

Не люблю заявлять заранее, но в будущих версиях KFM я собирался переписать на второй поток процедуры копирования, перемещения и удаления. Сделать загрузку содержимого директории вторым потоком еще проще, просто никто таких просьб ранее не выдвигал. Ты первый, с чем тебя и поздравляю. :-)
А вообще при первом обращении к ATAPI устройству в Винде после вставки диска притормаживается вся система. Так что Колибри в этом отношении гораздо лучше себя ведет.

Author:  Maxis [ Thu Sep 06, 2007 3:38 pm ]
Post subject: 

Serge
Сложность встроенного в ядро GUI постоянна, а вот если я правильно понимаю идею Xов то с каждым обьектом будет возрастать его сложность и ошибка в каком-нибудь из обьектов может задеть ядро.

Author:  Serge [ Thu Sep 06, 2007 5:04 pm ]
Post subject: 

Maxis

В Х только один вид объектов - окно как прямоугольная область на экране. Все графические элементы управления -виджеты программы рисуют сами. libGUI построена по таком же принципу. Вообще реализовывать контролы в оконном менеджере идея не очень хорошая.

Author:  shamaz.mazum [ Wed Jan 02, 2008 2:57 pm ]
Post subject:  Re: переделать оконную систему...

Maxis wrote:
Вообще реализовывать контролы в оконном менеджере идея не очень хорошая

OMG. Хоть один здравомыслящий человек

Author:  SHREDER [ Mon Jan 14, 2008 7:50 pm ]
Post subject:  Re: переделать оконную систему...

ИМХО их лучше всего вообще сделать child окнами. Т.е. любой контрол - окно. Так в принципе всюду сделанно. Если ядро поддерживает окна больше и не надо и все контролы лежат в Dll. А реализовывать контролы в ядре ИМХО - идиотизм оно и так жрет 32М ОЗУ.

Page 3 of 3 All times are UTC+03:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/