[sK1 project] Разработка векторного редактора.

там есть несвободная компонента libCDraw.a

Дык ведь

LICENSE TO USE AND MODIFY SOFTWARE
----------------------------------

This file is part of Xara LX.

Xara LX is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License version 2 as published
by the Free Software Foundation.

>GTK'шный GIMP под Linux ещё более-менее, но под вендой - лучше перед сном не видеть.

Шел бы ты отсюда, петушок, со своим оффтопиком.

>в дебе xaralx лежит в non-free, не в main.

Да в этом дебиане, поди, и фаерфокса в main нет. Только какой-то ушибленный айсвизель.

Я бы тоже не хотел чтобы кто-то вносил изменения в sK1 и потом продолжал его распространять не меняя название.

Интерфейс у sk1 просто вырвиглазный. Шкуру надо было вчера менять.

>apt-get source xaralx прошло и вроде нет ни одного бинарного файла, на вскидку. текст gpl тоже приложен.

К сожалению, в XaraLX самое «вкусное» в виде бинарного блоба - модуль cdraw (аналог cairo) который Xara лицензировала у сторонних разрабов. Ее перетащили на cairo, но в итоге получилось ни то ни се.

Но дело даже не в этом. Разработка на C++ гораздо более трудоемка, нежели гибрид Python+C (в ~10 раз). Держать ораву в 20-30 девелоперов для опенсурса мало реально. Особенно когда разноязычное вавилонское столпотворение как в «базарной» разработке.

>Интерфейс у sk1 просто вырвиглазный. Шкуру надо было вчера менять.

Об этом и речь - дофига усилий на его причесывание и все-равно как седло на корове :)

блин, а кому нужна свободная обертка вокруг блоба? :((

Немного оффтопа, но, увидав тему в трекере прочитал как «Разработка ядерного реактора». Задумался...

Где то близко. Наверно такая же нудная работа, дающая всем радость и свет :)

Для каких целей был создан sK1? Векторный редактор. Векторный редактор для кого? Допустим для профессиональных студий дизайна. Кто сегодня «программа для профи»? Корел, Иллюстратор. Самые распространенные, и вряд ли их сместят другие ПЛАТНЫЕ аналоги. Хотя иллюстратор вроде как нишу занимает заметно больше, чем корел.

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

Ваш КЭП.

И не важно QT это будет или GTK. Помоему разницы особой нет: Оба тулкита одинаково портабельны. GTK3 помоему уже аппаратную поддержку имеет. GTK бинд на Python 3 вроде есть

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

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

Сейчас наберём список всего нужного отсортируем в порядке надобности оценим время и вперёд.

Так вы таки скенсил будете поддерживать или тоже бросаете? :)

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

>Так вы таки скенсил будете поддерживать или тоже бросаете? :)

Скенсил как был простой векторной рисовалкой, так и останется. Это собственно и было заявлено при возрождении проекта. Из серьезных вещей его ожидает только портирование на Gtk.

>блин, а кому нужна свободная обертка вокруг блоба? :((

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

Ну попробовал ... практически пустой проект (пару овалов) - тормозит ресайз рабочего окна на трехядернике 3.3 Мгц (и это при нормальной работе дров для видео).
Если вы ухитрились сделать тормозиллу на tk, то чего следует ожидать на gtk ?

>Ну попробовал ... практически пустой проект (пару овалов) - тормозит ресайз рабочего окна на трехядернике 3.3 Мгц (и это при нормальной работе дров для видео). Если вы ухитрились сделать тормозиллу на tk, то чего следует ожидать на gtk ?

Можно подробнее про проблему? Что тормозит? и более точно, что на канве?

да перерисовка меню при растяжке - правый скролбар и меню выбора цвета
ну я первый раз такой отклик на tk вижу...
зы:
Ба, да тут сплошное злоупотребление питоном !!))
Ну тады нет вопросов ))

Пардон, протупил :) Да, ресайз окна тормозит - это фишка tk. Особенно хорошо проявляется, если не установлен композитный оконный менеджер. tk виджеты работают в single thread и обновляются по очереди. Причем после того, как прекращается ресайз окна. В итоге это воспринимается как тормоза.

>Ба, да тут сплошное злоупотребление питоном !!))

Ну тады нет вопросов ))

Это «злоупотребление питоном» отрисовку канвы делает шустрее, нежели кошерный Inkscape на правильных C++ ;) А улучшить виджетсет... Чесслово - забодался уже с ним бороться. Целый пакет с костылями уже тащим (sk1sdk). Потому и обсуждается вопрос миграции на gtk.

> это фишка tk.

