[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:       "matthew" <matthew () mjdsystems ! ca>
Date:       2010-09-18 19:17:01
Message-ID: 201009181517.07727.matthew () mjdsystems ! ca
[Download RAW message or body]


On Saturday 18 September 2010 06:33:34 Ingo Klöcker wrote:
> On Saturday 18 September 2010, Aurélien Gâteau wrote:
> > On 18/09/2010 00:06, Ingo Klöcker wrote:
<snip>
> > > > bool isActive() const;
> > > > void setActive(bool);
> > > > void silentSetActive(bool);
> > > 
> > > I suppose this is supposed to set the active state without emitting
> > > the corresponding signal, i.e. it is equivalent to
> > > 
> > > dualAction->blockSignals( true );
> > > dualAction->setActive( true/false );
> > > dualAction->blockSignals( false );
> > 
> > It is roughly equivalent: it does not have to block signals, it just
> > does not emit them.
> > 
> > > 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.
> > 
> > A concrete example is the play/pause action of a media player: While
> > playing the action text is "Pause". When the played song stops, the
> > action text must be set to "Play".
> > 
> > Having it as a single method is interesting because:
> > - It avoids the use of blockSignals(), which can be tricky, the
> > example you give is not completely correct, it should be something
> > like this:
> > 
> > bool blocked = dualAction->blockSignals( true );
> > dualAction->setActive( true/false );
> > dualAction->blockSignals( blocked );
> > 
> > - The method can be turned into a slot and directly connected to the
> > object it represents.
> > 
> > Still I agree it is mostly there for developer convenience, so if you
> > feel strongly against it, it can be removed.
> 
> I'd prefer it being removed.
> 
> 
> Regards,
> Ingo
> 


Instead of having to different functions, why not have two different signals?  Qt in \
its QLineEdit class has two signals, textChanged and textEdited.  textEdited does not \
get emitted when the text is changed using the setText function, while textChanged \
is.

Matthew


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

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