что думаешь по этому поводу?

А что я? Поддерживаю. sK1 Color Picker или даже sK1Picker звучит лучше чем просто Color Picker.

Возможно, и sK1/UniConvertor 2.0 стоит назвать sK1Editor и sK1Convertor соответственно.

А что я? Поддерживаю.

Ну значит так и запишем :)

Возможно, и sK1/UniConvertor 2.0 стоит назвать sK1Editor и sK1Convertor соответственно.

Ну это уже устоявшееся - четко с проектом ассоциируется. Да и клешей с другими вроде нет.

устоявшееся - четко с проектом ассоциируется

Переписывание тулкитов - вот что четко с проектом ассоциируется ;)

Это лозунги переводчиков, слабо понимающих что происходит. Проект начал использовать wxWidgets в 2013м, когда началась ветка sK1 2.0 До этого были сделаны прототипы на Qt и Gtk, но они не получили развития. Да и никуда особо не экспонировались. RC1 был уже на wxWidgets, причем на паттерне WAL (Widgetset Abstarction Layer… но паттерны, как нам тут объяснили «знающие» - это НИНУЖНО). Без R&D фазы глупо было бы начинать такую махину лепить. Но альтернативно одаренные восприняли все по-своему :)

Проект начал…

Стоп! Харе! Не надо мне пересказывать историю, я могу и в википедии почитать :D

Как там разработка sK1 2.0 продвигается? Будет еще что-то добавлятся до релиза? И когда релиз будет?

вот что четко с проектом ассоциируется

Я когда писал про «дежурные ведра с дерьмом» совершенно не преувеличивал. Почивший в игноре гражданин занимался регулярно этим, особенно любил проехаться по «переписыванию», хотя прекрасно знал, что это были исследовательские прототипы.

Серьезная смена виджитсета была только одна и сопровождалась полной переимплементацией кода, потому как старый код менять и совершенствовать было нереально (да и виджетсет Tk протух). Кстати, тоже по причине игнорирования в работе паттерна MVC, хотя таковой был формально задекларирован в документации Skencil. Но на практике весь код был запутанным клубком, который рефакторить не получалось из-за массы неявных взаимосвязей. Меняешь одну часть - отваливается функционал совершенно в другом месте, которое по логике не должно было быть связано с изменениями.

А паттерн WAL (хоть паттерны это НИНУЖНО) уже много раз дал положительный результат. Его смысл заключается в том, что виджетсет напрямую не используется, а юзается через абстракционный слой, что позволяет:

• уменьшить объем кода UI (в 2-3 раза)
• серьезно облегчить миграцию между версиями тулкита или на другой тулкит

Последнее уже было - с gtk2 на gtk3 переход никто и не заметил, а несовместимостей там хватало. Даже несмотря на wxWidgets - разница все-равно в тулкитах была и код, работавший на gtk2 просто фейлился на gtk3. sK1 вот прямо сейчас работает и на wxWidgets-gtk2 и на wxWidgets-gtk3.

Как там разработка sK1 2.0 продвигается? Будет еще что-то добавлятся до релиза? И когда релиз будет?

Нет. Запланированные к релизу фичи уже все готовы. Ну разве что мелкие фиксы будут. В январе допилю фильтры импорта и скорее всего на этом и отрелизимся. В планах большего не было.

BTW: Есть красивая дата для релиза - 02.02.2020 ;)

Следующий этап - миграция на python3. Все базовые вещи, в которых есть расхождения между py2 и py3 уже обкатаны и пофикшены в Color Picker. Думаю, серьезных проблем с миграцией не будет

но паттерны, как нам тут объяснили «знающие» - это НИНУЖНО).

Они нужны тем, кто не понимает, что такое архитектура проекта.
Но «мыслящие» паттернами - пациенты с 6-й палаты.

Владимир

Паттернами не мыслят. Их соблюдают. И из них делают архитектуру проекта. А если их не знают, да еще и забывают, то получаются зачотные клубки спагетти.

Во избежание дальнейших недоразумений советую прочитать статью самого Новикова образца 2011 года:

http://digilinux.ru/2011/10/12/perezagruzka-proekta-sk1/

«Как уже упоминалось ранее, перед нами стояла задача определиться, какой из ведущих виджетсетов начать использовать — GTK+ или Qt. Чтобы решить эту задачу, мы поступили крайне просто: написали первичные функционирующие макеты на обоих тулкитах...»

«Исходя из перечисленного выше, выбор пал на GTK+.»

«Итак, за основу будущего редактора был взят GTK+.»

«Поскольку GTK+ не предоставляет готового решения MDI, интерфейс пользователя для управления документами был разработан на вкладках (a-la Firefox).»

