Board.KolibriOS.org

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

Можно просто хранить в word, 1/65536 намного меньше пикселя.

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

Mario, честно говоря не очень тебя понял..
Код начальной инициализации не так велик, чтобы стоило его выносить в отдельное приложение.. И еще я не понял, что он должен скидывать в INI файл, и откуда..

Gluk
Идея в том чтобы предоставить широкие возможности для конфигурирования.

В INI файле хранить значения в абсолютных единицах, а не в каких либо процентах: если пользователь хочет чтобы система сама инициализировала под разрешение экрана - пожалуйста можно в автозагрузке прописать автоконфигуратор, если хочет работать с постоянными значениями, то пожалуйста берутся значения опять же из INI файла, но записанные туда другим путем, например сохраненными с последнего сеанса. Это даст возможность удовлетворить большее количество пользователей, поскольку у каждого свой взгляд на то, какая должны быть панель: кто-то предпочитает малюсенькую полоску, кто-то панель на треть экрана. Плюс такой подход хоть немного, но упростит структуру программы.

И еще я не понял, что он должен скидывать в INI файл, и откуда..

В INI файле нужно хранить как можно больше настроек, проще будет менять функциональность и внешний вид, не меняя код приложения.

Впрочем ты автор тебе видней, я только предложил идею как можно сделать.

Mario, можно пока отложить эти ньюансы, потом решение придумать

выложил слегка обновленную документацию. изменения небольшие, описаны в том же посте что и документация

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

Albom: "Размер виджета на панели может, в принципе, тоже выражаться в процентном соотношении к ширине/высоте панели."
-тамнаписано:

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

типы элементов панели перечислены в таблице в начале, и виджеты среди них есть, так что да, может.

"Как будет вести себя панель, если сумма размеров всех виджетов будет превышать её ширину/высоту" - думаю, будет рисовать их за пределами экрана. другой вопрос - зачем создавать такой конфиг чтобы все не умещалось? конфиг полностью в состоянии "разрулить" такую ситуацию - ширина панели задается конфигом, так что размещение элементов, зависящих от ширины панели, предсказуемо. А если уж делать размеры какого-либо элемента зависящими от длины панели, то размеры всех остальных элементов панели тоже можно задать в процентах от длины панели, тогда просто надо следить чтобы проценты в сумме не приближались к 100% (ну там еще несколько пикселов уйжут на минимальные промежутки между элементами).
Проверять все это программно - то же что если бы ядро перед запуском кода на выполнение проверяло бы - а не вызовет ли он ошибки, правильно ли будет работать..

Выглядит _прикольно_ если учитывать что цвета от балды. Функционал оценить трудно, потому что неизвестно, как там с виджетами (по всей видимости никак)... Пока панели не тягать - всё ок, и бордюрчики тоже симпатичные (вопрос зачем? и расположение панелей какое-то странное.... но если всё действительно кастомизабельно, то почему бы и нет...). А как начинаем двигать - бордюрчики остаются на местах. даже если я правую и левую панели поменял местами. Мне почему-то кажется, что не должно быть разницы - где находится панель.

Теперь о мыслях относительно т.н. документэйшна...
А зачем вообще всё это дело нумеровать??? и почему именно так? Не понял.
так так так. Смотрим на горизонтальные панели... здесь у нас "ширина" панели - в действительности это её высота. Соответственно, виджет должен пересчитывать всё в масштабе...И всё в порядке. А теперь у нас вертикальная панель. По-хорошему она должна быть "шире" горизонтальной (чтобы вместить кнопки переключения между программами например), причем её "ширина" - это действительно ширина. Как жить виджетам? Какие размеры они должны иметь? чтобы занять всю ширину? Чтобы растянуться на полную высоту?
А если я хочу несколько виджетов в одной строке или в одном столбце? Мне вешаться? о_О


