Peter Sikking said:
> If wrinkles need to be ironed out, let me know.
Okay, here's my quick proof-read; I'll try to leave my opinions on
usability out of it and stick to the technical stuff:
> anything that is based on assumptions of ‘what users usually want to
> do next…’;
The drop zone is guilty of violating this ban. Instead of removing the
drop zone, how about we just lift the ban? ;)
> Close via the window manager (e.g. close box on the window frame,
> close on the taskbar) is invoked on an image window
Here, the spec states that the "close window" button may not actually
close the window, if it was the last open window. There was a little
bit of concern over this earlier in the list, both in terms of usability
and technical challenges, and I don't think it got sorted out.
It would probably be easiest if the "close window" button always closed
the window, regardless of whether that meant closing the image, or
quitting the app.
> The text shall be displayed either in black or in white, in both cases
> at 10% opacity. Which color is used depends on the UI theme: if the
> average brightness of the area under the text is less than 50%, white
> shall be used. In all other cases black shall be used.
The "average" part in particular sounds like it would probably be a
pretty big technical challenge. Instead of analyzing the background,
simply using the default font colour specified by the theme would
probably be safe, easier, and for most themes it would do exactly what
your spec defines anyway.
> And when we say ‘morphed’, we do mean that some animated growing or
> shrinking (where possible) would have real usability benefits, bringing
> a continuity in this transition situation. Pretty please.
I'm not sure if this is part of The Gimp's district. There may well be
some usability benefits to helping the user know when a window is
programmatically being resized, but you should probably be trying to
convince the writers of window managers to implement that feature.
If they *did* try to implement this feature in The Gimp instead of in
the window manager, there's a very real possibility that it would run
too slowly or be too clunky in some environments.
> Also the position of the window shall not be changed by GIMP, to keep
> the menubar in exactly the same place (if the window manager moves the
> window, caused by the resize, then tough luck).
Well, you say tough luck, but this might not be as uncommon as you
think. If, for instance, the user-override size is maximized (or
nearly-so) and the images aren't, this would *always* happen.
Also, consider a system with two monitors. The system I'm on right now,
for instance, has a primary monitor at 1680x1050 and a secondary monitor
at 1280x1024. Now, if I size the no-image window to fill my primary
monitor, then size my last image to fill my secondary monitor, the
no-image window would be resized to a ridiculous size that's mostly
(You might think the "maximum effort" section would usually solve this,
since if I want the window to fill my monitor, I'd probably use the
maximize button. That's not actually the case; I rarely use the
maximize button in The Gimp, because I need to leave space for the
Since the spirit of the idea is that the last open window is simply
reused, would you consider not resizing it?
One last thing, the term "'no image' window" is a little obtuse. Since
most users will recognize this as a welcome screen (even though it
doesn't explicitly say "welcome") why don't we start calling it that?
Those are the only things that jumped out at me. I don't really agree
with all of the usability decisions, but it's not a bad starting point,
and I definitely can't wait to see it implemented if it fixes the
problem of utility windows not acting like utility windows.
Gimp-developer mailing list