Другой взгляд на интерфейс, альтернатива @panel
-
Но довольно опасно загружать активное содержимое в собственную память и потом его запускать как отдельный поток.Не бойтесь делать ошибок. Бойтесь ничего не делать.
волков бояться - в лес не ходить
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
В другой оси такое точно не стали бы реализовывать.(:
Если уже делать, то прийдётся хедер разработать и расширение файла придумать, типа *.wid
Если уже делать, то прийдётся хедер разработать и расширение файла придумать, типа *.wid
Last edited by konstantin_666 on Tue Feb 02, 2010 10:54 pm, edited 2 times in total.
Не бойтесь делать ошибок. Бойтесь ничего не делать.
а Колибри ставить тоже опасно, разработчики не несут ответственности за возможный ущерб
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Вот приблизительный формат хедера:
размеры виджета- устанавливает виджет
положение относительно окна- передаёт панель
Code: Select all
db 'KWid' ;id
dw 0x01 ;header version
dd 0x0 ;icon
dd START ;program start
dw 0x120,0x100 ;размеры виджета
dw 0х0,0х0 ;положение относительно окна
положение относительно окна- передаёт панель
Last edited by konstantin_666 on Wed Feb 03, 2010 12:11 am, edited 2 times in total.
Не бойтесь делать ошибок. Бойтесь ничего не делать.
konstantin_666
А зачем запускать отдельным потоком? Кажется все со страшной силой стараются избавиться от мультипоточного ICON (в свое время это между прочим был качественный скачок, потому что то что было в Menuet вообще отжирало по собственному адресному пространству, т.е. одна иконка это было отдельное приложение вообще) и вместо этого куча виджетов с собственными потоками? А может переосмыслить? Ведь в конкретный момент времени все равно активен только один из виджетов, зачем плодить сущности? Мне так кажется все вполне реализуемо в пределах самого потока панели.
А зачем запускать отдельным потоком? Кажется все со страшной силой стараются избавиться от мультипоточного ICON (в свое время это между прочим был качественный скачок, потому что то что было в Menuet вообще отжирало по собственному адресному пространству, т.е. одна иконка это было отдельное приложение вообще) и вместо этого куча виджетов с собственными потоками? А может переосмыслить? Ведь в конкретный момент времени все равно активен только один из виджетов, зачем плодить сущности? Мне так кажется все вполне реализуемо в пределах самого потока панели.
А как же тогда виджет будет получать сообщения от системы?
Тем более виджетов будет не 27, а 5-10 (и то если на панели поместятся).
Просто не логично было запускать один и тот же код ICON так много раз, нагружая при этом систему.
Тем более виджетов будет не 27, а 5-10 (и то если на панели поместятся).
Просто не логично было запускать один и тот же код ICON так много раз, нагружая при этом систему.
Last edited by konstantin_666 on Wed Feb 03, 2010 9:27 am, edited 1 time in total.
Не бойтесь делать ошибок. Бойтесь ничего не делать.
konstantin_666
1) Отображение компонента
2) Проверка события мыши.
3) Проверка события клавиатуры
...
и т.д.
Событие может обрабатываться как самим компонентом так и основным потоком, например нажатие клавиатуры имеет смысл обрабатывать основным потоком в большинстве случаев, а вот события мышки уже может обрабатывать сам компонент. Правда если компонентов много (несколько десятков), но обработка например нажатия кнопок мыши (двойной щелчок и т.п.) может запаздывать и приводить к рассинхронизации, в таких случаях полезно это делать основной программой вызывающей компоненты.
1) Система не имеет зафиксированного самого нижнего и самого верхнего уровня = все окна в оконном стеке равноправны.
2) Один поток может иметь только одно окно, а если нарисовать его на весь экран (чтобы отобразить все иконки) оно перекроет все остальные окна и они станут недоступны, даже если окно иконки в промежутках между иконками будет прозрачным, потому что см. п.1
Нормально будет получать, например как это сделано в box_lib для большинства элементов. Есть несколько типов вызовов:А как же тогда виджет будет получать сообщения от системы?
1) Отображение компонента
2) Проверка события мыши.
3) Проверка события клавиатуры
...
и т.д.
Событие может обрабатываться как самим компонентом так и основным потоком, например нажатие клавиатуры имеет смысл обрабатывать основным потоком в большинстве случаев, а вот события мышки уже может обрабатывать сам компонент. Правда если компонентов много (несколько десятков), но обработка например нажатия кнопок мыши (двойной щелчок и т.п.) может запаздывать и приводить к рассинхронизации, в таких случаях полезно это делать основной программой вызывающей компоненты.
Ограничения которые привели к такой ситуации:Просто не логично было запускать один и тот же код ICON так много раз.
1) Система не имеет зафиксированного самого нижнего и самого верхнего уровня = все окна в оконном стеке равноправны.
2) Один поток может иметь только одно окно, а если нарисовать его на весь экран (чтобы отобразить все иконки) оно перекроет все остальные окна и они станут недоступны, даже если окно иконки в промежутках между иконками будет прозрачным, потому что см. п.1
Думаю, что в принципе @ICON можно и одним потоком, если использовать функцию 50.
P.S. Мне многопоточность @ICON нисколько не мешает, тем более, что эти потоки и глаза не кому не мозолят в последней ночной сборке.
P.S. Мне многопоточность @ICON нисколько не мешает, тем более, что эти потоки и глаза не кому не мозолят в последней ночной сборке.
2Asper:
И тогда они одновременно вылазить будут. Оригинально.
2Mario:
А сообщения о перерисовке? Прийдётся виджету каждый раз проверять, для чего его запустили.
Каждый виджет в таком случае запросто сможет повесить всю панель.
И тогда они одновременно вылазить будут. Оригинально.
2Mario:
А сообщения о перерисовке? Прийдётся виджету каждый раз проверять, для чего его запустили.
Каждый виджет в таком случае запросто сможет повесить всю панель.
Last edited by konstantin_666 on Tue Feb 02, 2010 11:37 pm, edited 1 time in total.
Не бойтесь делать ошибок. Бойтесь ничего не делать.
Да смешно.
А в действительности Марио прав нужны уровни в оконном стеке.
А в действительности Марио прав нужны уровни в оконном стеке.
Вообще то ради справедливости - это не моя идея она у всех в головах бродила, с самого начала, и не я первый ее высказывал. Вроде как оно само по смыслу вытекает, если подумать. Как то так...
А если виджету нужно обновляться без события, например, часам или графике?
Прийдется прогонять процессор по всем виджетам с периодом, который задаёт самый быстрый виджет.
Тогда и хедер нужно доработать:
Прийдется прогонять процессор по всем виджетам с периодом, который задаёт самый быстрый виджет.
Тогда и хедер нужно доработать:
Code: Select all
db 'KWid' ;id
dw 0x01 ;header version
dd 0x0 ;icon
dw 0x120,0x100 ;размер виджета
dw 0x0,0x0 ;положение виджета относительно окна
dd 0xffffffff ;период обновления
Не бойтесь делать ошибок. Бойтесь ничего не делать.
konstantin_666
Никто не мешает использовать ожидание события с таймаутом. В zSea например я так реализовал отображение динамических GIF и никаких особых накладных расходов. В блоке данных виджета можно указать что он динамический.
Впрочем ладно, если столько упорства в споре проявляется, я ведь не настаиваю - делай как хочешь.
Никто не мешает использовать ожидание события с таймаутом. В zSea например я так реализовал отображение динамических GIF и никаких особых накладных расходов. В блоке данных виджета можно указать что он динамический.
Впрочем ладно, если столько упорства в споре проявляется, я ведь не настаиваю - делай как хочешь.
Обновил документацию, разместил в том же посте.
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Who is online
Users browsing this forum: No registered users and 3 guests