![](https://secure.gravatar.com/avatar/15f5e6abf26f57e1838c29a8356ce7f8.jpg?s=120&d=mm&r=g)
I've committed the first step in refactoring the toolbars. So far only the calligraphy toolbar has been updated.
Andy's given it an initial shakedown, and suggested turning it on by default. If anyone wants to turn it off, adding this under the "options" group in preferences should do the trick:
<group id="options"> ... <group id="stocktoolbars" value="0" />
Give it a spin and see how it works with the platforms, themese, etc.
![](https://secure.gravatar.com/avatar/bb65b6b3a109d97cf9f8d6c014ede042.jpg?s=120&d=mm&r=g)
Problems I see currently in the calligraphic toolbar:
- Alt+x does not activate the first widget of the toolbar (you need to assign to it "altx-calligraphy" string for that, as was done before, see desktop->setToolboxFocusTo)
- Left/right and up/down shortcuts in Calligraphic are broken (again, a matter of assigning proper strings to spinbuttons so they are accessible from the tool context)
- Esc in a spinbutton must undo any changes in it and return focus to the canvas; see the old code in spinbutton-events for how this is done
- Enter must set the new value and return focus to the canvas; see the old code in spinbutton-events for how this is done
- Tab must pass focus to the next field in the toolbar; instead it returns focus to the canvas
- there must be a space before the next spinbutton's label so they don't run into one another
- the size of the spinbuttons is bigger than before
- when some stuff does not fit, there's usually a big empty space before the end, which looks weird. Ideally, a partially visible widget should be shown there instead - that will give the user a much better idea of what's going on
- the "show me more" button needs an explanatory tooltip
- in the "show me more" menu, selecting a spinbutton item does nothing. At least the current value must be listed, but properly you need to allow editing it somehow.
![](https://secure.gravatar.com/avatar/15f5e6abf26f57e1838c29a8356ce7f8.jpg?s=120&d=mm&r=g)
Quoting bulia byak <buliabyak@...400...>:
Problems I see currently in the calligraphic toolbar:
- Alt+x does not ...
The key and focus handling needs to finish going in. After taking a while to digest the existing code, I think it will go in nicely with no external calls to refocus needed.
- there must be a space before the next spinbutton's label so they
don't run into one another
I'll need to tweak that in the composite widget creation. That's an expected item, and should not take too much. I just want to be sure I do it in a theme-compatible manner.
- the size of the spinbuttons is bigger than before
Yes. Before we release I'll definitely need to get that set. The prior code did not work in the context, so I think it might have something to do with widget realization order, etc.
- when some stuff does not fit, there's usually a big empty space
before the end, which looks weird. Ideally, a partially visible widget should be shown there instead - that will give the user a much better idea of what's going on
I'm not sure there's much we can do on this point. That's stock GTK+ behavior.
As a minor note, the toolbar and button look slightly better when they extend all the way to the right... but I'm not sure if there's a better place for the style preview.
As a side note, I need to add a user-visible preference to not override the stock Toolbar theme behavior. At the moment I had to add that extra call to prevent lables from appearing.
- the "show me more" button needs an explanatory tooltip
I agree about the benefit, but again that is stock GTK+ behavior. In this case I'm pretty sure there's not much we can do about it on our side... though it might be good to try to push upstream.
On the other hand, since it is standard GTK+ and GNOME behavior, at least in this case we can have a little more expectation of the user knowing what it is.
- in the "show me more" menu, selecting a spinbutton item does
nothing. At least the current value must be listed, but properly you need to allow editing it somehow.
Bingo! You found the biggest point that needs thought.
We do have control of what MenuItem gets created, so we might be able to get a sub-menu. I'll check on that.
Another option is to have it activate a dialog or panel to enter the value.
I'll see what options work out, as I think picking between these can be done by adding a property to a EgeAdjustmentAction or leaving it off.
participants (2)
-
unknown@example.com
-
bulia byak