Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Сб окт 21, 2017 10:35 pm

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




Начать новую тему  Ответить на тему  [ 44 сообщения ]  На страницу Пред. 1 2 3
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Ср сен 05, 2007 9:34 pm 
Maxis
Цитата:
когда приложение входит в цикл и не может ответить на сообщение о перерисовке окна(когда требуются все ресурсы процессора, например, при архивации файла), то это окно при попытке его перетащить перестает перерисовываться и может пропасть совсем, я так понимаю, чтобы решить эту проблему нужно пихать GUI-обьекты в ядро.

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


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср сен 05, 2007 11:17 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт май 18, 2007 11:11 pm
Сообщения: 125
Mario79
Цитата:
Зачем? Все гораздо проще - запускается приложение, рисует окно и запускает второй поток, который занимается непосредственно архивацией.

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

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


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср сен 05, 2007 11:33 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пн апр 16, 2007 6:38 pm
Сообщения: 1222
Alver
Цитата:
Это верно, но приложений не использующих второй поток, тоже хватает, сюда же кривые и зависшие проги.

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


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср сен 05, 2007 11:43 pm 
Не в сети
Аватара пользователя

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


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт сен 06, 2007 2:23 am 
Не в сети
Аватара пользователя

Зарегистрирован: Чт мар 01, 2007 4:16 pm
Сообщения: 426
> И сразу все проблемы снимутся.
Не смеши. Если код приложения кривой, то, например, при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.

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

..bw


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт сен 06, 2007 7:22 am 
bw
Цитата:
при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.

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


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

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Maxis

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

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


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

Зарегистрирован: Вс фев 04, 2007 2:07 pm
Сообщения: 176
Mario79
Цитата:
Зачем? Все гораздо проще

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

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

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

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

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

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


Последний раз редактировалось Maxis Чт сен 06, 2007 3:32 pm, всего редактировалось 1 раз.

Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт сен 06, 2007 3:29 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Maxis

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


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт сен 06, 2007 3:34 pm 
Maxis
Цитата:
А не выльется ли такая простота в проблемы для разработчика программы? Не знаю на сколько проблематично было делать Tinypad.

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

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


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

Зарегистрирован: Вс фев 04, 2007 2:07 pm
Сообщения: 176
Serge
Сложность встроенного в ядро GUI постоянна, а вот если я правильно понимаю идею Xов то с каждым обьектом будет возрастать его сложность и ошибка в каком-нибудь из обьектов может задеть ядро.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Чт сен 06, 2007 5:04 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Maxis

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


Вернуться к началу
 Заголовок сообщения: Re: переделать оконную систему...
СообщениеДобавлено: Ср янв 02, 2008 2:57 pm 
Maxis писал(а):
Вообще реализовывать контролы в оконном менеджере идея не очень хорошая

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


Вернуться к началу
   
 Заголовок сообщения: Re: переделать оконную систему...
СообщениеДобавлено: Пн янв 14, 2008 7:50 pm 
Не в сети

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

_________________
Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.


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

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


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

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


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

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