Why does KPushButton have a delayedMenu?

[Thomas Lübking]

Am 06.04.2012, 15:20 Uhr, schrieb Stephen Kelly <steveire at gmail.com>:

> Interesting. So should KPushButtons which wish to use the delayed popup
> stuff be changed to QToolButtons

Likely. At least bot examples should actually be toolbuttons - esp. since  
the konqueror button is -typically- in a, well, toolbar...

> or should we try to get the feature from QToolButton to QAbstractButton
QAbstractButton (source of QCheckBox and QRadioButton) has no menu - one  
could add a global behavior property there, but it would make less sense
(also i frankly wonder why QPushButton should have a menu at all - you  
likely wanted to use a combobox if you use it)

> Also, I'm a bit confused by the docs for this stuff:
>
>     /**
>      * Sets a delayed popup menu
>      * for consistency, since menu() isn't virtual
>      */
>      void setDelayedMenu(QMenu *delayed_menu);
>
>     /**
>      * returns a delayed popup menu
>      * since menu() isn't virtual
>      */
>      QMenu *delayedMenu();
>
> What does the delayed menu stuff have to do with menu() not being  
> virtual?
This looks weird - the -to me- natural approach would have been to use the  
present set/menu functions and re-implement the MBPress event *shrug*

>> Always thought QToolButton should be a "mode" of QPushButton instead of  
>> a separate class :)

> Maybe... I guess it would be possible in theory to get its features into

I guess you'd have to branch many QStyle calls - also focus chain and/or  
kbd input handling.

> QPushButton and deprecate QToolButton, but again, someone would have to
> justify and implement that.

I doubt it's really worth it, since both share most common code in  
QAbstractButton - it's more or less about the menu (which i -personally-  
would kick from QPushButton, since it's a clear trigger and not a  
selector, while QToolButton is some sort of menubar shortcut)

Cheers,
Thomas

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<