Зачем? Все гораздо проще - запускается приложение, рисует окно и запускает второй поток, который занимается непосредственно архивацией. Обмен между потоками, для получения данных о прогрессе выполняемой операции и о ее завершении осуществляется либо через глобальные переменные, либо через оговоренную область памяти.когда приложение входит в цикл и не может ответить на сообщение о перерисовке окна(когда требуются все ресурсы процессора, например, при архивации файла), то это окно при попытке его перетащить перестает перерисовываться и может пропасть совсем, я так понимаю, чтобы решить эту проблему нужно пихать GUI-обьекты в ядро.
переделать оконную систему...
-
Maxis
Mario79
Maxis
Это верно, но приложений не использующих второй поток, тоже хватает, сюда же кривые и зависшие проги. Я лично за то чтобы при событии перерисовки окна, имеющего рамки, рамки рисовались ядром, так окно не потеряется. А внутренние обьекты это дело приложения.Зачем? Все гораздо проще - запускается приложение, рисует окно и запускает второй поток, который занимается непосредственно архивацией.
Maxis
ИМХО Возможно через специальное приложение и IPC можно попробовать реализовать такие фишки как перетаскивание обьектов (файлов, текстов и т.п.). Возможно единственное что потребуется от ядра, присваивать специальным программам - системным сервисам фиксированные PIDы, для обращений, ну может улучшить(ускорить) функции IPC.А что если программа(сервер окон) вызывает(один раз) некую системную функцию, которая делает так что бы ядро перенаправляло все события клавиатуры и мыши этому приложению и только ему. Это приложение создает и перемещает окна(или регионы), а так же их перерисовывает через селектор gs. Обычное приложение через IPC создает обьекты этого сервера и получает события от мыши и клавиатуры также через IPC.
Alver
Я считаю, что не стоит ради поддержки неграмотно написанных прог мучать бедное ядро, почем зря. может предложишь еще ошибки в программах при исполнении исправлять, или оптимизировать насильно? чтобы бедненькие кривые программки окна не растеряли?Это верно, но приложений не использующих второй поток, тоже хватает, сюда же кривые и зависшие проги.
Нужно концептуально вынести интерфейс в отдельный поток. Создал окно - получил поток. И сразу все проблемы снимутся. Чем тупо копировать существующие решения, лучше один раз подумать головой.
> И сразу все проблемы снимутся.
Не смеши. Если код приложения кривой, то, например, при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.
Это был оффтом. А по теме я думаю мое мнение известно. Я за то, что бы был отдельный сервер WM и быстрый IPC .
..bw
Не смеши. Если код приложения кривой, то, например, при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.
Это был оффтом. А по теме я думаю мое мнение известно. Я за то, что бы был отдельный сервер WM и быстрый IPC .
..bw
bw
Криво написанный код может подвесить любую даже сверхнадежную систему. Даже QNX при желании можно подвесить (теоретически, оговариваюсь, чтобы меня не загрызли любители этой опрационки).
Работа с проблемным кодом это головная боль программиста, а не ядра.при обращении потока, который занимается отрисовкой, к "проблемноку коду" может вызвать зависание этого потока. К примеру это может произойти из-за взаимной блокировки потоков при попытки синхронизации доступа к общим данным.
Криво написанный код может подвесить любую даже сверхнадежную систему. Даже QNX при желании можно подвесить (теоретически, оговариваюсь, чтобы меня не загрызли любители этой опрационки).
Maxis
Похожим образом работает Х в *никсах и без особых тормозов.
Видеопамять начинается с 0xFE000000 и у любого приложения есть доступ к этим адресам и без селектора gs.
Кстати в WinXP если программа надолго зависает система прячет её окно и подменяет его своим с такими же характеристиками чтобы пользователь мог его перемещать. В документации оно называется ghost window. Это потому что отрисовка рамок окна и код перемещения и изменения размеров выполняется программой где-то в глубинах DefWindowProc() - обработчиками сообщений WM_NCPAINT WM_NCACTIVATE WM_SIZING и т.д. Разница с Х только в том что там весь код работает в user mode а в Win частично в ядре. В Kолибри можно сделать ещё один поток в контексте ядра который будет работать как оконный сервер. Даже не обязательно писать его на асме. elf или pe dll модули очень хорошо подходят для разных экспериментов.
Похожим образом работает Х в *никсах и без особых тормозов.
Видеопамять начинается с 0xFE000000 и у любого приложения есть доступ к этим адресам и без селектора gs.
Кстати в WinXP если программа надолго зависает система прячет её окно и подменяет его своим с такими же характеристиками чтобы пользователь мог его перемещать. В документации оно называется ghost window. Это потому что отрисовка рамок окна и код перемещения и изменения размеров выполняется программой где-то в глубинах DefWindowProc() - обработчиками сообщений WM_NCPAINT WM_NCACTIVATE WM_SIZING и т.д. Разница с Х только в том что там весь код работает в user mode а в Win частично в ядре. В Kолибри можно сделать ещё один поток в контексте ядра который будет работать как оконный сервер. Даже не обязательно писать его на асме. elf или pe dll модули очень хорошо подходят для разных экспериментов.
Mario79
Тогда может рекомендации какие-нибудь писать? Типа не стоит в одном потоке устраивать циклы потребляющие большие ресурсы или доступ к cdromy.
Gluk
Serge
А не выльется ли такая простота в проблемы для разработчика программы? Не знаю на сколько проблематично было делать Tinypad.Зачем? Все гораздо проще
Тогда может рекомендации какие-нибудь писать? Типа не стоит в одном потоке устраивать циклы потребляющие большие ресурсы или доступ к cdromy.
Gluk
Кфар, КФМ, ТиниПад это не бедьненькие и кривые программки, но и они тоже окна теряют если например попробовать обраться к cdromучтобы бедненькие кривые программки окна не растеряли?
Serge
в контексте ядра сцуко апасна.в контексте ядра который будет работать как оконный сервер
Last edited by Maxis on Thu Sep 06, 2007 3:32 pm, edited 1 time in total.
Maxis
Cейчас работает в ядре и ничего...
Cейчас работает в ядре и ничего...
Maxis
А вообще при первом обращении к ATAPI устройству в Винде после вставки диска притормаживается вся система. Так что Колибри в этом отношении гораздо лучше себя ведет.
Все проблемы находятся в мозгу программиста. У меня таких проблем нету.А не выльется ли такая простота в проблемы для разработчика программы? Не знаю на сколько проблематично было делать Tinypad.
Не люблю заявлять заранее, но в будущих версиях KFM я собирался переписать на второй поток процедуры копирования, перемещения и удаления. Сделать загрузку содержимого директории вторым потоком еще проще, просто никто таких просьб ранее не выдвигал. Ты первый, с чем тебя и поздравляю.Кфар, КФМ, ТиниПад это не бедьненькие и кривые программки, но и они тоже окна теряют если например попробовать обраться к cdromу
А вообще при первом обращении к ATAPI устройству в Винде после вставки диска притормаживается вся система. Так что Колибри в этом отношении гораздо лучше себя ведет.
Serge
Сложность встроенного в ядро GUI постоянна, а вот если я правильно понимаю идею Xов то с каждым обьектом будет возрастать его сложность и ошибка в каком-нибудь из обьектов может задеть ядро.
Сложность встроенного в ядро GUI постоянна, а вот если я правильно понимаю идею Xов то с каждым обьектом будет возрастать его сложность и ошибка в каком-нибудь из обьектов может задеть ядро.
Maxis
В Х только один вид объектов - окно как прямоугольная область на экране. Все графические элементы управления -виджеты программы рисуют сами. libGUI построена по таком же принципу. Вообще реализовывать контролы в оконном менеджере идея не очень хорошая.
В Х только один вид объектов - окно как прямоугольная область на экране. Все графические элементы управления -виджеты программы рисуют сами. libGUI построена по таком же принципу. Вообще реализовывать контролы в оконном менеджере идея не очень хорошая.
OMG. Хоть один здравомыслящий человекMaxis wrote:Вообще реализовывать контролы в оконном менеджере идея не очень хорошая
ИМХО их лучше всего вообще сделать child окнами. Т.е. любой контрол - окно. Так в принципе всюду сделанно. Если ядро поддерживает окна больше и не надо и все контролы лежат в Dll. А реализовывать контролы в ядре ИМХО - идиотизм оно и так жрет 32М ОЗУ.
Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.
Who is online
Users browsing this forum: No registered users and 23 guests