Дальше есть уже личная переписка от августа 2013 года, в которой Новиков пишет, что в мае 2013 года при портировании приложения на винду и мак вылезли проблемы с pygtk, поэтому переползли на wxWidgets. Упоминается, что до того момента wxWidgets два года не смотрели, т.е. с момента выбора тулкита при ребуте проекта в 2011 году, когда было анонсировано, что приложение уже переписано на GTK+ после тестов (см. выше слова самого же Новикова).

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

Мне несложно

Но зачем? Лучше потратить время на тестирование и написание патчей.

Но зачем?

Ну вот ты общаешься с гражданином, который тебе и окружающим открыто врёт, а когда уличают во вранье — шлангует.

Ты готов смотреть на это сквозь пальцы только потому, что гражданин пишет некий полезный код? Т.е. надо к этому относиться с позиции «Ой, ну ха-ха, это просто наш Игорь, он такой»?

Но это же ничем принципиально не лучше чем, «Ой, ха-ха, ну это просто наш фюрерпрезидент страны, он такой».

Я на это смотрел 14 лет или около того и вижу, что от года к году дела только хуже. Самим софтом можно пользоваться или не пользоваться — по надобности. Поддерживать контакт с таким разработчиком — ну на хер.

Лучше потратить время...

Что, собственно, и.

Т.е. надо к этому относиться с позиции

Т.е., если хочется разводить срач — есть же толксы.

Ну вот ты общаешься с гражданином, который тебе и окружающим открыто врёт, а когда уличают во вранье — шлангует.

Поразительно! Поциент пересказывает другими словами/цитатам мой пост, с точно таким же смысловым содержанием и делает глубокомысленный вывод про вранье.

Вот сложно даже понять что это:

• то ли Прокудин настолько не в теме, что не разбирается в написанном (искренне сомневаюсь - слишком давно трется в разработке)

• то ли у него измененное состояние сознания (тоже маловероятно - ЗОЖ и всякое такое)

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

Из всех вариантов я вижу подходящим только последний. Тем более, что на ЛОРе за таким занятием Прокудин уличался уже многократно в спорах.

Кстати, вот и пример лжи и передергиваня Прокудина:

приложение уже переписано на GTK+

КАК МОЖНО ТАКОЕ ЗАЯВИТЬ, если ни RC релиза, ни кода Прокудин не видел и видеть не мог, поскольку их не было. Речь шла ТОЛЬКО про прототип. Из Qt и Gtk был выбран Gtk, но чуть более проработанный прототип показал кучу проблем на винде, а на маке так совсем трешак. И когда в 2013 было выполнено сравнение wxWidgets и Gtk по проблемным моментам, стало понятно, что wxWidgets гораздо лучше подходит для разработки. И даже название у прототипа было другое - PrintDesign. Разница между «уже переписано» и «начали писать» просто колоссальная.

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

2020: sK1 2.0 & Python 2.x ?

• https://github.com/sk1project/sk1-wx

Please note that application uses Python 2.x version. So Python interpreter and python based dependencies should be for 2.x, but not 3.x

С 1 января 2020 года ветка Python 2.x является ‘deprecated’, и (скорее всего) уже НЕ будет входить в состав новых релизов дистрибутивов Linux:

• https://www.python.org/doc/sunset-python-2

Linfan, что дальше?

Как уже выше по треду отмечалось по этому поводу:

Color Picker 1.0 — свободный десктопный редактор палитр

Разработка этого проекта преследовала две цели: -… -Спортировать базовую часть sK1/UniConvertor на Python3.

Возможно я недостаточно детально объяснил, но при разработке color-picker брались базовые фрагменты sk1/uc2 и портировались на py3. В частности, спортировано управление цветом (да, color-picker саппортит cmyk, lab, grayscale и spot цвета) и система управления фильтрами/моделями импорта-экспорта. Весь UI код sK1 практически полностью py3-compatible. Отрелизим 2.0 и на версии 2.1 перейдем на py3 без суеты.

ОК.

FTR, Тут люди просят добавить фичу с обрезанием пересекающихся кривых (как в CorelDRAW)

• https://twitter.com/dncnmckn/status/1220646728929628160

Давай в тикет. Только попроси чела подробнее - может нарисует, что ему нужно. Обрезать линии можно по-разному. Это похоже на подготовку к порезке пленки на плоттере, но лучше уточнить.

Вангую что речь идёт про splitting

Такую фичу без интеграции 2geom вряд ли получится реализовать.

Но фича реально нужная, и в Inkscape её тоже нет (автор фичереквеста уже проверил)

• https://twitter.com/dncnmckn/status/1220812539937939457

