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

Другой взгляд на интерфейс, альтернатива @panel
https://board.kolibrios.org/viewtopic.php?f=39&t=1336
Page 8 of 11

Author:  konstantin_666 [ Tue Feb 02, 2010 9:53 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

Но довольно опасно загружать активное содержимое в собственную память и потом его запускать как отдельный поток.

Author:  Gluk [ Tue Feb 02, 2010 9:58 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

волков бояться - в лес не ходить

Author:  konstantin_666 [ Tue Feb 02, 2010 10:04 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

В другой оси такое точно не стали бы реализовывать.(:
Если уже делать, то прийдётся хедер разработать и расширение файла придумать, типа *.wid

Author:  Gluk [ Tue Feb 02, 2010 10:20 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

а Колибри ставить тоже опасно, разработчики не несут ответственности за возможный ущерб

Author:  konstantin_666 [ Tue Feb 02, 2010 10:36 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

Вот приблизительный формат хедера:

Code:
   db   'KWid'      ;id
   dw   0x01      ;header version
   dd   0x0      ;icon
   dd   START      ;program start
   dw   0x120,0x100   ;размеры виджета
   dw   0х0,0х0      ;положение относительно окна


размеры виджета- устанавливает виджет
положение относительно окна- передаёт панель

Author:  Mario [ Tue Feb 02, 2010 10:44 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

konstantin_666
А зачем запускать отдельным потоком? Кажется все со страшной силой стараются избавиться от мультипоточного ICON (в свое время это между прочим был качественный скачок, потому что то что было в Menuet вообще отжирало по собственному адресному пространству, т.е. одна иконка это было отдельное приложение вообще) и вместо этого куча виджетов с собственными потоками? А может переосмыслить? Ведь в конкретный момент времени все равно активен только один из виджетов, зачем плодить сущности? Мне так кажется все вполне реализуемо в пределах самого потока панели.

Author:  konstantin_666 [ Tue Feb 02, 2010 10:49 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

А как же тогда виджет будет получать сообщения от системы?
Тем более виджетов будет не 27, а 5-10 (и то если на панели поместятся).

Просто не логично было запускать один и тот же код ICON так много раз, нагружая при этом систему.

Author:  Mario [ Tue Feb 02, 2010 11:00 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

konstantin_666
Quote:
А как же тогда виджет будет получать сообщения от системы?

Нормально будет получать, например как это сделано в box_lib для большинства элементов. Есть несколько типов вызовов:
1) Отображение компонента
2) Проверка события мыши.
3) Проверка события клавиатуры
...
и т.д.
Событие может обрабатываться как самим компонентом так и основным потоком, например нажатие клавиатуры имеет смысл обрабатывать основным потоком в большинстве случаев, а вот события мышки уже может обрабатывать сам компонент. Правда если компонентов много (несколько десятков), но обработка например нажатия кнопок мыши (двойной щелчок и т.п.) может запаздывать и приводить к рассинхронизации, в таких случаях полезно это делать основной программой вызывающей компоненты.

Quote:
Просто не логично было запускать один и тот же код ICON так много раз.

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

Author:  Asper [ Tue Feb 02, 2010 11:05 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

Думаю, что в принципе @ICON можно и одним потоком, если использовать функцию 50.
P.S. Мне многопоточность @ICON нисколько не мешает, тем более, что эти потоки и глаза не кому не мозолят в последней ночной сборке.

Author:  konstantin_666 [ Tue Feb 02, 2010 11:16 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

2Asper:
И тогда они одновременно вылазить будут. Оригинально.

2Mario:
А сообщения о перерисовке? Прийдётся виджету каждый раз проверять, для чего его запустили.
Каждый виджет в таком случае запросто сможет повесить всю панель.

Author:  Asper [ Tue Feb 02, 2010 11:30 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

:) Да смешно.
А в действительности Марио прав нужны уровни в оконном стеке.

Author:  Mario [ Tue Feb 02, 2010 11:37 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  konstantin_666 [ Wed Feb 03, 2010 8:33 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

А если виджету нужно обновляться без события, например, часам или графике?
Прийдется прогонять процессор по всем виджетам с периодом, который задаёт самый быстрый виджет.
Тогда и хедер нужно доработать:
Code:
db    'KWid'       ;id
dw    0x01         ;header version
dd    0x0          ;icon
dw    0x120,0x100  ;размер виджета
dw    0x0,0x0      ;положение виджета относительно окна
dd    0xffffffff   ;период обновления

Author:  Mario [ Wed Feb 03, 2010 9:46 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

konstantin_666
Никто не мешает использовать ожидание события с таймаутом. В zSea например я так реализовал отображение динамических GIF и никаких особых накладных расходов. В блоке данных виджета можно указать что он динамический.

Впрочем ладно, если столько упорства в споре проявляется, я ведь не настаиваю - делай как хочешь. :mrgreen:

Author:  Gluk [ Wed Feb 03, 2010 5:32 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

Обновил документацию, разместил в том же посте.

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