Draft "StatusNotifierIcon" broken by design

Wed May 19 11:58:35 PDT 2010

On May 19, 2010, Wolfgang Draxinger wrote:
> Am Wed, 19 May 2010 17:33:25 +0200
> 
> schrieb Marco Martin <notmart at gmail.com>:
> > that's why the specification still requires a seamless fallback to
> > the xembed version
> 
> So you've got two codepaths to maintain, each with its own kinds of
> bugs...

not optimal, but it's an improvement to the average user and so we deal with 
it.

> > that we felt completely failed from an user interaction point of view.
> 
> Could you explain this a bit more in detail?

it's been explained numerous times in the past; it comes down to:

* being able to control the visualization / rendering so that the items blend 
properly with the destination (and there may be multiple destinations, even 
including ones where a graphical representation is innapropriate)

* being able to define the user interaction so that it is consistent with the 
rest of the system (whatever system that is)

* being able to sort / hide / show / elevate entries based on their context 
(e.g. "this app is doing something really important right now and needs your 
attention")

* being able to sort / hide / show / relocate items based on what they 
represent ("this is a messaging application", "this is about hardware", "This 
is system service"); the "relocation" bit might mean "into a dock" or "into 
the menu popup for the task bar entry of the application"

if you look at what KDE 4.5 is doing with the system tray area or what 
Canonical is currently doing with their version of GNOME's notification area, 
it becomes evident what the differences are: contextual appropriateness, 
interaction and visual consistency.

> How to react on user input? Most people are used, that by
> right-mouse-button clicking on a systray icon they get some sort
> of mini GUI, they can use for simple manipulations.

interestingly, mobile devices have tended to not re-use the system tray 
protocol because it was so desktop centric (mice, right clicking, etc) and 
completely non-changeable. so projects like Maemo introdued their own system 
for these things. by contrast, one of our summer of code projects is to write 
a mobile appropriate visualization using the status notifier items.

we need to start thinking about not only the desktop exclusively but the 
entire device spectrum, where the desktop is an important part of that but 
only a part.

> certain status information. If it's not displaying through a mini
> window, then it's rendering it's stuff into a pixmap sending that to
> the proposed status notifier icon.

in practice, what you describe is actually the exception to the case with the 
status notifiers. we've ported several dozen applications and found all sorts 
of interesting cases in the process, so we have some practical experience to 
go by here.

> > moderm canvas-based visualizations really need to be able to paint
> > the icons themselves (or what they decide it is the best
> > represetation, maybe not icons at all)
> 
> Couldn't that be done using the composite?

no, because the only issue that addresses is being able to get a pixmap we can 
paint wherever we want. it doesn't address any of the user interaction issues 
or the visualization appropriateness issues. it also relies on composite being 
there, which we currently don't rely on.

> > what we need is a model-view based approach, that really provides
> > informations about applications,  where is completely up to the
> > workspace to decide how to present that information (if at all) to
> > the user all tose considerations put xembed out of the game, except
> > as a legacy falback, that is -not- going away, so you are perfectly
> > free to not support this specification.
> 
> As I understand it, you could do this with the existing systray already
> (maybe extending it a little)? It has an selection/atom for sending
> textual information to be shown in a standard format, you could as well
> place any kind of markup therein. Also nothing prevents one from sending
> icons through an systray atom. Heck you could include the icons as SVG
> in the markup. IMHO the existing systray can easily be extended to such
> lightweight status notifiers, w/o going D-BUS.

the idea of "drawing into a window" would still have to be removed from the 
equation to get the benefits we require. 

but ignoring that, if we view XAtoms and DBus as two IPC mechanisms, then yes, 
what you can do with one you can theoretically do with the other. DBus is a 
lot more comfortable for application developers and isn't tied to X11 as a 
mechanism (freeing us to use this on other non-X11 systems as well; even where 
X11 is available, with this mechanism, one could have console apps that have 
no open X connection pop up status notifiers). most importantly, nobody 
stepped up to do anything about the xembed protocol, while a group of people 
finally did something using DBus. work trumps talk/hope/expectation/desire.

-- 
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://lists.freedesktop.org/archives/xdg/attachments/20100519/b43818b2/attachment.pgp>