Board.KolibriOS.org

Подозреваю что это не то что надо, но с чего-то же надо начинать, верно?) все носит предварительный характер.

14.10.09, полпервого ночи:
обновил бинарик, в нем появилось то, что еще не описано в документации, и вроде как убран баг с недостающей длиной 1й панели. Документацию обновлю на днях, в зависимости от степени загруженности меня всякими посторонними делами.
Еще одну вещь доделаю в бинарике и возьмусь за размещение элементов (это та самая вещь по окончании которой я собираюсь выложить исходники).

14.10.09, полседьмого вечера:
Обновление документации, теперь она перегоняет бинарик. Добавлено описание бортика у края панели (то, что было сделано в бинарике версии что описана выше), а также пара новых возможных значений для прямоугольников пересечения панелей.

3.02.10, полшестого раннего вечера:
в документации дано описание потока виджета. Там же добавлен новый элемент - спэйсер, в результате чего у остальных элементов уже не задается их положение (нет необходимости). Таким образом все нужное по положениям элементов описано.

15.03.10, час ночи:
в документации убраны все упоминания о бортике, связанное с ним - зачеркнуто. Бинарик показывает, почему это было сделано, а также добавлен хоткей для завершения работы приложения (см. документацию), и восстановление предыдущей рабочей области (см. документацию). Прошу бинарик протестировать, посмотреть.

4.09.11, полдесятого вечера:
Бинарик берёт настройки из файлов, лежащих с ним в одной директории. Файлы настроек прилагаются к бинарику, соответственно. Можете поиграться, переименовывая файлы друг в друга, удаляя их. Документация чуток спешит, и описывает содержимое последних моих сумбурных постов в этой теме, плюс расписано про обмен виджет-серверов с виджет-клиентами ч/з расшаренную память, и большинство настроек, содержащихся в файле настроек.

11.09.11, одиннадцать вечера:
В бинарик добавлена проверка заголовка файлов настроек, теперь можно спокойно класть рядом с ним рандомные файлы *.s, однако такие файлы с верным заголовком, но с испорченным содержанием, всё еще опасны для программы. Файлы же *.a (исходные коды настроек) никоим образом не проверяются - да и как можно, если каждый по-своему код пишет. Так что тут всё зависит от поведения fasm. Документация сильно исправлена, визуально лучше оформлена, и несколько дополнена. В частности, указано, как именно будут именоваться разделённые области памяти. Осталось совсем немного до запуска первых виджетов...

Тему читал не очень внимательно, но могу предложить такое дело: выделяешь на панели место, заводишь область памяти размером с это место и кнопку на нём создаёшь. Виджет - стандартная библиотека, будет сидеть в в пространстве панели, получать от основного процесса панели сообщения о нажатиях на эту кнопку и тому подобных. Сам виджет рисует в указанной ему области памяти, а уж панель решает куда и как вывести эту область. Кажись, в винде в первом приближении так и сделано (ищем по слову NOTIFYICONDATA).

мне не нравится идея чтобы виджеты работали в том же потоке что и панель. так виджет сможет упасть (и уронить панель), да и банально зависнуть (и повесить панель).
Фишка еще в том, что виджету может быть нужно больше одной активной области (и меньше одной тоже), и реакция не только на клик мышью, но и например на нажатие клавиши. Поэтому использование просто кнопки, как для других элементов, неприемлимо

-раскрывающийся список можно наверное будет сделать на основе программы @menu, ну или подглядывая туда.

В бинарике нашел крохотную ошибку сделанную по причине забывчивости - панель1 не доходит до низа экрана 1 пиксель. Исправлю - перевыложу.
Да, исходник выложу как только он будет соответствовать собственной документации =) но если кому надо раньше - пишите, скину без проблем, хотя сейчас в общем-то незачем, по идее сейчас программа на этапе разработки документации (ну хотя бы до тех пор пока с виджетами однозначно не определимся, или хотябы с основными принципами).
Тем временем завтра надеюсь обновлю документацию (и бинарик, но это еще под вопросом), дополнив парой важных моментов.

а рационально делать панели такой ширины? у меня после запуска 4 панелей совсем не остаётся места на экране... (да, конечно, в реальной системе я боковые панели не использую, но всё же)

поэтому предложение - выбрать оптимальный для всех размер панелей, который будет установлен по умолчанию

Я подразумевал не в одном потоке, а в одном процессе. Не знаю как в KolibriPE, но когда я ещё использовал систему, потоки одного процесса имели общее адресное пространство. А то что каждый виджет имеет свой поток (и даже не один) - кто ж ему помешает. Я говорил только о механизме взаимодействия между виджетами и панелью, а не о строении виджетов. Могу порекомендовать поискать виндовую версию утилитки GuiTherm, она хорошо всё это иллюстрирует. В принципе, чуть позже могу и выложить.

Albom
Ребята, я сам рос начианя с КР580ВМ80... Но наверное сейчас можно сказать что 1280x1024 это минимум, а остальное это либо вы***н в сторону RAR (гуглим монеты), либо одно из двух...
Если будет спец. реализация, споров нет, но их пока нет, и не надо искуственно завышать рамки.

Ghost
Ребята, я сам рос начианя с 80486DX2-66... Почему-то у меня разрешение экрана всего 1024х768 на домашнем и рабочем компьютерах и 1024х600 на нетбуке, а это значит я не имею права высказать свою точку зрения...

да я в бинарик (как и в рисунок) значения размеров вообще наугад подставлял. В любом случае по умолчанию будут не все 4 панели, а размеры - продуманными и рациональными.

Доработку документации не сделал, много дел было, ну соответственно и бинарика (разве что баг вышеописанный исправил, но перевыкладывать смысла не вижу)

обновил бинарик, ссылка и описание изменений там же где и был бинарик.

В Ubuntu ширина панелей по умолчанию 24 пиксела. В Suse 32 пиксела.

Как считаете, нужно ли делать возможность задавать ширину панелей в процентах от высоты/ширины экрана? Так в какой-то мере возможно разрешится разница в разрешениях экрана.
Эту возможность будет не обязательно использовать, разумеется. Просто мне кажется что лишней она не будет. Что думаете?

Как считаете, нужно ли делать возможность задавать ширину панелей в процентах от высоты/ширины экрана?

Нужно. Чем больше возможностей настраивать, тем лучше. Только если выражать размеры панели в процентах, то это число должно быть вещественным(иначе разброс размера будет 6-13 пикселей).

Gluk
А что если код проводящий начальную инициализацию будет в отдельной программе - скидывает данные в INI файл, а панель уже пользуется готовыми данными. За одно и экономия памяти будет, неактивный код не будет висеть в памяти все время.