python-lcms2 v0.1

кто на ком стоял? потрудитесь изъясняться точнее.

Что такое LittleCMS2?

Что такое LittleCMS2?

Библиотека управления цветом. Детали тут: http://www.littlecms.com/

Поясняю: LittleCMS де-факто основная библиотека для управления цветом в опенсурсе. LCMS1 имела привязку к питону. Потом автор подзабил на нее и предложил пользоваться питонистам опосредованно через libcolord. Поэтому для страждущих и сделали это сабжевое нативное расширение.

ОК, так понятнее. Хотя я все равно дальтоник.

А изначальным толчком что было? Какие-то части sK1 Project написаны на питоне?

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

Когда Марти выпустил LittleCMS v2, привязки он обновлять не стал. И все приложения на Пайтоне сразу отвалились.

svn checkout https://github.com/sk1project/python-lcms2 python-lcms2

ШТОА? :)

«Бывает» (c)

А чо, не работает? :)

Но зачем SVN на гитхабе? :)

Алсо, может в README на https://github.com/sk1project/sk1-gtk2 всё-таки указать, что это дохлый репозиторий, который не планируется развивать?

А зачем функционал DVCS подавляемому большинству пользователей? У гитхаба есть svn-морда. Для взятия сорцов ее более чем. А локальная ветка репозитория нафик не нужна трудящимся.

Кстати, большинству проектов тоже это не уперлось - когда один-полтора разраба, работа идет в режиме SVN и функционал распределенного вершинкотрола не используется.

Видимо стоит. И не только в этом репе.

А зачем функционал DVCS подавляемому большинству пользователей?

Кем оно подавляется? :)

Кстати, большинству проектов тоже это не уперлось

Я лично не знаком с большинством проектов, а ты, видно, все пересмотрел. Придётся поверить тебе на слово :)

Кем оно подавляется? :)

Знамо дело - масонами, мировой закулисой и рептилоидами :)

Если там только матан, зачем писать на медленном питоне?

Полностью нативный код можно было бы пилить еще лет пять.

Так нужно было на Qt клепать, а не на гтк с сишкой.

как раз таки матана в GUI аппликухах очень и очень мало. В основном логика.

По ссылке два файла. Где там GUI?

Насколько я знаю Qt, описание на нем интерфейса будет в 2-3 раза больше просто по объему кода, чем на питоне с Widgetset Abstraction Layer. Сейчас в репе ~2Mb питонского кода. На кутях будет 4-6 метров. Это по объему в районе ПСС дедушги Ленина :)

Почти тоже самое, но в составе проекта:

https://github.com/sk1project/sk1-wx/tree/master/src/uc2/cms

Там вообще ничего не нужно описывать, ибо можно клепать .ui файлы. Всяко лучше долбатни с wxWidgets.

Код в мегабайтах - это что-то странное. Насчитал 75к строк кода в /src. Не густо конечно, но вам виднее.

В остальном вкусовщина: нравится питон - страдайте. Ну или как минимум PyQt используйте.

Насчитал 75к строк кода в /src.

Как считал? Просто интересна метода.

Кстати, 75к это на питоне. На крестецах будет ~200к. Но дело не в пузомерках. Главное довести до релиза проект.

Там вообще ничего не нужно описывать, ибо можно клепать .ui файлы.

Это подходит только для статичных диалогов. И опять же - сгенерированный код залог качественных тормозов :)

Ну или как минимум PyQt используйте.

Не, пасиб. Widgetset Abstraction Layer (это не wxWidgets) как-то надежнее.

Как считал? Просто интересна метода.

https://github.com/Aaronepower/tokei

Это подходит только для статичных диалогов.

И что под этим подразумевается?

И опять же - сгенерированный код залог качественных тормозов

Только в ваших фантазиях.

Только в ваших фантазиях.

На хеллоуворлдах не проявляется, эт верно :)

Пруфов так и не будет?

В репах болтается прототип sK1 на pyqt. По нему оценивал и ресурсы и сгенеренные окошки и отказался от этого пути. Подтормаживать начало весьма быстро. Правда сейчас он уже нерабочий - базовая часть (UniConvertor) ушла далеко вперед и несовместима со старым прототипом.

Подтормаживать может только при создании окон. На работу это никак не влияет.

И это при условии, что текущая версия на wxWidget всё равно сильно тормозит.

По нему оценивал и ресурсы

Смысл оценить ресурсы в приложении на python? Он не для этого предназначен.

Подтормаживать может только при создании окон.

Об этом и речь. Бонусом - большее потребление памяти. В нонешнее время вроде и не принято ее экономить. Но как-то неприятно когда прототип на Qt жрет на старте 40-50 метров вместо 20 метров как у прототипа на gtk.

Кроме того, ui-файлы это жесткое прикручивание к Qt. Эт из личной фобии, связанной с tk - весь GUI пришлось переписывать из-за проблем с виджетсетом.

текущая версия на wxWidget всё равно сильно тормозит

