[Gimp-developer] Save + Export proposal

[Nicolas Robidoux]

An idea (especially for when GIMP moves to GEGL). Apologies if this
has been suggested/shot down before.

I think that the following terminology would be fairly clear to users:

  Save IMAGE (basically, export to a non-xcf format)

  Save PROJECT (save the xcf/gegl tree)

  Save WORKSPACE (save the current configuration of GIMP, not the
  xcf/gegl tree or the image: visible tools, visible non image windows
  etc)

IMHO, this 3-pronged "save" option makes it pretty clear what this is
about.

I suggested earlier that "Save workspace" (like nip2) should be the
non-export quick save, but eventually realized that a "workspace"
suggests a set of easily accessible tools organized to fit a specific
TYPE of project. 

On the other hand, "Save project' suggests that all the components of
the intended final image should be kept around.

"Save image" really suggests that what you are saving is the final
product, in a common image format, that is, it corresponds to
exporting.

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

[Gimp-developer] Save + Export proposal

[photocomix]

probably this will be my last reply on the matter, i do not like insist
proposing something that someone else has to code, even if in this case
would be just a trigger for  not interactive call(s)

I divided the objection in 2 groups, the first group  focused on possible 
disadvantages and technical problem ,

 ..the second in my opinion derived of some 
misunderstanding of what proposed, or how i proposed to implement


In the first group

>- so it is easy to set (
>but how to stop it for a file? it was in the Save >dialog,
>but to get there again? Save as?

>Suppose you do this. You edit something, and press >C-s. What would happen?

Correct ,  i was too generic in proposing the change for "the save dialogs"

let focus in the "Save as" dialog,  in that case i can't image any similar
problems
(For who wish something as "save+export"  a third party script
 may be a better option and the script already exist)

#
Then there is the second group of objection:
 a lot complains about  the risk to complicate the code 
or on the work needed to modify both the Save and Export function

>so why not add it anyway, doesn't hurt no? yes it does:

>- by associating 2 or more export files, "Export to foo.png"
>(ctrl-E) has to be redesigned and never be as good as now.

>- you have coupled saving to exporting of multiple files, hard.
>in general these things do not happen at the same time,
>saving work is a different thing then delivering. write
>times go up by a factor of 1+N, where N is the number of
>export formats.



>- UI also needs to be not-error-inducing and give a clear model
>to users to how things work. this proposal here is one of several
>to get a litle bit of export back into the Save dialog.
>each of these creates _a_ way to export, that users may figure
>out as _the_ way to export, because they are migrating from
>2.6 to 2.8. No, it does not help that we have clear Export on
>the File menu. we simply cannot let these models of export develop.

well i can't see nothing to redesign (except a detail in the Save as dialog)
neither any need to re-associate files or redesign ctrl_E

Because i do not propose any change for the save function, but basically
only
 a modification to the GUI of "save AS"
 
 Sure any change in the GUI is connected to a change in the code
 
 But in this case not to a change in the Save as functions:
that "export copy too as"would be there just because is most handy for users
there, but will not interfere on how the Save function will work but just add 
not interactive call(s) after saving will be done

So whatever user will chose Save as will work as usual with no any change, no
interference, no complications
 
just at the end "Export" will be called 
  in not interactive way passing as arguments the filename, 
  the directory used to save and the chosen file formats(my mock up show how
chose
   the file format ) and for the rest the user deafault.

   
   Export function does not need any modification to support not interactive
call
   (as far i know):
   
   If the user chose to Save as+ export a jpg ...a not interactive call will
be done 
 if user wish also also png  , a second call would be done to "export as
png"
 using for the rest the identical arguments  (same filename and directory +
user defaults
 chosen for that format)
---   - 
 
 please allow me a metaphor 
 Eat and Drink are 2 different concept ,no less then Save and Export
 
 Suppose you go in a Restaurant to eat, you order your food then you ask
 "do you have something to drink ?"
 
And the waiter reply
 "sure we have!..but drinking is a different concept and we do not want
create confusion
 in our clients.

 we have a separate room for who wish to drink, you will be welcome there
 Obviously  eating there is not allowed, that is for drink...but you are free
to
  change room anytime you feel thirsty and get back here when you wish to eat
"



  
  The fact that 2 things are conceptually different do not exclude that may
be much better achieve both simultaneously
  


-- 
photocomix (via www.gimpusers.com)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save + Export proposal

[Ilya Zakharevich]

[Looks like every time I post, I kill the list.  My apologies; reposting]

On 2009-10-05, photoco...@gmail.com  wrote:
> So why do not offer a chance to speed up the workflow, save time and
> patience
> achieving both result simultaneusly ?
>
> A image is worth 1.000 words ,to avoid misunderstunding i invite to give a
> look to this 
> mock up
> http://farm3.static.flickr.com/2653/3981269891_998c2f513b_o.jpg

Suppose you do this.  You edit something, and press C-s.  What would happen?

Ilya

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

Re: [Gimp-developer] Save + Export proposal

[Rob Antonishen]

On Tue, Oct 20, 2009 at 11:02 AM, peter sikking  wrote:

> so that is why I am against this.
>
>     --ps

Even that said, anyone is free to develop a save and export plugin and
offer it up for public consumption.  It may not make it into the core,
but assuming it is worthwhile, it will find use.

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

Re: [Gimp-developer] Save + Export proposal

[peter sikking]

photocomix wrote:

> i knew that Peter Sikking (or somebody else from Gimp UI brainstorm
> staff)replied but the message get lost for technical problems (full  
> storage
> disk)

yes, I am (by default) the Gimp UI brainstorm staff, and I had about
3 threads going on here before the list collapsed.

> I am very interested to know the content of that reply,i hope you  
> may send
> again now


here we go:

OK, I waited with replying because I wanted to think about this  
carefully.
that is because quite a few issues are combining here.

first two fundamental issues:

1) let's face it: this is a new feature request. it is not that we
   broke something in this 50 pictures a day (10 minutes each) workflow.
   actually, on balance things got a bit better for this with clear
   saving and exporting.
2) an even bigger picture: does GIMP has to solve this problem?
   since part of what you want is a no-brainer conversion from
   png to jpeg. sounds like a job for a batch tool. this way you
   would save your GIMP file, then ctrl-shift-E, return, return,
   and GIMP does remember if you wanted TIFF or png all the time.
   run the batch job at the end of the day.

so why not add it anyway, doesn't hurt no? yes it does:

- by associating 2 or more export files, "Export to foo.png"
  (ctrl-E) has to be redesigned and never be as good as now.

- you have coupled saving to exporting of multiple files, hard.
  in general these things do not happen at the same time,
  saving work is a different thing then delivering. write
  times go up by a factor of 1+N, where N is the number of
  export formats.

- so it is easy to set (well, you will have to 50 times a day)
  but how to stop it for a file? it was in the Save dialog,
  but to get there again? Save as?

- UI also needs to be not-error-inducing and give a clear model
  to users to how things work. this proposal here is one of several
  to get a litle bit of export back into the Save dialog.
  each of these creates _a_ way to export, that users may figure
  out as _the_ way to export, because they are migrating from
  2.6 to 2.8. No, it does not help that we have clear Export on
  the File menu. we simply cannot let these models of export develop.

so that is why I am against this.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

[Gimp-developer] Save + Export proposal

[photocomix]

i knew that Peter Sikking (or somebody else from Gimp UI brainstorm
staff)replied but the message get lost for technical problems (full storage
disk)

I am very interested to know the content of that reply,i hope you may send
again now 

-- 
photocomix (via www.gimpusers.com)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Save + Export proposal

[photocomix]

I send the mock up to the gimp-Ui brainstorm.

And for end users that may be interested ,in the while RobA cooked a script
that offer basically equivalent features 

obviously can't offer same GUI of my mock up, but allow 

1 ) to Save+Export , popping out a error message if the image was not already
saved
2 )to Save AS + Export ...this basically allow to run the Save As dialog as
usual and then automatically export copies in the chosen format

Actually Export only in jpg and png but should be trivial add more format
option

But has a price to crowd even more the File menu with 2 additional entries 

while, in my opinion a similar added option to the Save dialogs will not
screw up the GUI and will be clear and handy .

Maybe no much feel the need as now but is hard feel the need for something
never experienced before...
Once experienced may be more clear that may be a time saver

anyway the script works may be easy edited to add more export format (for
example tiff, psd) and is here

http://ffaat.pointclark.net/incoming/scripts/save_and_export_1.2.scm





>> This assumption is wrong. Complex compositions will need to be refined
for
>> weeks. All work is done in XCF. Before final delivery there is only an
>> occasional need to export to some other format.

Your point is not too clear to me, i agree that a composition may take weeks,
but at the end (at least in most cases ) as, not only to be saved but also to
be exported

Sure would be much less needed for who has to export only once in week,and
much more needed by who has to export Save last edit +Export every 30 minutes

But as added option seems to me unobtrusive in that Spheciphic GUI and the
distiontion between SAVE and EXPORT is not only preserved but may even made
more clear (at least in the mock up)

-- 
photocomix (via www.gimpusers.com)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save + Export proposal

[Liam R E Quin]

On Mon, 2009-10-05 at 22:24 +0200, Martin Nordholts wrote:
> Hi,
> 
> On 10/05/2009 02:10 AM, photoco...@gmail.com wrote:
> > But even if conceptually different in practice ,   both operation are always
> > needed for the every edited image:
> > is needed to Save the original AND to export as jpg or png .
> 
> This assumption is wrong. Complex compositions will need to be refined for
> weeks. All work is done in XCF. Before final delivery there is only an
> occasional need to export to some other format.

Actually the two statements don't contradict each other -- it's fair
to say that the most likely workflows are
(1) load image (jpeg. png, tiff, cr2, etc)
work on image
maybe save image in proprietary format temporarily, between sessions
eventually, do at least one of
. save in archive format (tiff, png)
. export to jpeg or gif or .mov or whatever
. print

(2) create new image, and rest as above.

And in most cases you'll need to export the image at some point,
for every image.

It's got a little harder to track what you've done, now, because
you need to know if the export filenames are up to date as well
as the xcf filenme, and right now you can't tell.

E.g. an "image file history" panel showing save status, or
adding save & export events to the undo history (even though
you can't undo them they are part of the history) might help.

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] Save + Export proposal

[Martin Nordholts]

Hi,

On 10/05/2009 02:10 AM, photoco...@gmail.com wrote:
> But even if conceptually different in practice ,   both operation are always
> needed for the every edited image:
> is needed to Save the original AND to export as jpg or png .

This assumption is wrong. Complex compositions will need to be refined for
weeks. All work is done in XCF. Before final delivery there is only an
occasional need to export to some other format.


 / Martin

-- 

Latest blog post Sunday, October 4, 2009:
"Single-window mode progress report"

My GIMP Blog:
http://www.chromecode.com/

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

Re: [Gimp-developer] Save + Export proposal

[Omari Stephens]

photoco...@gmail.com wrote:
::snip? SNIP!::
> As you may see the idea is not to replace the Export dialog, but  to offer a
> handy option from the Save dialog, to simultaneously export , with same name
> and in the same directory in other file formats
Wouldn't this be fairly straightforward to do as a plugin/python-fu/script-fu?

Adding code makes things slower.  If this isn't something that would benefit 
the 
vast majority of GIMP users (and I'm not sure it would), it seems better to 
offer it as an option for those who want it, rather than to add extra code for 
the users who won't touch it.

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

[Gimp-developer] Save + Export proposal

[photoco...@gmail.com]

A clear distinction between Save and Export was needed

But even if conceptually different in practice ,   both operation are always
needed for the every edited image:
is needed to Save the original AND to export as jpg or png .

So why do not offer a chance to speed up the workflow, save time and
patience
achieving both result simultaneusly ?

A image is worth 1.000 words ,to avoid misunderstunding i invite to give a
look to this 
mock up
http://farm3.static.flickr.com/2653/3981269891_998c2f513b_o.jpg

As you may see the idea is not to replace the Export dialog, but  to offer a
handy option from the Save dialog, to simultaneously export , with same name
and in the same directory in other file formats

A possible objection is that "same name and some directory" is a severe limit
but

1) For other cases there is well the proper Export Dialog

