[opennet][эпидемия]Разработчики GIMP заразились тем же вирусом, что и разрабочтики Mozilla и Google Chrome

>в cron прописать git pull с пересборкой каждые 5 минут.

gentoo_root

gentoo

а такую херь порешь

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

>а такую херь порешь

Не тебе ж одному херь пороть =D

я её не порю
а тебе советую смотреть в сторону smart-live-rebuild
чоб не писать такого бреда больше

>а тебе советую смотреть в сторону smart-live-rebuild

Дык если это запихнуть в крон каждые 5 минут, то при отсутствии обновлений ничего не будет собираться. А если ‘git pull; make clean all install’, то компьютер будет постоянно чем-то занят ;).

смысл?

> Зато сколько до 3.0 можно будет выпустить 2.xx :)

В реальности, либо одну, либо нисколько.

>смысл?

Комнату греть, видимо. Смысл было версии херить?

> смысл?

Зимой греться же.

> Оно страшное и мне не нравится.

Ты точно не путаешь тему с тулкитом? :) Это раз.

Версия на GTK+3 не тормозит при рисовании кисточкой в полтыщи пикселов. Это два.

> Лишь бы однооконный интерфейс и т.п. не совали.

Не нравится — не пользуйся :)

> Версия на GTK+3 не тормозит при рисовании кисточкой в полтыщи пикселов.

Это заслуга GTK или оптимизации движка редактора? Что-то первый вариант сомнителен...

> Она есть в 2.7, только криво работает.

Вообще-то починили уже месяца два как.

Как ни странно, именно первый вариант.

Надо будет заглянуть.

>Ты точно не путаешь тему с тулкитом? :)
Да я и не спорю, тулкит может быть вполне себе замечательный, но вот пока оно выглядит как УГ, оно мне не нравится:)

Не нагуглилось сходу. Можно пруф относительно производительности gtk3?

Не нагуглилось потому, что обсуждения на IRC не журналируются, хотя я вроде писал про это в новостях на gimp.ru :)

Мар 19 01:57:31 <mitch>   Alexia_Death: painting is *much* faster on gtk3
Мар 19 01:57:50 <mitch>   i suspect using cairo globally fixed a lot of cairo slowness
Мар 19 02:00:28 <mitch>   it's really incredible, zero lag
Мар 19 02:00:29 <mitch>   huge brush
Мар 19 02:00:34 <mitch>   huge canvas
Мар 19 02:02:21 <prokoudine>   finally
Мар 19 02:02:29 *   prokoudine considers building gtk3
Мар 19 02:02:46 <mitch>   it flickers like hell
Мар 19 02:03:02 <mitch>   i could fix that, but then it would be impossible to see another bug fixed
Мар 19 02:03:09 <mitch>   first things first
Мар 19 02:04:29 <mitch>   i can almost fluently paint with a 1000 px brush on a 5000x5000 image
Мар 19 02:04:43 <mitch>   totally fluently with a 500px brush on the same image
Мар 19 02:05:13 <mitch>   Alexia_Death: is that huge by your standards?

Ясно. :)

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

Лучше бы существенно пересмотрели интерфейс пользователя.

А кто сказал, что каждый новый релиз будет начинаяться с 3, 4, 5? Может всё будет как всегда, просто чаще.

> Лучше бы существенно пересмотрели интерфейс пользователя.

Они его и пересматривают

Они его уже на протяжении многих лет пересматривают. Чего только стоит меню на правую кнопку мыши.

Лучше бы существенно пересмотрели интерфейс пользователя.

а что с ним не так?

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

Правильно Каганов говорил:

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

Какого-такого опенсорса?

если нажать на правую кнопку при активной кисти - то выскочат все свойства кисти, если при активном пере - то, соответственно, свойства пера.

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

> Они его уже на протяжении многих лет пересматривают.

Так ты определись: или пересматривают или не пересматривают.

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

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

> Это не «всех идей» а всего лишь двух, которые уже давно на первом месте стоят - слои с эффектами и интерфейс.

Что это за идея такая — интерфейс?

И просто неизвестно почему разработчики не могут реализовать эти две простые идеи

Действительно, реализовать эффекты слоёв — это же как раз задача для программистов интерфейса. Тут и в движок-то лезть не надо. Всё логично, чо.

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

Специально для тебя, ещё раз. Весь новый функционал пишется только на GEGL. Никто не будет впиливать принципиально новую функцию и расширять старый движок только для того, чтобы потом всё заново переписать. Это попросту нерационально. И это было бы нерационально даже если бы в проекте было 50 постоянных разработчиков, а не 2,5 как сейчас. Пока доходит? Поехали дальше.

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

Соответственно, когда в программе I/O и обработку окончательно перепишут на GEGL (v3.0), можно будет начать спокойно заниматься тем, что должно основываться на этом новом движке: эффекты слоёв, корректирующие слои и пр. Сначала строят фундамент, и только потом стены и крышу. Улавливаешь мысль?

в приложениях на qt это давно сделано

Во-первых, не в приложениях, а в приложении. Во-вторых, Krita изначально на порядок проще GIMP (и по ряду параметров до сих пор остаётся таким), так что перетащить его на новый движок удалось существенно быстрее. Но после этого криту ещё года три доводили до ума, чтобы программа при каждом чихе в корку не валилась. Это понятно, или какие-то буковки надо специально объяснить?

>Почему тебе это «просто неизвестно», я не знаю. Возможно, ты принципиально им не интересуешься, чтобы иметь возможность при удобном случае потрындеть ни о чём.

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

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

