[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: An action class to ease implementation of show/hide-like
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2010-09-19 14:47:06
Message-ID: 201009191647.07311 () thufir ! ingo-kloecker ! de
[Download RAW message or body]


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 )


> >>>>     bool isActive() const;
> >>>>     void setActive(bool);
> >>>>     void silentSetActive(bool);
[snip]
> >>> IMHO something like a silentSetActive() (or using blockSignals())
> >>> is evil because the caller can never know whether there are other
> >>> listeners which rely on the signal to be emitted. Therefore, I
> >>> strongly suggest removing this method from the class's interface.
> >> 
> >> I think it is useful to have this method for situations where the
> >> state of the element represented by the action has changed and you
> >> need to update the action to reflect the new state.
[snip]
> 
> 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.


Regards,
Ingo

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]