QAction-related problems/needs

[Simon Hausmann]

On Wednesday 05 April 2006 01:14, David Faure wrote:
> I'm currently trying to implement KOffice's undo/redo action based on
> QAction (and in kdeui).
>
> That action was a KToolbarPopupAction - i.e. simple menuitem in a menu, but
> button with popup in a toolbar - but its particularity is that the popup
> doesn't contain usual text-based items, but instead one QListView
> (was a QListBox in qt3), so that the user can select multiple items in that
> listview, starting from the top. This is used to undo N steps at once. The
> popup also has a QLabel at the bottom to show "Undo N actions" while moving
> the mouse.
>
> So this brings me to the following question: how do I add a widget to a
> menu? This doesn't seem to be available; only actions can be added to a
> menu. Hmm. Looking at qmenu.cpp ... it's worse than I thought. There are no
> widgets at all used internally for every "item"; it's all done by qstyle
> painting based on the action's text and icon :( Probably more efficient,
> but very unflexible compared to Qt3's QPopupMenu.
> Thiago: I remember a similar request on kde-devel, do you know if a TT task
> ended up being created for that? Although now that I see the code I see how
> this will never happen...

We will support widgets in menus again. It wasn't possible on the Mac so far, 
but we found a way to implement it with >= 10.3, as they are now using 
HIViews for menus. API wise this will be handled the same way as custom 
widgets in toolbars through actions, using a dedicated QAction class, in Qt 
4.2.

> OK, maybe this means I shouldn't use a popupmenu, but rather create a
> widget for the popup (with the Qt::Popup flag) which contains my
> listview+label. However for this I need to write an action which pops up
> such a custom popup, i.e. not using QToolButton::setPopupMode nor
> QToolButton::setMenu, since that is QMenu based.
> This means redoing by hand the support for showing a delayed 'popup' from
> a toolbutton...
>
> Argl, is there really no better solution?
> What used to be doable with one qlistbox subclass in qt3 would now require
> - a kaction subclass
> - a qlistview subclass
> - a qabstractlistmodel subclass
> - a qtoolbutton subclass
> The first three seem logical, but the latter is killing me; lots of code
> duplication. Maybe QToolButton's support for a "popup" could be generalized
> so that the popup isn't necessarily a QMenu, but any QWidget? Looking at
> the code I see little that actually requires a menu... except for the
> exec() call, but I guess the QMenu::exec() code could be done directly in
> qtoolbutton to "exec" any widget...
> Does this make sense, or am I overlooking anything? I guess my next step
> is to talk to TT about this and see if they (or I) can generalize
> QToolButton's idea of popups...

Being able to specify a widget as a popup instead of just a menu is on the 
To-do list for QToolButton :)

Simon