[GIMP 2.7.x] Зачем разделили сохранение и экспорт?

Это инновации.

Да, второе проявление этого - открываешь jpg чтобы что-то подправить, сохраняешь - а хрен там, опять надо делать экспорт. Где логика?

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

Где логика?

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

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

Логика есть, но тоже бесит порой.

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

Но новый диалог вообще ничем не отличается, кроме того что xcf вынесли в отдельный диалог.

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

Формально - да, разные. Но с точки зрения пользователя, это одно и то же - он хочет сохранить файл в определенном формате.

Если была задача явно обозначить то, что например при сохранении в jpeg будут потеряны слои, прозрачность и т.д. (уж не помню что там еще xcf-формат поддерживает), то мне кажется лучше было бы сделать предупреждения в окне сохранения, чем городить такую конструкцию.

Меня на самом деле больше удивляет другое: это не изначально так, это изменили осозанно - в 2.6 было же нормально. Вот мне поэтому и хочется услышать какие-то вразумительные причины на этот счет.

мдя. Было же все отлично. Нафига менять, спрашивается...

Старый диалог сохранения, в котором было 100500 форматов, был неудобен.

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

При необходимости автоматически предлагается экспорт. Считаю это удобнее.

Вообще мода какая-то пошла интерфейс в линуксе корежить

Если была задача явно обозначить то, что например при сохранении в jpeg будут потеряны слои, прозрачность и т.д. (уж не помню что там еще xcf-формат поддерживает), то мне кажется лучше было бы сделать предупреждения в окне сохранения, чем городить такую конструкцию.

А оно предупреждение и было (есть) в 2.6

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

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

Вообще мода какая-то пошла интерфейс в линуксе корежить

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

+1. Однооконный режим это конечно удобно, но из-за этого я уже думаю обратно на 2.6 откатиться (плюс 2.6 работает быстрее).

гимп почти не использую, но поддерживаю негодование.

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

Пункт «Сохранить копию» в гимпе был с незапамятных времен.

Пункт «Сохранить копию»

переименовали в «экспорт»?

Ага. Но логически сохранение не в XCF должно быть именно экспортом. К тому же так меньше вероятность ошибиться и переписать не то, что надо.

Насколько я помню, они ещё несколько лет назад подобную инициативу выдвинули.

Всё правильно сделали

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

Более того - новая логика не снижает, а повышает вероятность случайно затереть другой файл, ибо даже самое элементарное редактирование jpeg выглядит так:

1. Открываем jpeg (например, через «Открыть»).
2. Делаем с ним что нам надо - например, crop или цветокоррекцию
3. Вызываем диалог экспорта
4. В открывшемся диалоге ищем в списке оригинальный файл. Понятно, что тут есть риск случайно выбрать другой. Жмем «Экспортировать». На самом деле, в большинстве случаев - а может и всегда - достаточно нажать кнопку «Экспортировать», ибо имя файла уже вписано и открыта последняя директория, но это не очевидно.
5. Подтверждаем свое намерение перезаписать файл.
6. Подтверждаем параметры экспорта (качество и т.д.)
7. Выбираем «закрыть файл»
8. Подтверждаем, что закрываем без сохранения (хотя все уже сохранили на деле)

Итого - получается очень неслабый overhead, что особенно заметно, когда надо обработать большое количество изображений.

Для сравнения, как это выглядит в 2.6:

1. Открываем jpeg (например, через «Открыть»).
2. Делаем с ним что нам надо - например, crop или цветокоррекцию
3. Жмем сохранить
4. Подтверждаем параметры экспорта
5. Закрываем файл

Действий - почти вдвое меньше.

Похоже, вам что-то другое надо, вроде Digikam.

У меня так:
1. Открываем jpeg.
2. Немедленно сохраняем в xcf (приучил себя делать это сразу).
3. Делаем с ним что нам надо, долго и со вкусом. Периодически вызываем диалог экспорта, в открывшемся диалоге пишем новое имя...

