Gluk wrote: Asper,
чем в данном случае SWF будет лучше? я не нашел при беглом поиске в сети ни аргументов за, ни аргументов против, кроме того, что этот формат рссчитан таки в первую очередь на анимацию, поэтому спрашиваю, т.к. с форматом этим не знаком

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

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

а еще лучше помимо этого ссылку на подробное описание формата (на русском языке), я что-то ничего толкового не нашел (при, честно говоря, не особо глубоком поиске)

а по поводу пока что основного сабжа, на повестке пусть побудут:
1) хватит ли 255 видов объектов? объектом может быть не только что-либо рисуемое, но и объявляемое и затем используемое (градиенты, шрифты, слои).
2) вводить ли разделение объектов на 127 рисуемых и 127 объявляемых (см. выше).

Мне так кажется экономия в 2 байта несущественна - зато потом не будет мучительно больно.

Mario, я просто даже пятидесяти видов объектов придумать не могу.. мм, да и, собственно, тридцати.. // кстати, вроде, 1 байт

Gluk wrote:а сам формат?
в какой степени избыточен (по лишней информации, а также отдельно - по объему, занимаемому не лишней информацией)?
в какой степени подходит для статических изображений (надо ли объявлять изображение как кадр с бесконечной продолжительностью, или что-то в этом роде)?
насколько машинонепонятен (насколько сложным должен быть код для парсинга)?

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

Вот посмотри ещё эту тему.

Gluk wrote: а еще лучше помимо этого ссылку на подробное описание формата (на русском языке), я что-то ничего толкового не нашел (при, честно говоря, не особо глубоком поиске)

Спецификация на English, на русском нет http://www.adobe.com/devnet/swf/pdf/swf ... pec_v9.pdf
Если трудности с языком, то можешь поступить с ней как предлагает Mario.
На счёт лицензии если кто ещё сомневается http://otvety.google.ru/otvety/thread?t ... 81b28e5ec9

Не понимаю почему формат, который предлагает Gluk нельзя сделать промежуточным при чтении SVG?

А может тогда вместе с исходниками виджета хранить svg-файлы и при компиляции конвертировать их в формат, который предлагает Gluk? Тогда отредактировать такую графику не заставит труда (подойдет любой редактор работающий с SVG) и нужно будет всего лишь пересобрать виджет. Согласитесь это легче, чем делать свои редакторы векторной графики или возится с hex-редактором

Nasarus истину глаголит.

..bw

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

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

Остался мааааленький ньюанс - дописать саму спецификацию.. Предлагаю кандидаты в куски спецификации просто писать в эту тему, а я соберу в один файл/пост, когда будет что собирать

по повестке только два мнения, и то, разделившиеся.. хватит ли 256 видов объектов?
надо ли вводить разделение рисуемый объект/объявляемый (прямоугольник, эллипс, звезда, спираль, ... / слой, градиент, кисть, шрифт, ...) в виде номеров слева направо (0-256) и справа налево (256-0) соответственно. Это нужно только для тех, кто будет "рисовать" прямо в таком формате, но никак не мешает и остальным (конвертеру какая разница? ну цифорка и цифорка)

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

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

Nasarus wrote:А может тогда вместе с исходниками виджета хранить svg-файлы и при компиляции конвертировать их в формат, который предлагает Gluk?

Это уже потом, а сейчас речь совсем о другом. Тем более, что они собрались всё флэшем завешать.

А ведь на самом деле всё задумывалось совершенно не так.
Знаете ли вы о Microsoft HTML Application host http://ru.wikipedia.org/wiki/HTA?
Эта программа поставляется в дистрибутиве Windows (C:\Windows\system32\mshta.exe).
Она позволяет запускать HTML-файлы и создавать окна без наличия браузера.
Эту программу, к примеру, очень часто используют различные WPI-установщики.
Как-то раз меня посетила мысль: "А почему бы не найти этому другое применение".
Вот тогда я и вспомнил о реализации панелей в Колибри.
Сам по себе формат HTML очень гибкий и межет использоваться для чего угодно.
И действительно зачем создавать панель, а потом ещё её настраивать, если можно сделать саму панель файлом настройки?

В HTML-файле панели можно будет проставлять линки на HTML-файлы виджетов, вставлять "ваши любимые флэши", разрисовывать панели и виджеты векторной графикой в формате SVG, а также запускать бинарные программы с параметрами.
Всё что описано выше уже умеют файлы *.hta , от себя ещё добавил бы возможность работы по IPC и отключил к чертям java/VB и другие всевозможные скрипты. Также панель можно было бы сжать в архив целиком.

Как видите, в результате мы не получаем Python'овских(screenlets) или JavaScript'овых(windows sidepanel) панелей, никаких интерпретируемых скриптов.
"Думают" как и прежде бинарники на ассемблере, а данные хранятся в мультимедийных файлах, пусть и с HTML-разметкой.

P.S. Если кому охота посмотреть на *.hta файлы, добавляю свою демку. Правда, она процессор грузит, потому как на JavaScript'е.

Gluk wrote:по повестке только два мнения, и то, разделившиеся.. хватит ли 256 видов объектов?

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

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

Gluk wrote:по повестке только два мнения, и то, разделившиеся.. хватит ли 256 видов объектов?

Ну, в крайнем случае, если 256 типов вдруг станет не хватать, то можно сделать так: значения от 0x00 до 0xFE будут обозначать объект определённого типа. Если же байт равен 0xFF, то это - "расширенный" (условно говоря) объект, и его тип задаётся следующим байтом/словом/двойным словом.

Например:
0x00 - линия
0x01 - кривая Безье
0x02 - прямоугольник
...
0xFE - звезда
0xFF 0x00 - спираль
0xFF 0x01 - ещё что-нибудь
...
и т.д.

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