[Qt-interest] Standard keys in menus

[Andre Somers]

KC Jones wrote:
> Thanks for the pointers.  It helps me better understand how
> actions and menus fit together.
>
>   
>>> Am I really supposed to code slots for each standard key I put in the menu?
>>>       
>> Yes. Usually thats easy though, as the delete-code is inside a slot in
>> the relevant widget. That means all you need to do is connect the action
>> to the right slot of the right widget.
>>     
>
> And keep changing that with disconnect()/connect() as focus
> moves?  Seems like a lot of unnecessary work.
>
>   
>>> And how am I supposed to implement correct menu enable/disable sensitivity?
>>>       
>> Listen to focus changes or enter/leave events and enable/disable the
>> actions.
>>     
>
> I had not thought about this approach.  But now that I take
> a closer look at QAction, I see that the way I thought it
> would work is not possible.
>
> What I *thought* I would do would be to subclass QAction and
> implement the isEnabled() method to examine the current
> widget (or clipboard contents, or...) to determine if the
> action was possible at the time the menu is posted.  This
> assumed that menus would call isEnabled prior to showing the
> menu, and that QAction::isEnabled() was virtual -- which it
> is not.
>
> I'm surprised by this.
>
>   
>>> Unless I'm missing something, I would suggest it would be very useful
>>> to provide static QAction instances for many of the statdard
>>> QKeySequences.
>>>       
>> Well, the problem is how should the slot be implemented by Qt in a
>> generic way? And how should the action decide which widget to connect
>> to, for example if you have multiple text edits. This is part of your
>> job as app developer - to put the widgets together and connect them to
>> create a meaningful application.
>>     
>
> If my approach of specialized QActions were possible, it
> would be pretty trivial to implement standard actions for
> some of the more important standard key sequences.
>
> But now that I see how these objects work, I see your point.
> _______________________________________________
The reason your approach is not possible, is that QActions do a lot more 
than just show up in menu's. They can be put on a toolbar and they 
handle shortcuts. How would polling isEnabled help in this case? Note 
that for menu's, your approach is perfectly possible and in many 
scenario's even standard practice. For instance, populating a recent 
documents list or an open documents list in a menu is usualy done at the 
moment the menu is shown. This works well, and there are good examples 
doing that. If you don't need your actions anywhere else than in menu, I 
suggest you take that approach.

On the other hand: how many actions are you talking about? How much work 
is it to write a small manager slot that updates the availablity of your 
actions and other UI elements according to the state of the application? 
I use this approach all the time, and I can tell you: not that much work 
at all. I simply create a single slot in for my dialog, and hook 
everything that may require a state change to this slot (focus changes, 
ticked checkboxes, you name it). In that slot I simply get the state, 
and enable/disable the actions appropriately. In case of actions that 
can work on multiple widgets, you have two options here: simply create 
one generic slot that dispatches the signal as needed, or in your 
updateUi() slot above disconnect & connect. In the near future (4.6), 
you may be able to leverage the state machine stuff in Qt to do this. 
That may be an interesting way out.

André