Review Request: New action class proposal: KDualAction

[Christoph Feck]

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


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.

- Christoph


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/20100903/46b783d8/attachment.htm>