multiple actions in toolbars, take 2

one of the bits of feedback i got fro my last blog entry on kmultiactionbutton is that it might be possible to do this via the style itself. this would be preferred since it would mean every app could take advantage of it with less special code. the baghira style for kde3 does this, for instance, but it does so with some pain and some hacks. in fact, there is this cute comment in the sources at the relevant point:

this is crap at all - so if the best thing would be to patch qtoolbutton to provide conjuncted buttons - i'll ask them (maybe qt4)

dude, i feel your pain.

looking at qt4, we obviously don't have support for conjoined buttons. or ... do we? enter QActionGroup! according to the documentation:

In some situations it is useful to group actions together. For example, if you have a Left Align action, a Right Align action, a Justify action, and a Center action, only one of these actions should be active at any one time. One simple way of achieving this is to group the actions together in an action group.

exclusivity is optional in an actiongroup, and so this gives us what looks like a nice generic way to denote "these actions belong together". with a bit of trickery in the style, more reliable than what baghira was able to accomplish with qt3, we should be able to detect buttons on a toolbar that are next to each other and belong to the same action group.

the application code might look like:

QActionGroup* group = new QActionGroup(this);
new QAction(i18n("Some Action"), group);
new QAction(i18n("Another Action"), group);
toolbar->insertActions(group->actions());

sadly for the style code, the QStyleOptionToolButton class doesn't note which action group (if any) an action belongs to and so we'd need to do a bunch of casting and parent/child traversing. even if it did contain some info on the action pointer, it would only work for toolbuttons (as opposed to any/all widgets) and the style would still need to know what the previous and next button's groups are (meaning wandering the parent/child tree a bit). and yes, we'd probably only check widget.actions().first() but that's an ok limitation.

so, moral of the story is that perhaps we should start using QActionGroup, even when it's only used for semantic purposes. this might be something the liveui guys want to consider if they haven't as well since this ought to be part of our toolbar building technology (yes, i'm looking at you tronical and ervin ;)