Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[peter sikking]

Nicolas wrote:

> It also appears to me that a dedicated "export and close" shortcut
> pretty much kills this debate.

you are on a roll with brainstorming, aren’t you?

taking that a bit further, that would be ‘export + force close’
or ‘overwrite and force close’.

the combinations; the integration in the file menu; and
the edge case-ness all give me stomach ache. interaction
stomach ache.

but Force close,

that could be useful to a lot more people.

--ps

founder + principal interaction architect
man + machine interface works

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



___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[Jon Nordby]

On 17 June 2012 15:24, Robert Krawitz  wrote:
> On Sun, 17 Jun 2012 12:55:56 +0200, peter sikking wrote:
>>
>> I am going to summarise it because you are doing some
>> catching up in there that bloats the mail:
>>
>> - you recognise that there is a competing situation between
>> two different types of use
>
> There are more than two different types of use.
>
>> - you say there is a problem with File->Open importing non-GIMP images
>> - you have realised that xcf files are great for persisting work and
>> are acknowledging the Project reality of graphics work.
>
> Absolutely.  But sometimes the "project" is very simple, such that I'm
> very confident I'm not going to need to revisit it (or that I'm just
> going to tweak the curves or otherwise do something that doesn't need
> layers -- when GIMP has 16 or 32 bit depth, that might be a different
> matter, and if I think I might want to revisit it later, I'll simply
> save it as an XCF file).
>
> Certainly there are other tools around that are designed for simple
> things like that, but if I'm familiar with GIMP, it's easier to use the
> same tool for both.
>
>> here is my reaction to that:
>>
>> in short you want the old situation back, with the clear and
>> unambiguous working-on-a-GIMP-file workflows being secondary
>> to the one-shot png-in, png-out (same for jpeg, tiff, etc)
>> workflows. this is clear from how you label the menus.
>>
>> I have two reasons to say: no way.
>>
>> the first one is how GIMP works: it can only edit GIMP files.
>> sure, this is a superset of the simple file formats that we all like
>> to take as examples: jpeg/png/tiff. it is not for other ones
>> (ps to start with, there must be more import/export supported
>> formats that have things GIMP cannot do). the old fudge that
>> we got rid of in 2.8 is GIMP communicating that it is editing
>> a non-GIMP file, when it is not.
>
> How GIMP operates *internally* and what it presents to the user don't
> have to be one and the same.  Libre/OpenOffice use ODF as the native
> file format, but if I want to save it as a Word file, I simply Save As,
> or Save if what I originally opened was a Word file.  Internally,
> though, I believe it's operating on (a representation of) an ODF file.

You are right that there does not need to be a direct match between
the application internals and what is presented to the user. What is
important is that the user interface does not give any expectations
that the application cannot fulfill.

When LibreOffice allows you to save your work as a Word document, it
is making the user expect that the work (not just a subset of it) is
saved.
In the case of GIMP and "saving to" PNG/JPEG that is not an
expectation it can fulfill.

>> so you either import/export into GIMP format at the boundaries
>> of the GIMP app and be clear about it. this is what we do now.
>>
>> or you do your plan, build in non-GIMP-file-workflows, where for
>> each non-GIMP file type, you have to build a mode for GIMP where
>> what is on the screen matches what is in the file, right after
>> invoking Save. remember, this is the law.
>
> Why is that the "law"?  If I'm saving as a JPEG, I know that there will
> be loss.  But that's my lookout.
>
>> the second reason for saying no is checking the vision
>> and what it means:
>>
>> 
>>
>> this makes me 100% sure that the Project/Work workflow
>> with persisted GIMP files is number one for our target
>> user groups. one-shot working is a distant second.
>
> That's fine, but how does preventing "Save" to a JPEG file interfere
> with that?  Your target audience knows that a JPEG file will lose
> information.
The target audience knows that JPEG will lose information. But if one
is basing the interaction design on that foundation, the user will be
required to not only know this, but to always keep this information in
mind when interacting with the software.

Is this a burden we want to put on the user? Will he always make the
right decision? Is it responsible software engineering to assume so?

> What it does is require using a separate operation for
> exporting, which would seem to get in the way of "speed, speed, speed".
Triggering an "export" or "overwrite" action (once you have set up the
key binding) is just as fast as a "save action".

-- 
Jon Nordby - www.jonnor.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[Richard Allen]

>
> As a software developer, I see parallels within Integrated Development
> Environments. Gimp exporting to a lossly format is akin to building
> software. Gimp saving is akin to saving the project and source files back
> to disk. If my IDE ever let me save the compiled binary without updating
> the project/makefile(s)/sources or a big warning that it was going to do
> so, that would be bad.


> So I see this the same situation applied to Gimp.
>
> For people doing minor edits or simple rescaling (my use case), maybe it
> makes things a little more complicated. For someone who has put a week of
> work into a video game box cover, that would be terrible.
>
>
> One idea would be similar to IDEs - the XCF is the source, and
> JPEG/PNG/thumbnails are the output. The export button effectively becomes
> 'build' then and generates everything you've listed.
>

