open/save/export

[yahvuu]

hi all,

as this issue stays intricate, a brainstormish thought:

clearly, Save must result in an XCF getting written somewhere (unless the operation gets cancelled).
This doesn't rule out that e.g. a JPG gets exported in the process.

So in the last resort we could abstract away the export/save distinction
by automatically writing a backup XCF, much like an on-disk undo stack which
persists across editing sessions. Such a cross-session undo stack will shurely
be worth it's price in general; some corner cases have to be solved, though.


Another variant:
allow save-as-jpeg and ask for writing a backup XCF upon closing the image.

As anything but save-as-xcf results in a final nag-screen anyway, the user doesn't
gain much from learning the export/save distinction. So we can as well sweep that
under the table and pretend that save-as-jpeg were safe, up to the point when
the image gets closed.


peter sikking schrieb:
> however it is not the fundamental principles that are wrong

yes, absolutely. And what we're doing here is trying to cure the symptoms
of the deeper problem that is the broken concept of 'Save'. That trojan horse
is a gift from today's underpowered desktop environments.
...with greetings from Jef Raskin. More of this rant available upon request ;)


regards,
peter

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

hi,

after some more thinking, here's my reasoning why indeed 'Save' is the problem.

This becomes clear in comparison with a database-driven, version-controlled approach
as e.g. sketched in the last mockup of [1]. A Save command is superfluous in this
scenario. When an image gets edited, it's reasonable to assume the user wants to keep
the changes. Otherwise she can undo, revert (= bulk undo) or simply delete the image.
The only IO-commands required here are Import and Export, to exchange images between
the world and the database. Easy interface _and_ technically clean, i think.


Now current GIMP already employs sort of a temporary database of version-controlled
images: that is the working set of currently opened images.
Prior to editing, images are opened (=imported) into the working set.
The equivalent for Export is Save-a-Copy.

The major difference from a user's point of view is that the composition
explicitely has to be saved to disk, otherwise it gets lost.
So obviously the problem must be rooted in having to Save manually,
which is a legacy concept from the era of floppy disks [2].


The current spec builds a clean model on top of that legacy Save concept.
And the result is not as easy as we all would like it to be. That a lot of
effort is required to communicate the model in the UI is probably a sign of that.

In mid-term i see GIMP going the database-driven path anyway [3], but for now
we clearly have to support the classic Open/Edit/Save cycle. For that scenario,
it seems we can't have both of easy and clean. So i think it's worthwile
to reconsider easy-but-dirty models.


greetings,
peter




Notes sorted from on-topic to off-topic:

[1] http://gimp-brainstorm.blogspot.com/2009/04/version-control.html

[2] slightly related, i was quite surprised to find that messing with files also
    builds a good share of the accidental complexities of batch processing. compare:
    http://gimp-brainstorm.blogspot.com/2009/05/basic-batch-processing.html

[3] the canonical objections are that version control is too expensive for
    graphical work and that databases lead to application lock-in.

    With GEGL under the hood, the first is not valid anymore. In general,
    it is wasteful to store a second XCF instead of a diff of the GEGL tree.
    And storing each composition in a self-contained file will face efficiency
    problems as well: consider a composition created from 5 JPEGs of GPixel
    size each. Should all the source data be duplicated in the XCF?


    Application lock-in is a serious concern, though. I think there's concensus
    that at desktop level, hierarchical file systems don't serve users well anymore,
    due to their thousands of multimedia documents. Applications like F-Spot and Rhythmbox
    maintain their own databases, which leads to lock-in or at best duplicated effort.

    So ideally, these databases have to be provided by the desktop environment,
    and that's the point when GIMP will shurely jump on that train.
    Anyhow, it is debatable wether a private database for GIMP causes application
    lock-in any worse than the XCF format already does now.


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

On Thu, Jun 25, 2009 at 4:55 PM, yahvuu wrote:

> In mid-term i see GIMP going the database-driven path anyway [3],

While in the shortterm tools like dropbox get hot :)

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

hi,

Alexandre Prokoudine schrieb:
> On Thu, Jun 25, 2009 at 4:55 PM, yahvuu wrote:
>
>> In mid-term i see GIMP going the database-driven path anyway [3],
>
> While in the shortterm tools like dropbox get hot :)

why shure, dropbox is an example of what can be gained on the database-driven
path. It's hard/laborious to achieve the same with conventional file systems.

While dropbox seems to focus on sharing/network storage, the desired
benefits for GIMP are version control and potentially reliable linking of
files together (think of Inkscape SVGs with embedded PNGs)

This doesn't rule out to make parts of such a database public...

greetings,
peter
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

yahvuu wrote:
> This becomes clear in comparison with a database-driven, version-controlled approach
> as e.g. sketched in the last mockup of [1]. A Save command is superfluous in this
> scenario. When an image gets edited, it's reasonable to assume the user wants to keep
> the changes. Otherwise she can undo, revert (= bulk undo) or simply delete the image.
>  

While this and the rest of your mail is true and I agree, one could
argue that users of a high-end app still want to be in complete control
of when an image composition is written to disk for whatever reason. Or
perhaps I'm just too backwards... :)

 / Martin
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Mirai Warren]

