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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
