New property proposal for StatusNotifierItem protocol: Label

[Aaron J. Seigo]

On August 10, 2010, Ted Gould wrote:
> I think that's were we're coming at this from different positions, we
> don't have another API for it. 

ah, i see. that is indeed problematic. so i'm guessing this is for Unity or
some other not-gnome-panel-based work, meaning you have no pre-existing
applet API to lean on. which makes all this make a lot more sense now,
 assuming i've read that right :)

unfortunately, i don't feel comfortable with agreeing to something that
would erode the quality of the status notifier API to fill in such a gap
 (which shouldn't really exist).

but perhaps all is not lost! to the important question:

> have one right
 now.  So, the question becomes: how do we manage these
> tasks the user wants to do?

absolutely... well, here's a suggestion, even though it's not optimal,
 perhaps:

assuming i'm reading between the lines correctly here and this is a Unity
related thing where the design goal is to put this kind of information into
a screen-edge-docked panel and it needs to be touched-based (which also
 explains the no-tooltips thing? :)  ...

... then these are addons that are created almost exclusively for Unity
itself, no? things that you have control over? and things that wouldn't
 necessarily need to be perfectly rendered in other workspaces?

if so ... then perhaps we are back to the issue of: 

	Can we have
 non-standard key/value pairs as added information
	that may be implementation specific attached to a StatusNotifierItem.

this came up with the audio player menu as well, in terms of how to glue a
status notifier from a random player to the mixer popup -> that requires
jumping from the status notifier from the app to the appropriate MPRIS
interface, and that is most reliably done by embedding that information in
 the status notifier.

this could be a similar thing: in this "non-standard collection of key/value
pairs", Unity (or whatever it really is in this case :) could go looking for
 an "IconText" key (or whatever it would get named) and use that.

it would mean that there would be no need to expand the spec itself while
allowing us to all experiment a bit more freely with it. all without
endangering the future quality of the API and burden existing
 visualizations.

and if i am proven horribly, wonderfully wrong and the label text is shown
to be a purely awesome idea full of rainbows and unicornsparkles then we
could 'promote' that key/value pair into the spec as either a document item
in the key/value property, or as a full fledged named property in the API
 itself

what does everyone think? (and by "everyone" i mean mostly Marco, Ted and
 Aurelian, though others are welcome to weight in, of course :)

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