Hi,

Alchemie foto\grafiche wrote:

gib_mir_mehl wrote:

Don't all those export troubles disintegrate once we presume a little more confidence in the undo function?

More confidence will require a option to save undo history.

As it is now once the image is closed its Undo History vanish,forever lost, so can't be used to correct saving's errors

This keeps me thinking. Given the case gimp cares for saving the undo history, where should it be stored?

Saving inside the image file would create bloat and is not possible for most formats. So it must be saved separately. This is feasible on the local computer. But what if files are transferred between computers and users suddenly miss their undo history?

What would a user interface look like for exporting undo history and for merging the history with the image again?

Are there already proposals for this?

peter

On Thu, 12 Jun 2008 01:35:27 +0200 gib_mir_mehl@gmx.net wrote:

What would a user interface look like for exporting undo history and for merging the history with the image again?

Are there already proposals for this?

Just my take... is this not something that GEGL and the non-destructive editing will take care of? Given the possibility to adjust a curve applied 25 steps ago at any point, the only remaining use for undo will be on drawables.

Jon Senior wrote:

gib_mir_mehl@gmx.net wrote:

What would a user interface look like for exporting undo history and for merging the history with the image again?

Are there already proposals for this?

Just my take... is this not something that GEGL and the non-destructive editing will take care of? Given the possibility to adjust a curve applied 25 steps ago at any point, the only remaining use for undo will be on drawables.

No, i'm thinking of the case where you saved those 25 steps to a jpeg and the next day, sitting in the plane to your customer, you discover that this curve should be tweaked a litte bit more.

peter

Hi,

On Thu, 2008-06-12 at 02:09 +0200, gib_mir_mehl@gmx.net wrote:

No, i'm thinking of the case where you saved those 25 steps to a jpeg and the next day, sitting in the plane to your customer, you discover that this curve should be tweaked a litte bit more.

That is exactly why JPEG should not be offered as a save format. Saving to a JPEG file is clearly an export. No one will be surprised that an exported file can't be edited again. The user needs to save the file to XCF (or whatever the next generation file format will be called).

Sven

On Thu, 12 Jun 2008 08:36:39 +0200, Sven Neumann wrote:

Hi,

On Thu, 2008-06-12 at 02:09 +0200, gib_mir_mehl@gmx.net wrote:

No, i'm thinking of the case where you saved those 25 steps to a jpeg and the next day,
sitting in the plane to your customer, you discover that this curve should be tweaked a litte bit more.

That is exactly why JPEG should not be offered as a save format. Saving to a JPEG file is clearly an export. No one will be surprised that an exported file can't be edited again. The user needs to save the file to XCF (or whatever the next generation file format will be called).

Sven

Hi,

I agree there is a certain logic to that approach but it should not involve constant importing and exporting as extra steps if working on a "foreign" file format, png for example.

If open png becomes an import then save will duplicate the file as an xcf unless it is explicitly exported again. There's a danger this could all cause a lot of duplication of large files and yet more user interactions to a simple task of opening, changing and saving an existing image , which will almost certainly not be gimp's native format.

Anyone wanting to "undo" changes made to a lossy format like jpeg clearly has no understanding of graphics formats anyway. This request does not even apply to gimp's target user base.

If it becomes possible to maintain an undo history across gimp sessions in the native format that would be a nice feature.

Beyond that the user had better learn what the characteristics of the different formats he is using are, and the value of keeping backups of different stages of one's work.

/gg

Hi all,

Sven Neumann wrote:

[..] JPEG should not be offered as a save format. Saving to a JPEG file is clearly an export.

this is totally true.

The problem is that this violates widely accepted UI standards. Usability shows it's ugly side here by demanding conformance to users' expectations even if those were formed by broken standards.

In fact, the whole concept of 'Save to Harddisk' is fundamentally broken from a pure UI perspective [1]. Despite of that, the GIMP will have to support the Open->Edit->Save cycle for quite some years.

This hints at providing different UIs: one that emphasises on technical soundness and a standard one which potentially jumps through hoops to meet users' expectations. While beeing an ugly thought at first, this opens up a lot of possibilies.

