--===============1094287720==
Content-Type: multipart/signed;
  boundary="nextPart1509231.DVqmeouHoj";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1509231.DVqmeouHoj
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Tuesday 14 April 2009, Marco Martin wrote:
> On Tuesday 14 April 2009, Aaron J. Seigo wrote:
> > b) should a setHandleParentAsPopup(bool) method, which would internalize
> > this behaviour and all it's intricacies? this way there could also be t=
wo
> > code paths: one for the legacy mode and one for the new mode
>
> position would have to be passed anyways tough...

yes...

> > c) is there someway to avoid having to support this at all? ;) kmix is
> > using it rather .. uhm .. creatively. but it seems like a valid use case
> > in that situation.
>
> klipper too, where left and right mouse buttons do the same thing

another good example indeed ...

> or maybe the icon could constantly inform the app about its geometry when
> changes? this would remove x and y parameters from contextmenu too...

this would break with multiple visualizations and would cause a lot of traf=
fic=20
on the bus when moving the icons around (with the benefit of keeping shown=
=20
popups "next to" the icons as they move)

> maybe the default impl will take it into account for context menu and not
> for activate, if for activate is rare enough it could be subclassed in
> application that need it

hm.. true, that's what we already do in fact. still, we need geometry=20
information available to do it.

> > * activateRequested() signal - unused?
> >
> > the activateRequested() signal doesn't seem to be used; is there a
> > purpose for it?
>
> aaaw, could be a piece i forgotten, was to give the application a way to
> know when the user activated the icon clicking on it (useful? not?),
> thinking about it could be avoided reimplementing the show event in the
> main widget...

that makes sense, yes, though shouldn't it have a bool then for whether it =
was=20
actually activated or not?

> > * context menu handling
> >
> > when using KSystemTrayIcon there are some additional items added
> > (activate, quit). thinking about how to handle this, we could either do
> > exactly what KSystemtrayIcon does when in "new and improved" mode and a=
dd
> > these items after aboutToShow is called the first time or we could
> > improve on this somewhat ;)
> >
> > the thing with KSystemTrayIcon is that if you clear the menu after it's
> > shown once, you won't get those actions in the menu anymore. nobody does
> > this it seems, however., so that's all good so far. so maybe this is Go=
od
> > Enough(tm)
> >
> > however, we could do thing a few different ways:
> >
> > - provide a KActionCollection to register actions with, and then when t=
he
> > menu shows clear it and populate it with the context of the action
> > collection plus our own
>
> couldn't be that apps could -not- want the default actions (no quit action
> sounds nasty hmm, but could even make sense for system stuff?)

it could be, yes. but i think they should have to take specific steps to ge=
t=20
that behaviour, rather than randomly end up there because they repopulate o=
n=20
aboutToShow() ;)

in any case, the standard items are only there if a parent widget is handed=
=20
in. well, that's not entirely true: the quit action is currently hardcoded =
in=20
there in KSystemTrayIcon.

we could come up with some nice way of handling this i suppose ...

=2D-=20
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software


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

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

iEYEABECAAYFAknkQzkACgkQ1rcusafx20O9OgCgieIsvlzoRfFV5cMBeK4N4EQE
1yQAn0w6EoE/Epqc/rAh8Lc2kPLcrUGP
=nS1G
-----END PGP SIGNATURE-----

--nextPart1509231.DVqmeouHoj--

--===============1094287720==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

--===============1094287720==--