What version of the gimp is this?  I don't have any Export menu or
Export to option.  The only problem I ever have is with exports from
multilayer to single layer images: several of the dialogs presented at
save seem unnecessary or superfluous.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

Mirai Warren wrote:
> What version of the gimp is this?

This is the gimp-developer mailing list where GIMP development is
discussed. Most of the new features discussed on this list is not in any
released version of GIMP yet. You can however always use the latest
implemented features by for example compiling GIMP from git:
http://git.gnome.org/cgit/gimp/

or finding someone that does regular builds for your OS.

 / Martin
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Graeme Gill]

Martin Nordholts wrote:
> While this and the rest of your mail is true and I agree, one could
> argue that users of a high-end app still want to be in complete control
> of when an image composition is written to disk for whatever reason. Or
> perhaps I'm just too backwards... :)

Not just high end apps, all apps. Since Open/Edit/Save is
the dominant paradigm, any application that works in
a different way is going to be the odd one out, and
will drive users insane.

Graeme Gill.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alec Burgess]

Graeme Gill (graeme2@...) wrote (in part)  (on 2009-06-25 at
20:34):

Martin Nordholts wrote:
  

> While this and the rest of your mail is true and I agree, one could 
> argue that users of a high-end app still want to be in complete control 
> of when an image composition is written to disk for whatever reason. Or 
> perhaps I'm just too backwards...  :) 
    

Not just high end apps, all apps. Since Open/Edit/Save is
the dominant paradigm, any application that works in
a different way is going to be the odd one out, and
will drive users insane.

I'm not a developer nor programmer and applications which use or were changed to use immediate commit to database in a new version caused me some conceptual problems when first encountered. (eg "libraries" in JGSoft's RegexBuddy, database for Website-Watcher, database in PIM InfoQube - aka SQLNotes, captured clips in ClipCache Plus and bookmarks in Firefox 3).

However, once I've convinced myself that the save to database *is* happening and *is* reliable,  the switch to the alternate paradigm turns out to be exactly what I want. If I exit having forgotten to save or the application crashes or has to be manually terminated or even it the system blue-screens no fears or worries about what work may have been lost. How could life be any better?

Whether this is possible or feasible with a graphics application like GIMP I leave to better minds than mine.


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Graeme Gill]

Alec Burgess wrote:
> However, once I've convinced myself that the save to database *is*
> happening and *is* reliable,  the switch to the alternate paradigm turns
> out to be exactly what I want. If I exit having forgotten to save or the
> application crashes or has to be manually terminated or even it the
> system blue-screens no fears or worries about what work may have been
> lost. How could life be any better?
>
> Whether this is possible or feasible with a graphics application like
> GIMP I leave to better minds than mine.

That is the issue. In creative applications where most of the time
the process is one of exploration from a given start point, having an
app. that by default overwrites a previous save point (ie.
when it crashes, is killed, exit'ed accidentally, by mistake etc.)
is probably not what you want. Many times the process is "I'll
open the document, modify it, evaluate, then decide whether
to discard/ovewrite the save point/save to something else".
Note that the "accidentally loose work" problem is overcomeable
in ways that don't involve by default overwriting the start point.

Graeme Gill.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Liam R E Quin]

On Thu, 2009-06-25 at 18:33 +0200, Martin Nordholts wrote:

> While this and the rest of your mail is true and I agree, one could
> argue that users of a high-end app still want to be in complete control
> of when an image composition is written to disk for whatever reason.

When saving an image to png takes 5 or 10 minutes, I certainly don't
want it happening when I didn't ask for it... especially as I might not
have 300 megabytes (the approx size of the last image I saved with gimp)
of available space.

People who work with images for pre-press and print generally have
larger files than people working on facebook avatars :-) and need
more control.

Liam


--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org www.advogato.org

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

On Fri, Jun 26, 2009 at 4:34 AM, Graeme Gill wrote:

> Not just high end apps, all apps. Since Open/Edit/Save is
> the dominant paradigm, any application that works in
> a different way is going to be the odd one out, and
> will drive users insane.

You just never used Palm :)

Somehow users of GRAMPS almost never complain :) (And yes, I happen to
be one of them)

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

On 06/23/2009 09:13 PM, peter sikking wrote:

> I have re-evaluated every fundamental
> principle that is the basis for the change, looking at "what is it
> is the other way around for users?" and if that also could solve
> the 2.6 mess. because let's face it, the 2,6 situation is a mess.
>
> however it is not the fundamental principles that are wrong, but
> the current execution. I will now outline what has to change,
> it uses suggestions of Liam, Simon and Alexia, glued into a
> solid concept again:
>
> - no longer Untitled
>     in the title bar of the window for imported images or
>     (the interesting case) where a new composition is exported
>     but not yet saved. the name part of the filename is
>     displayed in the titlebar (e.g. "[lawnmower]" for
>     "lawnmower.jpg")
>
> - the '*' is still used for the save-state, but we can show more
>     info after the filename in the title bar of the window:
>     "(imported)", "(overwritten)", "(exported)".
>
> - change to the title of the menu item that does the 'back-sport',
>    after a long brainstorm on irc and munching
>     on it for a couple of days more the winner is:
>
>     "Overwrite lawnmower.jpg"
>
>     where lawnmower.jpg is the imported file.
>
>    

I have implemented these changes now, try it out with latest git master

  / Martin

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer