Re: [Gimp-developer] proposed solution for: protection from information loss

2008-07-01 Thread Sven Neumann
Hi,

On Sat, 2008-06-14 at 13:43 -0400, Liam R E Quin wrote:

 A long-term gnomish model might be to make it easier to drag things onto
 the desktop (or into folders in the file manager), but people use gimp
 also in other environments.

You can already do that in GNOME. Drag the image preview from the
toolbox (you need to enable the image preview there in the Preferences
dialog) to the GNOME desktop or to the file manager and the image will
be saved there. The protocol to do this is called XDS and GIMP supports
it since version 2.4.


Sven


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


Re: [Gimp-developer] proposed solution for: protection from information loss

2008-06-14 Thread Liam R E Quin
On Fri, 2008-06-13 at 06:20 +0200, [EMAIL PROTECTED] wrote:
 Hi all,
 
 Carl Karsten wrote:
  proposed spec:
  
  File Open/Save/Save_as_Copy only work on .xcf - all other formats must use
  File Import/Export.[1]

Yesterday I saved an image in xcf by mistake, by mistyping the .png at
the end of the filename (left off the dot).

Usually if I type a filename ending in .png though, I don't want an xcf
file to be created.

 What about using just Import/Export?
 
 The GIMP could take care of saving automatically, e.g. by writing XCFs to a 
 private folder.

How then do I give the xcf file to someone else, or back it up?
I'd quickly have several hundred gigabytes of data there if I wasn't
careful, too.


 Throwing out Open/Save/Save_as_Copy as a whole solves a lot of issues.

A long-term gnomish model might be to make it easier to drag things onto
the desktop (or into folders in the file manager), but people use gimp
also in other environments.

It's important to remember that some of the interactions between gimp
and content management systems are and will remain manual (e.g. when to
save an interim milestone copy, and when the work is finished...)

Also, right now, I can use Save As, do some changes, undo the changes,
and see where I had got to when the image is marked as unchanged (the
star goes away from the window title for example).

But maybe a note in the Undo History about image was saved here would
be even more useful to me and clearer to others.

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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] proposed solution for: protection from information loss

2008-06-12 Thread gib_mir_mehl
Hi all,

Carl Karsten wrote:
 proposed spec:
 
 File Open/Save/Save_as_Copy only work on .xcf - all other formats must use
 File Import/Export.[1]

What about using just Import/Export?

The GIMP could take care of saving automatically, e.g. by writing XCFs to a 
private folder.
Import/Export work on all filetypes.
Closing an image writes an XCF to the private folder.
Closed images can be retrieved via File-Recent

This leaves open the problem of when to delete the XCFs.

Throwing out Open/Save/Save_as_Copy as a whole solves a lot of issues.
cheers,
peter

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] proposed solution for: protection from information loss

2008-06-09 Thread Michael Schumacher
 Von: Akkana Peck [EMAIL PROTECTED]

 For that workflow, what would be even more useful is to be able to
 have a command that could do both: save the current .xcf (.gz or .bz2)
 AND, from the same menu item or keystroke, save a copy to a simpler
 format. Then you wouldn't have to go back and forth between Save and
 Save a Copy every time you make a change, and you wouldn't have to
 confirm the copy's filename every time you saved it.

Something like this has been brought up during the first usability meeting, 
where some of the boring tasks a user has to do have been identified.

 It would be great if it were possible to write a plug-in that would
 do that, even if gimp didn't include it natively. It would need to
 get the current filename (that's easy already, gimp-image-get-filename)
 and also what the last save a copy filename was (not so easy --
 I don't think there's an API to get that now, is there?)

For ages I've heard rumours about a feature that lets file save plug-ins pass a 
save operation throught to other save plug-ins. I'm not sure if this does 
exists, as I haven't seen any example yet (to be fair, I didn't search, 
either), but maybe this can be used here.


HTH,
Michael
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] proposed solution for: protection from information loss

2008-06-08 Thread Carl Karsten
proposed spec:

File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File 
Import/Export.[1]

Add File/Import and Export to handle alien formats.

File/New and File/Import would be very similar: they both create a new image 
with various attributes.  New gets the the attributes from the dialog, Import 
gets them from the image file.  Currently, File/New, OK, file/Close does not 
produce a nag. (good.)  File/Import, File/Close would not nag.

File/New currently does not name the image.  That gets asked for on save.  The 
same would apply to File/Import: it would not inherit the name.  File/Save 
would 
default the name to Import name, but using .xcf instead of ext of Import. 
File/Export would default to the Imported name.ext and type.  (example: 
File/Import foo.gif, File/Save prompts for name, defaults to foo.xcf. 
File/Export defaults to foo.gif)

