Board.KolibriOS.org

SVG сам по себе довольно простой формат, однако спецификация по нему не такая уж крохотная.
Кстати, в Колибри ведь есть библиотека вывода векторной графики, так что заниматься выводом непосредственно графики может и она. Нужен "всего лишь" парсер Нечто примитивное можно написать довольно в короткие сроки...

Sorcerer wrote:SVG сам по себе довольно простой формат

Да, уж... одних только типов данных 35

Sorcerer wrote:Кстати, в Колибри ведь есть библиотека вывода векторной графики

Какая?

konstantin_666. wrote:Sorcerer писал(а):
Кстати, в Колибри ведь есть библиотека вывода векторной графики

Какая?

Библи отека векторных функций: viewtopic.php?f=9&t=1319

konstantin_666. wrote:Sorcerer писал(а):
SVG сам по себе довольно простой формат

Да, уж...

Сложный?
Картинка 400x400, прямоугольник (0,0)-(400,400) без заливки с линией толщиной 5пкс и прозрачностью линии 0.5,
слой с прозрачностью 0.7 и толщиной линий 0.5пкс, и в нем три окружности, смещенные относительно центра.

Ну, что же, значит нужно писать.
Если кто захочет поучаствовать, номер аськи в профиле. Если не будет в сети, пишите в личку.
А то и так уже тему засорили. Модераторы вряд ли почистят.

По хорошему надо бы отделить тему про SVG от темы панели. В свое время форум чистился своевременно, но некоторым это не нравилось (мне в том числе)

konstantin_666, классная идея про использование векторной графики! а я прям как-то и не знал даже что такое бывает!.. хотя и упомянул это в одном из постов (полтемы назад, кажется, см. чуть ниже), а также в документации. Сорри за сарказм.
"Вс янв 31, 2010 2:31 am ... и возможно средства для векторного рисования."

"Если Вы все "единогласно" решили, что рабочий стол должен быть гибким и настраиваемым, то так тому и быть. Ура!" - не единогласно, но я насчитал большинство голосов

"II Виджеты на машинном коде:
3.Загрузка виджетов в память панели." - вот это. Скриптовые языки и не рассматривались ввиду мифичности этого направления в среде КолибриОС. А загрузка виджета в память панели позволяет панели позаботиться о загрузке всех библиотек, что могут понадобиться виджетам (в заголовке виджета будет указано, какие библиотеки ему нужны, не нужные никому (панели самой в т.ч.) библиотеки грузиться не будут). Впрочем, это уже детали

про SVG - надо просто переконвертировать файлы из человекопонятного XML в машинопонятный бинарный код вида "[байт что рисовать - 1 круг, 2 прямоугольник, и т.д., или что объявить, 3 - градиент][байт/слово/двойное слово (зависит от возможного числа праметров) - битовая маска какие из всех возможных (поддерживаемых) параметров этого объекта далее указаны, например начало такое 1010..][набор байт, слов, двойных слов, строк с длиной в начале (нуль может быть частью строки, посему не нуль-завершенные) - это набор параметров. для примера мы рисуем, допустим, прямоугольник, и его возможные параметры (некоторые) - высота, цвет линии, ширина, цвет заливки. допустим, что они идут первыми. тогда из предыдущего примера (помните, да, 1010..?) в списке параметров будут указаны подряд две величины - высота и ширина, а цвет линии и прямоугольника либо дефолтны, либо как у предыдущей фигуры][следующий объект..]"
сделать это не сложно (а парсить готовый такой код - дыки одно удовольствие), я делал нечто подобное (в действительности, довольно близкое) для хтмл, когда пытался делать браузер, и оно работало, причем неплохо. Но тогда это было чисто внутрипрограммное решение, а тут предлагаю в таком формате сохранять файлы, ну и хранить бинарно внутри программ-виджетов. Прошу считать этот пост кандидатом на спецификацию такого формата, т.к. не очень хочется чтобы панель при работе распарсивала человекопонятный XML, который человек-то никогда, видимо, и не увидит =)

ВНИМАНИЕ, на пост этот прошу сюда не отвечать, сейчас создам соответствующую тему

Gluk