2) consider a  real case

 if in 1 day i edit 50 photos, i  need to
go trought 150 Save and Export dialog (and as now to click away about 300
warning ) to save original,a looseness png or tiff copy, and a jpg of my work

Using that option at the end of the work, in case i wish original, png and
jpg in different folder i may get the result in 1 minute:

Is trivial filter the folder content for file extension and batch move all
xcf, png, and jpg in their own dedicated folder

Even Picasa, or xnview and irfanview may do in a heartbeat...so would be not
even needed to type a couple of  commands  in a terminal 

1 minute Vs 100 additional dialogs




PS

i will appreciate a reply to this somehow connected technical question
http://www.gimpusers.com/forums/gimp-developer/12001-Gimp-file-save-interactive.html
 :
In case the above proposal will be rejected, and anyway
in time-while  i will really need a script doing something similar...script
is ready but that problem spoils the result








-- 
photoco...@gmail.com (via www.gimpusers.com)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save/Export Patch

[Liam R E Quin]

On Wed, 2009-09-16 at 10:16 +0100, James Hughes wrote:

> Can someone advice me the best place to start in making a patch to the UI to 
> revert the 2.7 version to using the 2.6 style save dialogue.


If you can bear it, I'd say wait a little longer - the design is still
evolving, and I think it's improving.

Also, you can of course say what about the new design is making things
harder for you, and maybe that will help.  For me the hardest thing
left is that GIMP doesn't remember the "right" directory to export
images, and that's already being fixed, or at least the design is
in place now.

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] Save/Export Patch

[Martin Nordholts]

On 09/16/2009 11:16 AM, James Hughes wrote:
> Hello, 
> 
> Can someone advice me the best place to start in making a patch to the UI to 
> revert the 2.7 version to using the 2.6 style save dialogue. If someone would 
> kindly point me in the right direction of which files I need to change would 
> really appreciate it.

Hi James,

The first work regarding save+export was merged to git master in
commit cd8829b91b3a. Type

  gitk cd8829b91b3a

in your GIMP git repo and you'll see the initial commits. After that,
development has happened incrementally directly in git master so you'll
need to manually browse the commits and identify the relevant ones.

HTH,
Martin

-- 

My GIMP Blog:
http://www.chromecode.com/

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

Re: [Gimp-developer] Save/Export Patch

[Alexia Death]

On Wed, Sep 16, 2009 at 1:32 PM, Alexandre Prokoudine
 wrote:
>
> On Wed, Sep 16, 2009 at 1:16 PM, James Hughes wrote:
> > Hello,
> >
> > Can someone advice me the best place to start in making a patch to the UI to
> > revert the 2.7 version to using the 2.6 style save dialogue. If someone 
> > would
> > kindly point me in the right direction of which files I need to change would
> > really appreciate it.
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
>
> Sticking a fork into GIMP was never successful. Most everybody who
> tried didn't get as far as picking a knife with the other hand.
>
10pts for good humor.

To the fork operator, in all seriousness tho, look at git. Relevant
commits are clearly marked. However, the remark above is 100% true.
Just stick to 2.6 if you like that so much.

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

Re: [Gimp-developer] Save/Export Patch

[Alexandre Prokoudine]

On Wed, Sep 16, 2009 at 1:16 PM, James Hughes wrote:
> Hello,
>
> Can someone advice me the best place to start in making a patch to the UI to
> revert the 2.7 version to using the 2.6 style save dialogue. If someone would
> kindly point me in the right direction of which files I need to change would
> really appreciate it.

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

Sticking a fork into GIMP was never successful. Most everybody who
tried didn't get as far as picking a knife with the other hand.

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

[Gimp-developer] Save/Export Patch

[James Hughes]

Hello, 

Can someone advice me the best place to start in making a patch to the UI to 
revert the 2.7 version to using the 2.6 style save dialogue. If someone would 
kindly point me in the right direction of which files I need to change would 
really appreciate it.

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Martin Nordholts]

peter sikking wrote:
> after checking out Inkscape and Scribus, I think Alexandre just
> added another valid factor, which means that the balance just
> tipped the other way:
>
> Export should be shift-ctrl-E
>
> 'Export to ' should be ctrl-E


Makes sense, I'll swap the shortcuts. It is quite ironic though that 
Inkscape has something similar to Shrink Wrap on ctrl-E :)

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

Re: [Gimp-developer] Save + export spec essentials implemented

[peter sikking]

Alexandre wrote:

> On Sat, May 16, 2009 at 3:38 PM, Martin Nordholts wrote:
>
>> One notable change is that Ctrl + E is now bound to File->Export by
>> default instead of View->Shrink Wrap. Hopefully this change will  
>> not be
>> too much of a pain. We may need to consider finding a new keyboard
>> shortcut for View->Shrink Wrap.
>
>> From what I remember both Inkscape and Scribus use Ctrl+Shift+E for
> exporting. Why not be consistent with them and don't have to look for
> a new shortcut for View->Shrink Wrap? :)


there is a couple of things I know for sure:

- both Export and 'Export to ' need a shortcut.
- one of these shortcuts needs to be a  variant of the other.
- 'E' is too good of a shortcut not to use for both of them.

so shrink wrap and fit image in window are looking for new shortcut.

deciding which one should be ctrl-E and which shift-ctrl-E is
a rational vs. feeling kind of struggle with many factors.

after checking out Inkscape and Scribus, I think Alexandre just
added another valid factor, which means that the balance just
tipped the other way:

Export should be shift-ctrl-E

'Export to ' should be ctrl-E

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexandre Prokoudine]

On Sat, May 16, 2009 at 3:38 PM, Martin Nordholts wrote:

> One notable change is that Ctrl + E is now bound to File->Export by
> default instead of View->Shrink Wrap. Hopefully this change will not be
> too much of a pain. We may need to consider finding a new keyboard
> shortcut for View->Shrink Wrap.

>From what I remember both Inkscape and Scribus use Ctrl+Shift+E for
exporting. Why not be consistent with them and don't have to look for
a new shortcut for View->Shrink Wrap? :)

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Martin Nordholts]

Martin Nordholts wrote:
> Hi
>
> I have been working on implementing the Save + export spec [1] for a 
> while. 

And I have also merged the base work to GNOME master now, so to try it 
out all you have to do is git pull. There is still work to be done (see 
the merge commit message) but we are definitely ready for some broader 
testing.

One notable change is that Ctrl + E is now bound to File->Export by 
default instead of View->Shrink Wrap. Hopefully this change will not be 
too much of a pain. We may need to consider finding a new keyboard 
shortcut for View->Shrink Wrap.

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexander Rabtchevich]

I suspect thumbnailing will not be enough. Let's see an example of  
"high end" workflow for photography. One has taken a bunch of RAW 
images. He has to browse them and compare, delete the bad ones. Then the 
images need conversion with desired comparing at that stage and the 
selection goes on... Some of them need postprocessing. And _after_ 
postprocessing they need scalable up to full-size browsing. Not 
thumbnails, but full-size preview. No thumbnail would replace large 
image when selecting which to print, handle, convert to flat format or 
delete. So the library should be able to make full-size preview.

Martin Nordholts wrote:
> Alexander Rabtchevich wrote:
>
>> Can one guarantee GIMP compositions will be at least correctly rendered
>> with third-party viewers as image browsing is not in GIMP goals? At
>> least recently xcf has been considered as internal GIMP format. Having
>> thousands files what cannot be easily and quickly viewed and organized
>> is not a good idea IMHO. That will be a reality a user runs into. What
>> is you vision of that problem?
>>  
> The solution to this is to provide a, probably GIMP maintained,
> plug-inable component that can do the thumbnailing. Since the current
> XCF format is tightly coupled with the GIMP internals this is a bit
> messy but will likely become much easier once we do our rendering with
> the GEGL library.
>
>
With respect
Alexander Rabtchevich

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Martin Nordholts]

Alexander Rabtchevich wrote:
> Can one guarantee GIMP compositions will be at least correctly rendered 
> with third-party viewers as image browsing is not in GIMP goals? At 
> least recently xcf has been considered as internal GIMP format. Having 
> thousands files what cannot be easily and quickly viewed and organized 
> is not a good idea IMHO. That will be a reality a user runs into. What 
> is you vision of that problem?

The solution to this is to provide a, probably GIMP maintained, 
plug-inable component that can do the thumbnailing. Since the current 
XCF format is tightly coupled with the GIMP internals this is a bit 
messy but will likely become much easier once we do our rendering with 
the GEGL library.

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexandre Prokoudine]

On Wed, May 13, 2009 at 9:57 AM, Alexander Rabtchevich wrote:
> Pleasant interactive cropping

In fact tools like Lightroom or Rawstudio beat GIMP for me when it
comes to cropping of photos -- for reasons multiple times explained to
GIMP developers.

> and scaling, required for web are enough
> reasons. Red eyes reduction sometimes...

All of the above including cropping can be perfectly done in tools
like Rawstudio or F-Spot or digiKam or even in Darktable (which is
becoming GEGL based btw). This is why they are (becoming) *workflow*
tools.

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexander Rabtchevich]

Can one guarantee GIMP compositions will be at least correctly rendered 
with third-party viewers as image browsing is not in GIMP goals? At 
least recently xcf has been considered as internal GIMP format. Having 
thousands files what cannot be easily and quickly viewed and organized 
is not a good idea IMHO. That will be a reality a user runs into. What 
is you vision of that problem?


peter sikking wrote:
> and to show again our priorities: at LGM Hylke Bons (works
> on visual design all day long) said: "of course all my work
> is in project-type files." enough said.
With respect
Alexander Rabtchevich
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save + export spec essentials implemented

[peter sikking]

peter (yahvuu) wrote:

> peter sikking schrieb:
>> foo.png was never inside GIMP. it was an xcf that had foo.png as a
>> starting point. we try to reflect this in every way. one way that  
>> came
>> up during LGM discussions was that the layer should be always
>> (even for "background") be named after the image that was imported as
>> its starting point. I think we should do that.
>
> that's a really good idea! Regarding export/import, GIMP's document  
> model
> is much like Inkscape's, with the difference that for the latter, it  
> is
> immediately understandable why...
>
> Still, i very much hate to send users into one-way streets, and for  
> the
> open=import case, this is not planned.

right, that is an obvious optimisation.

> I wonder if we can't somehow
> ease the case where export=save? Perhaps via a shortcut like
> 'export to PNG & close document & discard data'?
>
> When export is just a branch in the workflow and editing continues  
> on the
> GIMP document in RAM, it might be beneficial to offer one-click Save
> into a backup-directory without having to choose a filename.
> Perhaps 'export to PNG & save backup'?


it is absolutely a design goal that after we have helped users
so much to open(/import) foo.png, make some edits and do a
'Export to foo.png' in one click, without dialogs, users must be
fully aware that they are throwing away the GIMP document
(LGM discussion result: call it a composition) that they used
to reach their goal.

we cannot have accident with GIMP compositions not being saved
because we offered a too-clever-by-half shortcut.

and to show again our priorities: at LGM Hylke Bons (works
on visual design all day long) said: "of course all my work
is in project-type files." enough said.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] Save + export spec essentials implemented

[yahvuu]

Hi all,

peter sikking schrieb:
 > foo.png was never inside GIMP. it was an xcf that had foo.png as a
> starting point. we try to reflect this in every way. one way that came
> up during LGM discussions was that the layer should be always
> (even for "background") be named after the image that was imported as
> its starting point. I think we should do that.

that's a really good idea! Regarding export/import, GIMP's document model
is much like Inkscape's, with the difference that for the latter, it is
immediately understandable why...

Still, i very much hate to send users into one-way streets, and for the
open=import case, this is not planned. I wonder if we can't somehow
ease the case where export=save? Perhaps via a shortcut like
'export to PNG & close document & discard data'?