И ещё вопрос, о котором уже говорилось.... Зачем увеличивать количество реальностей? У нас элементы и Кнопка, и Виджет, и Раскрывающийся список.... Может, подойти к делу минималистичнее? Так или иначе, каждый виджет _должен_ (мм, ладно, "может" вместо "должен") предоставлять хотя бы контекстное меню для своей настройки. А может вообще открывать новое окно... Мне вообще кажется, что хватило бы элемента "кнопка с рисунком" или чего-то такого, сам рисунок передавать битмапом...

Но тут уже дело автора программы решать, что да как.


p.s. Про "велосипеды". Если мы здесь обсуждаем альтернативы панели задач.. Почему бы и не иметь несколько вариантов панелей? Есть же в конце концов несколько файловых менеджеров, каждый пользуется тем, что ему нравится.

"Пока панели не тягать - всё ок" - по идее они не должны тягаться ^^
"А зачем вообще всё это дело нумеровать??? и почему именно так? Не понял." - документация не только вообще по программе, но и по внутреннему ее строению, и именно так именованы переменные) почему именно так - берется то же направление обхода что и при нумерации панелей, и ставим номер предыдущей панели, а рядом - следующей.
"Какие размеры они должны иметь? чтобы занять всю ширину? Чтобы растянуться на полную высоту?" - ну шириной панели я назвал меньший размер, длиной - больший, рассматривая панель как полоску, а не как прямоугольник) соответственно в любом положении ширина панели это ширина, а длина - это длина. Далее. Для любого элемента задается один размерный параметр - тот, что не равен ширине панели. Второй соответственно равен, он не задается отдельно для каждого элемента, т.к. уже задан шириной панели. Таким образом для каждого элемента известны и ширина и высота.
на следующую цитату отвечу цитатой) "А если я хочу несколько виджетов в одной строке или в одном столбце? Мне вешаться? о_О" - "Может, подойти к делу минималистичнее?", собственно я и подошел) стоит взглянуть на рисунок на первой странице, и представить сколько места заняла бы панель если б отображение заряда батареи и прогноза погоды были в одной строчке.
"Так или иначе, каждый виджет _должен_ (мм, ладно, "может" вместо "должен") предоставлять хотя бы контекстное меню для своей настройки. А может вообще открывать новое окно..." - панель обязательно будет иметь окно настройки (вернее все панели одно окно), где можно будет установить как настройки каждой панели (расположение элементов, цвета, и т.д.), так и настройки виджетов.
"Если мы здесь обсуждаем альтернативы панели задач.. Почему бы и не иметь несколько вариантов панелей? Есть же в конце концов несколько файловых менеджеров, каждый пользуется тем, что ему нравится." - ну собственно поэтому альтернатива, а не замена) просто еще один вариант. Основная его идея (ну я так ее вижу) - максимальная кастомизабельность, если от этого конечно не страдают остальные моменты.

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

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

Предлагаю для панели использовать treelist. При нажатии Enter запускается программа под курсором. Данный пример можно и немного оптимизировать при добавлении строк, и вынести команды в отдельный файл, но пока даю так.

это для всплывающих менюшек, типа @menu, я так понял?
// собственно объясню почему я ничего не выкладываю. я хочу дождаться новой версии библиотеки pixlib, чтобы дальнейшую разработку проводить с учетом структуры работы с этой библиотекой (в т.ч. API виджетов). это раз. примеряюсь к использованию TLS, это два.

Gluk wrote:это для всплывающих менюшек, типа @menu, я так понял?

Да так. Я сделал эту программку более универсальной. Все записи сохраняются в отдельном файле menu.lst. Также сделал редактор к файлу. Вот пример.

У меня тоже есть одна идея. Год назад поставил себе Talisman Desktop на XP, сразу же решил создать свою тему. Вот уже год пользуюсь прогой, тему усовершенствовал.
Думаю, неплохо было бы сделать подобный интерфейс для колибри.
Главное удобство в том, что окна могут быть постоянно развёрнутыми на весь экран и не важно сколько окон открыто.