Inkscape 0.46

Есть еще один метод, но это уже затрагивает workflow программы и позволяет решить не только вопросы быстрого отклика, но и кучу других проблем.

И? :)

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

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

> Хочешь, я напомню тебе твою теорию об ужасе невысказанного

Так вот он какой - Говард Филлипс... :>

А ты думал! :)

Ладно, уговорил. ;)

Мысль такова. Каждый векторный (да и не только векторный) рисунок, это древовидная структура областей (шейпов и битмапов) и функций (градиент, блендинг и т.д. ).

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

Изначально шейпы редактируются легко и быстро, но теперь любое изменение их формы влечет пересчет всех зависимых от них функций, что в теории может быть бесконечно долго. То есть рисунок становится трудноредактируемым. Причем помимо проблем со скоростью, появляются еще и проблемы с тем, что на экране может быть много других элементов рисунка, которые мешают редактированию конкретного шейпа. А теперь представим себе, что окно редактора может отображать не только финальный рисунок, но и состояние рисунка в любом узле этой древовидной последовательности элементов. То есть мы видим структуру рисунка в виде дерева, в котором в корне лежат шейпы, на которые все и навернуто и если мы выделяем узел конкретного шейпа, то мы и видим только этот шейп, если выделили дочерний узел с фильтром, кторый применен к этому шейпу, то увидим этот шейп с этим фильтром и т.д.

Тогда назначив на просмотр нужный нам узел, мы можем отредактировать шейп, не пересчитывая при этом все дерево рисунка и не отвлекаясь на ненужные детали. Быстро и точно.

Хм, если под функциями подразумеваются те же фильтры SVG, то это делается временным выключением всех навешенных фильтров кроме нужного. Этого пока нет, но, само собой, будет. И я даже знаю, кто это сделает :)

И ситуация несколько сложнее, если речь идёт об отрисовке клонов и втяжек.

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

И такая функция нужна безотносительно к обсуждаемой теме.

Но есть принципиальные моменты.

1) применение игнора фильтра влечет за собой изменение самого рисунка. Экспортнув битмап мы увидим, что рисунок изменился. А этого как раз и не надо. Рисунок должен оставаться неизменным. Меняется только текущий вид в окне редактирования.

2) Игнор фильтра применяется к одному фильтру. В то время как переключая точку показа в дереве можно быстро преключать отображения целых ветвей. То есть перещелк между быстрым редактированием шейпа и финальной доводкой под градиентами всегда гарантированно занимает один щелчок мышью. Не больше.

>И ситуация несколько сложнее, если речь идёт об отрисовке клонов и втяжек.

Неа. Эти функции просто могут иметь нескольких предков. от этого ничего не меняется.

Блин, ну где еще можно столкнуться втроем? ;)

Эхх... Еще бы сборка под тигра была :-/

> Хочешь, я напомню тебе твою теорию об ужасе невысказанного, рассказанную в кухне одного маленького, но очень гордого дистрибьютора Autodesk? (с) :)

Пьянствовали-с? :)

> Вас что-то конкретно и в том, и в другом огорчает?

Внешний вид в особенности ужасен...

И это по Вашему мнению конкретика? :)

> И это по Вашему мнению конкретика? :)

Ну хорошо. :)

Итак.

1. Тема иконок. Она просто ужасно некрасива. 2. Общее оформление интерфейса страдает от осуствия стандартов. Для примера - диалог Object Properties и Effects->Color->Custom... Полное безобразие с кнопками на диалогах(различаются по высоте в различных из них, в некоторых вообще отсуствуют, e.t.c) 3. Сами диалоги с точки зрения юзабилиста организованы тоже некачественно. Чего только стоит один диалог Find.

В общем, программа своим создает впечатление "детской поделки". Жаль, что разработчики сконцентрировались только на функционале.

> 1. Тема иконок. Она просто ужасно некрасива

Я знаю минимум две (!) альтернативных темы. Смотрите в системный каталог icons внимательнее :)

Пример старого скрина: http://linuxgraphics.ru/images/news/gsoc-2007-midterm/046-skeletal-1.png

> 2. Общее оформление интерфейса страдает от осуствия стандартов.

Общее оформление интерфейса страдает от недопереписанности с C на C++/GTKMM, что, как ни странно отражается и на внешнем виде диалогов.

> Для примера - диалог Object Properties

Да, этот диалог ещё не переписан.

> Полное безобразие с кнопками на диалогах(различаются по высоте в различных из них

Примеры?

> в некоторых вообще отсуствуют

Что отсутствует? :)

> Сами диалоги с точки зрения юзабилиста организованы тоже некачественно.

Юзабилист - это Вы? :)

> Чего только стоит один диалог Find.

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

> Жаль, что разработчики сконцентрировались только на функционале.

Ваше частное мнение весьма далеко от истины :)

> Я знаю минимум две (!) альтернативных темы. Смотрите в системный каталог icons внимательнее :)

О, это хорошо. :) Спасибо, не знал.

> Примеры?

Document Properties, Inkscape Preferences.

> Юзабилист - это Вы? :)

Ну, не то, чтобы я работал именно юзабилистом. Но, в своей компании я в.т.ч специализируюсь и на этом. :)

> У меня есть кое-какие мысли по его реорганизации. Будет время в апреле - напишу блюпринт.

Отлично!

> Ваше частное мнение весьма далеко от истины :)

Я очень рад это слышать. :)

P.S Show close bitton on dialogs считаю очень странным решением.

> Document Properties, Inkscape Preferences.

А где именно там кнопки разной высоты? "Take from selection" длинновата, да, но это а) следствие резиновости контейнера и б) всё-таки не высота :)

> P.S Show close bitton on dialogs считаю очень странным решением.

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

> А где именно там кнопки разной высоты? "Take from selection" длинновата, да, но это а) следствие резиновости контейнера и б) всё-таки не высота :)

Там их по умолчанию нет. :) А так же вообще нет в Fill and Stroke да, я думаю, вы и сами знаете еще где.

Высота:

Find, Trace Bitmap помню еще где-то было.

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

Да, но вопрос не в HIG'e. 99% софта пишутся именно с этой кнопкой. Т.е это "де факто" стандарт (да и попасть в кнопку Close легче чем в крестик окна). По крайней мере, так должно быть по умолчанию.

> Высота: Find, Trace Bitmap помню еще где-то было.

ОК, погляжу :)

> да и попасть в кнопку Close легче чем в крестик окна

Предпочитаемый способ сейчас - запаркованные сбоку, а не плавающие панели. В припаркованных панелях кнопок "Закрыть" отродясь не было :)

P.S. Для Ъ и не только выложил интервью с разработчиками: http://linuxgraphics.ru/readarticle.php?article_id=48

Понял, спасибо за объяснения. :)