command line usage would still work with any format.  but that only applies to 
'loading' the file, not what it's name is.  (i think all save/export cases are 
covered above)

The only nag will be when trying to close a touched image that has not been 
saved (which by #1 would always be as .xcf)

File/Preference option to turn off the you will loose info nag.  Possibly 
some 
options to tune it, like Only nag if not saved in any format. (I have a 
feeling that is more confusing than it is worth, but would be easy enough to 
implement, and would save my ass when I accidentally close the wrong image 
window.)  I am pretty sure there is a usability law that says an app should 
always warn before discarding data, so I am pretty sure there should always be 
the Save the changes to 'Untitled' before closing? nag.

/proposed spec

I think this would remove the need for all nags except save unchanged?

It would add steps when using gimp to edit an alien format.
current: gimp foo.gif, (or launch gimp, Open foo.gif), edit, Save, Close.
proposed: gimp foo.gif, (or launch gimp, Import foo.gif), edit, Export, Hit 
Save 
button (filename defaulted to foo.gif)[2], Close, hit Don't_Save in respose to 
Save Unchanged...?

Damm... there is still something that I am not sure how to handle: When 
Exporting, should it nag when you are overwriting an existing file?  I think 
the 
answer is 'yes' which will add another step.  I can see gimp being intelligent 
about this and doing the obvious thing (don't nag if using the default) but 
that 
  might be crossing a line into automagic.  maybe another Preferences option.

One question: should gimps 'normal' behavior make it easy (minimum nags) to edit
A) alien formats,
or
B) gimps native format?

I am kinda liking the idea that gimp makes it easy to edit/save gimp images, 
and 
  alian formats are derivatives, not the primary storage for images.

Did I mis anything?

Carl K



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


Re: [Gimp-developer] proposed solution for: protection from information loss

2008-06-08 Thread gib_mir_mehl
Carl Karsten wrote:

 proposed spec:
 
 File Open/Save/Save_as_Copy only work on .xcf - all other formats must use
 File 
 Import/Export.[1]
 
 Add File/Import and Export to handle alien formats.

Save_as_Copy and Export are the same (the user should be able to export as 
.xcf).


This approach shifts the problems from saving to opening.
Additionally, the 'forced .xcf' behaviour can be quite nagging - consider 
user experience for a quick Levels adjustment to a photo:
1- Open doesn't work
2- Import
3- adjustments, all jpeg-compatible
4- Save only allows .xcf, which is overkill here
5- Step back to Export
6- remaining image mysteriously nags on closing

Where i agree with you, is that gimp should support the typical workflow
which centers around a .xcf main document with several regularily updated 
offsprings.
But that is another topic.

To answer your question: please, A and B.


Another idea i'm currently tinkering with:
Don't all those export troubles disintegrate once we presume a little
more confidence in the undo function?

What if Save foo.jpg would actually flatten the image?
If that was not intended, the user could easily undo and use Export the next 
time.
Advantage: The result can be seen, with layersalpha being lost. This is much 
more
intuitive than textual explanations...


so long,
peter



-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] proposed solution for: protection from information loss

2008-06-08 Thread Akkana Peck
[EMAIL PROTECTED] writes:
 Additionally, the 'forced .xcf' behaviour can be quite nagging - consider 
 user experience for a quick Levels adjustment to a photo:
[ ... ]
 Where i agree with you, is that gimp should support the typical workflow
 which centers around a .xcf main document with several regularily updated 
 offsprings.
 But that is another topic.

For that workflow, what would be even more useful is to be able to
have a command that could do both: save the current .xcf (.gz or .bz2)
AND, from the same menu item or keystroke, save a copy to a simpler
format. Then you wouldn't have to go back and forth between Save and
Save a Copy every time you make a change, and you wouldn't have to
confirm the copy's filename every time you saved it.

It would be great if it were possible to write a plug-in that would
do that, even if gimp didn't include it natively. It would need to
get the current filename (that's easy already, gimp-image-get-filename)
and also what the last save a copy filename was (not so easy --
I don't think there's an API to get that now, is there?)

 What if Save foo.jpg would actually flatten the image?
 If that was not intended, the user could easily undo and use Export the next 
 time.
 Advantage: The result can be seen, with layersalpha being lost. This is much 
 more
 intuitive than textual explanations...

That trains users not to save intermediate results in some cases.
Consider the case where you need to add text to a jpeg with the
result being another jpeg for a website; yet you still might want
to try several different fonts, text strings etc.
I know, you're thinking Why not save the intermediates as xcf?
But if there are only a couple of layers and fifteen minutes of work,
it doesn't always seem worth the extra disk space to save an xcf
in addition to the final jpg.

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