дык а я тебе о чем: «изначально так спроектирован проект, что нифига не расширяем»

Krita изначально на порядок проще GIMP

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

Это понятно, или какие-то буковки надо специально объяснить?

А почему ви такой нервный, неужто один из разработчиков жимпа?

> Все правильно, кроме как «принципиально» я смотрю на жимп из глаз пользователя, а не программиста и мне пофиг что там да как куда реализовывают

Иными словами, ты ни хрена не понимаешь в причине и следствии, тебе нравится сам процесс высасывания выводов из пальца.

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

И на чём основан этот вывод?

дык а я тебе о чем: «изначально так спроектирован проект, что нифига не расширяем»

В том-то и дело, что ты говоришь ни о чём.

Я тебе говорю: «старый движок расширять невыгодно, лучше доделать и интегрировать новый». Ты мне отвечаешь: «Ну я же говорю, что он не расширяемый!» Извини за прямоту, но ты дурак или прикидываешься?

Ибо KISS

Нет, потому что долгое время Krita была невыразительным, никому не нужным говном без идеи и полезного кода. И выехала (вернее, начинает выезжать) только за счёт энергии одного человека, который сугубо из лени не захотел программировать на C и нашёл более подходящий (C++, Qt) проект для приложения сил, убедив ещё нескольких человек, что после дохрена лет работы из говна можно сделать конфетку.

А почему ви такой нервный

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

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

В некотором смысле, да.

> Наконец то, вместо рассказов как всё будет здорово в версии 2.8 где будет всё-всё-всё и ещё чуть-чуть больше, появятся версии с новыми фичами, которыми можно будет пользоваться сразу, а не ждать 5 лет очередного мегарелиза

А я и так не ждал - собирал из репозитория раз в неделю-месяц.

>А я и так не ждал - собирал из репозитория раз в неделю-месяц.

А мне мама сказала, что если слишком много компелировать, волосы на ладошках вырастут

И это хорошо.

Так вообще GIMP уже поддерживает CMYK.

KDE41user> После этого Ирси вернут на ЛОР?

Да он и сам зайти может. Кстати, общались с ним недавно. Весело было.

>Так вообще GIMP уже поддерживает CMYK.

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

> Да он и сам зайти может. Кстати, общались с ним недавно. Весело было.

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

Довольно много можно сделать через CMYKTool с его редактором связующих профилей (device link).

http://i.imgur.com/0MmoE.jpg

Эти профили можно потом засунуть в separate+, который работает прямо из гимпа.

> GIMP 3.6: возможность записывать действия

GIMP 3.8: добавление универсального инструмента для трансформации

печалька

>separate+, который работает прямо из гимпа

Про separate+ да, знаю. Очень нужная и полезная вещь. Но.
Обрабатывать получившийся CMYK TIFF в Gimp можно? Ну там, K отдельно пошарпить или подменить его на K из картинки с другим цветоделением, кривые там покрутить etc? Потому что если результат планируется отдавать CMYK то и, по крайней мере, некоторые этапы коррекции тоже желательно делать в нём.

> печалька

http://gimp.ru/news.php?readmore=162

Я думаю, ты прекрасно знаешь ответ на свой вопрос :)

>Я думаю, ты прекрасно знаешь ответ на свой вопрос

Я тоже думаю, что знаю. Но вдруг я что-то пропустил и оно уже есть, пусть и в бета-версии? Я, честно говоря, не очень пристально слежу за этой областью, потому что фотография для меня - почти исключительно хобби, а не работа. Тем не менее, очень хочется иметь свободный, а главное, удобный инструмент для всего цикла обработки фото. Вот с raw-конвертацией с появлением DT стало гораздо лучше, со временем и функциональность устаканится и стабильность подтянут. Для ретуши Gimp, в целом, пригоден. Для суровой коммерческой обработки (на стоки, в каталоги и для прочих страшных целей) - не знаю, мне кажется, что нет, но, возможно, я и ошибаюсь. Вот и хочется разобраться.

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

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

Иными словами, есть два варианта появления цмика в гимпе:

1. Быстрый. Из ниоткуда появляется группа разработчиков, которая с завидным упорством сначала фигачит гегл с гимпом, а потом цмик.

2. Медленный. В 3.0 I/O и обработку переписывают на GEGL, после чего достаточно хотя бы одного человека (и пары консультантов) для запиливания цмика.

Лично мне второй вариант кажется наиболее вероятным.

>Лично мне второй вариант кажется наиболее вероятным.

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

Там было две стратегических ошибки.

В начале нулевых геглом занимались практически только программисты из Rhythm and Hues, которых в конце концов сняли с проекта (равно как и с проекта FilmGIMP). Т.е. команда никак не подстраховалась на случай, если это произойдёт, хотя было ясно, что у R&H сугубо утилитарный взгляд на проект, что они, кстати, сами подтвердили, см. https://lists.xcf.berkeley.edu/lists/gimp-developer/2002-December/007794.html. Это была первая ошибка.

Вторая заключалась в том, что они несмотря на несколько лет участия в проекте и даже руководство им (Маттис с Кимбеллом отошли от дел примерно к 99-му) по молодости не очень представляли себе масштаб работы, поэтому тогда же в начале нулевых можно было прочитать заявления из серии «да ладно, мы щаз сделаем», хотя в реальности... ну, ты понял. Это была вторая ошибка.

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

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

Поэтому последние лет пять GEGL тянули на себе несколько энтузиастов, которые просто так проект не бросят. Ну вот они его и вытянули: в прошлом году Оэвинд наконец сказал, что GEGL в принципе готов для окончательной интеграции в GIMP.

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