RFC: An action class to ease implementation of show/hide-like actions

[Aurélien Gâteau]

On 19/09/2010 16:47, Ingo Klöcker wrote:
> On Sunday 19 September 2010, Aurélien Gâteau wrote:
>> On 18/09/2010 12:33, Ingo Klöcker wrote:
>>> On Saturday 18 September 2010, Aurélien Gâteau wrote:
>>>> On 18/09/2010 00:06, Ingo Klöcker wrote:
>>>>> On Friday 17 September 2010, Aurélien Gâteau wrote:
>>>> I created this constructor to make it as easy as possible to
>>>> replace a KToggleAction with a KDualAction. Since KToggleAction
>>>> has a constructor which takes the offActionText, I created one as
>>>> well. Maybe it should be changed to KDualAction(offText, onText,
>>>> parent). What do you think of this?
>>>
>>> Makes more sense since a dual action will probably always have two
>>> different texts. (Otherwise, one wouldn't use it.)
>>
>> Indeed.
>>
>>> I'd revert the two texts, but that's probably just me.
>>
>> What do you mean?
> 
> I meant change their order, i.e.
>   KDualAction( activeText, inactiveText, parent )

Oh I see. If we take my sidebar example, then if the API is inactive,
active the call looks like this:

  new KDualAction(i18n("Show Sidebar"), i18n("Hide Sidebar"), parent)

It feels more natural to me than:

  new KDualAction(i18n("Hide Sidebar"), i18n("Show Sidebar"), parent)

>> Would you prefer Matthew solution (two different signals?)
> 
> I'm not sure whether it's worth adding two different signals. But I'd 
> prefer Matthew's solution over a silentSetActive() method because it 
> let's the listener decide whether he is interested in changes triggered 
> by the user only or in all changes.

OK. I just gave it a try with Konqueror and it works fine. Still it felt
a bit odd because at connect() time you take the decision of whether all
calls to setActive() will trigger your slot, instead of taking this
decision at the time you actually want to change the action active property.
I'd also like to point out having an explicit "silent" method is better
than using blockSignals(): blockSignals() could cause trouble with the
implementation of the widget if it uses signals internally whereas an
explicit "silent" method would avoid such side-effects.

Aurélien