Review Request: New action class proposal: KDualAction

[Aurélien Gâteau]

> On 2010-09-03 01:30:15, Christoph Feck wrote:
> > Some questions from my side:
> > 
> > * A tool button would need to make sure that the widest of the text labels is used as the size hint, so that the tool bar does not need to re-layout on state changes. Does your code allow that?
> > 
> > * Does it make sense to hard-code the limit to two states? What about maybe "KMultiAction", which also allows a third or fourth action if the programmer has a use case? Or allow something which uses QState? KStateAction?
> > 
> > * Do we need the "First" and "Second" enums? I would just use an "int" for the state. The programmer probably wants his own descriptive names, such as
> > 
> >     enum State {
> >         Stopped = 0,
> >         Playing = 1
> >     };
> > 
> > and I think numbers are just more readable here.
> > 
> > Other than that, an action which has "more" state than just "On/Off" would make a useful addition to kdeui.

> A tool button would need to make sure that the widest of the text labels is used as the size hint, so that the tool bar does not need to re-layout on state changes. Does your code allow that?

No. As far as I know there is no way for a QAction to influence the way it is rendered by widgets. Note that using KToggleAction + KToggleAction::setCheckedState() suffers from the same problem.

> Does it make sense to hard-code the limit to two states? What about maybe "KMultiAction", which also allows a third or fourth action if the programmer has a use case? Or allow something which uses QState? KStateAction?

I am a bit reluctant to go this way because I don't think it would be good for usability: having to click repeatedly on a button to reach the wanted state sounds painful, better use a combobox or a set of toggle buttons in this case.

I had a discussion with a developer of Rekonq (hi Lionel!) and he made me realize KDualAction should use real QAction instead of KGuiItem, reasons behind this was the ability to have separate shortcuts for each action, and ensuring that KDualAction can notice when one of the actions is triggered so that it updates itself (example: user press F5 in Rekonq, this triggers the "reload" action, the "reload/stop" KDualAction should change to show the "stop" action). Therefore I am going to rework the class this way. This should remove the need for enums. I may discard this request and reopen a new one if it takes too much time.


- Aurélien


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5237/#review7375
-----------------------------------------------------------


On 2010-09-02 22:17:33, Aurélien Gâteau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5237/
> -----------------------------------------------------------
> 
> (Updated 2010-09-02 22:17:33)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> This review-request introduces a new class named KDualAction. The goal of this class is to make it easy to create a dual-state action: an action which represents two actions, switching from one to the other whenever it is triggered. KDualAction can be used to implement actions such as the Play/Pause action of a media player or the Reload/Stop action of a web browser.
> 
> Right now some applications mis-use KToggleAction to implement such dual-state actions: They set the first action as the unchecked state and provide an alternative KGuiItem for the checked state with KToggleAction::setCheckedState(). This is wrong because when the user clicks a button representing the action in a toolbar, the button stays down.  The appropriate use cases for toggle buttons (and thus KToggleAction) are documented in a recent addition to the HIG:
> http://techbase.kde.org/Projects/Usability/HIG/Toggle_Buttons
> 
> Potential users for this class:
> 
> - Dragon, Juk, Amarok to implement their Play/Pause action.
> 
> - Rekonq to implement its Reload/Stop action. Konqueror could also use this but it does not feature a dual reload/stop action as far as I know.
> 
> - Dolphin could maybe use it to implement its Split/Close action (although it's a bit more involved in this case because the close action changes depending on which panel it is going to close)
> 
> - <insert-your-app-here>
> 
> I already have a patch to make Dragon use KDualAction (I used Dragon as a test application) and I plan to port other applications if the class is accepted in kdelibs (I also plan to fix some applications which mis-use KToggleAction so that they don't use setCheckedState() when it is not appropriate).
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdelibs/kdeui/actions/kdualaction_p.h PRE-CREATION 
>   trunk/KDE/kdelibs/kdeui/tests/CMakeLists.txt 1171068 
>   trunk/KDE/kdelibs/kdeui/tests/kdualactiontest.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kdeui/actions/kdualaction.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kdeui/CMakeLists.txt 1171068 
>   trunk/KDE/kdelibs/kdeui/actions/kdualaction.h PRE-CREATION 
> 
> Diff: http://svn.reviewboard.kde.org/r/5237/diff
> 
> 
> Testing
> -------
> 
> The class comes with unit-tests. I tested the API made sense while porting Dragon to it.
> 
> 
> Thanks,
> 
> Aurélien
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100904/c9acd25d/attachment.htm>