эмм..., сомневаюсь, что это основное.

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

2. DE Gnome. Открыть файл - бац, диалог открытия файла подлез под основное окно редактора . Это не есть good.))

> 1. меняю только высоту окна
+++

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

>2. DE Gnome. Открыть файл - бац, диалог открытия файла подлез под основное окно редактора . Это не есть good.))

А че вы хотите от tk? ;) Она с оконным менеджментом паршиво дружит.

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

Проще виджетсет сменить. Палитра сама по себе перерисовывается шустро - погоняйте цвета кнопками (прямая отрисовка зерез Xlib). Но если в виджетсете стоит задержка на 0.5 сек. после события <Configure> , то тут хоть об стенку лоб расшиби - не ускоришь никак. А визуально воспринимается как тормоз: появляется новый фрагмент окна залитый дефолтным цветом, потом задержка виджетсета и лишь после этого иксы практически моментально обновляют палитру. Видимое изменение - нижняя часть палитры моргает, как будто медленно перерисовывается.

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

Первый ряд структурно не меняется. А второй ряд (контекстная панель) реагирует на события внутри редактора и при изменениях обновляется полностью заново (перерисовка, появление группы выбранных объектов на канве и т.п.)

Чтобы не вводить в искушение, сразу скажу - сабж топика появился не с перепою под НГ :) Первоначальное решение было принято полгода назад и основывалось на массе тестов по перформансу. И после этого тоже было проведено куча анализа по текущей ситуации и что нужно делать.

Решение о переписывании с нуля далось не легко - искренне душила жаба закопать труд за столько то лет развития редактора. Но если архитектурные косяки были заложены изначально в Скенсиле - тут крайне тяжело отрефакторить. Особенно это касается питонской части кода (логика приложения). Переписывание с нуля - гораздо более быстрый путь. Тем паче, что замечательный предлог - переход на новый виджетсет (т.е. весь код UI сразу в треш).

Пара вещей, которые помогают в работе:

- Возможность редактировать контуры сразу у нескольких объектов.

- Каждое выделение/снятие выделения считается как действие. Профит - можно отменить выделение не того объекта (когда их выделено 50 шт, это уже критично :) ) или отменить сброс выделения.

С контурами согласен.

На счет отмены выделения не вижу смысла, лучше проработать удобство выделения объектов несколькими способами. Кстати в инке с этим делом всё нормально. Текущая имплементацию в sK1, лично мне не нравится и новички постоянно жалуются, по тому что необычно.

только что скачал на «поюзать» sk1. С компизом отрисовка вполне себе. Каждое меню отрисовывается как отдельное окошко. Но вот с метасити совсем не айс.

>только что скачал на «поюзать» sk1. С компизом отрисовка вполне себе. Каждое меню отрисовывается как отдельное окошко. Но вот с метасити совсем не айс.

Без композита начинает буянит tk виджетсет, тормозя на каждом оконном эвенте.

>На счет отмены выделения не вижу смысла, лучше проработать удобство выделения объектов несколькими способами.

Это удобно, когда выделил 49 объектов, а потом чихнул и всё сбросилось. Хотя может и не нужно.

Ещё идеи про выделение:

- Shift+click - инвертирование выделения (как сделано в большинстве редакторов). Ctrl+click - снятие выделения c объекта. Ctrl+Shift+click выделение объекта.

- Отображение выделенного. Когда много объектов друг над другом, не всегда понятно, что выделенно. Может быть будет удобно, если контур будет подсвечен (только это должно быть отключаемо, иначе будет много матерков). И/или предпросмотр объекта в отдельном окне (например, уменьшенное изображение объекта во вкладке свойств).

- Если контуры будут подсвечиваться, может сделать последний выделенный другим цветом. Будет удобно при булевых операциях и расстановке объектов.

- Лассо для выделения (хотя это не так сильно нужно).

В топку понтовый микс векторорастровой графики с неточными координатами узлов - Корел. Посмотрите вдумчиво на Адоб Иллюстратор.
Это очень мощный и точный инструмент по работе с вектором. Сделать аналогичную функциональность, да чтобы не тормозило как инкскейп, было бы очень круто.

В топку понтовый микс векторорастровой графики с неточными координатами узлов - Корел. Посмотрите вдумчиво на Адоб Иллюстратор.

Это очень мощный и точный инструмент по работе с вектором. Сделать аналогичную функциональность, да чтобы не тормозило как инкскейп, было бы очень круто.

Увы, разработчики sK1 «отсидели» за Корелом по 10-15 лет в полиграфии. Тяжело спрятать в карман такой опыт :) Но вы правы - к Люстре нужно внимательно присмотреться.