Looking from outside, i've gotten the impression that the GIMP project has been beaten by similar issues before. I feel like too many GUI changes got discussed to death, because no one managed to come up with solutions which fit all user groups (let alone the coding perspective). At times, the project gets partially paralyzed by the lack of usability input. Sven's unanswered calls for specs are strewn throughout the archives.

Quite paradoxically, splitting UI development into GIMP-Pro and GIMP-Standard could be beneficial for the GIMP as a project. This is not saying that such a split is desirable or unavoidable, the point is that it may speed up UI development by not hunting for the one unified GUI anymore. In case of the Export/Save logic such a solution may even be impossible due to problem roots outside the GIMP.

I see the current state of Export/Save as the result of a not-untangled development process. The Pro users, in utter need of Export workflow automation features, get thwarted by useless dialogs (from their perspective), while Standard users are confused and usability measures are shurely subterraneous. No one is happy with that.

The corresponding arguments in turn have been ping-ponged for years. Every now and then, someone new comes by and restarts the whole cycle, like myself. If all this energy could be freed for speccing & coding less universal UIs, i guess GIMP would make quick advances towards both an efficient Pro interface and a reasonably conforming Standard UI.

The golden way, of course, would be to follow the Firefox path and allow new UIs to ripen as plug-ins [2]. This requires an omnipotent plug-in API, thus putting even more burden on the coders (as far as i can see). Dreaming of "Adam's Pupus Pipeline"[3] for nearly a decade now, i doubt the upcoming GEGL goodness will fill in that role anytime soon.

Is it imaginable to have multiple GUIs for the GIMP?

peter

sorry, the links got chopped off in my previous post:

[1] Why does the user have to Save to disk at all? Are there inevitable hardware reasons why software can't take care of user's data? I don't think so. And old story and quite outside GIMP's scope, of course: http://jef.raskincenter.org/humane_interface/summary_of_thi.html
[2] as has been indicated by Akkana Peck some days ago: http://lists.xcf.berkeley.edu/lists/gimp-developer/2008-June/020311.html

[3] http://lists.xcf.berkeley.edu/lists/gimp-developer/2000-December/013952.html

peter

On Thu, Jun 12, 2008 at 10:56 PM, wrote:

Dreaming of "Adam's Pupus Pipeline"[3] for nearly a decade now, i doubt the upcoming GEGL goodness will fill in that role anytime soon.

GEGL is basically Pupus, it doesn't do network transparent buffers yet, but it has an infrastructure already used for shared disk swap between processes on the same machine. Almost all of what Adam outlined in his mail about pupus applies to todays GEGL.

/Øyvind K.

gib_mir_mehl@gmx.net wrote:

Looking from outside, i've gotten the impression that the GIMP project has been beaten by similar issues before. I feel like too many GUI changes got discussed to death, because no one managed to come up with solutions which fit all user groups (let alone the coding perspective). At times, the project gets partially paralyzed by the lack of usability input. Sven's unanswered calls for specs are strewn throughout the archives.

[...]

Is it imaginable to have multiple GUIs for the GIMP?

peter

Hi Peter

First of all, thanks for showing enthusiasm in hepling GIMP UI wise.

It seems however that you have not noticed the UI progress that has been put into GIMP through the work of mailny Peter Sikking. In fact, several UI related specifications has been written by Peter Sikking and implemented by the core developers.

I suggest you check out the UI wiki [1] to get a view of the current GIMP UI state, and then coordinate with the existing UI people.

Regarding multiple UIs, the big problem with that is that it multiplies the required efforts in several areas: coding, documentation, knowledge when giving help, and so on.

Best regards, Martin Nordholts

Hi,

On Thu, 2008-06-12 at 23:56 +0200, gib_mir_mehl@gmx.net wrote:

Quite paradoxically, splitting UI development into GIMP-Pro and GIMP-Standard could be beneficial for the GIMP as a project.

I don't think so. Such a split would make coding a lot more difficult and less fun. Since our product vision clearly targets the pro user, I don't see why we should go through the hassle of adding an extra user interface for the people who actually don't need a professional image editor.