"Если Вы все "единогласно" решили, что рабочий стол должен быть гибким и настраиваемым, то так тому и быть. Ура!" - не единогласно, но я насчитал большинство голосов

Во оно всегда так - автор стоит в сторонке и тихо помалкивает, пока остальные решают что и как ему делать. Поздравляю с прозрением.

Интерфейс виджетов будет основываться на векторных форматах SWF или BFG(VS) [ссылка на обсуждение выше], либо в растровом формате (но тогда виджет должен учитывать всякие разные масштабирования самостоятельно).
Т.е. реализованы будут все варианты, а автор виджета уже выбирает что ему удобнее использовать.

Gluk: "Скриптовые языки и не рассматривались ввиду мифичности этого направления в среде КолибриОС." - недальновидно было сказано. Теперь концепцию приходится сильно менять, но оно и к лучшему.

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

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

Помимо этого: настройки панелей теперь считываются из бинарных файлов, имеющих имена top.s, bottom.s, left.s, right.s, которые должны лежать рядом с бинариком.

Мысли читателей (предполагаемые мною): "Где бинарик/исходники?" - исходники - когда будет достигнут функционал @panel. Бинарики (ну потестить, пореверсить, посмотреть - да мало ли зачем) - когда сделаю компиляцию файлов настроек fasm'ом из одноимённых файлов (top, bottom, left и right) с расширением .a, лежащих рядом же. Зачем? Чтобы не слышать ни слова про ini облегчить редактирование настроек. Синтаксис простой, будут макросы и образцы. Компиляция, забыл сказать, автоматическая.

Ещё раз про виджеты - это файлы, лежащие в некой директории, имеющие расширение .wc для компилированных, .wpy для питоновских, .wls для лисповых и т.д. (или .ws для скриптовых всех - обсуждаемо), они запускаются панелью с параметром, содержащим имя именованной области памяти, приготовленной для них. Виджеты будут нескольких типов, не беспокойтесь о повторном использовании, о нём будут беспокоиться авторы виджетов.

кстати, такое построение связи с виджетом позволяет их создавать на основе имеющихся программ. Например, менюшной программы:

пусть есть программа, показывающая меню, подменю - многопоточное приложение.
пусть есть готовая revo-панель (вот уж фантастика...)
в панель надо добавить кнопку меню слева снизу (панель нижняя горизонтальная, т.е. №0)
как меняется программа меню для интеграции:

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

что делает код примера? он просто следит за кнопкой и реагирует на событие нажатия созданием потока, адрес старта которого - бывшая точка входа в программу Menu. Всё, остальной код работает как обычно.

остаётся только полученный после компиляции бинарик положить в нужную папочку с нужным расширением (.wc, наверное), прописать его загрузку в файле настроек (bottom.a), ну и скомпилировать настройки (для получения bottom.s, это будет происходить автоматически при перезапуске панели по горячей комбинации - ctrl+alt+backspace - сейчас это завершение, но последнее будет переназначено, видимо, т.к. завершаться нечасто придётся, я надеюсь).

Я думаю, работы в данном простом (я не специально попроще выбрал - просто это одна из первостепенных функций панели) случае, если повезёт, без учёта тестирования, минут на 10.

Для диспетчера окон надо заново писать виджет будет, для трея тоже, а вот в часы можно превратить приложение календаря.

Если кто-то подумал, что это плохо, держать большие приложения в памяти:
1) меню - не большое приложение
2) календарь - тоже
3) если 1) or 2) == false, можно и отдельным приложением виджет, с запускалкой приложения вместо потока - такой пример тоже будет.

Впрочем, примеры будут не сложны, так что может были бы и не обязательны, но они будут брать на себя всю специфику работы revo, снимая ношу сию с плеч разработчика виджета - оный работает над функциональностью лишь.

Артем тебе вместо сумбурных постов на форуме было бы лучше оформить внятную документацию - глядишь бы и сам перестал запутываться и другие бы по делу говорили.

Mario, ещё лучше бы мне вообще приложение закончить, вместе с документацией... Пойду посмотрю как там fasm'ом компилировать

Файлы настроек уже компилируются fasm'ом успешно, но бинарик остался на выключенном компьютере. Будет нужен - говорите, выложу.

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