On Sun, Mar 16, 2008 at 8:31 AM, peter sikking wrote:

GIMPsters,

some good news on this front, I have spent a couple of man-days rethinking and re-specifying the 'no image' window situation. It is now roughly complete:

If wrinkles need to be ironed out, let me know.

I think some of the "gimmicks" could be useful (and remain professional):

# any splash-screen-like graphics or interaction, or GIMP contributor credits; A fairly small, horizontal graphic that is very similar to the initial start-up splash screen is not only more interesting, but also ties the window to the application. If for example the window becomes partially obscured while a user is opening their file manager to begin dragging a file, they can readily identify the portion that is still visible.

# any 'what would you like to do today' type of interaction, including 'recently open images';
I consider a list of recent images and a list of templates to be functional. As long as these can be configured easily or disabled I see no reason to rule it out completely. Something for "Paste as New" would be handy - any of these would cut down on the number of clicks/menus needed to perform the most common tasks.

The spec seems well thought out but I think that this window could do more for the user. Perhaps not right now, but I wouldn't rule those two out for all time.

My 0.02, Chris

Quoting peter sikking :

some good news on this front, I have spent a couple of man-days rethinking and re-specifying the ‘no image’ window situation. It is now roughly complete:

If wrinkles need to be ironed out, let me know.

The further fall-out of getting this done is menubar integration and getting the toolbox and inspectors off their main window status (no more dialogs in the taskbar). All to general users' relieve.

Regarding the "Overall Goals" section of the GUI specification:

1. get the menubar out of the toolbox; 2. keep the application instance alive by always having a window with a menubar open, even when no image is open.

I think the goal of making the Toolbox a utility window or dock should be addressed directly as an overall goal (THE overall goal?). That would seem the main point of this exercise. Removing the menubar from the Toolbox in and of itself would hardly seem worth all the discussion and effort that has gone into this.

With regard to the window closure behavior, I don't see the benefit in having the closing of the last image forcing a resize of its window. Once I have placed my windows into a desirable desktop arrangement, I really shouldn't want GIMP to automagically reconfigure things just because I don't have an image open.

Even upon opening a new no-image instance of GIMP, I am hoping that using the last size and location of the window from the previous session would be offered as a option (in Preferences), rather than having that dynamically chosen. (Presumably the size and location of the image window from which GIMP was quit in the previous session would have been saved.)

Thanks to the GUI team for their hard work on this project. It is appreciated and I do basically approve of the direction it is heading.

Hi,

On Mon, 2008-03-17 at 05:38 -0400, saulgoode@flashingtwelve.brickfilms.com wrote:

I think the goal of making the Toolbox a utility window or dock should be addressed directly as an overall goal (THE overall goal?). That would seem the main point of this exercise. Removing the menubar from the Toolbox in and of itself would hardly seem worth all the discussion and effort that has gone into this.

It is the goal. However, how well this will actually work with all the different window managers out there, remains to be seen.

With regard to the window closure behavior, I don't see the benefit in having the closing of the last image forcing a resize of its window. Once I have placed my windows into a desirable desktop arrangement, I really shouldn't want GIMP to automagically reconfigure things just because I don't have an image open.

I agree with that. IMO, the less resizing, the better. But perhaps this is something we need to try and refine later. Let's first implement what Peter suggested and see how well it works.

Even upon opening a new no-image instance of GIMP, I am hoping that using the last size and location of the window from the previous session would be offered as a option (in Preferences), rather than having that dynamically chosen. (Presumably the size and location of the image window from which GIMP was quit in the previous session would have been saved.)

Yes, I think I would also like such behavior.

Sven

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-

Rick Yorgason wrote:

Peter Sikking said:

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.

Since the spirit of the idea is that the last open window is simply reused, would you consider not resizing it?

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.

Hello

That a window is not actually closed after the user has clicked the "close window" button does not pose any techical problems at all. All sane window systems allow applications to make the final decision of wether or not to actually close the window. If this would not be the case it would be impossible to click Cancel on the customary question "You have unsaved changes in this document/image, do you want to save?".

From a usability point of view it is quite a brave approach however, but

I think it will work well. Only time will tell.

Note that GIMP trunk already now has a considerable amount of the spec implemented, so if you manage to compile GIMP from there you can already now try this out and get a pretty good feel for what the end result will be like.

BR,
Martin Nordholts

What we call the "no image" window doesn't really matter since that

On Wed, 2008-03-26 at 20:58 +0100, peter sikking wrote:

hey GIMPsters,

let me give you an update here.

in the last 10 days the concept and spec has matured quite a bit.

the feedback and plain old bug reports, both here and on the IRC went into what is being built right now.

check it out when you have the chance.

Where can one see the new spec?

To give my $0.02, I think Gimp should simply emulate what is out there, namely the behavior of established applications such as Open Office and gedit. there is really no reason to reinvent the wheel, this type of window has existed for a long time in other applications and users should be comfortable with it by now.

the No image window should have nothing at all in the empty area like gedit, or an empty frame like OO. As for grayed out menus, I'm all for following guidelines and the Gnome HIG says no. gedit and OO also don't gray out menus. Scribus does, though it's in the minority.

I also like the small "X" button just below the real close button in OO. it allows you to differentiate between closing a document and closing the application. It only appears when there is only one document open.

peter sikking wrote:

Michael Grosberg wrote:

On Wed, 2008-03-26 at 20:58 +0100, peter sikking wrote:

check it out when you have the chance.

Where can one see the new spec?

same old place:

but I actually meant check out the software...

To give my $0.02, I think Gimp should simply emulate what is out there,
namely the behavior of established applications such as Open Office and
gedit.

I am really struggling to say something nice here... ah:

The perfect family car was invented ages ago: the volkwagen beetle.

That did not stop designer from creating totally different cars for different needs. And customers from actually buying better cars.

Sorry for interruption...

Speaking of the cars... Designers made different types of cars, but they've never broken basic principles we all got used to.

Following your analogy: We have serious parking place issues. Currently GIMP takes four parking places by default.

I like this kind of interface GIMP uses. I agree that one window per image is great thing when you get used to it. My only objection is that registering four of them clutters taskbars. Just for the record, I know about TAB key and Keep on top settings. :)

Vlada

--ps

founder + principal interaction architect man + machine interface works

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

For the UI team...

I've been watching svn really close the last few days and I know that there are a lot of changes coming, (and I really don't know whats planned) but I'd thought I would throw out my thoughts so far...

* The "NIW" or main application window... o I found myself thinking "Great, now I have another window to find space for on my desktop... " + You can't close it or GIMP closes... + It really doesn't make a difference that I can resize it small... It still has to be on my desktop... o I will personally probably never use the niw drop zone... mainly because the toolbox is still a drop zone... o Working with it the last couple days, I've noticed when I open nautilus or thunar I really have to move windows in order to get to the NIW dropzone... in contrast the toolbox dropzone is usually at the side of a desktop layout - less movement, it's easier and quicker... + Even If I resize the NIW to half the screen and nautilus to the other half, I still have to resize the image once its open... which is a pain.. o What would really be nice and make the dropzone a lot more usable... if there is was a file browser built into it... split the niw vertically, put a file browser on one side, and dropzone and whatever else on the other side... + With this approach, you could at all times have the NIW maximized to the largest size possible... o Moving the toolbox menu is a good improvement, and I think there is talk to reorganize the menu items which would be good...
o Another close button when an image is open would be good too... o I'm not sure if the plan is to have tabbed images into this window... If not I bet there will be a million requests for it...
o Maybe add a double click feature to the dropzone to automatically create a new default image (without the prompts)

* The new "Wilber" dropzone area above the toolbox... o The entire toolbox widget is a dropzone in itself, why take up extra space ?
o When a user grabs an image to drag onto this toolbox area, they will naturally just head for the center of the toolbox... Chances are they probably wont specifically target that tiny area at the top... o Some Ideas...
+ Allow the user to remove it if they want + Allow the user to specify some other item in that space # Maybe a small color selector # RGB color input # Hex color input # Double click to create a new default image

* The main opinion I would like to throw out is to "give the end user as much control as possible"... Your right when you say that designers keep designing new cars, but the thing is people always want to customize the cars they buy... * For every component and widget in the interface ask yourself "How would a user like to customize this" * Some examples:

+ Come up with docking window framework that allows # Any docking window to be docked to another in any arrangement # Multiple levels of nested docks # Ability to assign shortcuts to each window + Menus
# Allow the user to create their own menus # Allow the user to dock a menu anywhere they would like... + Toolbar
# Allow the user to create their own toolbars # Allow them to dock toolbars anywhere

