Page 8 of 11

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 9:53 pm
by konstantin_666
Но довольно опасно загружать активное содержимое в собственную память и потом его запускать как отдельный поток.

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 9:58 pm
by Gluk
волков бояться - в лес не ходить

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 10:04 pm
by konstantin_666
В другой оси такое точно не стали бы реализовывать.(:
Если уже делать, то прийдётся хедер разработать и расширение файла придумать, типа *.wid

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 10:20 pm
by Gluk
а Колибри ставить тоже опасно, разработчики не несут ответственности за возможный ущерб

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 10:36 pm
by konstantin_666
Вот приблизительный формат хедера:

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		;положение относительно окна
размеры виджета- устанавливает виджет
положение относительно окна- передаёт панель

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 10:44 pm
by Mario
konstantin_666
А зачем запускать отдельным потоком? Кажется все со страшной силой стараются избавиться от мультипоточного ICON (в свое время это между прочим был качественный скачок, потому что то что было в Menuet вообще отжирало по собственному адресному пространству, т.е. одна иконка это было отдельное приложение вообще) и вместо этого куча виджетов с собственными потоками? А может переосмыслить? Ведь в конкретный момент времени все равно активен только один из виджетов, зачем плодить сущности? Мне так кажется все вполне реализуемо в пределах самого потока панели.

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 10:49 pm
by konstantin_666
А как же тогда виджет будет получать сообщения от системы?
Тем более виджетов будет не 27, а 5-10 (и то если на панели поместятся).

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

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 11:00 pm
by Mario
konstantin_666
А как же тогда виджет будет получать сообщения от системы?
Нормально будет получать, например как это сделано в box_lib для большинства элементов. Есть несколько типов вызовов:
1) Отображение компонента
2) Проверка события мыши.
3) Проверка события клавиатуры
...
и т.д.
Событие может обрабатываться как самим компонентом так и основным потоком, например нажатие клавиатуры имеет смысл обрабатывать основным потоком в большинстве случаев, а вот события мышки уже может обрабатывать сам компонент. Правда если компонентов много (несколько десятков), но обработка например нажатия кнопок мыши (двойной щелчок и т.п.) может запаздывать и приводить к рассинхронизации, в таких случаях полезно это делать основной программой вызывающей компоненты.
Просто не логично было запускать один и тот же код ICON так много раз.
Ограничения которые привели к такой ситуации:
1) Система не имеет зафиксированного самого нижнего и самого верхнего уровня = все окна в оконном стеке равноправны.
2) Один поток может иметь только одно окно, а если нарисовать его на весь экран (чтобы отобразить все иконки) оно перекроет все остальные окна и они станут недоступны, даже если окно иконки в промежутках между иконками будет прозрачным, потому что см. п.1

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 11:05 pm
by Asper
Думаю, что в принципе @ICON можно и одним потоком, если использовать функцию 50.
P.S. Мне многопоточность @ICON нисколько не мешает, тем более, что эти потоки и глаза не кому не мозолят в последней ночной сборке.

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 11:16 pm
by konstantin_666
2Asper:
И тогда они одновременно вылазить будут. Оригинально.

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

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 11:30 pm
by Asper
:) Да смешно.
А в действительности Марио прав нужны уровни в оконном стеке.

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Tue Feb 02, 2010 11:37 pm
by Mario
Вообще то ради справедливости - это не моя идея она у всех в головах бродила, с самого начала, и не я первый ее высказывал. Вроде как оно само по смыслу вытекает, если подумать. Как то так... :mrgreen:

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Wed Feb 03, 2010 8:33 am
by konstantin_666
А если виджету нужно обновляться без события, например, часам или графике?
Прийдется прогонять процессор по всем виджетам с периодом, который задаёт самый быстрый виджет.
Тогда и хедер нужно доработать:

Code: Select all

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

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Wed Feb 03, 2010 9:46 am
by Mario
konstantin_666
Никто не мешает использовать ожидание события с таймаутом. В zSea например я так реализовал отображение динамических GIF и никаких особых накладных расходов. В блоке данных виджета можно указать что он динамический.

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

Re: Другой взгляд на интерфейс, альтернатива @panel

Posted: Wed Feb 03, 2010 5:32 pm
by Gluk
Обновил документацию, разместил в том же посте.