Raphaël Quinet wrote:

There are some subtle differences that are internal and IMHO not important from the user's point of view:

if we look at the remaining differences (again, from the user's point of view, not from the code point of view), what is left?

- The toolbox has a menu bar. - The toolbox contains the buttons for switching tools.

- Drag & drop of URLs, image icons, etc. opens up the image.

That's the only one I can think of off the top of my head.

Cheers, Dave.

Hi,

Raphaël Quinet writes:

Following the discussion in bug #115092 and according to Sven's suggestion, I am moving a part of the discussion here: what is special about the GIMP toolbox, from a user's point of view? What makes it different from the other docks?

The toolbox is the first window that opens and the last that closes. It is even raised when the last image window is closed. It is treated special when you hit Tab. All this makes it the leader window of the GIMP application. It is a very special window and IMO there's no reason for this to change.

As I wrote in bug #115092, I don't think that any user would be surprised if we allowed the menu and the tool buttons to be dragged from the toolbox to any other dock. In fact, it would be nice to add this feature to a future release.

You can already add a tools list/grid to whatever dock you like.

Sven

Hi,

Raphaël Quinet writes:

You can already add a tools list/grid to whatever dock you like.

But this list or grid of tools does not behave like the one in the toolbox, unfortunately. The grid view does not behave as set of buttons (different background color, no highlighting on mouse-over) and it is not possible to drag & drop images (as mentioned in Dave's message). It would be nice to replace the main tools area in the toolbox by a grid view of the tools if these differences could be fixed. But then there would be even less reasons to treat the toolbox differently from all other docks.

Exactly and that's why the toolbox is special. It holds the tool buttons, it decides what tool is active, it has the most important menu and for that reason it also creates images when things are dropped there.

If the menu could also be removed or dragged to another dock, then the last difference between the toolbox and the other docks would go away. Or did I miss something important?

You missed the important fact that the menu cannot be removed and that we don't intent to change this. Face it, as it stands, the toolbox is special. I really don't understand why you are questioning this. It's a fact.

Sven

Hi,

Raphaël Quinet writes:

I am questioning this because I think that the fact that the toolbox is "special" is an artificial limitation that should go away in a future release in order to make the user interface more consistent and easier to use.

This discussion is about proper defaults for GIMP-2.0, not some future plans.

Let's imagine for a moment that the menu can be moved to any dock, and the tools area is just a grid view that can also be moved around. We may have to ensure that at least one menu is present in some dock, but this may not even be necessary if the functions can be accessed in some other way. If we achieve this, then the mental model of how the GIMP behaves becomes much simpler:
- There is one, two or any number of windows (docks) that can include various controls acting on the image windows. - All docks are session-managed top-level windows. Their size and position are kept accross sessions. - All docks are equal and can host any number of tabs, including the one containing the tools.
- The main menu is just another thing that can be included (or not) in a dock. If present, it would appear at the top of the dock.

Wouldn't this be easier to understand and work with? The user simply has a number of control windows in which several dockable items can be organized in any way they want. And none of them is more "special" than the others.

I seriously doubt that this would make it easier for the user. In my opinion it only adds an completely unneeded level of configurability and thus complexity. The GIMP should have a common window that everyone (and the docs) can refer to as "the toolbox". I don't see any good reason of changing this.

Sven

Raphaël Quinet (quinet@gamers.org) wrote:

On 24 Nov 2003 17:04:37 +0100, Sven Neumann wrote:

It is even raised when the last image window is closed. It is treated special when you hit Tab. All this makes it the leader window of the GIMP application.

But could you explain to a newbie _why_ this is like that? Is there a reason why only that window (which includes a dock) is raised when the last image window is closed and why this one is treated differently when you press Tab? Why don't we do the same thing for all docks?

Actually the "raising" action that Sven mentioned is a side-effect of the Tab-Feature. I'm pretty sure that you know about it, but it appears garbled in your description.

* The first in an image window hides the toolbox and the docks * The second lets the toolbox reappear * The third also lets the docks reappear.

Basically the Tab key cycles between Full blown GUI, Toolbox only, just image windows. And IMHO the possibility to have a reduced GUI (Toolbox only) seems useful to me.

Of course we have to make sure that a window of the Gimp is visible when the last image window gets closed. So we make sure that the toolbox gets _present()ed again [1], when the last open image gets closed.

So the Toolbox Window is different, because it is by definition the minimal GIMP GUI.

Hope this clears things up.

Bye, Simon

[1] There lurks an annoyance here: this step actually should be omitted when actually closing the GIMP. I sometimes have the effect that I shut down the Gimp (living in its own Viewport), switch to a different Viewport and want to do something different and *oops* Sawfish switches back (because the toolbox got _present()ed) and I have to watch the Shutdown process of the GIMP.

Hi,

as discussed in bug #115092, we have recently added some gimprc settings that allow to tune how GIMP interacts with the window manager.

Here's what the gimprc manpage says about the new settings:

(toolbox?window?type normal) The window type hint that is set on the toolbox. This may affect how your window manager decorates and handles the toolbox window. Possible values are normal and utility.
(dock?window?type utility)

The window type hint that is set on dock windows. This may affect the way your window manager decorates and handles dock windows. Possible values are normal and utility.

(activate?on?focus no)
When enabled, an image will become the active image when its image window receives the focus. This is useful for window managers using "click to focus". Possible values are yes and no.

The question I'd like to bring up is what should be the default values for these. After quite some discussions I now propose the following:

(toolbox?window?type normal) (dock?window?type normal)
(activate?on?focus yes)

This means that we wouldn't set the utility window type hint any longer (at least not by default). It was causing a lot of confusion and whoever liked the special treatment that some window managers give these windows can easily change this in the preferences dialog.

Switching to activate-on-focus as the default setting seems to make sense given that most desktops seem to be using "click-to-focus" by default these days. We used to set this to yes for Win32 only but I'd like to avoid different default settings if possible.

So, if you have a strong opinion against this change, please speak up now.

Sven

On Mon, Nov 24, 2003 at 07:25:01PM +0100, Raphaël Quinet wrote:

I am questioning this because I think that the fact that the toolbox is "special" is an artificial limitation that should go away in a future release in order to make the user interface more consistent and easier to use.

Artificial limitations give the application some shape. A place that a user can stand and from which they can survey the rest of the application. Otherwise why doesn't the context menu in your text editor have an option to download QuickTime movies over UUCP and play them in the toolbar?

Nick.

Hi,

Raphaël Quinet writes:

In most cases, a new user will have two GIMP windows that have more or less the same size: in the current docs, one of them is refered to as "the toolbox" and the other one is just a "dock". Both of them have roughly the same importance: they control what happens to the image, and it is possible to move (almost) all dockable items freely between these windows. Both of them are managed in (almost) the same way.

I don't agree. You are IMO simply putting it the wrong way. There's the toolbox that has the main menu and some other functions that are unique to the toolbox. Then there are docks. As a convenience, some of the dock functionality has been added to the toolbox. Note that the toolbox is not even a full-featured dock since it can't have an image menu. The toolbox is a special window and it is meant to be one. The fact that it can also swallow dockables is just a nice add-on, nothing more.

For what reason do we want to call one of them "the toolbox" and treat it in a special way in the code and in the docs? Why couldn't we call any of the top-level control GIMP windows "a toolbox" or "a dock", without having to care about how this window was created? If the list or grid of tools can be moved to any dock, wouldn't it be more appropriate to use the term "toolbox" for whatever window happens to contain the tool icons?

But why should we make the tool buttons detachable? It would only lead to confusion and wouldn't add any extra value.

So call me thick if you want (or just persistent), but I still do not see a good reason to have this artificial difference between the toolbox and the other docks. The argument from Simon about the "minimal GIMP GUI" seemed interesting at first, but on second thought it is not very good either: as the current toolbox window is also a dock containing several tabs, it is usually far from "minimal".

The default setup for the toolbox is just the tool buttons and the tool options docked to it. We allow the user to add more tabs here but it is certainly not what most people are using.

Sven

On Tue, Nov 25, 2003 at 01:33:15PM +0100, Sven Neumann wrote:

The question I'd like to bring up is what should be the default values for these. After quite some discussions I now propose the following:

(toolbox¡¾window¡¾type normal) (dock¡¾window¡¾type normal)
(activate¡¾on¡¾focus yes)

This means that we wouldn't set the utility window type hint any longer (at least not by default). It was causing a lot of confusion and whoever liked the special treatment that some window managers give these windows can easily change this in the preferences dialog.

Switching to activate-on-focus as the default setting seems to make sense given that most desktops seem to be using "click-to-focus" by default these days. We used to set this to yes for Win32 only but I'd like to avoid different default settings if possible.

Although I have a strong opinion against click-to-focus, it's probably the most widely used default and "expert users" are used to changing this setting anyway, so the default makes sense.

However, it would be great, if the window manager's focus policy could be determined and the default changed acccordingly (since activate-on-focus will complicate things with a point-to-focus policy)

Bye, Tino.

Hi,

Sven Neumann wrote:

The question I'd like to bring up is what should be the default values for these. After quite some discussions I now propose the following:

(toolbox??window??type normal) (dock??window??type normal)
(activate??on??focus yes)

I agree wholehearedly.

Cheers, Dave.

Hi,

tino.schwarze@informatik.tu-chemnitz.de (Tino Schwarze) writes:

However, it would be great, if the window manager's focus policy could be determined and the default changed acccordingly (since activate-on-focus will complicate things with a point-to-focus policy)

Sure, but as far as I know there is no well-established and portable way of getting this piece of information.

Sven

Sven Neumann (sven@gimp.org) wrote:

The question I'd like to bring up is what should be the default values for these. After quite some discussions I now propose the following:

[...]

(activate-on-focus yes)

[...]

Switching to activate-on-focus as the default setting seems to make sense given that most desktops seem to be using "click-to-focus" by default these days. We used to set this to yes for Win32 only but I'd like to avoid different default settings if possible.

So, if you have a strong opinion against this change, please speak up now.

I have a strong opinion on that, mainly because I put a lot of thought and discussion effort into the active-view idea when I proposed it.

It basically boils down to:

* (activate-on-focus yes) breaks in the focus-follows-mouse model, since the active view changes randomly when you just move your mouse across the Screen, containing multiple image views.

* (activate-on-focus no) works for both models,

While I agree that (activate-on-focus yes) works better for the click-to-focus model, we should avoid shipping a default with a broken behaviour on focus-follows-mouse models.

Bye, Simon

On Tuesday 25 November 2003 11:42, Tino Schwarze wrote:

Although I have a strong opinion against click-to-focus, it's probably the most widely used default and "expert users" are used to changing this setting anyway, so the default makes sense.

However, it would be great, if the window manager's focus policy could be determined and the default changed acccordingly (since activate-on-focus will complicate things with a point-to-focus policy)

I had an Horrible Experience (tm) regarding this yesterday.

I was making a title in Gimp 1.3.23, and was using 140pt font. Suddenly, by accident I flipped the mouse wheel over the "unit" listbox ..it changed from PT to IN .... hell came over on my desktop. before I could do much, the keyboard froze as the GIMP tried to allocate more memory than avaliable in the whole city - I managed to xkill the gimp, but the X server remained frozen. I had to remote login and kill the X process.

Since this the whole issue is not strictly related to activate on focus, but on memory consumption by the Text plugin, Sven, do you think it would be feasible to put a warning on the font-size selectors, just as there are when one tries to create an image too large?

Bye, Tino.

On Tue, 2003-11-25 at 15:50, Joao S. O. Bueno wrote:

I was making a title in Gimp 1.3.23, and was using 140pt font. Suddenly, by accident I flipped the mouse wheel over the "unit" listbox ..it changed from PT to IN .... hell came over on my desktop. before I could do much, the keyboard froze as the GIMP tried to allocate more memory than avaliable in the whole city - I managed to xkill the gimp, but the X server remained frozen. I had to remote login and kill the X process.

I believe this is a known issue:
http://bugzilla.gnome.org/show_bug.cgi?id=85103

./Brix

Hi,

"Joao S. O. Bueno" writes:

I had an Horrible Experience (tm) regarding this yesterday.

I was making a title in Gimp 1.3.23, and was using 140pt font. Suddenly, by accident I flipped the mouse wheel over the "unit" listbox ..it changed from PT to IN .... hell came over on my desktop. before I could do much, the keyboard froze as the GIMP tried to allocate more memory than avaliable in the whole city - I managed to xkill the gimp, but the X server remained frozen. I had to remote login and kill the X process.

Since this the whole issue is not strictly related to activate on focus, but on memory consumption by the Text plugin, Sven, do you think it would be feasible to put a warning on the font-size selectors, just as there are when one tries to create an image too large?

This is completely unrelated to the discussion, so please keep it out of it. There's a bug report about it already and it will be taken care of before 2.0.

Sven

Hi,

Henrik Brix Andersen writes:

On Tue, 2003-11-25 at 15:50, Joao S. O. Bueno wrote:

I was making a title in Gimp 1.3.23, and was using 140pt font. Suddenly, by accident I flipped the mouse wheel over the "unit" listbox ..it changed from PT to IN .... hell came over on my desktop. before I could do much, the keyboard froze as the GIMP tried to allocate more memory than avaliable in the whole city - I managed to xkill the gimp, but the X server remained frozen. I had to remote login and kill the X process.

I believe this is a known issue:
http://bugzilla.gnome.org/show_bug.cgi?id=85103

No, that is the wrong bug number. The related bug is #118356 as well as #122707. The bug you mentioned here doesn't affect GIMP-1.3 at all and I just changed the milestone accordingly.

Sven

I believe this is a known issue:
http://bugzilla.gnome.org/show_bug.cgi?id=85103

No, that is the wrong bug number. The related bug is #118356 as well as #122707. The bug you mentioned here doesn't affect GIMP-1.3 at all and I just changed the milestone accordingly.

Sven

However, you've read what I wrote. What I got was X freezing which seemed quite related to what is listed under 85103.

I am reading the ones you mentioned now: 118356 talks about the problem I faced, and asks, like I did, for a work around. But the deep cause seems to be 85103 nonetheless. I agree that 85103 is out of scope for Gimp at all, and resolving 118356 will do it.

122707 seems to be entirely unrelated to the crashing, and talks about a nice feature.

Hi,

"Joao S. O. Bueno" writes:

However, you've read what I wrote. What I got was X freezing which seemed quite related to what is listed under 85103.

Believe me, X11 didn't freeze. What you observed most probably was GIMp dying while it has the pointer grabbed. This looks like a frozen X server but it isn't.

122707 seems to be entirely unrelated to the crashing, and talks about a nice feature.

It is very much related since it will limit the amount of memory allocated to render text.

Sven

Hi,

Raphaël Quinet writes:

I was talking about the list or grid of tools (the "Tools" dockable), not the current tool buttons. Currently, we have two ways to display the tool icons: either as buttons (as shown in the current toolbox), or as a dockable list or grid of tools. Although the latter should be improved to have the same features as the current buttons (tooltips), it is more flexible because the user can customize how the icons are displayed. In order to reduce the amount of partially redundant code, we could get rid of the current toolbox replace it by the dockable grid of tools. Then we would call this the "toolbox" and it could be moved to any dock. That's what I tried to explain two messages earlier, in my reply to your first comments. Sorry if that was not clear enough.

Actually that list or grid of tools is only there because it was so trivial to add. It's nothing but a completly generic view on the container of GimpToolInfo objects. As it stands it isn't particulary useful. Perhaps it could be extended to become a toolbox editor where you can show/hide tool buttons in the toolbox or rearrange them or reconfigure the tool shortcuts. I don't think it should ever become a toolbox replacement. It was never designed to be that and it would be quite tricky to make it one.

Sven

hi, question:
On Mon, Nov 24, 2003 at 06:42:21PM +0100, Sven Neumann wrote:

Hi,

Rapha??l Quinet writes:

You can already add a tools list/grid to whatever dock you like.

But this list or grid of tools does not behave like the one in the toolbox, unfortunately. The grid view does not behave as set of buttons (different background color, no highlighting on mouse-over) and it is not possible to drag & drop images (as mentioned in Dave's message). It would be nice to replace the main tools area in the toolbox by a grid view of the tools if these differences could be fixed. But then there would be even less reasons to treat the toolbox differently from all other docks.

Exactly and that's why the toolbox is special. It holds the tool buttons, it decides what tool is active, it has the most important menu and for that reason it also creates images when things are dropped there.

If the menu could also be removed or dragged to another dock, then the last difference between the toolbox and the other docks would go away. Or did I miss something important?

You missed the important fact that the menu cannot be removed and that we don't intent to change this. Face it, as it stands, the toolbox is special. I really don't understand why you are questioning this. It's a fact.

What about the tools that only appear in the menus?

carol

Hi,

Carol Spears writes:

What about the tools that only appear in the menus?

They are tools but not in the toolbox, so what?

Actually the toolbox editor that I roughly outlined would allow you to decide for yourself which tools are in the toolbox and which can only be accessed thru the menus.

Sven

Well ...
On Wed, Nov 26, 2003 at 10:17:46AM +0100, Sven Neumann wrote:

Carol Spears writes:

What about the tools that only appear in the menus?

They are tools but not in the toolbox, so what?

Actually the toolbox editor that I roughly outlined would allow you to decide for yourself which tools are in the toolbox and which can only be accessed thru the menus.

it was such a thorough discussion of the tools and such, i was interested to see so much exchanged about them and the tools that are only found in menus not mentioned.

are there other instances of tools that do not appear in either the menus or in the toolbox?

carol

Hi,

Carol Spears writes:

are there other instances of tools that do not appear in either the menus or in the toolbox?

No. All tools register a menu entry at least. A few of them set a flag that indicates that they don't want to show up in the toolbox. We should probably make this configurable somehow; perhaps for 2.2.

Does that answer your question?

Sven

hiya, thanks for responding,
On Sat, Nov 29, 2003 at 12:54:12PM +0100, Sven Neumann wrote:

Carol Spears writes:

are there other instances of tools that do not appear in either the menus or in the toolbox?

No. All tools register a menu entry at least. A few of them set a flag that indicates that they don't want to show up in the toolbox. We should probably make this configurable somehow; perhaps for 2.2.

Does that answer your question?

having seen alts egg in gimp-1.2, i have no idea what might not show up in the gimp menus. i really thought that someone might 'fess (confess) to having a tool or plug-in included in gimp that does not use the usual registration protocol to get there.

i was sorry to see only one negative and late response here. i wish i had time to try all the different key combinations on all the buttons of all the widgets to see if what you say is true.

one thing i have learned, is that just because i try to do things the right way, it doesn't mean that others have done the same thing.

carol