New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)

[Aaron J. Seigo]

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
> both.

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 
introduced.

-- 
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
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110203/79289ea0/attachment.sig