Board.KolibriOS.org
https://board.kolibrios.org/

Другой взгляд на интерфейс, альтернатива @panel
https://board.kolibrios.org/viewtopic.php?f=39&t=1336
Page 9 of 11

Author:  konstantin_666 [ Wed Feb 03, 2010 5:33 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  Gluk [ Mon Mar 15, 2010 1:31 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  Mario [ Mon Mar 15, 2010 1:40 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  Gluk [ Thu Aug 12, 2010 11:53 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  Mario [ Fri Aug 13, 2010 12:18 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  Gluk [ Fri Aug 13, 2010 12:33 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  Gluk [ Fri Aug 13, 2010 10:49 pm ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  SoUrcerer [ Sat Aug 14, 2010 10:57 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  konstantin_666. [ Mon Aug 16, 2010 5:29 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

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

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

Author:  SoUrcerer [ Mon Aug 16, 2010 9:57 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  konstantin_666. [ Mon Aug 16, 2010 10:16 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  SoUrcerer [ Mon Aug 16, 2010 10:35 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

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

Author:  konstantin_666. [ Mon Aug 16, 2010 10:40 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  SoUrcerer [ Mon Aug 16, 2010 11:03 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

Author:  konstantin_666. [ Mon Aug 16, 2010 11:10 am ]
Post subject:  Re: Другой взгляд на интерфейс, альтернатива @panel

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

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

Page 9 of 11 All times are UTC+03:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/