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 
utility windows.)

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

Reply via email to