Board.KolibriOS.org

Maxis

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

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

Mario79

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

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

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

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

Alver

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

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

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

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

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

..bw

bw

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

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

Maxis

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

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

Mario79

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

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

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

Gluk

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

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

Serge

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

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

Maxis

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

Maxis

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

Все проблемы находятся в мозгу программиста. У меня таких проблем нету.

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

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

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

Maxis

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

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

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

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