Кстати, часто ещё и каталог создаю, вроде проекта, с промежуточными, заготовками и пр.

Согласен. Похоже что теперь при открытии файла сразу происходит импорт в XCF, получается вся проблема заключается в том, что GIMP не запоминает параметры исходного файла (путь, формат изображения).

Я привел эти простые действия в качестве примера. Ими дело ограничивается далеко не всегда :) Но иногда действительно надо бывает тупо обработать пачку изображений. И брать для этого другой инструмент как-то глупо.

В том то и дело что на самом деле - запоминает. Но делает вид что забыл.

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

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

Да? Тогда это определённо баг.
Вообще идея с разделением диалогов вполне логичная, но при экспорте хотелось бы, чтобы предлагалась запись в исходный файл.

Всё очень просто.

Сохранять можно только то, что потом целиком можно отредактировать ­— слои, режимы смешивания, каналы, контуры. Для этого есть один формат: XCF (точнее, PSD тоже, но его поддержку надо ещё допилить). Всё остальное по факту является экспортом, приводящим к потере всей или почти всей этой информации. Это первое.

Второе. GIMP как продукт разрабатывается для продвинутых пользователей, работающих со сложными многослойными проектами, которые в любом случае сохраняют XCF. Поэтому ты можешь во время работы нажимать Ctrl+S для периодического сохранения проекта, а, скажем, Ctrl+E нажимать для повторного генерирования «сплющенного» PNG или JPEG, причём при повторном сохранении параметры уже не спрашиваются. Для тех, кому очень нужен аналог прежнего Ctrl+Shift+S, сохранна вохможность повесить произвольное сочетание клавиш на каждый из пунктов меню: «Экспортировать» и «Экспортировать как».

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

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

Именно это и делается.

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

Ну ладно, похоже с этим придется смириться. Но осталась ли возможность открыть-поправить-сохранить-закрыть png/jpg без пачки дополнительных действий?

Проверил, вы правы. Тогда претензий к новым диалогам не имею :)

А он вообще жив, такими темпами 2.8 после e17 выйдет.

Какой из двух коммитов тебе нравится больше?

http://git.gnome.org/browse/gimp/commit/?id=011b0589457406cabcb619524bb6df04b...

http://git.gnome.org/browse/gimp/commit/?h=goat-invasion&id=aca456a5604cf...

Ну это хорошо, а релиз то когда?

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

Тогда было бы логично подсмотреть как это сделано в фотошопе. Там это намного удобнее.

Мы щас поменяли API и ABI в GEGL и повесили зависимость на них в 2.8 Так что сначала будет новый GEGL, а это уже уравнение с двумя неизвестными. Думаю, что пара недель ещё точно. Так-то рассчитывали 1 апреля приколоться :)

Всё очень просто.

Опять же, почему не сделать, как в фотошопе. Там, если открыл простой, например, JPEG, подредакрировал, на Ctrl+S просто сохранишь его. Если внес в файл то, что потеряется при сохранинии в jpeg, слои например, то при нажатии ctrl+s выскочит диалог, который по-умолчанию предлагает сохранить в PSD

Вот так всегда: распишешь весь workflow, и всё равно у людей вопросы :)

Вот так всегда: распишешь весь workflow, и всё равно у людей вопросы :)

Я понимаю, почему так сделали. Я не понимаю, почему считают, что так будет удобнее ))

Будем ждать, а то на 2.7 не солидно сидеть :)

Логика то понятна, просто не все с ней согласны :)

Такой вопрос, как разработчику: насколько сложно будет, с учетом проделанных изменений, сделать патч, возвращающий старое поведение?

Разработчиком меня называть некорректно :) Я скорее пиарщик + локализатор.

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

ИМХО~так как сейчас намного удобней. привык быстро и на 2.6.* уже неудобно