Why artificially constrain toolbox window size?
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| Why artificially constrain toolbox window size? | Martin Nordholts | 27 May 09:13 |
| Why artificially constrain toolbox window size? | Thorsten Wilms | 27 May 09:36 |
| Why artificially constrain toolbox window size? | Martin Nordholts | 27 May 18:47 |
| Why artificially constrain toolbox window size? | Michael Natterer | 27 May 18:48 |
| Why artificially constrain toolbox window size? | Christopher Curtis | 28 May 04:40 |
| Why artificially constrain toolbox window size? | Martin Nordholts | 28 May 08:18 |
| Why artificially constrain toolbox window size? | Michael Natterer | 28 May 16:07 |
Why artificially constrain toolbox window size?
Hi,
Right now, we put an artificial constraint on the toolbox dock window to make it resizeable only in tool button sized increments. If there is a dockable dialog present, the constraint is only on the width. If there are no dockables, the constraint is both on the width and the height.
The GtkToolPalette widget that hosts the buttons is able to nicely distribute available space among the buttons, so I would like to remove the resize constraint and make the toolbox dock window freely resizeable. The attached patch does that.
Are there any important use cases or interaction design aspects I'm not thinking about here?
/ Martin
Why artificially constrain toolbox window size?
On Thu, 2010-05-27 at 09:18 +0200, Martin Nordholts wrote:
The GtkToolPalette widget that hosts the buttons is able to nicely distribute available space among the buttons, so I would like to remove the resize constraint and make the toolbox dock window freely resizeable. The attached patch does that.
Do the buttons still flow/wrap then, or does this lead to a fixed n rows and m columns?
Are there any important use cases or interaction design aspects I'm not thinking about here?
I assume the icons force a minimum button size?
There *might* be some advantage to fix sized buttons regarding a training effect.
At some point the icons will looks strange, surrounded by too much empty space, but that's not really an issue as the user can keep it out of the silly range easily.
Why artificially constrain toolbox window size?
On 05/27/2010 09:36 AM, Thorsten Wilms wrote:
On Thu, 2010-05-27 at 09:18 +0200, Martin Nordholts wrote:
The GtkToolPalette widget that hosts the buttons is able to nicely distribute available space among the buttons, so I would like to remove the resize constraint and make the toolbox dock window freely resizeable. The attached patch does that.
Do the buttons still flow/wrap then, or does this lead to a fixed n rows and m columns?
The buttons still flow/wrap.
Are there any important use cases or interaction design aspects I'm not thinking about here?
I assume the icons force a minimum button size?
There *might* be some advantage to fix sized buttons regarding a training effect.
At some point the icons will looks strange, surrounded by too much empty space, but that's not really an issue as the user can keep it out of the silly range easily.
It looks slightly strange when you resize the window, because the buttons jump around more than usual. You do indeed get pretty severe button spacing for certain widths:
http://www.chromecode.com/temp/button-spacing.png
but I mean, so what? If a user panics, he can just make the window slightly bigger/smaller. Being able to adjust the window freely is far more important in my opinion.
/ Martin
Why artificially constrain toolbox window size?
On Thu, 2010-05-27 at 09:18 +0200, Martin Nordholts wrote:
Hi,
Right now, we put an artificial constraint on the toolbox dock window to make it resizeable only in tool button sized increments. If there is a dockable dialog present, the constraint is only on the width. If there are no dockables, the constraint is both on the width and the height.
The GtkToolPalette widget that hosts the buttons is able to nicely distribute available space among the buttons, so I would like to remove the resize constraint and make the toolbox dock window freely resizeable. The attached patch does that.
Are there any important use cases or interaction design aspects I'm not thinking about here?
Yes, the concern is that tool buttons *do* have a fixed size, and I really don't think we should scale them. The interface is IMHO better with the resize steps. There is no reason to have non-square buttons, because it doesn't exactly look good or professional.
--mitch
Why artificially constrain toolbox window size?
On Thu, May 27, 2010 at 12:48 PM, Michael Natterer wrote:
On Thu, 2010-05-27 at 09:18 +0200, Martin Nordholts wrote:
The GtkToolPalette widget that hosts the buttons is able to nicely distribute available space among the buttons, so I would like to remove the resize constraint and make the toolbox dock window freely resizeable. The attached patch does that.
Yes, the concern is that tool buttons *do* have a fixed size, and I really don't think we should scale them. The interface is IMHO better with the resize steps. There is no reason to have non-square buttons, because it doesn't exactly look good or professional.
By looking at the screenshot I don't think this is true; to the contrary, I like the look with more space around the buttons, and expect that I would find it easier to use because it's (a) a bigger target, but more importantly, (b) I find it a challenge sometimes to find a tool in the newer versions because many of them tend to blend together for me. I think more spacing like this makes them more distinct and easier to discern.
Chris
Why artificially constrain toolbox window size?
On 05/27/2010 06:48 PM, Michael Natterer wrote:
Yes, the concern is that tool buttons *do* have a fixed size, and I really don't think we should scale them. The interface is IMHO better with the resize steps. There is no reason to have non-square buttons, because it doesn't exactly look good or professional.
--mitch
I have to admit rectangular buttons doesn't look very pretty. So how about vertically centering the toolbox? Mockup, where left is "worst case" and the right one is "one pixel extra wide":
http://files.chromecode.com/temp/button-spacing-collected.png
We get the best of both worlds:
* Ability to pixel perfectly adapt the toolbox to any windowing setup and an interface with a smoother feel to it * Always square and nice-looking and compact tool buttons
We also get rid of the quite ugly flicker when inter-button spacing is adjusted as the toolbox window is resized. And again, if a user thinks the spacing around the toolbox is butt-ugly and can't stand it, he can just decrease the toolbox width.
/ Martin
Why artificially constrain toolbox window size?
On Fri, 2010-05-28 at 08:23 +0200, Martin Nordholts wrote:
On 05/27/2010 06:48 PM, Michael Natterer wrote:
Yes, the concern is that tool buttons *do* have a fixed size, and I really don't think we should scale them. The interface is IMHO better with the resize steps. There is no reason to have non-square buttons, because it doesn't exactly look good or professional.
--mitch
I have to admit rectangular buttons doesn't look very pretty. So how about vertically centering the toolbox? Mockup, where left is "worst case" and the right one is "one pixel extra wide":
http://files.chromecode.com/temp/button-spacing-collected.png
We get the best of both worlds:
* Ability to pixel perfectly adapt the toolbox to any windowing setup and an interface with a smoother feel to it * Always square and nice-looking and compact tool buttons
I'm sorry but I absolutely don't see how the minor benefit of resizing the toolbox freely outweights the advantage of *always* having a nicely laid out toolbox.
I'm all for code simplification and freely configurable windows, but this feels like overdoing it.
--mitch
