New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)
Aaron J. Seigo
aseigo at kde.org
Thu Feb 3 19:43:53 CET 2011
On Thursday, February 3, 2011, Ted Gould wrote:
> The use case was
use cases! excellent ... :)
> people wanting different menus on the panel vs. on the launcher.
crazy idea: different menus from the same SNI for different (well-defined in
the spec) contexts? if the SNI only provides a "generic" menu, use that
everywhere. if they provide a "launcher" menu, use that for launchers? we'd
need a set of menu contexts (generic or primary controller, launcher, ..?)
> Or not appearing on the panel at all even if there wasn't a
> launcher available.
could be a piece of metadata in the SNI itself to dictate this.
(and then it would work with any launcher.)
> So the specific case was with Tomboy where in the
> menu on the panel they wanted to have a "Quit" button but the launcher
> menu automatically has a close (through the WM) and they didn't want
sounds like we need/want action-level metadata.
> Also, in our specific case there are more restrictions on the
> menus in the launcher (no submenus) so if an app wanted to use those
> they wouldn't want it to appear in the launcher.
this can be determined with a heuristic?
> I would imagine that for most applications if they were going to use
> this feature they would be building more than one Item. They'd build
> one for a very specific visual target and then another that is a generic
> item for all other visualizations.
assuming they know of the available visualizations (and their design
guidelines), also create a generic one and then actually get the
visualization-specific ones right (esp over time -> what happens when the
visualization changes design in some way?). it's a lot of overhead for the
developer and very prone to breakage over time.
any time we've put visualization control in app developer hands things get
messy very quickly over the years due to these issues :(
for Canonical, you have Unity today but in 5 years what will you have? maye
something different. it's probably better not to get a whole bunch of app code
specific to today's Unity design that in N years you're going to have to
either provide legacy support for (probably with hacks) or which will result
in having to re-work all those apps .. again.
for KDE, it's even trickier: we don't have just one to-market product to
support. different vendors ship Plasma in different forms and configurations,
so we have to deal with "instant legacy" whenever these kinds of features are
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 Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110203/79289ea0/attachment.sig
More information about the Plasma-devel