Так что в sK1 надо добавить такой инструмент.

2geom интегрировать будет необходимо и не только из-за этой фичи. Многие операции с кривыми Безье требуют такой библиотеки.

maxim2, atsym в команде +1 переводчик - теперь и итальянский есть.

Хотелось-бы поскорей увидеть эти фичи в ночнушках

Linfan, может в WAL вместо наследования использовать композицию? Чтобы не смешивать методы.

class Application(wx.App): pass

class Application(object):
    _w = None

    def __init__():
       _w = wx.App()

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

Сейчас методы не смешиваются - в sk1 они по PEP8, а в wxpython юзается camelcase, из-за автогенерации по плюсовым сорцам wxwidgets:

    def exit(self, *_args):
        self.Exit()

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

Хотелось-бы поскорей увидеть эти фичи в ночнушках

Увы, теперь есть еще работа, которая не позволяет кодить круглосуточно.

maxim2, atsym и опять возвращаясь к началу, «перезагрузке» проекта. Ряд просветвленных личностей ржали тогда над тем, что Qt «может иметь лицензионные проблемы» и нежелателен для sk1. Нонче виртуальное становится явью:

Qt Company объявила о изменении модели лицензирования фреймворка Qt

Об отображении метаданных/свойст PDF-файлов, экспортированых из sK1

Немного офтоп, но «я четыре года ждал»

• https://github.com/sumatrapdfreader/sumatrapdf/issues/498#issuecomment-581681013

(на самом деле, нет; уже и забыл)

Надо будет этот PDF найти в архиве и разместить по корректному адресу.

Кстати, почти в тему - maxim2 atsym вроде эксперименты по рендерингу CMYК изображений через cairo получились успешными. Поэтому буду запиливать в продакшин:

https://github.com/sk1project/sk1-wx/issues/252

И походу тема «Cairo and CMYK rendering» будет сабжем доклада на LGM2020.

Кстати. Планирую генератор текстур замутить. Как в корел/ксара. Чисто для прокачивания скила в С++. Потом ZebraTrace переделаю.

Дело хорошее, только зачем кресты то?

А какие есть варианты?

Python+С или Cython

Python+С или Cython

Или Inlinec

• http://www.opennet.ru/opennews/art.shtml?num=52306

вроде эксперименты по рендерингу CMYК изображений через cairo получились успешными. Поэтому буду запиливать в продакшин:

Жду в ночнушках ;)

И походу тема «Cairo and CMYK rendering» будет сабжем доклада на LGM2020.

Здорово! Так понимаю что релиз sK1 2.0 будет тоже там представлен?

Так понимаю что релиз sK1 2.0 будет тоже там представлен?

Не сглазь :) А то текущая работа шибко много времени занимает.

BTW Переводчик-итальянец взялся редизайнить иконки под вариант адаптивной цветовой схемы приложения.

Спасибо, не надо.

Обнови баннер в твиттер-профиле @sK1ProjectOrg ;)

• https://twitter.com/LGMeeting/status/1225799654513659906

Честно говоря, какой-то стремный баннер и странная метОда раскрутки. Не вижу смысла в ней.

Ты заявку уже подал?

Дэдлайн: 17 февраля!

• https://twitter.com/wheel_o_values/status/1227685316645019655

Естебственно!

Cairo and CMYK rendering: color management workarounds.

Cairo is a 2D vector graphics library that provides a set of different rendering surfaces, including Image, PNG, PDF, PostScript and different platform-specific windowing surfaces.

Cairo provides an interface which exposes PDF-like operations. Therefore Cairo is widely used for complex screen graphics rendering. But it lacks color management and operates RGB colors only. This limits the scope of the Cairo library.

The purpose of this presentation is a basic outline how to design a wrapper for Cairo library which augments it with color management support and forces Cairo to render CMYK and CMYKA images.

Over the past ten years, the sK1 Project has been successfully using this wrapper to manage CMYK colors and images in sK1 and UniConvertor applications. We hope that this experience can be useful in other open-source projects.

Зацени багу - в файле uc2/formats/xar/xar_const.py в хедере не было # -*- coding: utf-8 -*- В результате xgettext прерывал обработку по апдейту POT файла, пропустив пару десятков строк для перевода. С начала прошлого лета не замечали недостачи :)

maxim2, atsym будет время, добейте украинскую локаль - в мастере уже проапдейтченая версия uk.po с недостающими строками.

Казалосьбы где хедере и где xgettext.

ага, а недостача по строкам была совсем в других файлах - заметил в диалоге настроек. Часть строк переведена, а часть нет.

Если чо, на тебе ревью фиксов перевода висит ;)

Я в курсе. Обновлю Poedit и ревьювну ;)