Кстати, от имени sK1 Project Team поздравляем ВСЕХ С НОВЫМ 2011 ГОДОМ! :)

Увы, разработчики sK1 «отсидели» за Корелом по 10-15 лет в полиграфии.

Возможно иллюстратор и мощная штука, но не нравиться мне ихний UI, что у иллюстратора, что у фотошопа. Кореловский PhotoPaint мне больше нравится, до этого сидел в фотошопе. Да и с цветопередачей и точностью его воспроизведения на разных устройствах Корел получше искаропки.

Вот только не надо про цветопередачу пожалуйста. Я сам отдал много лет жизни полиграфии, и то, как растеризует градиенты Корел при создании eps для последующего вывода цветоделенных пленок для оффсетной печати - это тихий ужас. Вернее это непредсказуемая рулетка.
Инструмент не должен нравиться или не нравится. Он должен максимально быстро и точно выполнять задачу профессионала его использующего. И этот инструмент не даже не обязан быть удобным с точки зрения нового или необученного пользователя.
Корел же пытается быть ближе к простым людям, да. Наваять в нем мегадизайн визиток для ООО «Рога и копыта» - сможет и одаренный сынишка главбуха и штатный эникейщик. Однако чтобы потом это напечатать - верстальщику печатной конторы придется произвести много работы. И в 80% случаев первый этап этой работы будет перевод макета в .AI

>то, как растеризует градиенты Корел при создании eps для последующего вывода цветоделенных пленок для оффсетной печати - это тихий ужас. Вернее это непредсказуемая рулетка.

Корел с Адоби форматами не дружит по идеологическим причинам. У него и импорт из серии «обнять и плакать».

Корел же пытается быть ближе к простым людям, да. Наваять в нем мегадизайн визиток для ООО «Рога и копыта» - сможет и одаренный сынишка главбуха и штатный эникейщик. Однако чтобы потом это напечатать - верстальщику печатной конторы придется произвести много работы. И в 80% случаев первый этап этой работы будет перевод макета в .AI

Собственно, как уже не раз озвучивалось, цель проекта sK1 создать инструмент с низким порогом вхождения и с высококачественным результатом в печати. UI никак не связан с качеством экспортера в Postscript. Главное не создавать артефакты, которые потом будет крайне сложно влепить в PDF (а корректный PDF конвертнуть в PS можно брутальным AcroReader'ом).

Корел при создании eps для последующего вывода цветоделенных пленок для оффсетной печати - это тихий ужас. Вернее это непредсказуемая рулетка.

В чем проблема то? Самому кореловские файлы печатать редко приходилось. Что мешает сделать UI как у корела и без багов? Да и удобный UI наверное плюс, чем минуст.

> Чем больше исходных запросов, тем лучше. Заранее спасибо.

Как с Вами связаться?

>Как с Вами связаться?

http://sk1project.org/contact.php

>Как с Вами связаться?

Ну или тут: http://www.linuxgraphics.ru/forum/viewthread.php?thread_id=924

Линуксу жизненно не хватет хорошего векторного редактора, хоть немного приближающегося к возможностям XARA, и написанного на чистом Qt.

Inkscape уныл, хотя альтернатив нет. Поэтому приходится плакать, но использовать его.

Фреймверк Qt идеально подходит для старта нового проекта векторного редактора. Если сделать хорошую базовую объектную модель графических элементов, как в XARA (смотрим код XARA LX), то результат будет хорош.

Если вы опять замкнётесь на питоне или GTK, то у вас получится очередной УГ.

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

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

Инк RGB редактор. И для своих задач он хорош (за исключением тормозов при размытии).

Есть потребность (по крайней мере для меня) в CMYK редакторе, для замены корелу.

Кстати, хотелось бы у авторов узнать, для решения каких задач позиционируется SK1?

> Кстати, хотелось бы у авторов узнать, для решения каких задач позиционируется SK1?

Расчет идёт на удовлетворение потребностей рынка полиграфии. Основная цель генерация PDF-файла соответствующего условиям цифровой, листовой офсетной печати с учетом отраслевых стандартов. Также изготовление рекламных материалов, публикуемых в журналах и газетах.

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

Без экспорта в формате TIFF (CMYK), с возможностью выставить dpi никак

>Поэтому сначала сделаем gtk версию (порт на венду возможен), а потом будем экспериментировать с qt.

Зачем распылять усилия, если можно сразу сделать на Qt?

Я тоже больше склоняюсь к qt. В любом случае до работы над интерфейсом еще далеко. Может Игорь и передумает.