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

Projects yet to be implemented in working code
  • волков бояться - в лес не ходить
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • В другой оси такое точно не стали бы реализовывать.(:
    Если уже делать, то прийдётся хедер разработать и расширение файла придумать, типа *.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 вообще отжирало по собственному адресному пространству, т.е. одна иконка это было отдельное приложение вообще) и вместо этого куча виджетов с собственными потоками? А может переосмыслить? Ведь в конкретный момент времени все равно активен только один из виджетов, зачем плодить сущности? Мне так кажется все вполне реализуемо в пределах самого потока панели.
  • А как же тогда виджет будет получать сообщения от системы?
    Тем более виджетов будет не 27, а 5-10 (и то если на панели поместятся).

    Просто не логично было запускать один и тот же код ICON так много раз, нагружая при этом систему.
    Last edited by konstantin_666 on Wed Feb 03, 2010 9:27 am, edited 1 time in total.
    Не бойтесь делать ошибок. Бойтесь ничего не делать.
  • konstantin_666
    А как же тогда виджет будет получать сообщения от системы?
    Нормально будет получать, например как это сделано в box_lib для большинства элементов. Есть несколько типов вызовов:
    1) Отображение компонента
    2) Проверка события мыши.
    3) Проверка события клавиатуры
    ...
    и т.д.
    Событие может обрабатываться как самим компонентом так и основным потоком, например нажатие клавиатуры имеет смысл обрабатывать основным потоком в большинстве случаев, а вот события мышки уже может обрабатывать сам компонент. Правда если компонентов много (несколько десятков), но обработка например нажатия кнопок мыши (двойной щелчок и т.п.) может запаздывать и приводить к рассинхронизации, в таких случаях полезно это делать основной программой вызывающей компоненты.
    Просто не логично было запускать один и тот же код ICON так много раз.
    Ограничения которые привели к такой ситуации:
    1) Система не имеет зафиксированного самого нижнего и самого верхнего уровня = все окна в оконном стеке равноправны.
    2) Один поток может иметь только одно окно, а если нарисовать его на весь экран (чтобы отобразить все иконки) оно перекроет все остальные окна и они станут недоступны, даже если окно иконки в промежутках между иконками будет прозрачным, потому что см. п.1
  • Думаю, что в принципе @ICON можно и одним потоком, если использовать функцию 50.
    P.S. Мне многопоточность @ICON нисколько не мешает, тем более, что эти потоки и глаза не кому не мозолят в последней ночной сборке.
  • 2Asper:
    И тогда они одновременно вылазить будут. Оригинально.

    2Mario:
    А сообщения о перерисовке? Прийдётся виджету каждый раз проверять, для чего его запустили.
    Каждый виджет в таком случае запросто сможет повесить всю панель.
    Last edited by konstantin_666 on Tue Feb 02, 2010 11:37 pm, edited 1 time in total.
    Не бойтесь делать ошибок. Бойтесь ничего не делать.
  • :) Да смешно.
    А в действительности Марио прав нужны уровни в оконном стеке.
  • Вообще то ради справедливости - это не моя идея она у всех в головах бродила, с самого начала, и не я первый ее высказывал. Вроде как оно само по смыслу вытекает, если подумать. Как то так... :mrgreen:
  • А если виджету нужно обновляться без события, например, часам или графике?
    Прийдется прогонять процессор по всем виджетам с периодом, который задаёт самый быстрый виджет.
    Тогда и хедер нужно доработать:

    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 и никаких особых накладных расходов. В блоке данных виджета можно указать что он динамический.

    Впрочем ладно, если столько упорства в споре проявляется, я ведь не настаиваю - делай как хочешь. :mrgreen:
  • Обновил документацию, разместил в том же посте.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Who is online

    Users browsing this forum: No registered users and 1 guest