From kde-core-devel  Mon Sep 20 18:48:06 2010
From: Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date: Mon, 20 Sep 2010 18:48:06 +0000
To: kde-core-devel
Subject: Re: RFC: An action class to ease implementation of show/hide-like
Message-Id: <201009202048.06839 () thufir ! ingo-kloecker ! de>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=128500853907386
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart2781405.xgA1KeVnKv"

--nextPart2781405.xgA1KeVnKv
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Monday 20 September 2010, Aur=E9lien G=E2teau wrote:
> On 19/09/2010 16:47, Ingo Kl=F6cker wrote:
> > On Sunday 19 September 2010, Aur=E9lien G=E2teau wrote:
> >> On 18/09/2010 12:33, Ingo Kl=F6cker wrote:
> >>> On Saturday 18 September 2010, Aur=E9lien G=E2teau wrote:
> >>>> On 18/09/2010 00:06, Ingo Kl=F6cker wrote:
> >>>>> On Friday 17 September 2010, Aur=E9lien G=E2teau 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?
> >>>=20
> >>> Makes more sense since a dual action will probably always have
> >>> two different texts. (Otherwise, one wouldn't use it.)
> >>=20
> >> Indeed.
> >>=20
> >>> I'd revert the two texts, but that's probably just me.
> >>=20
> >> What do you mean?
> >=20
> > I meant change their order, i.e.
> >=20
> >   KDualAction( activeText, inactiveText, parent )
>=20
> Oh I see. If we take my sidebar example, then if the API is inactive,
> active the call looks like this:
>=20
>   new KDualAction(i18n("Show Sidebar"), i18n("Hide Sidebar"), parent)
>=20
> It feels more natural to me than:
>=20
>   new KDualAction(i18n("Hide Sidebar"), i18n("Show Sidebar"), parent)

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


> >> Would you prefer Matthew solution (two different signals?)
> >=20
> > 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.
>=20
> 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=20
the decision at the time you want to change the action's active=20
property. But as soon as there is a second listener you have no way to=20
know whether this second listener must be notified about the change of=20
the action's active property. With two different signals the second=20
listener has the choice. With just one signal and a "silent" setter you=20
take the choice away from the second listener.

This is very similar to model/view in the case of multiple views for one=20
model. Only the views know which notifications they want to receive from=20
the model. Therefore none of the views must control which notifications=20
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=20
just as evil as the usage of blockSignals(). blockSignals() should only=20
be used internally by a class which needs to block its own signals under=20
certain circumstances.


Regards,
Ingo

--nextPart2781405.xgA1KeVnKv
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAkyXrGYACgkQGnR+RTDgudhDGQCg1+7RGFg6U6TX7++gXKfVK0LH
gM8AoIrelTmIDJ1WBHd5KU9Vb9E4w5Up
=BaYy
-----END PGP SIGNATURE-----

--nextPart2781405.xgA1KeVnKv--