* Once a good customizable framework has been set up then do some studies, graphs, reports, wikis, and meetings to figure out the best standard default layout. And if the user wants to change it, he/she would have the capability... * People like to customize, and everybody has their own workflow style...

//Cinema 4D by Maxon - www.maxon.net - has an incredible interface framework... If you've never messed with it, download the demo and just mess with customizing the interface for a while... They have really taken the time to give the users ultimate control of their layout and workflow, yet at the same time provide a solid standard setup...

Finally, and most important - Thanks for all of your volunteer time... There have been some excellent improvements over the last few months with GIMP itself and the attitude in the community...

Your work really is appreciated by many people...

jbaker

On Thu, 2008-03-27 at 22:08 +0100, peter sikking wrote:

Michael Grosberg wrote:

On Wed, 2008-03-26 at 20:58 +0100, peter sikking wrote:

check it out when you have the chance.

Where can one see the new spec?

same old place:

but I actually meant check out the software...

Difficult since it's not being built daily as far as I know.

To give my $0.02, I think Gimp should simply emulate what is out there,
namely the behavior of established applications such as Open Office and
gedit.

I am really struggling to say something nice here... ah:

The perfect family car was invented ages ago: the volkwagen beetle.

That did not stop designer from creating totally different cars for different needs. And customers from actually buying better cars.

No reason to design a joystick-steered three wheeled car just to be different! Predictability of the UI is a very powerful tool and should not be dismissed. Applications don't work in a vacuum: they are used along with other applications, and asking users to "switch mental gears" when they switch from one app to another for no reason is not a good thing. The developers of those apps have struggled long with exactly the same problems Gimp is trying to solve and have come up with good solutions.

Case in point: in your specification you state that the application will quit if:
"Close in the File menu is invoked and the no image’ window is shown" While usually in such cases the close command is grayed out and only the quit command is available. What good reason do you have to change that?

The idea of a window with no document in it is already established. You yourself said "no gimmicks" and yet in the design there's a cute looking wilber in the window's background, which is nice but really, you think without it users won't know what this window is? give users some credit! it's a gimmick and by your own rules should be removed.

On Fri, Mar 28, 2008 at 5:27 PM, Michael Grosberg wrote:

To give my $0.02, I think Gimp should simply emulate what is out

> > there,
> > namely the behavior of established applications such as Open Office > > and
> > gedit.
>
> I am really struggling to say something nice here... ah: >
> The perfect family car was invented ages ago: the volkwagen beetle. >
> That did not stop designer from creating totally different cars for > different needs. And customers from actually buying better cars. >
No reason to design a joystick-steered three wheeled car just to be different! Predictability of the UI is a very powerful tool and should not be dismissed. Applications don't work in a vacuum: they are used along with other applications, and asking users to "switch mental gears" when they switch from one app to another for no reason is not a good thing. The developers of those apps have struggled long with exactly the same problems Gimp is trying to solve and have come up with good solutions.

Case in point: in your specification you state that the application will quit if:
"Close in the File menu is invoked and the no image' window is shown" While usually in such cases the close command is grayed out and only the quit command is available. What good reason do you have to change that?

I agree this is difficult. I believe the intent here is to make gimp more symmetrical, so you can close images, and then you close the final image (the no-image-window)

The idea of a window with no document in it is already established. You yourself said "no gimmicks" and yet in the design there's a cute looking wilber in the window's background, which is nice but really, you think without it users won't know what this window is? give users some credit! it's a gimmick and by your own rules should be removed.

