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

[Aaron J. Seigo]

On Wednesday, February 2, 2011, Ted Gould wrote:
> We also started to use some of the application indicators from
> applications in the launcher on the left side of the screen.  We use the
> application indicator to provide additional menus for the launcher which
> we call a quick list.  We're currently choosing which application is on
> the panel and which is in the launcher based on heuristics, but we'd
> like to have a way for applications to explicitly control that behavior
> if they so desire. 

don't we have a way to do this already with the Categories? applications -> go 
into the launcher. not applications -> go into the panel / system tray.

do you have use cases (i'm assuming you must :) for where that dichotomy does 
not hold up?

> What we'd like to add is two properties that are
> lists of strings: NotShowIn and OnlyShowIn.  These would work exactly
> the same as the same properties in Desktop files where an application
> could say "NotShowIn=["Unity Launcher"]" and ensure that they'd never
> end up with that item used as a quicklist. 

this makes for a great hack to customize apps for a specific shell. 
unfortunately for the app developer (and their users) when that shell is 
replaced, then things go to hell all over again.

in the .desktop files, this is used to pair platform specific apps to their 
specific platforms. this mechanism you describe is sort of the opposite: pair 
apps to various platforms in different ways. the .desktop approach works due 
to the symmetry. i expect the status notifier approach to fail due to lack of 
that same kind of symmetry.

in the example of Unity, it only will work if the app developers release their 
apps along with Unity. otherwise, Unity can never change its design strategy 
without breaking 3rd party entries. perhaps you're approaching this from a 
"apps we write / patch" angle, but eperience shows that such patterns break 
because 3rd party devs do exist, they don't follow shell development very 
well, have their own ideas of what's good and what isn't and users flock to 
them all the same. it's what gave us the mess in the system tray in the first 
place :)

so instead of the application prescribing what to do, which requires all sorts 
of knowlege on the part of the app developer (what the "right" thing to do is 
in each shell, what the different shells even are), we should define the use 
cases and come up with a way for the app devel to add appropriate metadata to 
their icon that can be used by _any_ shell to make the "right" decisions, 
whatever that means for them over time.

without the use cases you have in mind, it's really hard for me to offer 
anything more specific, but perhaps you could?

> Most applications would
> hopefully not find a reason to use this, but for those that would like
> the precise control it would be available.

to me, this is a great reason not to do this :) application developers have 
demonstrated after 15 or so years of system tray usage that they are not able 
to manage these things well on their own.

-- 
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/cc3269d9/attachment.sig