New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)
Aaron J. Seigo
aseigo at kde.org
Thu Feb 3 18:19:08 CET 2011
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
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
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110203/cc3269d9/attachment.sig
More information about the Plasma-devel