Как в проекте принимаются решения по реализации функционала и чего ждать

Вопрос, почему в GIMP не реализованы те или иные функции, с завидной частотой повторяется в разнообразных форумах. Сегодня этот вопрос снова появился на linux.org.ru. Просмотрев архивы новостей, редакция gimp.ru не нашла одной публикации, где это было доходчиво расписано. Исправляемся.

Есть две сверхзадачи, которые с учётом количества активных разработчиков являются конкурирующими между собой: улучшение интерфейса и добавление продвинутого функционала. Определить, что для пользователей является более предпочтительным, практически невозможно. Одним готовы мириться с недочётами интерфейса ради 16/32 разрядов на цветовой канал и LAB, других текущий функционал устраивает, но отпугивает интерфейс.

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

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

Фактически приоритеты в разработке расставляются исходя из следующего:

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

Поясним последний момент: в проекте сейчас всего один программист-универсал — это Митч Наттерер. Мартин Нордхольц специализируется на интерфейсе и интеграции GEGL, Оэвинд Колас занимается только GEGL, Алексия занимается только кистевыми инструментами и динамикой, Мишель занимается только инструментами трансформации, Кевин занимается только Script-Fu. Из них по количеству вносимых изменений с солидным отрывом от остальных лидирует как раз Митч.

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

Текущий результат оценки приоритетов можно посмотреть здесь. Теперь давайте посмотрим, что раньше делала команда:

В 2005 году параллельно с разработкой GIMP была возобновлена активная работа над GEGL. По достижении минимального уровня готовности GEGL в GIMP 2.6, выпущенном осенью 2008 года, была реализована начальная интеграция в виде опционального использования библиотеки в инструментах цветокоррекции. Одновременно с этим в GIMP 2.6 попали первые результаты работы с командой Петера Сиккинга, занимающегося эргономикой: улучшенные инструменты выделения и кадрирования, улучшенный интерфейс для управления кистевой динамикой и т.д.

Работа над GEGL с тех пор надолго больше не останавливалась, состоялось несколько успешных проектов Google Summer of Code, включая реализацию поддержки OpenCL для вычислений на GPU. Примерно год назад лидер проекта GEGL сказал, что библиотека в принципе готова для окончательной интеграции. К тому моменту GIMP 2.8 разрабатывался уже два года, и необходимость скорейшего выпуска этой версии была более чем очевидна, но оставалось слишком много недоработок.

В готовящейся к выпуску версии 2.8 изменения также делятся примерно поровну: это разнообразные улучшения в интерфейсе (помимо однооконного режима), существенные улучшения в кистевой динамике и дальнейшая интеграция с GEGL: рисование проекций (подробнее о проекциях — в готовящейся статье) через GEGL и новый инструмент трансформации по рамке (Сage tool), использующий GEGL для вычислений. Кроме того, в прошлом году для стимуляциии перехода на GEGL вступил в силу запрет на добавление новых инструментов, использующих старый движок.

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

Заодно давайте развеем миф об однооконном интерфейсе: он реализован не для того, чтобы угодить мигрантам из Photoshop, а потому, что у него есть ряд преимуществ при работе с одним монитором. Недавний краткий опрос на канале IRC, где присутствуют почти все, кто так или иначе участвует в разработке GIMP, показал, что большинство участников проекта, включая его лидеров, уже перешли на однооконный интерфейс.

Теперь посмотрим, что нас ждёт в будущем. В общем и целом, ожидается дальнейшая игра на два лагеря. Изменения в интерфейсе на версии 2.8 не заканчиваются. Здесь программа-минимум такова:

Момент с портированием на GTK+3 требует отдельного пояснения. Для GIMP это выигрыш сразу на нескольких фронтах: более чистый и удобный API для программирования интерфейса, принципиальное ускорение отрисовки при работе с кистями большого диаметра (500-1000px без задержек), стабильно работающие расширенные устройства ввода, такие как графические планшеты (в GTK+2 многое разломано).

Со стороны окончательной интеграции GEGL планы таковы: сначала выпускается версия 2.10 с необходимой доработкой API в GIMP, затем выпускается версия 3.0, где тот же интерфейс и тот же функционал, что в 2.10, но на GTK+3 и с обработкой в режиме 32 разряда на цветовой канал. Если порт на GTK+3 окажется готов раньше, теоретически может быть принято решение выпустить 3.0 без окончательной интеграции GEGL, но это пока что маловероятный сценарий.

После окончательного перехода на GEGL в 3.0 разработчики смогут наконец спокойно заниматься реализацией продвинутого функционала, такого как неразрушающее редактирование, эффекты слоёв и так далее. Эти функции будут использовать все преимущества новой архитектуры: гибкость за счёт обработки на нодах, распараллеливание по ядрам процессоров, использование GPU, ускорение обработки за счёт использования мипмапов, работа с произвольными цветовыми моделями в произвольных цветовых пространствах.

Остаётся разобрать всего несколько моментов.

Во-первых, можно ли было реализовать расширенный функционал без перехода на GEGL, как это было сделано в FilmGIMP/Cinepaint? Да, можно, но этот функционал был бы реализован на технически устаревшей архитектуре. Проект GEGL был начат разработчиками FilmGIMP, которые это осознали.

У разработчиков продолжения FilmGIMP, Cinepaint, также был собственный проект по реализации нового движка — Glasgow. Как видите, предыдущий опыт показывает, что писать новое на старой архитектуре — тупиковый путь, который при нынешнем количестве активных участников отложит адекватную реализацию востребованных функций ещё на несколько лет.

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

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

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

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

Если у вас остаются какие-либо вопросы, задавайте их в комментариях.

Add a comment