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 off-screen! (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. Cheers, -Rick- _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