When export is just a branch in the workflow and editing continues on the
GIMP document in RAM, it might be beneficial to offer one-click Save
into a backup-directory without having to choose a filename.
Perhaps 'export to PNG & save backup'?


just a rough thought,
peter

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

Re: [Gimp-developer] Save + export spec essentials implemented

[peter sikking]

Michal wrote:

>> This is a point that Martin and I discussed on irc.
>> Here is the main point that the changes are clarifying is:
>>
>>a file is only safe when it is Saved (in xcf)
>>
>> this means that export is never the solution to unsaved changes and
>> "Export" and "Export to foo.png" cannot be there in the dialog as
>> ways to resolve the situation.
> O.K., but I may not care if file is safe or not. All I want is to  
> have that
> changed file on my disk. I don't mind if it's saved or exported. Why  
> make
> things complicated for this kind of users?

we currently have a mess and it needed straightening out by a clear
separation of save and export. the clear separation is destroyed for
users as soon as there is one hint that and export is also save/safe.

> Next: It's not clear what will happen to my "foo.png" file after I  
> choose
> "Save" image as 'Untitled.xcf'. Will my "foo.png" be changed as  
> well? Will my
> "foo.png" disappear because it's now "safe" as 'Untitled.xcf' and I  
> don't need
> it any longer?

foo.png was never inside GIMP. it was an xcf that had foo.png as a
starting point. we try to reflect this in every way. one way that came
up during LGM discussions was that the layer should be always
(even for "background") be named after the image that was imported as
its starting point. I think we should do that.

to answer your question: foo.png is not touched on disk unless you use
"Export to foo.png" in the file menu. easy, no?

> Maybe it'd be better to completely rearrange that dialog to  
> something like:
> "If you close the image, changes from last minute will be lost.
> You can either save image as 'Untilted.xcf' or export it to any other
> format"
> "CLOSE" "CANCEL" "SAVE" "EXPORT"


sorry, not a hint...

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

[Gimp-developer] Save + export spec essentials implemented

[Michal Predotka]

peter sikking wrote:


> Michal wrote:

>> 2. When I open image "foo.png", do some changes and close it, GIMP  
>> message
>> says:
>> "Save the changes to image 'Untitled' before closing?
>> If you don't save the image, changes from the last minute will be  
>> lost."
>> There are options:
>> "Close without Saving", "Cancel", "Save As".
>>
>> I think it'd be very useful to have option: "Export" and even  
>> "Export to
>> foo.png". Obviously in this case GIMP message should be different as  
>> well.
>
>This is a point that Martin and I discussed on irc.
>Here is the main point that the changes are clarifying is:
>
> a file is only safe when it is Saved (in xcf)
>
>this means that export is never the solution to unsaved changes and
>"Export" and "Export to foo.png" cannot be there in the dialog as
>ways to resolve the situation.
>
O.K., but I may not care if file is safe or not. All I want is to have that
changed file on my disk. I don't mind if it's saved or exported. Why make
things complicated for this kind of users?

Next: It's not clear what will happen to my "foo.png" file after I choose
"Save" image as 'Untitled.xcf'. Will my "foo.png" be changed as well? Will my
"foo.png" disappear because it's now "safe" as 'Untitled.xcf' and I don't need
it any longer?

 Maybe it'd be better to completely rearrange that dialog to something like:
"If you close the image, changes from last minute will be lost.
You can either save image as 'Untilted.xcf' or export it to any other
format"
"CLOSE" "CANCEL" "SAVE" "EXPORT"

Best Regards

Michal (mmiicc)


-- 
Michal Predotka (via www.gimpusers.com)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexander Rabtchevich]

Pleasant interactive cropping and scaling, required for web are enough 
reasons. Red eyes reduction sometimes... Why should one use something 
other if the tool he uses most of the time is convenient and powerful? 
The above mentioned actions are not too complicated to be reproduced in 
one minute. Do they worth storing their result in xcf? I think it is so 
only in the case the format is _well_ understood by third-party 
applications like image viewers and like.

Alexandre Prokoudine wrote:
>> correcting perspective distortion. If a photo is properly exposed, has
>> not excessive noise and is not a portrait of a person you need to
>> improve, there is no need to retouch it after proper RAW conversion.
>>  
> And therefore there is no need to use GIMP.
>
> Alexandre
>
>

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Øyvind Kolås]

On Tue, May 12, 2009 at 6:16 PM, Alexander Rabtchevich
 wrote:
> Peter, I think you (or me :) ) will be surprised if know the statistics
> on the percentage of photos which really need complex retouching or
> complex actions with layers. The most common cases I can give are face
> retouching, "repairing" of a photo with too high dynamic range or
> correcting perspective distortion. If a photo is properly exposed, has
> not excessive noise and is not a portrait of a person you need to
> improve, there is no need to retouch it after proper RAW conversion.

Such adjustments will at some point in the future conceptually be
layer-like as well. White balance, exposure control, unsharp-masking
and noise reduction, cropping and rotation will be done
non-destructively and be possible to tweak later, perhaps even when
you re-open your GIMP composition (xcf, xcf2, OpenRaster or whatever,.
native GIMP document). If you want to share the resulting image you
might as well export it as a JPG, or perhaps even in some other format
suited for some particular use.

/Øyvind K.
-- 
«The future is already here. It's just not very evenly distributed»
 -- William Gibson
http://pippin.gimp.org/http://ffii.org/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexandre Prokoudine]

On Tue, May 12, 2009 at 9:16 PM, Alexander Rabtchevich wrote:

> correcting perspective distortion. If a photo is properly exposed, has
> not excessive noise and is not a portrait of a person you need to
> improve, there is no need to retouch it after proper RAW conversion.

And therefore there is no need to use GIMP.

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexander Rabtchevich]

Peter, I think you (or me :) ) will be surprised if know the statistics 
on the percentage of photos which really need complex retouching or 
complex actions with layers. The most common cases I can give are face 
retouching, "repairing" of a photo with too high dynamic range or 
correcting perspective distortion. If a photo is properly exposed, has 
not excessive noise and is not a portrait of a person you need to 
improve, there is no need to retouch it after proper RAW conversion.

peter sikking wrote:
> I simply have to make a trade-off between your kind of use and
> high-end use that (also for photo) always includes layers and
> other GIMP specific stuff. The high-end simply has a higher
> priority, and your kind of use is well supported.

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

Re: [Gimp-developer] Save + export spec essentials implemented

[peter sikking]

Alexander Rabtchevich wrote:

> I think you are too biased towards xcf as an everyday storage  
> format. It is not needed very often, at least for now. May I provide  
> my usual workflow?


I read your workflow and I am confident that when you try it out
you will find that we support it well with the Export command and
even repeated exporting during your editing session with the
'Export to .jpg' command. The initial critique on the
specification made us focus hard to re-evaluate and improve
these parts of the spec.

The indicator I cannot do because its price (confusion) is too high.

I simply have to make a trade-off between your kind of use and
high-end use that (also for photo) always includes layers and
other GIMP specific stuff. The high-end simply has a higher
priority, and your kind of use is well supported. This change
has been discussed for a long time (like at last year's lgm),
but before I came up with the 'Export to ...' solution we
would have not dreamed to put this in. Exactly because your
kind of secondary workflow would have been badly supported.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexander Rabtchevich]

I think you are too biased towards xcf as an everyday storage format. It 
is not needed very often, at least for now. May I provide my usual workflow?

1. I take pictures in RAW.
2. I convert the pictures I liked in UFRaw and save the result in jpg 
with maximum quality (1:1:1, floating point, 100%). The tests I made 
before showed there was no difference with png but the file sizes were 
less. If a photo requires cropping, resizing, retouching I process it in 
GIMP. And here is the main point: I save xcf only if I have made complex 
actions, including layers, which could take too much efforts to repeat. 
I store intermediate results as invisible layers as possible starting 
point for future modifications.

Look: the final aim is jpg or any other common format (web, printing, 
etc.). I only save in xcf if I think it can happen I will need to edit 
it once more. Storing data in xcf is not so convenient as image viewers 
do not understand all its nuances. So in most of cases I need 2 things: 
original untouched RAW as an untouched in any sense source and a result, 
which is flat image format. This is rather common workflow I guess.
If the situation with lossless editing and third-party image viewers 
changes I think the things with final format will change also. But 
currently the final format is flat image, not xcf. It is so for printing 
in a photo lab, web and so on. Storing additional large files or having 
to convert them to jpg each time they are needed to be handed to someone 
is not a good thing, at least for a person which has and stores RAWs.

My 2c.

peter sikking wrote:
> Alexander Rabtchevich wrote:
>
>> While I haven't tried the new behavior, I would like to be able to 
>> see either I have made any changes after the export in the title bar 
>> or not. Now it is indicated with a star. I prefer to see it remained.
>
>
> that would mean we needed two indicators, one that is is saved,
> and one that it is exported.
>
> but that again would deceive users that export is nearly the same
> as saving. it is not.
>
> maybe it is better to try it out (for a month) first.
> because I am sure that the new clarity of when the work you
> see on your screen is really safe (only in xcf) will change
> users thinking and behaviour about how to secure their work
> and when it is a good time to export.
>
>
With respect
Alexander Rabtchevich
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save + export spec essentials implemented

[peter sikking]

Alexander Rabtchevich wrote:

> While I haven't tried the new behavior, I would like to be able to  
> see either I have made any changes after the export in the title bar  
> or not. Now it is indicated with a star. I prefer to see it remained.


that would mean we needed two indicators, one that is is saved,
and one that it is exported.

but that again would deceive users that export is nearly the same
as saving. it is not.

maybe it is better to try it out (for a month) first.
because I am sure that the new clarity of when the work you
see on your screen is really safe (only in xcf) will change
users thinking and behaviour about how to secure their work
and when it is a good time to export.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] Save + export spec essentials implemented

[Alexander Rabtchevich]

While I haven't tried the new behavior, I would like to be able to see 
either I have made any changes after the export in the title bar or not. 
Now it is indicated with a star. I prefer to see it remained.

>> 2. When I open image "foo.png", do some changes and close it, GIMP
>> message
>> says:
>> "Save the changes to image 'Untitled' before closing?
>> If you don't save the image, changes from the last minute will be
>> lost."
>> There are options:
>> "Close without Saving", "Cancel", "Save As".
>>
>> I think it'd be very useful to have option: "Export" and even
>> "Export to
>> foo.png". Obviously in this case GIMP message should be different as
>> well.
>>  
> This is a point that Martin and I discussed on irc.
> Here is the main point that the changes are clarifying is:
>
>   a file is only safe when it is Saved (in xcf)
>
> this means that export is never the solution to unsaved changes and
> "Export" and "Export to foo.png" cannot be there in the dialog as
> ways to resolve the situation.
>
With respect
Alexander Rabtchevich
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save + export spec essentials implemented

[peter sikking]

Michal wrote:

first of all, thanks for trying it out and commenting.

> My comments and observations:
> 1. When I try to save and I change extension to (for example) .png,  
> GIMP
> message appears:
> "You can use this dialog to save to the GIMP XCF format. Use File- 
> >Export to
> export to other file formats."
> I think it'd be better:
> "You can use this dialog to save only to the GIMP XCF format. Use
> File->Export to export to other file formats."

you added "only" to the string. I actually find that negative thinking,
like we are sorry we are only able to do that for our users.

> 2. When I open image "foo.png", do some changes and close it, GIMP  
> message
> says:
> "Save the changes to image 'Untitled' before closing?
> If you don't save the image, changes from the last minute will be  
> lost."
> There are options:
> "Close without Saving", "Cancel", "Save As".
>
> I think it'd be very useful to have option: "Export" and even  
> "Export to
> foo.png". Obviously in this case GIMP message should be different as  
> well.

This is a point that Martin and I discussed on irc.
Here is the main point that the changes are clarifying is:

 a file is only safe when it is Saved (in xcf)