This is not saying that such a split is desirable or unavoidable, the point is that it may speed up UI development by not hunting for the one unified GUI anymore. In case of the Export/Save logic such a solution may even be impossible due to problem roots outside the GIMP.

I see the current state of Export/Save as the result of a not-untangled development process. The Pro users, in utter need of Export workflow automation features, get thwarted by useless dialogs (from their perspective), while Standard users are confused and usability measures are shurely subterraneous. No one is happy with that.

It is up to the user interaction designers to solve this. But I doubt that the whole user interface needs to be split in order to do that. If there's really a need for a pro mode when it comes to saving (and I very much doubt that), then we can add that. But I would like to see a complete spec first.

The corresponding arguments in turn have been ping-ponged for years. Every now and then, someone new comes by and restarts the whole cycle, like myself.

Well, we had these discussions because we didn't have a clear product vision until recently.

If all this energy could be freed for speccing & coding less universal UIs, i guess GIMP would make quick advances towards both an efficient Pro interface and a reasonably conforming Standard UI.

You are making the wrong assumption here that the same people that write the specs would also implement them. That is not any longer true and it has shown to be a good thing to split this. So there is absolutely no waste of energy if the user interaction architects and user interface designers talk about the changes that should be done in the next development cycle while the developers are busy implementing what needs to be done for the next release.

Sven

Hi,

thank you all for taking the time to consider and being patient with me. It seems what's lacking most is the virtue of patience on my side...

I understand now that multiple UIs are too expensive. (As a sidenote, the forking idea doesn't imply to anticipate the UI team's work. More appropriate labels would have been GIMP and GIMP-dirty-and-feature-ladden).

The issue of Export/Save/data-loss-protection is in my regard more of a bug which should be fixed as soon as possible than part of UI redesign. As with any fix this might be superseded by a more general solution later on.

Now it's not clear to me where to draw the line between useful discussion of potential fixes and uselessly anticipating the UI redesign. Probably by the severity of changes, seen a from user perspective.

Any guidance?

peter

Hi,

On Fri, 2008-06-13 at 18:21 +0200, gib_mir_mehl@gmx.net wrote:

The issue of Export/Save/data-loss-protection is in my regard more of a bug which should be fixed as soon as possible than part of UI redesign. As with any fix this might be superseded by a more general solution later on.

It's definitely too late to introduce larger changes in trunk as we are closing in on the GIMP 2.6 release and the tree can be considered tentatively feature-frozen.

On the other hand that should give us enough time to come up with a proper solution that can be implemented in the next development cycle. Preferably a complete spec would be ready when 2.6 is released.

Sven

On Fri, 2008-06-13 at 18:21 +0200, gib_mir_mehl@gmx.net wrote:

The issue of Export/Save/data-loss-protection is in my regard more of a bug which
should be fixed as soon as possible than part of UI redesign. As with any fix this
might be superseded by a more general solution later on.

This is definately not a bug.

If you chose to save to a lossy format like jpeg you opt to eliminate some information from your image, you reduce the data , it a trade-off choice for the compression you get.

If you chose png or another non-layered format you won't get your layers saved, etc.

If you save to gif you only get a palette of 256 colours.

Gimp does all these things correctly. It is aimed at a competant user base, it does not try to be a beginner's guide using different formats.

I see no sense in dramatising this as "data loss".

gg@catking.net wrote:

This is definately not a bug.

[..]

Gimp does all these things correctly. It is aimed at a competant user base, it does not try to be a beginner's guide using different formats.

It is true that GIMP provides correct functionality for export/save. The corresponding user interface however must allow the user to form habits.

It wouldn't be an urgent problem even if five confirmation steps were required for writing a simple file format. Users form a habit out of it.

The problem begins when these steps become unpredictable. Suddenly, the user's habits are considered wrong (this is why users are so upset). The problem gets serious when this may lead to data loss [1].

This is not talking GIMP into an educational tool for beginners. Habits are an inevitable part of human nature. In fact, they are the workhorse of advanced users. If users are not allowed to form secure habits it is a serious bug in the user interface.

peter

[1] Alexia gave an example: https://lists.xcf.berkeley.edu/lists/gimp-developer/2008-June/020296.html