-Richard
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[Nicolas Robidoux]

It also appears to me that a dedicated "export and close" shortcut
pretty much kills this debate.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[Guillermo Espertino (Gez)]

I'm following the whole discussion and I'm more and more convinced that 
a default keyboard shortcut for overwrite would solve this.
People is basically complaining because they lost a handy way to save 
lossy formats back after simple editing.

Typical example: open a JPG file, adjust curves, save over.
I agree 100% with the separation between save and export because it kind 
of forces me to work in a more organized way and helps me avoid mistakes 
that costed me a lot of time before.
I understand that it takes some time to get used to that separation, but 
in my opinion is a minor compromise if we consider the benefits.
That being said, I also find annoying that in a fresh install I have to 
go to the menu in order to overwrite files. As Peter already pointed 
out, assigning a shortcut for that is easy and permanent, but I wonder 
how bad it would be to assign one by default, so users get used to that 
combination for that specific procedure instead of customizing it.

I think that it would have a couple of benefits:
- The old lossy workflow would be back (it never went away, but now it 
takes a couple of extra clicks). After learling the new shortcut, I'm 
sure it will feel as natural as CTRL+S.
- Consistency through different GIMP installs (if you have to use a 
friend's GIMP you don't have to worry about what shortcut s/he used for 
that command).


What about using CTRL+ALT+E for that?
I guess that using something recognizable as an alternative to CTRL+E 
would make it easy to memorize since it's one of the exporting variants.


I understand the reasons behind not having a default shortcut, but I'm 
not sure if it really prevents a problem. I'd say that having a shortcut 
would be a reasonable compromise to help the introduction of the new 
save/export workflow in a less painful way for people used to lossy 
workflows.


Gez.

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Gimp file open/save/export ideas.

[Brian Allen Vanderburg II]

I haven't had a chance to try the new 2.8 release of GIMP yet, or to
read the hundred or so messages about the changes in file open/save, so
I'm sorry if something I say here has already been covered.

I have read an idea that the GIMP format could be called the 'Work',
which makes sense to me.  My idea is that each context should have two
file names associated with it (pseudocode):

char* work_filename = NULL;
char* image_filename = NULL;

Then the menu items that seem to make the most sense to me would be:

Open File (Use "File" as it can be importing an image or opening a work.
This opens the file and sets either the work or image file name,
depending on if it was a .xcf or not.)

Import File (This is the same, but it does not set the work or image
file name.  This way, CTRL+S doesn't overwrite if it was undesired to
do so.  Essentially it opens a copy of the file.)

Save Work (This saves the .xcf file.  If the work file name is not
already set, then it will prompt for a file name and set the work file
name.)

Save Work As (Same except always prompt for a file name and set the work
file name to the new file name.)

Export Work (Prompt for file name and save the work without setting the
work file name.)

Save Image (This saves an image file.  If the image file name is not
already set, then it will prompt for a file name and set the image file
name.)

Save Image As (Same except always prompt for a file name and set the
image file name to the new file name.)

Export Image (Prompt for file name and save the image without setting
the image file name.)


Again I'm sorry if any ideas here have already been covered, and thanks
for such a great program.

Brian Allen Vanderburg II


signature.asc
Description: PGP signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[Robert Krawitz]

On Sun, 17 Jun 2012 12:55:56 +0200, peter sikking wrote:
>
> I am going to summarise it because you are doing some
> catching up in there that bloats the mail:
>
> - you recognise that there is a competing situation between
> two different types of use

There are more than two different types of use.

> - you say there is a problem with File->Open importing non-GIMP images
> - you have realised that xcf files are great for persisting work and
> are acknowledging the Project reality of graphics work.

Absolutely.  But sometimes the "project" is very simple, such that I'm
very confident I'm not going to need to revisit it (or that I'm just
going to tweak the curves or otherwise do something that doesn't need
layers -- when GIMP has 16 or 32 bit depth, that might be a different
matter, and if I think I might want to revisit it later, I'll simply
save it as an XCF file).

Certainly there are other tools around that are designed for simple
things like that, but if I'm familiar with GIMP, it's easier to use the
same tool for both.

> here is my reaction to that:
>
> in short you want the old situation back, with the clear and
> unambiguous working-on-a-GIMP-file workflows being secondary
> to the one-shot png-in, png-out (same for jpeg, tiff, etc)
> workflows. this is clear from how you label the menus.
>
> I have two reasons to say: no way.
>
> the first one is how GIMP works: it can only edit GIMP files.
> sure, this is a superset of the simple file formats that we all like
> to take as examples: jpeg/png/tiff. it is not for other ones
> (ps to start with, there must be more import/export supported
> formats that have things GIMP cannot do). the old fudge that
> we got rid of in 2.8 is GIMP communicating that it is editing
> a non-GIMP file, when it is not.

