Liam wrote:
> Some nits ,some -- especially (2) and (4) -- bigger than others...
first thanks for writing this up
> (1) The file->export dialogue action button says save, not export
> (sounds really minor but given the save/export changes, can
> actually
> be confusing)
I see that Martin already repaired this. But the fact that this has
not been even specced thoroughly has to do with that we are not
following through the complete change down to the export dialogs.
> (2) The default save location should not be ~/Documents in the case
> that
> a file has been imported - it should default to the directory
> containing the imported image (see the spec)
yep bug (the complete precedence algo for Save (as), Export and Save
a copy needs verification).
> (3) in most programs, "save" mirrors "open", and "export" mirrors
> "import" - if GIMP is erally an XCF editor, "open" should work
> for .xcf and .xcf.gz files, and File->import should be there for
> the "rare" 99% case when you want e.g. to touch up a photo, and
> open a non-xcf file. So, please add file->import, with "import"
> as the label on the dialogue box. (I think?)
please hold the sarcasm on 99% import. yes: GIMP is by definition
more focussed on working with 'found images' then painting from scratch,
but I am sure that you can see the difference between keeping the
source code (.xcf) and keeping the executable (.png). since we can only
sanely promote working with source code (.xcf), we can assume that
when working on something in more than one session, you have to
open the source file each session. so that moves the percentage
in the direction of 50%.
Now, the spec says we fold open and import into one, and that is
because it _is_ more convenient, and there is no confusion price
to pay for it. for save + export, there _is_ a confusion price.
> (5) I'm not sure that the image title bar is up to spec at all times
> with respect to imported/exported. At any rate the little language
> for setting the image title in preferences probably needs to be
> expanded to include
> . the imported image name & (separately) folder
> . the last exported filename & (separately) folder
> . the (imported) / (exported) string
how much stuff do you want in a title bar? the title bar
actually shows the identity of what's in the window.
you know I have bent over backwards to take that identity already
from import or export actions before the file is ever saved, so
never-saving types like you can distinguish them in the taskbar.
the name of the exported to file is in your File menu.
> (6) There needs to be indication in the title bar (by
> default) of when an image has been exported/overwritten, not only
> immediately, but for the rest of the session, e.g. as
> *warmsock (*exported)
> warmsock (*exported)
> warmsock (exported)
> *warmsock (exported)
> depending on whether the image has been changed since last saved or
> exported respectively. Not doing this means that people will lose
> work.
I looked at *starring* the exported with interest, but the main
question is "has this state in my image window been exported or not?"
and have (exported) or not in the title is a much less subtle indicator
of that.
> There have already been requests to get rid of the "file has
> not been saved" message when you close the image, since in most (no
> all) workflows it's bogus, as the exported image is the final
> product. So, people get used to ignoring it even when they have
> not exported an image, and right now you can't esaily tell if you
> did or not.
please do not project your workflow on the general scheme of things.
you know the drill: source file, executable, best practice, safety
(losing work). I cannot allow the not-saved warning to be suppressed.
exactly for I-almost-never-save-xcf-files type of users, who need it
like hell when they do...
> (8) The curves and levels dialogues look really snazzy in full-screen
> mode, composited against the layer. Some problems with this
> (obviously incomplete) code...
> . no title on the doc, so may not always be obvious what it is
> . no way to drag the dock to a different part of the image
> . once docks are composited they stay that way, even after you
> leave full-screen mode. But they are not cmposited _before_ you
> go into full-screen mode, so I think it's a bug.
this is an experiment of Mitch. properly doing this starts with
taking contrast with any kind of image into account. this means
forgetting about theme-ing and executing everything in black-to-white
contrast. then all the handling you point out...
--ps
founder + principal interaction architect
man + machine interface works
http://mmiworks.net/blog : on interaction architecture
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