I must disagree. It is not a gimmick, because without it, it is difficult to rapidly identify where to drop. If your window has a title bar (keep in mind that not all window manager's show a titlebar attached to the window -- eg the WM I use shows the title of the window that is currently focused only, at the top of the screen.), the icon that identifies it as a gimp window is small, and may be obscured by other windows. Since this window is a DnD target and the user may want to do multiple drops quickly, it must be identifiable to the user in the greatest number of situations. Standard icon+text titlebars do not provide this.

Hi Peter,

On Wed, 2008-03-26 at 20:58 +0100, peter sikking wrote:

check it out when you have the chance.

As you can see from the responses to your mail, there are quite a few trolls on this list who aren't even willing to try the new stuff. Otherwise we wouldn't have gotten so many responses that are obviously based on wrong assumptions and that clearly show that people have not followed your invitation to try the stuff in SVN.

I suggest that we keep working on it some more and try to make sure that it works well on all platforms. Then we will do a 2.5.0 development release and that should give us the feedback we need for further improvements.

Sven

The best way to fight trolls in this case may be to post a screen-shot of the current trunk on the Wiki.

Hi,

On Fri, 2008-03-28 at 08:40 +0000, Laxminarayan Kamath wrote:

The best way to fight trolls in this case may be to post a screen-shot of the current trunk on the Wiki.

A screenshot can't show all the changes and you actually need to use the software to find out how it feels. I may post some screenshots in my weblog soon, but I would like to finish the work on the GIMP Tips button first.

Sven

Von: Sven Neumann

On Wed, 2008-03-26 at 20:58 +0100, peter sikking wrote:

check it out when you have the chance.

As you can see from the responses to your mail, there are quite a few trolls on this list who aren't even willing to try the new stuff.

Do not confuse those who are vocal with the majority.

HTH, Michael

On Sun, Mar 16, 2008 at 2:31 PM, peter sikking wrote:

GIMPsters,

some good news on this front, I have spent a couple of man-days rethinking and re-specifying the 'no image' window situation. It is now roughly complete:

I've used Gimp-SVN yesterday to create an black/white image from an photo to test the NIW. First of all I have to say, that I like it. But there are some points that feels wrong. I don't know if this are Gimp or Windowmanager (Metacity) problems but I hope we can find good solutions.

Here is my list:
- The close button in the toolbox closes Gimp and not only the toolbox. The best thing would be to remove the close button compleate. If that is not possible it would be nice if it would only close the toolbox. But then we need a way to get the toolbox back. - If I minimise the last image it would be nice if the toolbox and the layer window would be hidden too. Or add an way to see the complet desktop to find images I've placed there. - Do something with the wilber in the toolbox, I don't know why but I don't like it there. Perhaps move it in the lower left corner or add an different background colour.
- It was a little bit annoying to have the layers dialog always on top. That was something I was a bit astonished about because I always wanted such a feature. It's that I like to see as much from the image as possible. To have the toolbox always on top was however very nice. - And I still don't know if I like it that I have to click twice on the image close button to quit Gimp. To discover this I need to use the new UI a little bit more.

Hi,

On Fri, 2008-03-28 at 11:34 +0100, Tobias Jakobs wrote:

- If I minimise the last image it would be nice if the toolbox and the layer window would be hidden too. Or add an way to see the complet desktop to find images I've placed there.

You can try the transient-docks feature in the Preferences dialog. It has issues, but it will cause the toolbox and dock windows to minimize with the active image window.

- Do something with the wilber in the toolbox, I don't know why but I don't like it there. Perhaps move it in the lower left corner or add an different background colour.

You will get used to it :)

- It was a little bit annoying to have the layers dialog always on top. That was something I was a bit astonished about because I always wanted such a feature. It's that I like to see as much from the image as possible. To have the toolbox always on top was however very nice.

We are playing with preference settings here. Nothing of this is set in stone and if we really want to keep the defaults as they are now (utility window hint set on the toolbox and dock windows), then we need to fix bug #362915.

Sven

jbaker wrote:

o What would really be nice and make the dropzone a lot more usable... if there is was a file browser built into it... split the niw vertically, put a file browser on one side, and dropzone and whatever else on the other side...

I don't understand why you would want to do that? If you need a file browser, use the File->Open menu.

Hi,

On Thu, 2008-03-27 at 20:02 -0500, jbaker wrote:

o What would really be nice and make the dropzone a lot more usable... if there is was a file browser built into it...

We are definitely not going to do that. File management is a rather complex task, very specific to the target platform and already nicely solved by other applications (these are called file managers). GIMP tries to integrate nicely with the file manager that the user prefers to work with. And that's it.

o I'm not sure if the plan is to have tabbed images into this window...

At a later point, perhaps. Definitely not for GIMP 2.6.

o Maybe add a double click feature to the dropzone to automatically create a new default image (without the prompts)

How often is the default image what you want? Almost never, I'd say.

Sven

Hi all,

On Sun, Mar 30, 2008 at 5:33 AM, Kevin Cozens wrote:

jbaker wrote:
> o What would really be nice and make the dropzone a lot more > usable... if there is was a file browser built into it... > split the niw vertically, put a file browser on one side, > and dropzone and whatever else on the other side...