How GIMP operates *internally* and what it presents to the user don't
have to be one and the same.  Libre/OpenOffice use ODF as the native
file format, but if I want to save it as a Word file, I simply Save As,
or Save if what I originally opened was a Word file.  Internally,
though, I believe it's operating on (a representation of) an ODF file.

> so you either import/export into GIMP format at the boundaries
> of the GIMP app and be clear about it. this is what we do now.
>
> or you do your plan, build in non-GIMP-file-workflows, where for
> each non-GIMP file type, you have to build a mode for GIMP where
> what is on the screen matches what is in the file, right after
> invoking Save. remember, this is the law.

Why is that the "law"?  If I'm saving as a JPEG, I know that there will
be loss.  But that's my lookout.

> the second reason for saying no is checking the vision
> and what it means:
>
> 
>
> this makes me 100% sure that the Project/Work workflow
> with persisted GIMP files is number one for our target
> user groups. one-shot working is a distant second.

That's fine, but how does preventing "Save" to a JPEG file interfere
with that?  Your target audience knows that a JPEG file will lose
information.  What it does is require using a separate operation for
exporting, which would seem to get in the way of "speed, speed, speed".

> save + export has been designed for that, with added benefits
> of independently saving and exporting the same Work, and no more
> lost Work.

In 2.6, JPEG save already warns if the image has multiple layers.

> the success of this design is validated by the reaction of the
> target user groups, which ‘get it’ instantly, although I also
> changed _their_ keyboard shortcuts and put ‘unsaved changes’
> dialogs in their way.

-- 
Robert Krawitz 

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[peter sikking]

gg wrote:

> I was naively expecting it to be considered and possibly discussed. Not 
> refuted or ignored. Or attract insults.

ignored? what I did in return is spell out the basic facts
and usability considerations that put hard boundary conditions
on this design problem.

I expected you to be able to make the next step and adjust
your brainstorming idea to these conditions.

instead, you wanted to argue these away. either because you
don’t get it or because it does not suit your argument.

> So you seem to be saying this is not the place to discuss the way gimp UI is 
> being developed.

it is, but it has to be with respect towards those who can,
and do, the contributions. if you want to be heard, stop
the continuous flow of vitriol, especially towards anything
that has a design and/or architectural approach.

now, back to your mail of yesterday, the constructive one.

I am going to summarise it because you are doing some
catching up in there that bloats the mail:

- you recognise that there is a competing situation between
two different types of use
- you say there is a problem with File->Open importing non-GIMP images
- you have realised that xcf files are great for persisting work and
are acknowledging the Project reality of graphics work.
- you want to relabel: File->Open to File->Import, File->Save to
File->Save project
- you want a ‘new’ File->Save to to work in the old way: write to
GIMP file or export to non-GIMP file, depending on the type of file
associated with what is in the main window
- you want a new File->Open that explicitly says that this is a
non-GIMP file workflow

here is my reaction to that:

in short you want the old situation back, with the clear and
unambiguous working-on-a-GIMP-file workflows being secondary
to the one-shot png-in, png-out (same for jpeg, tiff, etc)
workflows. this is clear from how you label the menus.

I have two reasons to say: no way.

the first one is how GIMP works: it can only edit GIMP files.
sure, this is a superset of the simple file formats that we all like
to take as examples: jpeg/png/tiff. it is not for other ones
(ps to start with, there must be more import/export supported
formats that have things GIMP cannot do). the old fudge that
we got rid of in 2.8 is GIMP communicating that it is editing
a non-GIMP file, when it is not.

so you either import/export into GIMP format at the boundaries
of the GIMP app and be clear about it. this is what we do now.

or you do your plan, build in non-GIMP-file-workflows, where for
each non-GIMP file type, you have to build a mode for GIMP where
what is on the screen matches what is in the file, right after
invoking Save. remember, this is the law.

the second reason for saying no is checking the vision
and what it means:



this makes me 100% sure that the Project/Work workflow
with persisted GIMP files is number one for our target
user groups. one-shot working is a distant second.

save + export has been designed for that, with added benefits
of independently saving and exporting the same Work, and no more
lost Work.

the success of this design is validated by the reaction of the
target user groups, which ‘get it’ instantly, although I also
changed _their_ keyboard shortcuts and put ‘unsaved changes’
dialogs in their way.

--ps

founder + principal interaction architect
man + machine interface works

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



___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] present xcf as what it is, a gimp project file format

[Alexandre Prokoudine]

On Sun, Jun 17, 2012 at 6:04 AM, GSR - FR wrote:

> B. The keep lots of your work data, even when working also with
> limited formats, way: Save (XCF) and in parallel Save a Copy (PNG).
>
> At some point I thought that was the first steps to a better and
> automated system, some kind of multiple save (like B, but once set up,
> all the outputs would be updated automatically by a single save
> trigger). Instead with 2.8 we got manual export. :(

Now that is actually an interesting point :)

Alexandre Prokoudine
http://libregraphicsworld.org
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list