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

[Ingo Klöcker]

On Monday 20 September 2010, Aurélien Gâteau wrote:
> 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)

True. I didn't realize that activeText is the text that talks about the 
inactive state and vice-versa. I think this is rather confusing, but I 
guess there's not really much we can do about it.


> >> 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.

As long as you are the only listener you might have the choice to make 
the decision at the time you want to change the action's active 
property. But as soon as there is a second listener you have no way to 
know whether this second listener must be notified about the change of 
the action's active property. With two different signals the second 
listener has the choice. With just one signal and a "silent" setter you 
take the choice away from the second listener.

This is very similar to model/view in the case of multiple views for one 
model. Only the views know which notifications they want to receive from 
the model. Therefore none of the views must control which notifications 
the model sends out.


> 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.

True, but this is rather academic because an explicit "silent" method is 
just as evil as the usage of blockSignals(). blockSignals() should only 
be used internally by a class which needs to block its own signals under 
certain circumstances.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100920/523cf909/attachment.sig>