I don't understand why you would want to do that? If you need a file browser, use the File->Open menu item

..
The 'Open' window can remain up as you DnD items from it to the toolbox. Rather important to know for this jbaker's use case, and I didn't find it obvious (the 'Open' button is obvious, and in fact deterred me from investigating DnD because it lead me to assume that that was the dialog's main functionality and it had no DnD. Does GIMP suggest to DnD in a tooltip? If it can, I think it should.)

Hi,

On Sun, 2008-03-30 at 09:27 +1030, David Gowers wrote:

The 'Open' window can remain up as you DnD items from it to the toolbox.

Yes, this works. And if you like it, then please continue to use the Open dialog in this way. But it is certainly not the recommended use. If you want to open multiple files, just select multiple files, then press the button labelled "Open".

Sven

Am Freitag, den 28.03.2008, 19:41 +0100 schrieb Sven Neumann:

Hi,

On Fri, 2008-03-28 at 11:34 +0100, Tobias Jakobs wrote:

- If I minimise the last image it would be nice if the toolbox and the layer window would be hidden too. Or add an way to see the complet desktop to find images I've placed there.

You can try the transient-docks feature in the Preferences dialog. It has issues, but it will cause the toolbox and dock windows to minimize with the active image window.

It only minimised the dock windows and not the toolbox. And it has really annoying issues when you are working with more then one image.

- Do something with the wilber in the toolbox, I don't know why but I don't like it there. Perhaps move it in the lower left corner or add an different background colour.

You will get used to it :)

I'll have no choice, there is no better image manipulating program for Linux. :)

Tobias

Hi,

On Sun, 2008-03-30 at 14:05 +0200, Tobias Jakobs wrote:

You can try the transient-docks feature in the Preferences dialog. It has issues, but it will cause the toolbox and dock windows to minimize with the active image window.

It only minimised the dock windows and not the toolbox.

Interesting, as the code handles the toolbox and the docks equivalently.

And it has
really annoying issues when you are working with more then one image.

Indeed. Which is why it is just an experimental option for now. And if no one fixes these issues, then it is going to be disabled in the next stable release (just like it is disabled in gimp-2.4).

Sven

On Sun, Mar 30, 2008 at 10:31 PM, Sven Neumann wrote:

Hi,

On Sun, 2008-03-30 at 09:27 +1030, David Gowers wrote:

> The 'Open' window can remain up as you DnD items from it to the > toolbox.

Yes, this works. And if you like it, then please continue to use the Open dialog in this way. But it is certainly not the recommended use. If you want to open multiple files, just select multiple files, then press the button labelled "Open".

I liked to do that, then it stopped working consistently, and sometimes it would open all the files, and sometimes only the last one I selected. Seems to be working okay now, it might have been a glitch in my GTK+ build.

In any case, my workflow typically involves projects with multiple related images that I need to check and adjust for consistency, which leads me to open and close small selections of files sporadically. I still recommend the method I mentioned, for such a workflow. If I could open multiple files *without* the Open dialog automatically closing, then I would unconditionally recommend your method.

Hi,

the Open dialog is a poor replacement for a file manager. If you only use it as a drag source, then why not just use your file manager instead?

Sven

On Sun, Mar 30, 2008 at 11:14 PM, Sven Neumann wrote:

Hi,

the Open dialog is a poor replacement for a file manager. If you only use it as a drag source, then why not just use your file manager instead?

...
My file manager is Midnight Commander :) I've just tried Rox-Filer, and it looks good, I'll try it.

People using mc should not worry about drag and drop. They should use "Menu(F9)>Commands>Edit extensions file" and friends and add gimp-remote as handler for extensions you want.

If I am not wrong that is the mail reason gimp-remote was developed. If I continue about MC, I am afraid it will be offtopic.

Hi,

On Sun, 2008-03-30 at 14:54 +0000, Laxminarayan Kamath wrote:

People using mc should not worry about drag and drop. They should use "Menu(F9)>Commands>Edit extensions file" and friends and add gimp-remote as handler for extensions you want.

With gimp-2.4, the use of gimp-remote is deprecated, at least on the Linux platform. You can just call gimp directly (provided that you are running a DBus session daemon, but that is the case on pretty much all Linux desktops nowadays).

Sven