Board.KolibriOS.org

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

_________________
Не бойтесь делать ошибок. Бойтесь ничего не делать.

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

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

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

_________________
Не бойтесь делать ошибок. Бойтесь ничего не делать.

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

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

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

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

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

_________________
Не бойтесь делать ошибок. Бойтесь ничего не делать.

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

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

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

_________________
Не бойтесь делать ошибок. Бойтесь ничего не делать.

konstantin_666

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


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

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

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

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

_________________
Не бойтесь делать ошибок. Бойтесь ничего не делать.

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

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

А если виджету нужно обновляться без события, например, часам или графике?
Прийдется прогонять процессор по всем виджетам с периодом, который задаёт самый быстрый виджет.
Тогда и хедер нужно доработать:

db    'KWid'       ;id
dw    0x01         ;header version
dd    0x0          ;icon
dw    0x120,0x100  ;размер виджета
dw    0x0,0x0      ;положение виджета относительно окна
dd    0xffffffff   ;период обновления

_________________
Не бойтесь делать ошибок. Бойтесь ничего не делать.

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

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

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

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!