this means that export is never the solution to unsaved changes and
"Export" and "Export to foo.png" cannot be there in the dialog as
ways to resolve the situation.

> 3. I have file "foo.png" in "bar" folder, I try to save image "foo" as
> foo.png in that folder (I changed xcf to png manually) GIMP message  
> appear:
> "A file named "foo.png" already exists.  Do you want to replace it?
> The file already exists in "bar".  Replacing it will overwrite its
> contents."
> Options are: "Cancel" and "Replace". I choose  "Replace" and GIMP  
> message
> says:
> "You can use this dialog to save to the GIMP XCF format. Use File- 
> >Export to
> export to other file formats."
> I think the second message should appear straight after when I choose
> "Replace" because first message suggests that I can save "foo.png"  
> anyway,
> which if not true.

true, you have found a bug. like you say, the "you can use this  
dialog..."
message should appear straight away.

> 4. In Save Image dialog there's in bottom-right corner button, where  
> you can
> choose what you see:
> "all images", "all files", "gimp XCF Image"
> Although "all images" is selected, you can see only xcf files.


that looks like another bug to me. it is still useful to see all images
(to steal there filenames) in the dialog.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

[Gimp-developer] Save + export spec essentials implemented

[Michal Predotka]

>Hi
>
>I have been working on implementing the Save + export spec [1] for a while.
>Since it will affect the workflow for basically everyone it would be nice
>with getting some testing and comments before we finalize, merge and push
to
>GNOME master.

>  / Martin

Hi

My comments and observations:
1. When I try to save and I change extension to (for example) .png, GIMP
message appears:   
"You can use this dialog to save to the GIMP XCF format. Use File->Export to
export to other file formats." 
I think it'd be better:  
"You can use this dialog to save only to the GIMP XCF format. Use
File->Export to export to other file formats."

2. When I open image "foo.png", do some changes and close it, GIMP message
says:  
"Save the changes to image 'Untitled' before closing?
If you don't save the image, changes from the last minute will be lost."
 There are options:
 "Close without Saving", "Cancel", "Save As".

I think it'd be very useful to have option: "Export" and even "Export to
foo.png". Obviously in this case GIMP message should be different as well.

3. I have file "foo.png" in "bar" folder, I try to save image "foo" as
foo.png in that folder (I changed xcf to png manually) GIMP message appear: 
"A file named "foo.png" already exists.  Do you want to replace it?
The file already exists in "bar".  Replacing it will overwrite its
contents."
Options are: "Cancel" and "Replace". I choose  "Replace" and GIMP message
says: 
"You can use this dialog to save to the GIMP XCF format. Use File->Export to
export to other file formats."
I think the second message should appear straight after when I choose
"Replace" because first message suggests that I can save "foo.png" anyway,
which if not true. 

4. In Save Image dialog there's in bottom-right corner button, where you can
choose what you see: 
"all images", "all files", "gimp XCF Image"
Although "all images" is selected, you can see only xcf files.


Best Regards 

-- 
Michal Predotka (via www.gimpusers.com)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Save + export spec essentials

[M Gagnon]

> Show me one person outside GIMP developer community that thinks this
> > is a sane change.
Totally irrelevant comment, if you ask me; this is a patch on a 
development version. Not many
users will have tried it. Sure, there's the windows installer, but it 
remains a development version
and an early snapshot of an unfinished feature.

I am not part of the GIMP developer community, yet I like every bit of 
the spec I read.

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Liam R E Quin]

On Thu, 2009-05-07 at 17:08 +0200, Jernej Simončič wrote:
[...]
> Show me one person outside GIMP developer community that thinks this
> is a sane change.

I don't think many people think it's a sane change, but that's
not the right question.  The question is, will the resulting
interface be good?

People (including me) were very doubtful about the empty image
window, and whilst I'm not 100% happy, I'm 99% happy, and it
worked out much better than I had feared.  So I'm willing to
see what happens here.


If you want something different though, you'll need to do more
than say the proposed change is insane.  You'll need to supply a
new proposal that fits in with the vision of GIMP as an xcf editor,
or, persuade Peter and others to change the vision slightly.

Best,

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] Save + export spec essentials implemented

[Jernej Simončič]

On Thursday, May 7, 2009, 11:47:00, David Gowers wrote:

> Fortunately, those all sound more like (kneejerk) reactions than
> comments with any thought to them.

Show me one person outside GIMP developer community that thinks this
is a sane change.

-- 
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

There is no traffic until you start to back out of your driveway.
   -- First Law of Driving

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Martin Nordholts]

2009/5/7 

> If your request for comments is only on the
> implementation and you are not expecting comments on the export spec
> itself, I apologize for the following question:
>
> Shouldn't the "Save a copy..." menu item be eliminated since its
> functionality can be entirely attained by exporting to the GIMP native
> format?
>
>
I figured the best way to form an opinion on the spec is to try it out
"live" but you are of course free to have an opinion on the spec also
without having played around with an implementation of it.

Allowing to export to the GIMP native format would introduce ambiguity: "If
I export to .xcf, will my document be considered saved? Will the document
<-> URI association be updated?" And so on. Keeping Save a copy allows us to
avoid this ambiguity altogether.

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

Re: [Gimp-developer] Save + export spec essentials implemented

[Martin Nordholts]

2009/5/7 David Gowers <00a...@gmail.com>

> patch #0010 fails:


Did you pull from GNOME master before you applied the patches? I should have
said that the patches requires latest GNOME master. If you apply the patches
on top of commit 9c2aae1281d.. you should be fine.

This works REALLY well! I <3 it! It behaves much more comfortably than
> the old setup,


I like that you like it :)

I was confused by how 'export to foo.png' was only usable once the
> image became dirty (ie. I changed it ). If that is considered
> appropriate behaviour, then your ability to 'save' should also depend
> on the dirtiness of the image


Hmm this seems to work properly for me, I can 'Export to' repeatedly also
after having saved, it doesn't seem to depend on dirtiness. Maybe you
resolved some patch conflict in the wrong way? Could you try to reapply on
top of latest GNOME master? If you still have problems, what are the
step-by-steps?

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

Re: [Gimp-developer] Save + export spec essentials implemented

[David Gowers]

2009/5/7 Jernej Simončič :
> On Thursday, May 7, 2009, 0:24:12, Martin Nordholts wrote:
>
>> I have been working on implementing the Save + export spec [1] for a while.
>> Since it will affect the workflow for basically everyone it would be nice
>> with getting some testing and comments before we finalize
>
> I built a Windows installer with this yesterday, and the comments I
> got so far are:
> - i don't have to try a stupid idea to say that it's a stupid idea
> - That's bizarre...
> - eww so they going to do it after all?
> - why the hell did they do that
Fortunately, those all sound more like (kneejerk) reactions than
comments with any thought to them.
It's good to know what we might need to deal with, though :)

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

Re: [Gimp-developer] Save + export spec essentials implemented

[David Gowers]

