kactioncollection and associated widget

[Thomas Zander]

On Tuesday 20 November 2007 14:41:45 Hamish Rodda wrote:
> On Tue, 20 Nov 2007 10:57:07 pm Thomas Zander wrote:

> > The whole point of the actionCollection behaving like a dump collection
> > still holds, what I and I'm sure others meant with that is the point
> > that adding the action should not alter the context automatically.
> > The adding of the action to the parent widget still makes a lot of
> > sense to me, especially since that doesn't change the action and thus
> > doesn't break the concept of "just a collection".
>
> Well, I tried to fix the automatic addition when it was broken /
> partially removed, and I was told that it was too "magic" and violated
> the concept of a collection because it changed the actions (changed their
> shortcut context to WidgetShortcut)

You are mixing together two separate actions; one is the adding of the 
action to the widget that owns the actionCollection and the second is the 
automatically altering of the context.

People objected to the second point, why do you see them as being the same 
thing? (

> > Bottom line; right now the action collection no longer is usable as a
> > collection of actions *for*a*widget* and that means a lot of the
> > usecases for the collection no longer automatically work.
>
> It works every where else where it is used.

Did you follow the link to the bugreport I mentioned?  Its reported all over 
kde...
Here is the full link;
http://bugs.kde.org/show_bug.cgi?id=151421
take a look at the duplicates.

> BTW, the bug you refer to is not created by this change.  The bug is
> actually because it never worked with Qt 4 without adding all actions to
> the main window, and in fact you need to keep Qt::WindowShortcut, so you
> specifically _don't_ want associateWidget(). 

This is a misconception. The change in behavior you are referring to is that 
Qt3 used to have the action-context where all widgets and its children were 
getting the action and that now is a separate enum value added in Qt4.4.
The relevant bug id is;
http://trolltech.com/developer/task-tracker/index_html?id=141646&method=entry

So you were half correct, in 4.3 and earlier you require WindowShortcut or 
you need to add the action to all widgets. Both of which have their own set 
of problems.
The part where you are wrong is in saying that it can't work; it can. The 
proper way of working, both for simple windows and embedded parts, can be 
supported as soon as we depend on Qt4.4
In fact; I have it working in konsole compiled against qt4.4 just fine right 
now ;)

> I thought that actually it 
> shouldn't matter if it is not plugged into a shown widget if it is a
> _window_ shortcut, but Trolltech disagrees
> (http://trolltech.com/developer/task-tracker/index_html?id=106621&method=
>entry). I think the best fix is to change their mind, even if just for the
> specific case where a window level shortcut is plugged into a hidden menu
> bar.

The way a QAction works is that if its added to a widget using 
QWidget::addAction() the action-context is used. As set on the action.
In case a button, like a popup or a menu is created based on the action the 
shortcut is actually not routed through the action, the widget is the one 
that eats it.
The hiding (or disabling) of the button will then naturally stop the 
shortcut doing anything.  But this has little to do with the action.

The situation that you refer to above therefor doesn't actually occur. So 
such a fix would not help a lot. The reason for our current situation is 
because the action you added to the actionCollection is not actually added 
to any widget on screen by default anymore. So assuming there is a widget 
created by xmlgui that *also* happens to get the shortcut assigned from the 
action is a long stretch and doesn't cover nearly all cases.
Consider the cases where an action is not actually added in any menu or 
popup, for example (kmail has several of those, koffice has dozens).

So, I also disagree with your suggestion based on that it would not actually 
fix the problem anyway.
But the good thing is that I present you with a solution that works just 
fine for all usecases I know of :)

Summarizing;
* make a widget 'own' the actioncollection
* make all actions added to the actioncollection also be added to the 
widget.

Now; I'm pretty sure that a large part of the reason people wanted to make 
the actionCollection not set the context is because it broke things for 
them (as the default is WindowShortcut). So their keyboard shortcuts 
stopped working after the collection set them to the 
different-then-expected WidgetShortcut.
The solution you came with to not add any actions at all is worse; keyboard 
shortcuts stopped working for even more people.  The current code that sets 
it to Qt::WidgetWithChildrenShortcut, which solves all issues we have 
gotten reported.

I think we should revert to the kactioncollection behavior as it was in kde3 
(as described in the first mail on this thread).
For KDE 4.0 (or at least till distros recompile it against Qt4.4) the only 
choice we need to make is if we want possibly colliding shortcuts in 
kparts, or we want to stop actions that don't have a widget to work.
I'm personally inclined to go for the first as that surely hits a bigger 
group of people.
Best usecase; disable the menubar in konqueror and try to get it back 
afterwards using the standard shortcut 'Ctrl-M'.

-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071120/03125573/attachment.sig>