Что конкретно тормозит?

Бонусом - большее потребление памяти.

ui не увеличивают потребление памяти.

40-50 метров вместо 20 метров как у прототипа на gtk.

Зависит от того, как вы измеряли. У меня hello world жрёт 3МБ + 30МБ shared memory. Проект посерьезней, 30К строк кода, 8МБ + 42МБ shared.

Кроме того, ui-файлы это жесткое прикручивание к Qt.

То есть написанные руками формочки легко можно перенести на новый фреймворк, а ui - нет?

Что конкретно тормозит?

Всё.

В общем все симптомы тулкитофоба.

ui не увеличивают потребление памяти.

Увеличивают, но не существенно, если сравнивать с самим тулкитом.

У меня hello world жрёт 3МБ + 30МБ shared memory. Проект посерьезней, 30К строк кода, 8МБ + 42МБ shared.

Если десктоп не кде, это проявляется в полный рост. Те же тормоза на старте аппликухи.

Всё

угу, понятно - вэиксфобия :) Если что-то и тормозит, то только канва. И ее скорость работы не зависит от тулкита, а упирается в производительность cairo.

В общем все симптомы тулкитофоба.

Стопуд! Причем в отношении всех тулкитов :) Паттерн Widgetset Abstraction Layer позволяет использовать в бэкэнде и wx и kde и qt - короче любой зрелый тулкит. Причем без переписывания основной части кода.

Если десктоп не GNOME, это проявляется в полный рост. Те же тормоза на старте аппликухи.

fixed

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

И ее скорость работы не зависит от тулкита, а упирается в производительность cairo.

А там есть что-то кроме канвы?

Если десктоп не GNOME, это проявляется в полный рост. Те же тормоза на старте аппликухи.

fixed

Неа, не фиксед. Я по венде обычно сужу. Для чистоты экперименту )))

Да и о каких тормозах может идти речь, есть прога на питоне?

Нууу... пейсателям всегда пистон мешает.

А там есть что-то кроме канвы?

)))) https://youtu.be/1qDRClemtuI?t=345

Нууу... пейсателям всегда пистон мешает.

То есть wxWidgets быстрее и легче Qt, но в то же время и python быстрее и легче C++? Странные вещи вы пишете.

но в то же время и python быстрее и легче C++?

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

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

Ты, кстати, не заглядывал в код тулкита «mlib»? (На котором написан AzPainter 2.x.x).

За счет чего там такая высокая скорость рендеринга канвы?

Может, испытал бы «mlib» в качестве GUI?

Еще раз: рендеринг канвы от тулкита не зависит. Совсем не зависит. Ваапще не зависит.

За счет чего там такая высокая скорость рендеринга канвы?

Скорее всего за счет кеширования. В растровом редакторе только один вид объектов - слой битмапа.

Может, испытал бы «mlib» в качестве GUI?

)))) Предлагаешь переписать заново все? Хочешь смерти со смеху для AP? )))))

Да! )))))))

P.S.: sK1 должен быть портирован на все возможные тулкиты. Я так считаю ;-)

В растровом редакторе только один вид объектов - слой битмапа.

А как же рамки выделения и инструменты кривых в окне AzPainter? По логике, это должны быть векторные объекты

А как же рамки выделения и инструменты кривых в окне AzPainter? По логике, это должны быть векторные объекты

Рамка выделения векторная? Только на том основании, что у неё есть координаты? :)

В растровом редакторе только один вид объектов - слой битмапа.

Парни, вы меня оба решили смехом убить? :)

AzPainter вектор не саппортит. А на гимп не ссылайся - он уже комбинированный редактор, а не чисто растровый.

Ну тогда sK1 — тоже комбинированный редактор, потому что позволяет делать простые вещи с битмапами :) Или не позволяет? :)

Пока еще нет - простое редактирование битмапов запланировано (обрезка, простенькое затирание и т.п.) но не реализовано еще. Сейчас это по сути ректангл с заливкой битмапом.

Но всё же, одно из первых что хотелось бы для битмапов, так это настройка DPI для монитора и для экспорта в PNG

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

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

P.S.: набросал тут шаблон ROADMAP для wiki

https://github.com/sk1project/sk1-wx/wiki/ROADMAP

что хотелось бы для битмапов, так это настройка DPI для монитора

Зачем настройка DPI для монитора? Какой сакральный смысл в этом?

для экспорта в PNG

Изменение в размерах экспортируемого битмапа нужная вещь, позже добавим.

набросал тут шаблон ROADMAP для wiki

Эт мы сами справимся после релиза :) Сейчас не стоит распыляться на вангование или описание в роадмапе того, что уже сделано.

Но хоть пока и не позволяет редактировать, закос под растровый редактор уже можно делать ))) http://oi66.tinypic.com/xqizap.jpg

Кстати, как называется фон, на этом скриншоте серый без шахматки, в рабочем окне? (ниже канваса; типа «стол»,«скатерть») Нужно для перевода