On Thu, May 7, 2009 at 7:54 AM, Martin Nordholts  wrote:
> Hi
>
> I have been working on implementing the Save + export spec [1] for a while.
> Since it will affect the workflow for basically everyone it would be nice
> with getting some testing and comments before we finalize, merge and push to
> GNOME master. The patches are attached to the bug report
> http://bugzilla.gnome.org/show_bug.cgi?id=581655 . Quick-guide to apply and
> test:
>
>   cd ~/source/gimp
>   tar -zxvf save-plus-export-2009-05-06.tar.gz
>   git checkout -b save-plus-export-2009-05-06 master
>   git am save-plus-export-2009-05-06/*
>
> this will create and switch to a new branch based on top of your local
> master branch, and apply the patches to that branch. Then you build and
> install as usual.

This doesn't seem to work -- patch #0010 fails:

"
Applying app: Add an 'export' mode to the file save dialog
error: patch failed: app/dialogs/file-save-dialog.c:138
error: app/dialogs/file-save-dialog.c: patch does not apply
Patch failed at 0010.
"
The patch appears to be offset by about 10 lines.

I applied it manually, and then ran git-am --skip
Patch 0011 applied ok,
Patch 0012 had problems:
"Applying app: Improve save and export error messages
error: app/dialogs/file-save-dialog.c: does not match index
Patch failed at 0012."

Applied that manually,
Patches 013..017 applied OK.
018 says :
"Applying app: Remember last export URI for each image
error: app/dialogs/file-save-dialog.c: does not match index
error: patch failed: app/file/gimp-file.h:27
error: app/file/gimp-file.h: patch does not apply
Patch failed at 0018.
"
Done manually,
019 fails similarly, done manually,
same for 020, 021
022 applied ok.

It's possible that I didn't understand how to 'resolve' a problem (
now I think it is, apply the patch manually, 'git add' the relevant
files, and 'git am --resolved')

I'm now trying to build it..
Trying it out..

This works REALLY well! I <3 it! It behaves much more comfortably than
the old setup,
I anticipate no longer needing to awkwardly 'save copy' so frequently
simply to get a web-usable version of the image.

I like how, if I hit 'revert', it properly reverts to the source image
(eg 12.gif rather than the working document 12.xcf)

I was confused by how 'export to foo.png' was only usable once the
image became dirty (ie. I changed it ). If that is considered
appropriate behaviour, then your ability to 'save' should also depend
on the dirtiness of the image


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

Re: [Gimp-developer] Save + export spec essentials implemented

[saulgoode]

Quoting Martin Nordholts :

> I have been working on implementing the Save + export spec [1] for a while.
> :
> :
> Comments very much appreciated!

I haven't GITified my development yet and thus have not tried your  
implementation. If your request for comments is only on the  
implementation and you are not expecting comments on the export spec  
itself, I apologize for the following question:

Shouldn't the "Save a copy..." menu item be eliminated since its  
functionality can be entirely attained by exporting to the GIMP native  
format?


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

Re: [Gimp-developer] Save + export spec essentials implemented

[Jernej Simončič]

On Thursday, May 7, 2009, 0:24:12, Martin Nordholts wrote:

> I have been working on implementing the Save + export spec [1] for a while.
> Since it will affect the workflow for basically everyone it would be nice
> with getting some testing and comments before we finalize

I built a Windows installer with this yesterday, and the comments I
got so far are:
- i don't have to try a stupid idea to say that it's a stupid idea
- That's bizarre...
- eww so they going to do it after all?
- why the hell did they do that

-- 
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

Nature will tell you a direct lie if she can.
   -- Darwin's Observation

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

[Gimp-developer] Save + export spec essentials implemented

[Martin Nordholts]

Hi

I have been working on implementing the Save + export spec [1] for a while.
Since it will affect the workflow for basically everyone it would be nice
with getting some testing and comments before we finalize, merge and push to
GNOME master. The patches are attached to the bug report
http://bugzilla.gnome.org/show_bug.cgi?id=581655 . Quick-guide to apply and
test:

  cd ~/source/gimp
  tar -zxvf save-plus-export-2009-05-06.tar.gz
  git checkout -b save-plus-export-2009-05-06 master
  git am save-plus-export-2009-05-06/*

this will create and switch to a new branch based on top of your local
master branch, and apply the patches to that branch. Then you build and
install as usual.

The patches should cover more or less the entire spec, except

* A single, unified export dialog
 * Properly handling *.xcf.bz/gz2

Comments very much appreciated!

  / Martin



[1] http://gui.gimp.org/index.php/Save_%2B_export_specification
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] save + export...

[peter sikking]

On 9 Mar 2009, at 1:06, David Gowers gave gg a washing.

and then...

> Open, edit, export as XXX (where XXX is original file -- one of the
> actions described in the spec.), export settings could be taken from
> the info in the original file.

thanks for bringing that up.

looks like for something like png GIMP is already good at that.
if GIMP can gather all the details on non-lossy files, then it
should in the Export to abc.png case use those settings.

but we also know from a loong thread here that things are
not that trivial for lossy formats like jpeg. open a jpeg @ 50%
quality, edit and export back. at 50 or at default 85% ?

I could not tell you.

> I am concerned about whether this would require you to 'confirm close'
> since the image would not be saved as XCF.


yes, there is an unsaved xcf sitting in that main window.
and we cannot read users minds if they are doing this secondary use case
or a primary one...

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Alec Burgess]

gg (g...@catking.net) wrote (in part)  (on 2009-03-08 at 20:55):

 Sounds good. If exporting to original name with original options is
 readily accessible from a top level menu without having to retype the
 name that would be pretty good.

 > > I am concerned about whether this would require you to 'confirm
 close'
 > > since the image would not be saved as XCF.

 maybe if the xcf was never saved as such and the work was saved to
 it's
 original name, the in memory xcf data could be regarded as an
 expendable
 buffer rather than a document that needs to be saved.


Maybe a check-mark on the "beefed up" dialog being discussed:
[x] Close in-memory image after export?
and remember this setting for next/subsequent exports of other images 
until turned off?
(implicit in this would be a automatic [Yes] answer to the "Don't save" 
popup that would otherwise be shown for dirty images.


Perceived advantage is that it makes clear the primacy of the XCF in 
memory image vs whatever it was when originally imported.


No reason not to also support this if original import (or XCF opened 
image) is now being exported to a different format.


--
Regards ... Alec   (bura...@gmail & WinLiveMess - alec.m.burg...@skype)


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

Re: [Gimp-developer] save + export...

[gg]

David Gowers wrote:
> Hello,
> On Mon, Mar 9, 2009 at 10:09 AM, gg  wrote:
>> there is a problem with this new attitude. Why does GIMP try to impose
>> this " you will work with xcf or die" dictate?
> 
> Because it has always been an XCF editor, not an anything else editor.
> Being able to modify images loaded from PNG, JPEG etc is just because
> people have created loaders which effectively translate PNG ->
> in-memory XCF. Everything else, including PSD, is too
> underspecified/basic to handle GIMP images accurately.
> 
>> Sure xcf is a good format and has some useful features. However, if I
>> want to open (and I mean open, not "import") a png image make a couple
>> of simple mods and save it, GIMP is getting in my way and trying to
>> impose a one-size-fits-all way of working.
> That's because you cannot simply open a png, only import. And this has
> always been the case; what you object to is merely: making an idea
> that has been implicit in GIMP so far, explicit.
> 

IIRC, before (circa 2.2 ?) I could open a png/jpeg ... and save it, with 
the caveat of the flatten layers nag/warnings.

Yes, it seems that in making it explicit it is becoming more cumbersome. 
Implicit had some merits. I get the feeling that all this import/export 
business is in danger of making heavy weather of it.

>> Here I want to do some simple editing and save. I do not want to
>> "export" to a format which the file already had before I opened it,
>> neither be bugged about layers being flattened and compression ratios etc.
> I believe you are protesting your sudden realization of the inaccurate
> way you were thinking of things, here.
> 
>> All I require is open: edit: save , in original format with original
>> options.
> 
> Open, edit, export as XXX (where XXX is original file -- one of the
> actions described in the spec.), export settings could be taken from
> the info in the original file.

Sounds good. If exporting to original name with original options is 
readily accessible from a top level menu without having to retype the 
name that would be pretty good.

> I am concerned about whether this would require you to 'confirm close'
> since the image would not be saved as XCF.

maybe if the xcf was never saved as such and the work was saved to it's 
original name, the in memory xcf data could be regarded as an expendable 
buffer rather than a document that needs to be saved.

Thanks for your reply.

> 
> David
> 
> 

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

Re: [Gimp-developer] save + export...

[David Gowers]

Hello,
On Mon, Mar 9, 2009 at 10:09 AM, gg  wrote:
> there is a problem with this new attitude. Why does GIMP try to impose
> this " you will work with xcf or die" dictate?

Because it has always been an XCF editor, not an anything else editor.
Being able to modify images loaded from PNG, JPEG etc is just because
people have created loaders which effectively translate PNG ->
in-memory XCF. Everything else, including PSD, is too
underspecified/basic to handle GIMP images accurately.

>
> Sure xcf is a good format and has some useful features. However, if I
> want to open (and I mean open, not "import") a png image make a couple
> of simple mods and save it, GIMP is getting in my way and trying to
> impose a one-size-fits-all way of working.
That's because you cannot simply open a png, only import. And this has
always been the case; what you object to is merely: making an idea
that has been implicit in GIMP so far, explicit.

>
> Here I want to do some simple editing and save. I do not want to
> "export" to a format which the file already had before I opened it,
> neither be bugged about layers being flattened and compression ratios etc.
I believe you are protesting your sudden realization of the inaccurate
way you were thinking of things, here.

> All I require is open: edit: save , in original format with original
> options.

Open, edit, export as XXX (where XXX is original file -- one of the
actions described in the spec.), export settings could be taken from
the info in the original file.
I am concerned about whether this would require you to 'confirm close'
since the image would not be saved as XCF.

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

Re: [Gimp-developer] save + export...

[gg]

peter sikking wrote:
> Liam wrote:
> 
> I had a careful look at this:
> 
>> My own workflow for www.fromoldbooks.org tends to be,
>> 1. scan image with xsane plugin
>> 2. crop if needed
>> 3. save as "306-svens-ankles-raw.png
>> 4. either quit after doing several of these, or continue with one...
>> 5. use levels, curves, rotate, flatten, and save as
>>   e.g. 306-svens-ankles-cleaned.png
>> 6. spend up to an hour cleaning up the scanned image, under
>>   the same name
> 
> I guess you realised by now that with the new attitude GIMP prefers
> that you do all this in xcf, so we can fully support you. Then
> you can Export to something you consider archival/future proof.
> 

Hi,

there is a problem with this new attitude. Why does GIMP try to impose 
this " you will work with xcf or die" dictate?

Sure xcf is a good format and has some useful features. However, if I 
want to open (and I mean open, not "import") a png image make a couple 
of simple mods and save it, GIMP is getting in my way and trying to 
impose a one-size-fits-all way of working.

Here I want to do some simple editing and save. I do not want to 
"export" to a format which the file already had before I opened it, 
neither be bugged about layers being flattened and compression ratios etc.

All I require is open: edit: save , in original format with original 
options.

currently I have to jump through hoops and probably delete an extranious 
xcf that got created along the way because of a temporary save I did to 
preserve an edit.

This is uncomfortably close the MS approach of "we know best so you'd 
better fall into line."

Can't this be made less intrusive?

regards.




>> 7. make jpeg versions at various sizes, by
>>   7.1 save as 306-svens-ankles-1.jpg
>>   resize image smaller (e.g. to 75%)
>>   sharpen, curves etc if needed
>>   7.2 save as 306-svens-ankles-2.jpg
>>   undo the resize, sharpen, curves etc
>>   7.3 resize image smaller (e.g. to 56.25%)
>>   sharpen, curves, etc. if needed, and save again...
>> and so on, sometimes as many as 10 different sizes.
>>
>> So I don't want to have to re-enter the filename 10 times.
> 
> we are helping you by keeping the same filename filled in as
> default in the export. you remind me here that we can even help
> you for the first export by filling in the filename of the xcf.
> you also remind me that it is not specified what the default file
> type should be for export (it cannot be xcf...) it is easy to
> define it as ‘same as last time’ but what will be the very first
> default? some truly open format?
> 
>> It's important to me that I can see when I saved something in terms
>> of undo history / workflow.  I rely on the "*" a lot, from when I
>> last saved as PNG.  But, it would be even better if Save and Export
>> events appeared in the undo history (even though obviously "undo"
>> would have to skip over them, you can't undo a save with most file
>> systems!).
> 
> the "*" can only help you when saving, that is to xcf.
> 
> although Save and Export cannot be real undo list items
> (they are not targets or undoable), I can be convinced to
> annotate the undo history with the Save and Export moments.
> 
>  --ps
> 
>  founder + principal interaction architect
>  man + machine interface works
> 
>  http://mmiworks.net/blog : on interaction architecture
> 
> 
> 
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
> 
> 

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

Re: [Gimp-developer] save + export...

[peter sikking]

yahvuu wrote:

what an inspiring post.

> peter sikking schrieb:
>> I must also point out that this save + export change is also a
>> change in attitude for GIMP. it clearly supports that our high-end
>> users work in no-loss xcf all the time (if they want to store
>> results) and that also means avoiding doing things like merging,
>> flattening, applying masks, reducing colours. that is all part of
>> the export scenario.
>
> what about using the same mechanism for export as it
> is planned for managing the GEGL tree?
> I'm referring to http://gui.gimp.org/index.php/GEGL_analysed,
> especially your quote "ah, GEGL will solve that".

wow, that is ages ago I wrote or read that...

> That means for the user, all export functionality could be represented
> by a tiny GEGL tree/list which provides operations for flattening,
> color reduction, background creation, writing files and so on.
> This tree gets executed anytime the user exports her image.


what is interesting is your idea to use an operation chain to
automate the export. I say chain because for users this GEGl
graph stuff will be represented as a linear list. I say
automate because it has elements of script/macro creation in it.

one important thing to remember is that just getting GIMP to
export a png should not involve having to set up a macro.
that should just work in its improved dialog click-y way.

another thing we are seeing is that whenever there is a reduction
in fidelity (colour-bits or resolution) there is a need for users
to do optimisation (sharpening, corrective painting).

my rough plan for supporting that looks like overlaying the
image with a projection screen (lets not call it a layer)
that simulates the lowering of fidelity. then this projection
screen itself could contain several layers of optimisations
and corrections that users may want to take. the high fidelity
image data is still available for further development.

bonus:

that recent ars technica review had a really clarifying metaphor
for cymk for print workflows. along the lines of: the cymk file
is the LP pressing of the rgb master tape. seeing this cymk
conversion as a fidelity reducing (colour gamut) 1-way conversion,
it looks like the projection screen plan above could be the beginning
of a working cymk support solution.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Alchemie foto\grafiche]

> On Sat, 2009-03-07 at 18:27 +0100, peter sikking wrote:
> 
>  first, "Copy visible as new image" could easily turn
> out too smart,
>  but since the bottom Background layer prefers to be
> one without alpha,

The first basic  assumption is wrong...so maybe what build on that need 
reconsideration

A Alpha channel in the background layer do not create  problems or 
disadvantages of sort

A example if you open a png you get exactly that :
a image with a background layer that has a alpha channel ,that do not create 
any complication ,not when editing, not when saving

Problems come only in the contrary case.

Gimp now allow other layers to be without alpha channel, before that was 
possible only for the BG layer(not because BG layer is better without alpha,but 
because for the BG a a alpha layer is not strictly needed)

So now is easy have , without noticing , a layer on top without alpha channel

and that will react in a weird way to most layer mode,(when were implemented 
layer modes ,  layer(s) to merge were supposed to have alpha)

And obviously then also tools as eraser will also give unwanted results if the 
alpha is missed

I hope i didn't went too OT, my point is a alpha channel in the BG do not 
create problem ,neither slow the workflow.

but a NOT-BG layer without alpha that may well create problems ,will be better 
if layer with no alpha were more clearly "marked " then now


__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto 
spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] save + export...

[peter sikking]

Sven wrote:

> On Sat, 2009-03-07 at 16:03 +0100, peter sikking wrote:
>
>> no, squeezing these export options in the save dialog is not  
>> possible.
>
> I think there is a misunderstanding here.

OK, I looked to much at that attached mock-up.

> What people suggested is not
> to put the export options into the Save file-chooser but into the  
> dialog
> that the save plug-in shows. Not all save plug-ins do this, but for
> those that do it seems to make a lot of choice to integrate the export
> questions there.

it would certainly be an improvement to get these two
(or in general: all export interaction) together in one dialog
in an orderly way.

> The Save as GIF dialog for example would have a toggle
> to decide if the image should be merged or if an animation should be
> saved. That would also make the dialog somewhat simpler as we could  
> make
> all the animation-specific choices insensitive if the user decides to
> save the merged image.

I tried out how this works right now. integration into one
dialog would work like that.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Sun, 2009-03-08 at 11:15 +0100, Sven Neumann wrote:

> Not all save plug-ins do this, but for
> those that do it seems to make a lot of choice to integrate the export
> questions there.

That was supposed to read "... it seems to make a lot of sense ...".


Sven


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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Sat, 2009-03-07 at 16:03 +0100, peter sikking wrote:

> no, squeezing these export options in the save dialog is not possible.

I think there is a misunderstanding here. What people suggested is not
to put the export options into the Save file-chooser but into the dialog
that the save plug-in shows. Not all save plug-ins do this, but for
those that do it seems to make a lot of choice to integrate the export
questions there. The Save as GIF dialog for example would have a toggle
to decide if the image should be merged or if an animation should be
saved. That would also make the dialog somewhat simpler as we could make
all the animation-specific choices insensitive if the user decides to
save the merged image.

> that Ignore button has to go. what has to be supported is turning
> layers/channels/masks into documents, that then can be
> saved/exported.

OK

> I am still tending against a "never show this again" checkbox.
> even with a reset in the preferences.

OK. That makes it also a lot easier to implement.


Sven


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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Sat, 2009-03-07 at 18:27 +0100, peter sikking wrote:

> first, "Copy visible as new image" could easily turn out too smart,
> but since the bottom Background layer prefers to be one without alpha,
> I can see something like: when ‘visible’ has effectively universal
> full opacity, then omit alpha in the new image.
> 
> also the export step can wise up a bit and complain less when there
> is universal full opacity.

We just don't have a good way to figure this out currently. Copy Visible
makes a copy from the projection and the projection always has an alpha
channel. Perhaps we can make use of the tile-row-hints here. I'll
investigate a little if this is a possibility...


Sven


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

Re: [Gimp-developer] save + export...

[peter sikking]

Liam wrote:

I had a careful look at this:

> My own workflow for www.fromoldbooks.org tends to be,
> 1. scan image with xsane plugin
> 2. crop if needed
> 3. save as "306-svens-ankles-raw.png
> 4. either quit after doing several of these, or continue with one...
> 5. use levels, curves, rotate, flatten, and save as
>   e.g. 306-svens-ankles-cleaned.png
> 6. spend up to an hour cleaning up the scanned image, under
>   the same name

I guess you realised by now that with the new attitude GIMP prefers
that you do all this in xcf, so we can fully support you. Then
you can Export to something you consider archival/future proof.

> 7. make jpeg versions at various sizes, by
>   7.1 save as 306-svens-ankles-1.jpg
>   resize image smaller (e.g. to 75%)
>   sharpen, curves etc if needed
>   7.2 save as 306-svens-ankles-2.jpg
>   undo the resize, sharpen, curves etc
>   7.3 resize image smaller (e.g. to 56.25%)
>   sharpen, curves, etc. if needed, and save again...
> and so on, sometimes as many as 10 different sizes.
>
> So I don't want to have to re-enter the filename 10 times.

we are helping you by keeping the same filename filled in as
default in the export. you remind me here that we can even help
you for the first export by filling in the filename of the xcf.
you also remind me that it is not specified what the default file
type should be for export (it cannot be xcf...) it is easy to
define it as ‘same as last time’ but what will be the very first
default? some truly open format?

> It's important to me that I can see when I saved something in terms
> of undo history / workflow.  I rely on the "*" a lot, from when I
> last saved as PNG.  But, it would be even better if Save and Export
> events appeared in the undo history (even though obviously "undo"
> would have to skip over them, you can't undo a save with most file
> systems!).

the "*" can only help you when saving, that is to xcf.

although Save and Export cannot be real undo list items
(they are not targets or undoable), I can be convinced to
annotate the undo history with the Save and Export moments.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Chris Mohler]

I know this thread is already getting long, but I'd prefer to see
Export behave similar to:

1. Create a new, multilayer XCF
2. File->Export
3. Name it something.png, click Next
4. Set options, click Save

At no point do I want to be nagged about layers, masks, or anything
else.  If there were a small warning icon (with maybe a turn-down
triangle to display the actual warnings) on the bottom of the option
dialog in step 4, that would be nice - but not necessary.  I know PNG
does not support layers - I do not need the reminder every time.

5. Close the XCF file

At this point I should be prompted to save the XCF "master" file,
since I've only done an export and never saved the original.

I based this on PNG, but I'd like to see this workflow on all
non-natives.  GIF for instance should have the choice to save as
animation displayed on the GIF option dialog - not in the warning
dialog.  IMO, the warning dialog should die ;)

Just $0.02

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

Re: [Gimp-developer] save + export...

[peter sikking]

Sven wrote:

> PS: In your particular workflow, basically you are already doing the
>export conversion yourself. What's breaking your workflow is the
>fact that "Copy visible as new image" introduces an alpha channel.
>To improve your workflow we should have a look at that and try to
>figure out a way to avoid that.


first, "Copy visible as new image" could easily turn out too smart,
but since the bottom Background layer prefers to be one without alpha,
I can see something like: when ‘visible’ has effectively universal
full opacity, then omit alpha in the new image.

also the export step can wise up a bit and complain less when there
is universal full opacity.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[peter sikking]

Sven wrote:

> Let's have a look at the capabilities that the save plug-ins announce:

thanks for this overview, good for reference.

I saw yesterday how these questions get combined in one dialog.
that is a good thing.

now that with the new spec the Export part is explicit,
I want to make one change: all those questions that can turn
up in this dialog with only one possible answer: just omit them.
with a bit of luck there are no questions and no dialog.

> just a reminder that there are some bug reports about this topic that
> might be worth looking at:
>
> Bug 75328  – Add "skip this question" to export dialog boxes.
> Bug 75459  – Add persistent defaults for the Export dialog
> Bug 119545 – Merge Export features into the Save dialog
> Bug 164709 – Export dialog should not allow to ignore mandatory
>  export actions


to answer some of the big questions in there:

no, squeezing these export options in the save dialog is not possible.

that Ignore button has to go. what has to be supported is turning
layers/channels/masks into documents, that then can be
saved/exported.

I am still tending against a "never show this again" checkbox.
even with a reset in the preferences.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Liam R E Quin]

On Fri, 2009-03-06 at 17:40 +0100, Sven Neumann wrote:
[...]
> I am all for improving this situation. But so far no one has come up
> with a good idea how this could be done. We can't just guess what the
> user might want to do.

We could do better than today.  E.g. export to tiff should be probably
able to handle layers.

My own workflow for www.fromoldbooks.org tends to be,
1. scan image with xsane plugin
2. crop if needed
3. save as "306-svens-ankles-raw.png
4. either quit after doing several of these, or continue with one...
5. use levels, curves, rotate, flatten, and save as
   e.g. 306-svens-ankles-cleaned.png
6. spend up to an hour cleaning up the scanned image, under
   the same name
7. make jpeg versions at various sizes, by
   7.1 save as 306-svens-ankles-1.jpg
   resize image smaller (e.g. to 75%)
   sharpen, curves etc if needed
   7.2 save as 306-svens-ankles-2.jpg
   undo the resize, sharpen, curves etc
   7.3 resize image smaller (e.g. to 56.25%)
   sharpen, curves, etc. if needed, and save again...
and so on, sometimes as many as 10 different sizes.

So I don't want to have to re-enter the filename 10 times.

Why do I not work in .xcf?  Because it's not a published standard, and
most other programs can't handle it, e.g. to show me a thumbnail,
and even GIMP might one day not be able to open the old xcf files.
I do sometimes save as xcf in step 5, to save time, as saving in PNG
often takes several minutes.

It's important to me that I can see when I saved something in terms
of undo history / workflow.  I rely on the "*" a lot, from when I
last saved as PNG.  But, it would be even better if Save and Export
events appeared in the undo history (even though obviously "undo"
would have to skip over them, you can't undo a save with most file
systems!).  So, I want Export to make the star go away, if Save As
will no longer save as PNG.  Otherwise, GIMP sits there for several
minutes and I go off and do something else, and when I come back,
how do I know it did anything? I'll forget whether I saved the file
or not.

For anyone wondering -- I use gimp to rescale and make multiple versions
of engravings, and imagemagick in a script for photos, because
scanned engravings are so much harder to rescale and often need some
touchup.

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] save + export...

[yahvuu]

Hi,

peter sikking schrieb:
> I must also point out that this save + export change is also a
> change in attitude for GIMP. it clearly supports that our high-end
> users work in no-loss xcf all the time (if they want to store
> results) and that also means avoiding doing things like merging,
> flattening, applying masks, reducing colours. that is all part of
> the export scenario.

what about using the same mechanism for export as it
is planned for managing the GEGL tree?
I'm referring to http://gui.gimp.org/index.php/GEGL_analysed,
especially your quote "ah, GEGL will solve that".

That means for the user, all export functionality could be represented
by a tiny GEGL tree/list which provides operations for flattening,
color reduction, background creation, writing files and so on.
This tree gets executed anytime the user exports her image.

The first time the user exports something, he has to choose between
- automatic conversion, which follows the principle of least surprise and 
creates
  a default GEGL tree
- manual conversion, thereby building the list step by step. If the user forgets
  something, a dialog offers to create the missing steps, very similar to
  the current behaviour.

The cool thing is, all the complexity of image conversion is represented in
a fashion the user is already accustomed to.
And the user can easily customize the export process. I'm thinking here of a
photo workflow, where multiple versions of an image with different amounts of
resizing and sharpening have to be exported. Just add these steps to your 
'export tree/list'.

The items in the list should have a checkbox 'ask me every time'
(for adjusting jpeg compression etc.)

greetings,
peter


PS: Not shure if the export tree should be presented separately or
wether it can be merged with the main tree


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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

just a reminder that there are some bug reports about this topic that
might be worth looking at:

 Bug 75328  – Add "skip this question" to export dialog boxes.
 Bug 75459  – Add persistent defaults for the Export dialog
 Bug 119545 – Merge Export features into the Save dialog
 Bug 164709 – Export dialog should not allow to ignore mandatory
  export actions


And there's workflow analysis that Jimmac has done quite some time ago:

 http://primates.ximian.com/~glesage/wiki/doku.php?id=gimp:png_export


Sven


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

Re: [Gimp-developer] save + export...

[Jon Senior]

Apologies. I think I hit reply, not reply-all.

On Fri, 06 Mar 2009 17:40:36 +0100
Sven Neumann  wrote:
> Sure, we all just want the computer do do what we want, without being
> asked. But unfortunately mind-reading devices are not yet available. So
> the only thing we can do is to ask you if you want to flatten the image
> because you can't save it as a JPEG file as JPEG does not support
> transparency.

Granted. What I was trying to show was that I would prefer to have export 
manage everything (and simple tell me that I will lose data), than to be 
expected to modify the workflow in order to prepare images for export.

An example might be when gimp is ultimately capable of 16-bit editing. I will 
edit my photo in 16-bit to reduce the damage caused by applying curves etc, but 
I will still want to export to 8-bit jpgs. I might not want to resize so I just 
hit "export". You were saying that you view the warning when exporting as a 
reminder that you should have already done that work yourself. I view it as a 
reminder that the exported file format is a compromise. At the minute, this 
makes no difference to the end result, but it is a differing mindset which 
could come into conflict depending on the reworking of the menu items so I felt 
it worth mentioning.
 
> I am all for improving this situation. But so far no one has come up
> with a good idea how this could be done. We can't just guess what the
> user might want to do. If saving a multi-layered image as GIF, is she
> trying to save an animation or has she forgotten to merge the layers? If
> saving an image with transparency as a JPEG file, is that really the
> correct background color so that automatically flattening the image will
> give the desired result? IF saving an RGB image as GIF, does the user
> just don't care about the conversion to Indexed Colors or has she
> forgotten to do it?

I agree that it can't be 100% automatic and I wasn't suggesting that it should 
be. The point I was trying to make is better expressed above.

> PS: In your particular workflow, basically you are already doing the
> export conversion yourself. What's breaking your workflow is the
> fact that "Copy visible as new image" introduces an alpha channel.
> To improve your workflow we should have a look at that and try to
> figure out a way to avoid that.

Interesting. I gave that as the extreme example. Sometimes I just use "Save a 
copy" direct from the xcf image. It all depends on what I need the exported 
file for.

-- 
Jon Senior 

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

Re: [Gimp-developer] save + export...

[peter sikking]

Sven wrote:

> Alexia wrote:
>
>> Why would I convert it beforehand? Why would a user need to do a  
>> bunch
>> of actions that serve no purpose, are mostly 100% automatic and even
>> hinder when I want to follow the export action up with a native save?
>
> Because they are not 100% automatic. There is user choice involved. If
> there wasn't, we wouldn't have that dialog. The dialog basically tells
> you that you forgot to do one or more important steps in your export
> workflow. And it helps you to do them. It does so in the hope that  
> next
> time you will do them yourself.

let me take a nuanced position here:

I agree with Alexia that if there is no choice but only a warning
in an export dialog (looks like it for "Flatten Image" /
"Apply Layer Masks" / "Add Alpha Channel") then that can just be
done. after the spec is implement all exporting is explicit, no
longer sneaky like in 2.6.

I agree with Sven that when there is a choice the dialog(s) must
be shown. I even do not think there should be a ‘never show this again’
option on them (how to get them back when you really need it for that
one project?)

I must also point out that this save + export change is also a
change in attitude for GIMP. it clearly supports that our high-end
users work in no-loss xcf all the time (if they want to store
results) and that also means avoiding doing things like merging,
flattening, applying masks, reducing colours. that is all part of
the export scenario.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Fri, 2009-03-06 at 17:24 +0100, Jon Senior wrote:

> Just to present the opposing case.
> 
> My workflow is:
> 1) Open raw image via the ufraw plugin.
> 2) Retouch as necessary, saving as xcf file.
> 3) Copy visible as new image
> 4) Resize new image for print or web + sharpen as neccessary.
> 5) Save result to jpeg file.
> 
> I don't mind being warned that step 5 will result in a loss of data
> (although it'd be nice to be able to do the export silently). But I
> don't want to have to think about the processes required to export my
> image to a jpeg for publishing. I just want to do it and get back to
> editing my xcf file with its nice layers.

Sure, we all just want the computer do do what we want, without being
asked. But unfortunately mind-reading devices are not yet available. So
the only thing we can do is to ask you if you want to flatten the image
because you can't save it as a JPEG file as JPEG does not support
transparency.

I am all for improving this situation. But so far no one has come up
with a good idea how this could be done. We can't just guess what the
user might want to do. If saving a multi-layered image as GIF, is she
trying to save an animation or has she forgotten to merge the layers? If
saving an image with transparency as a JPEG file, is that really the
correct background color so that automatically flattening the image will
give the desired result? IF saving an RGB image as GIF, does the user
just don't care about the conversion to Indexed Colors or has she
forgotten to do it?


Sven

PS: In your particular workflow, basically you are already doing the
export conversion yourself. What's breaking your workflow is the
fact that "Copy visible as new image" introduces an alpha channel.
To improve your workflow we should have a look at that and try to
figure out a way to avoid that.


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

Re: [Gimp-developer] save + export...

[peter sikking]

saul goode wrote:

>> So here is a short spec:
>>
>> 
>
> If you are accepting feedback on the spec,

yep

> I should like to submit the following:
> Under the section "exporting files", the command names "Export...",
> "Save back", and "Save as template" are confusing. For the latter two,
> using the word "save" runs counter to one of the main purposes of this
> exercise -- that is to say, we don't want the user to think that
> exported data is "safe" so why would we use the word "save" when
> exporting.

I think you are bringing up some good points. I had already been
doubting between ‘Export back’ and ‘Save back’. up to now I felt
that the ‘Save back’ construct had the benefit of some familiarity.
but your arguments bite.

good also that you point out about ‘Save as template’ that does
not even go through a (save) file dialog. I think ‘Create template’
will solve the problem.

> "Save back" in particular is confusing. Not only does employment of
> the term "save" lead to expectations of data safety and behavior
> consistent with the other Save commands, but "back" is ambiguous and
> generates more questions than it answers (what is being saved, a
> back?, or if back is a place, where?, how far back?).

first of all I want to point out that the full text of the
menu item would be “Save back to ” when the item becomes
available. Example: “Save back to foo.jpg”

but now I will speed straight past the alternative
“Export back to foo.jpg” and optimise that to:

“Export to foo.jpg”

that looks clear. greyed out the item would read “Export to”

> Would it not be preferable to substitute "Export" for the spec's 'Save
> Back' command label, and to substitute "Export As..." for the spec's
> 'Export...' command. I don't see the reasoning behind the name
> juggling -- why deviate so dramatically from the logic underlying the
> naming of the "Save" and "Save As..." commands? Excepting for the
> name/status handling of the image, the correlation should be
> Save<=>Export and SaveAs...<=>ExportAs...

although tempting the equivalence does not hold. this is because
there is a strong, 2-way link between GIMP files and what you see in the
document window, and a weak, 1-way link between file exported to and
what you see in the document window.

> I also think that it must be possible to "export" to GIMP file types.
> This is necessary so that more than one version of GIMP data files can
> be supported.  (ie, GIMP 4.0 might still need to create GIMP 2.x
> compatible files). In fact, "Saving" should be limited to the latest
> preferred GIMP-native file format, while requiring that deprecated
> formats should be "Exported".

when the time comes it will work like that. but to be clear,
there will be no export to the latest preferred GIMP-native file
format, because it is not an export.

> It may also be useful if this "export" capability permitted the saving
> of single-layers, layermasks, channels, or eventually groups/branches
> of layers (under GEGL) to native GIMP formats. Such may not be, or
> ever become, useful but nonetheless I see little benefit to
> prohibiting exportation to native GIMP formats.

the challenge will be to elegantly save/export layers and masks
without ballooning the number of menu items/buttons involved,
or hurting the main priority of saving the whole document.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Fri, 2009-03-06 at 18:03 +0200, Alexia Death wrote:

> Why would I convert it beforehand? Why would a user need to do a bunch
> of actions that serve no purpose, are mostly 100% automatic and even
> hinder when I want to follow the export action up with a native save?

Because they are not 100% automatic. There is user choice involved. If
there wasn't, we wouldn't have that dialog. The dialog basically tells
you that you forgot to do one or more important steps in your export
workflow. And it helps you to do them. It does so in the hope that next
time you will do them yourself.

I do almost always convert my image to the final state before saving it
to a format such as JPEG or PNG. I can hardly remember how the Export
dialog looks like because I never get to see it.


Sven



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

Re: [Gimp-developer] save + export...

[Alexia Death]

On Fri, Mar 6, 2009 at 5:49 PM, Sven Neumann  wrote:

> Hi,
>
> On Fri, 2009-03-06 at 17:37 +0200, Alexia Death wrote:
>
> > And? If I save to a format it can be assumed that I know its
> > limitations. Being warned once about the information loss is good
> > enough.
>
> That is not what GIMP is doing. It tells you that it can't save to that
> format without modifying the image beforehand. And quite often it needs
> to ask you what to do because there are several possibilities.

But it does not modify the image I am working on, it converts the image into
a save result that I never see in gimp. Neither will I expect it to alter my
image If I initiate my action with export.


> If you knew about the limitations of the file format you are saving to,
> then you had converted the image beforehand and you wouldn't see the
> Export dialog at all.

Why would I convert it beforehand? Why would a user need to do a bunch of
actions that serve no purpose, are mostly 100% automatic and even hinder
when I want to follow the export action up with a native save?

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

Re: [Gimp-developer] save + export...

[Kevin Cozens]

yahvuu wrote:
> One minor suggestion, a simple renaming:
> Export...=>  Export as...
> Save back=>  Export
> 
> this way, 'Export' resembles 'Save' as a one-click-action
> and 'Export as...' parallels 'Save as'.

That sounds good to me. "Save back" would be something I've never seen in any 
other program to date. It doesn't give me any hints what it is doing other 
than it is supposedly some type of file(?) save operation.

-- 
Cheers!

Kevin.

http://www.ve3syb.ca/   |"What are we going to do today, Borg?"
Owner of Elecraft K2 #2172  |"Same thing we always do, Pinkutus:
 |  Try to assimilate the world!"
#include  |  -Pinkutus & the Borg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] save + export...

[yahvuu]

oops, just recognized i'm replicating a previous post, sorry

yahvuu schrieb:
> One minor suggestion, a simple renaming:
> Export...=>  Export as...
> Save back=>  Export

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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Fri, 2009-03-06 at 17:37 +0200, Alexia Death wrote:

> And? If I save to a format it can be assumed that I know its
> limitations. Being warned once about the information loss is good
> enough. 

That is not what GIMP is doing. It tells you that it can't save to that
format without modifying the image beforehand. And quite often it needs
to ask you what to do because there are several possibilities.

If you knew about the limitations of the file format you are saving to,
then you had converted the image beforehand and you wouldn't see the
Export dialog at all.


Sven


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

Re: [Gimp-developer] save + export...

[yahvuu]

great this gets tracked down.

One minor suggestion, a simple renaming:
Export...=>  Export as...
Save back=>  Export

this way, 'Export' resembles 'Save' as a one-click-action
and 'Export as...' parallels 'Save as'.

Additionally, the association between 'Save' and safe is kept consistent.
(Otherwise a user touching up a JPG might wonder why he is served a nag-screen
on closing the image - despite of having "saved back" before)


greetings,
peter


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

Re: [Gimp-developer] save + export...

[Alexia Death]

On Fri, Mar 6, 2009 at 3:53 PM, Sven Neumann  wrote:

> This results in a variety of possible dialogs:
>

And? If I save to a format it can be assumed that I know its limitations.
Being warned once about the information loss is good enough. Mind, gimp does
not even do that right now. Loss of vector layers and text data goes
unannounced. So how about doing it by letting the user per file type (once
if user so chooses), its capabilities. Export makes information loss
implicit anyway.


> And of course there are the various image mode conflicts that are
> handled by offering to convert to the mode that the plug-in supports:
>
>  "Convert to RGB"
>  "Convert to Grayscale"
>  "Convert to Indexed using default settings
>  (Do it manually to tune the result)"
>  "Convert to Indexed using bitmap default settings
>  (Do it manually to tune the result)"
>
> These can be combined as options if the destination format supports
> several modes.

Image mode conflicts are a separate problem IMHO.

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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Fri, 2009-03-06 at 14:17 +0100, peter sikking wrote:

> right. one thing I have no overview of is how many ‘topics’
> there are for which there are dialogs. Up to now I have seen
> layers, transparency, bit-depths.

Let's have a look at the capabilities that the save plug-ins announce:

typedef enum
{
  GIMP_EXPORT_CAN_HANDLE_RGB = 1 << 0,
  GIMP_EXPORT_CAN_HANDLE_GRAY= 1 << 1,
  GIMP_EXPORT_CAN_HANDLE_INDEXED = 1 << 2,
  GIMP_EXPORT_CAN_HANDLE_BITMAP  = 1 << 3,
  GIMP_EXPORT_CAN_HANDLE_ALPHA   = 1 << 4,
  GIMP_EXPORT_CAN_HANDLE_LAYERS  = 1 << 5,
  GIMP_EXPORT_CAN_HANDLE_LAYERS_AS_ANIMATION = 1 << 6,
  GIMP_EXPORT_CAN_HANDLE_LAYER_MASKS = 1 << 7,
  GIMP_EXPORT_NEEDS_ALPHA= 1 << 8
} GimpExportCapabilities;


This results in a variety of possible dialogs:

The image has more than one layer but the plug-in can't handle layers.
 -> "Flatten Image" or "Merge Visible Layers"
 (for plug-ins that need alpha channel, the "Flatten Image" option is
  omitted)
 (for plug-ins that can't handle an alpha channel, the "Merge" option
  is omitted)

The image has a single layer but that layer is of a different size than
the image, it is offset and/or it has an opacity != 100.
 -> "Merge Visible Layers"

The image has more than one layer and the plug-in can only handle this
if it treats those as frames of an animation.
 -> "Merge Visible Layers" or "Save as Animation"
 -> "Flatten Image" or "Save as Animation"
(for plug-ins that don't support transparency)

The image has a layer with an alpha channel but the plug-in can't handle
transparency.
 -> "Flatten Image"

The image has layer masks which the plug-in can't handle.
 -> "Apply Layer Masks"

The image has a layer without an alpha channel, but the plug-in relies
on one.
 -> "Add Alpha Channel"


And of course there are the various image mode conflicts that are
handled by offering to convert to the mode that the plug-in supports:

 "Convert to RGB"
 "Convert to Grayscale"
 "Convert to Indexed using default settings
  (Do it manually to tune the result)"
 "Convert to Indexed using bitmap default settings
  (Do it manually to tune the result)"

These can be combined as options if the destination format supports
several modes.


The gory details can be looked up in libgimp/gimpexport.c in the
function gimp_export_image().


Sven


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

Re: [Gimp-developer] save + export...

[peter sikking]

Sven wrote:

> Alexia wrote:
>> Does this mean that the annoying pop-up asking If I want to export
>> will go away if I choose export?
>
> The dialog does not really ask you if you want to export. It informs  
> you
> that the image can't be saved because the format you have chosen can  
> not
> handle some aspects of the image (transparency, multiple layers, ...).
> It also offers you one or more ways to deal with this situation.

right. one thing I have no overview of is how many ‘topics’
there are for which there are dialogs. Up to now I have seen
layers, transparency, bit-depths.

> As far as I can see the new spec does not really change this.

exactly.

> We should
> definitely try to straighten this dialog (as Peter already wrote).  
> Part
> of that is probably that the dialog remembers the last made choice  
> (per
> format or per image?) and perhaps it should even offer a choice to  
> skip
> it entirely when exporting this image to this format again. I will  
> have
> to think about how this fits into the current export functionality. As
> it is implemented on the plug-in side, it may turn out to be difficult
> to change it. But first it would be good for us to know how it should
> look and feel ideally.


looks like remembering as default per file type is the right thing.
the as-is situation of showing only once per time that the image is open
(should also be for export, I will add that to the spec) looks just  
about
right to me: both the source document and the export destination  
determine
what the right information reduction method is.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Fri, 2009-03-06 at 07:33 -0500,
saulgo...@flashingtwelve.brickfilms.com wrote:

> I also think that it must be possible to "export" to GIMP file types.  
> This is necessary so that more than one version of GIMP data files can  
> be supported.  (ie, GIMP 4.0 might still need to create GIMP 2.x  
> compatible files).

Can we please discuss that when a new file format has been introduced?
So far there is only XCF and we don't need to make this discussion more
complex than needed by talking about imaginary file formats that might
be added in the future.


Sven


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

Re: [Gimp-developer] save + export...

[Daniel Hornung]

On Friday 06 March 2009, Sven Neumann wrote:
> So we probably need to add specific actions to save a layer, a
> channel or a layer mask.

If that (plus to save all of a kind, e.g. all layers) could go into the 
generic save dialog, we would have another 10% questions less on irc :)

Daniel


signature.asc
Description: This is a digitally signed message part.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] save + export...

[saulgoode]

Quoting peter sikking :

> we have discussed this intensely before, the ambiguity of what you
> really
> got in your document window after opening--or saving to--a non-GIMP-type
> image (e.g. jpeg, png).
> :
> :
> So here is a short spec:
>
> 

If you are accepting feedback on the spec, I should like to submit the  
following:

Under the section "exporting files", the command names "Export...",  
"Save back", and "Save as template" are confusing. For the latter two,  
using the word "save" runs counter to one of the main purposes of this  
exercise -- that is to say, we don't want the user to think that  
exported data is "safe" so why would we use the word "save" when  
exporting.

"Save back" in particular is confusing. Not only does employment of  
the term "save" lead to expectations of data safety and behavior  
consistent with the other Save commands, but "back" is ambiguous and  
generates more questions than it answers (what is being saved, a  
back?, or if back is a place, where?, how far back?).

Would it not be preferable to substitute "Export" for the spec's 'Save  
Back' command label, and to substitute "Export As..." for the spec's  
'Export...' command. I don't see the reasoning behind the name  
juggling -- why deviate so dramatically from the logic underlying the  
naming of the "Save" and "Save As..." commands? Excepting for the  
name/status handling of the image, the correlation should be  
Save<=>Export and SaveAs...<=>ExportAs...

I also think that it must be possible to "export" to GIMP file types.  
This is necessary so that more than one version of GIMP data files can  
be supported.  (ie, GIMP 4.0 might still need to create GIMP 2.x  
compatible files). In fact, "Saving" should be limited to the latest  
preferred GIMP-native file format, while requiring that deprecated  
formats should be "Exported".

It may also be useful if this "export" capability permitted the saving  
of single-layers, layermasks, channels, or eventually groups/branches  
of layers (under GEGL) to native GIMP formats. Such may not be, or  
ever become, useful but nonetheless I see little benefit to  
prohibiting exportation to native GIMP formats.

Of course, exporting to GIMP-native should not alter the saved status  
or file name of the image. Not only does this maintain consistency  
with other export operations, but exporting to a deprecated GIMP  
format will likely mean a loss of image information.

There was much I liked about the specification, and feel it is  
especially important that GIMP users realize the potential of losing  
image data when using non-GIMP formats. This is a recurring problem  
for beginning users and while I don't think it is necessary to "dumb  
down" the GIMP interface for them, I do think that the terminology of  
the menu commands should be as consistent as possible.

Regards.

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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Fri, 2009-03-06 at 14:21 +0200, Alexander Rabtchevich wrote:
> The warning should survive in the case a user is trying to save the 
> image with a layer mask being selected, i.e. the layer mask is up to be 
> saved instead of the whole image. Of course, it can be the user's 
> choice, but anyway he should be warned.

In my opinion GIMP should never save only the current drawable unless
explicitely asked to do that. The user expects the whole image to be
saved. So we probably need to add specific actions to save a layer, a
channel or a layer mask.


Sven


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

Re: [Gimp-developer] save + export...

[Alexander Rabtchevich]

The warning should survive in the case a user is trying to save the 
image with a layer mask being selected, i.e. the layer mask is up to be 
saved instead of the whole image. Of course, it can be the user's 
choice, but anyway he should be warned.

Sven Neumann wrote:
> Hi,
>
> On Fri, 2009-03-06 at 11:50 +0200, Alexia Death wrote:
>
>> Does this mean that the annoying pop-up asking If I want to export
>> will go away if I choose export?
>>  
>
> The dialog does not really ask you if you want to export. It informs you
> that the image can't be saved because the format you have chosen can not
> handle some aspects of the image (transparency, multiple layers, ...).
> It also offers you one or more ways to deal with this situation.
>
> As far as I can see the new spec does not really change this. We should
> definitely try to straighten this dialog (as Peter already wrote). Part
> of that is probably that the dialog remembers the last made choice (per
> format or per image?) and perhaps it should even offer a choice to skip
> it entirely when exporting this image to this format again. I will have
> to think about how this fits into the current export functionality. As
> it is implemented on the plug-in side, it may turn out to be difficult
> to change it. But first it would be good for us to know how it should
> look and feel ideally.
>
>
> Sven
>
>
>
>

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

Re: [Gimp-developer] save + export...

[Sven Neumann]

Hi,

On Fri, 2009-03-06 at 11:50 +0200, Alexia Death wrote:
> Does this mean that the annoying pop-up asking If I want to export
> will go away if I choose export?

The dialog does not really ask you if you want to export. It informs you
that the image can't be saved because the format you have chosen can not
handle some aspects of the image (transparency, multiple layers, ...).
It also offers you one or more ways to deal with this situation.

As far as I can see the new spec does not really change this. We should
definitely try to straighten this dialog (as Peter already wrote). Part
of that is probably that the dialog remembers the last made choice (per
format or per image?) and perhaps it should even offer a choice to skip
it entirely when exporting this image to this format again. I will have
to think about how this fits into the current export functionality. As
it is implemented on the plug-in side, it may turn out to be difficult
to change it. But first it would be good for us to know how it should
look and feel ideally.


Sven


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

Re: [Gimp-developer] save + export...

[Alexia Death]

Does this mean that the annoying pop-up asking If I want to export will go
away if I choose export?
--Alexia
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] save + export...

[peter sikking]

Rob Antonishen wrote:

> Read this with intrest (as a user) what is the intrinsic difference
> between save a copy and save as?  I am assuming the working document
> changes in the save as case to the new saved as file. In the save a
> copy case I assume the working doment is unchanged.

yes it works like that in the current version.

> One suggestion in the revert...would it be possible introduce an timed
> auto backup feature (I have implemented one using a scheme script I
> invoke with a hot key, currently) and have the revert offer up any of
> the automatic backups as well as the open state as a revert option?


I think that needs its own little project. thinking through
reverting after a crash is not trivial.


Jon Senior wrote:

> As a user, I like it. I like the separation of saving native format  
> and "exporting" to non-native formats. Am I right in thinking that  
> "Save back" will only appear in the use case where a non-native file  
> is opened?

yes, that is the point where ‘Save back’ becomes available.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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

Re: [Gimp-developer] save + export...

[Jon Senior]

On Thu, 5 Mar 2009 23:36:52 +0100
peter sikking  wrote:

> Hi all,
> 
> we have discussed this intensely before, the ambiguity of what you  
> really
> got in your document window after opening--or saving to--a non-GIMP-type
> image (e.g. jpeg, png).
> 
> The discussion returned on the irc this Monday, and I realised then
> that some remaining nagging use cases could be solved elegantly,
> and that rationalising the whole situation does not look to be
> a tour de force.
> 
> So here is a short spec:
> 
> 

As a user, I like it. I like the separation of saving native format and 
"exporting" to non-native formats. Am I right in thinking that "Save back" will 
only appear in the use case where a non-native file is opened?

-- 
Jon Senior 

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

Re: [Gimp-developer] save + export...

[Rob Antonishen]

Read this with intrest (as a user) what is the intrinsic difference
between save a copy and save as?  I am assuming the working document
changes in the save as case to the new saved as file. In the save a
copy case I assume the working doment is unchanged.

One suggestion in the revert...would it be possible introduce an timed
auto backup feature (I have implemented one using a scheme script I
invoke with a hot key, currently) and have the revert offer up any of
the automatic backups as well as the open state as a revert option?

-Rob A>

On 3/5/09, peter sikking  wrote:
> Hi all,
>
> we have discussed this intensely before, the ambiguity of what you
> really
> got in your document window after opening--or saving to--a non-GIMP-type
> image (e.g. jpeg, png).
>
> The discussion returned on the irc this Monday, and I realised then
> that some remaining nagging use cases could be solved elegantly,
> and that rationalising the whole situation does not look to be
> a tour de force.
>
> So here is a short spec:
>
> 
>
> all we need is some keyboard shortcuts...
>
> ps: that was just a holiday from working on this:
>
> 
>
>  --ps
>
>  founder + principal interaction architect
>  man + machine interface works
>
>  http://mmiworks.net/blog : on interaction architecture
>
>
>
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>

-- 
Sent from my mobile device
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] save + export...

[peter sikking]

Hi all,

we have discussed this intensely before, the ambiguity of what you  
really
got in your document window after opening--or saving to--a non-GIMP-type
image (e.g. jpeg, png).

The discussion returned on the irc this Monday, and I realised then
that some remaining nagging use cases could be solved elegantly,
and that rationalising the whole situation does not look to be
a tour de force.

So here is a short spec:



all we need is some keyboard shortcuts...

ps: that was just a holiday from working on this:



 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



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