Board.KolibriOS.org

2Mario:
Я об этом и говорю. Просто нужно же как-то определять таймаут для 23-й функции.

_________________
Не бойтесь делать ошибок. Бойтесь ничего не делать.

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

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Поздравляю! Будет еще одна нормально спроектированная программа.

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

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Надо проверять на выход за пределы координат. Ну и сначала можно проверить на нажатие кнопок.
Хотя если запланировать всплывающую подсказку, то придется каждый "пук" проверять.

запланировано уведомление виджета о:
1) мышь навелась в его область
2) мышь кликнулась в его области кнопкой Х в координатах У*Z относительно его верхнего левого угла
3) мышь вывелась из его области
все остальные события мыши виджету отправляться не будут, если очень надо - поожение курсора сам посмотрит (получив уведомление номер 1, например, и пока не получит уведомление номер 3). Так я предполагаю.

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

и вопрос в том, сообщать ли еще и о изменении текущих координат курсора в пределах области виджета

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

В gnome всплывающее сообщение виджета "часы&погода" зависит от положения курсора над виджетом.
Но мне кажется, что совсем не обязательно так делать.

Как я уже понял, мы остановились на двух вариантах
I Скриптовые виджеты:
1.Портирование существующих языков;
II Виджеты на машинном коде:
3.Загрузка виджетов в память панели.

Если Вы все "единогласно" решили, что рабочий стол должен быть гибким и настраиваемым, то так тому и быть. Ура!
Поскольку ширина панели может меняться, то виджеты должны быть масштабируемыми.
Для масштабируемых виджетов необходимо использовать векторную графику, иначе...
Вот на этом и должен быть построен весь принцип рендеринга виджетов. Именно отрисовка занимает основную часть процессорного времени на машинах с не-геймерскими видеокартами. Именно графические библиотеки имеют наибольший объём. Вот о чём нужно думать в первую очередь.
К сожалению, Gluk уже решил пойти по пути наименьшего сопротивления, реализовывая несколько "либо-каких API", ну да ладно...

Так вот, векторная графика.
Для совместимости лучше использовать уже готовые форматы. Или Вы собираетесь ещё и редактор писать?
Самые распространённые на сегодня форматы векторной графики: SVG и Flash (других, по сути, и нет).
Но у Flash есть один маленький недостаток: проприетарная лицензия.
Ещё есть формат SVG, созданный Консорциумом W3C. (Читай: стандартизированный и бесплатный)
SVG хоть и является расширением XML, но при этом может находиться в сжатом виде, что существенно уменьшает объём SVG-графики.
В общем, можете и сами почитать: http://ru.wikipedia.org/wiki/SVG .
Наверное, для масштабирования виджетов лучшего решения не найти. Стоит копать именно в этом направлении.
А Вы как думаете?
Можно попытаться портировать эту библиотеку: http://librsvg.sourceforge.net/

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.

Векторная графика элементов управления - идея здоровская, но в linux вроде никто не стесняется использовать заранее заготовленные изображения разных размеров.

Как можно сравнивать Linux и Колибри?
В Linux лишний десяток изображений никто не заметит, а в Колибри даже одна обоина не поместится.
К тому же, качество векторной графики...

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.

Векторный арт может смотреться некруто при размерах меньше, например, 16x16 пикселей, а отрисовка его (если исходное изображение рассчитано на допустим 64x64 и выше) будет работать медленнее, чем отрисовка такой же png'шки. А векторный арт с малым количеством деталей может смотреться некрасиво при большом размере изображений.
Что касается дискового размера изображений, то...
Один простой png 32x32px занимает меньше, чем один простой svg созданный в inkscape. (1,3кб против 1,7).
Конечно, этот svg можно использовать и для 16x16, и 32x32, и 64x64. Но чем больше в нем будет элементов - тем больше он будет занимать места.

Вообще, считаю, что поддержка векторных форматов нужна и важна. Главное - все делать в меру

А как быть с плавным масштабированием? Растровое изображение достаточно уменьшить на несколько пикселов...
Ведь под конфигурированием, как я понял, имеется в виду именно плавное масштабирование.
К чему холиварить? И так понятно, что у растровых изображений преимущества в отображении фотографий, а у векторных в отображении рисунков.
Не припоминаю что-то ни одной фото-панели. Ну, если что, то можно юзать libimg.

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.

ОКей но кто будет заниматься портированием libsvg?

Ну, я могу попытаться... И, может, ещё кто.
Один к одному портировать нет смысла, потому как размер будет точно такой же
Можно писать по спецификации, а принципы взаимодействия модулей взять как у линуксоидов.
Так и на пространстве сэкономим, и структура будет более-менее продуманная.

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.