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

Projects yet to be implemented in working code
  • обновил документацию и бинарик, изменения описаны в том же посте что и файлы. Еще немного и можно будет над элементами панелей начинать работать =)
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Поздравляю! Будет еще одна нормально спроектированная программа.
  • нужно ли виджету знать в какой именно точке его области находится курсор мыши, если ни одно кнопка мыши не нажата (курсор просто наведен на область)? я считаю что нет, хватит и самого факта наведения, но т.к. я не собираюсь все виджеты писать в одиночку, решил узнать мнение сообщества)
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Надо проверять на выход за пределы координат. Ну и сначала можно проверить на нажатие кнопок.
    Хотя если запланировать всплывающую подсказку, то придется каждый "пук" проверять.
  • запланировано уведомление виджета о:
    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/
    Last edited by konstantin_666. on Mon Aug 16, 2010 11:00 am, edited 2 times in total.
    Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
  • Векторная графика элементов управления - идея здоровская, но в linux вроде никто не стесняется использовать заранее заготовленные изображения разных размеров.
  • Как можно сравнивать Linux и Колибри?
    В Linux лишний десяток изображений никто не заметит, а в Колибри даже одна обоина не поместится.
    К тому же, качество векторной графики...
    Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
  • Векторный арт может смотреться некруто при размерах меньше, например, 16x16 пикселей, а отрисовка его (если исходное изображение рассчитано на допустим 64x64 и выше) будет работать медленнее, чем отрисовка такой же png'шки. А векторный арт с малым количеством деталей может смотреться некрасиво при большом размере изображений.
    Что касается дискового размера изображений, то...
    Один простой png 32x32px занимает меньше, чем один простой svg созданный в inkscape. (1,3кб против 1,7).
    Конечно, этот svg можно использовать и для 16x16, и 32x32, и 64x64. Но чем больше в нем будет элементов - тем больше он будет занимать места.

    Вообще, считаю, что поддержка векторных форматов нужна и важна. Главное - все делать в меру :)
  • А как быть с плавным масштабированием? Растровое изображение достаточно уменьшить на несколько пикселов...
    Ведь под конфигурированием, как я понял, имеется в виду именно плавное масштабирование.
    К чему холиварить? И так понятно, что у растровых изображений преимущества в отображении фотографий, а у векторных в отображении рисунков.
    Не припоминаю что-то ни одной фото-панели. Ну, если что, то можно юзать libimg.
    Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
  • ОКей :) но кто будет заниматься портированием libsvg?
  • Sorcerer wrote:ОКей :) но кто будет заниматься портированием libsvg?
    Ну, я могу попытаться... И, может, ещё кто.
    Один к одному портировать нет смысла, потому как размер будет точно такой же :)
    Можно писать по спецификации, а принципы взаимодействия модулей взять как у линуксоидов.
    Так и на пространстве сэкономим, и структура будет более-менее продуманная.
    Last edited by konstantin_666. on Mon Aug 16, 2010 11:30 am, edited 1 time in total.
    Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.
  • Who is online

    Users browsing this forum: No registered users and 4 guests