Draft "StatusNotifierIcon" broken by design
notmart at gmail.com
Wed May 19 08:33:25 PDT 2010
On Wednesday 19 May 2010, Wolfgang Draxinger wrote:
> Right now I'm implementing my own window manager. Mainly because I'm
> not satisfied, what existing WMs provide or the way I have to configure
> those WMs which are closely to what I like. And the later unfortunately
> don't all implement things you need in a modern desktop.
> So I'm reading the specifications about X11/X.org and
> FreeDesktop.org - and at times went WTF?! to some higher power,
> because of, well... TSWAHELLAN and NIH.
> This is my first of probably a series of rants to come, especially about
> what's going on with xdg. My concerns are mainly attributes to the "to
> someone with a hammer, everything looks like a nail" (TSWAHELLAN) and
> "not invented here" (NIH) problems of the xdg folks.
> I'd like you to look at
> specifically at
> | The Status Notifier Item system relies on inter-process communication
> | via D-BUS and is composed by three parts: (...)
> And then think about this:
> xinit /sbin/ssh -X $REMOTEHOST $START_DESKTOP_SESSION_CMD
> or, even just something simple like
> ssh -X $REMOTEHOST $SOME_PROGRAM_USING_THE_SYSTRAY
> from a running X session. D-BUS won't work here, because SSH doesn't
> tunnel it. Oh yes, SSH could be expanded to implement it. But then
> there's the next problem: What about connecting from a X server/system
> where there's no D-BUS? Yes, those exists, and they're plenty.
that's why the specification still requires a seamless fallback to the xembed
> I understand, that there are some issues with the current systray
> mechanism, the biggest I agree with is about interaction with modality.
> But I highly disagree with the way how the proposed specification
> addresses this.
> And let's face it, the current XEmbed systray does it's job quite well,
> and the problem is not that systray is inherently flawed, but that the
> programs using it have bugs or don't conform. Let me cite from the
does its job if you want a "system tray" in the most classic sense of the word
with all its limitations, that we felt completely failed from an user
interaction point of view.
- being limited to show an icon, no alternative representations, no more than
- being forced to do exactly the representation the application choses (in
theory embedded windows should be resizable, in practice no one is)
- little to no communication between the icon and the host, on what it is its
status, importance, category etc (yes, a limited one could be achieved with
atoms, but that one would really be the hammer that adresses a non nail
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
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
More information about the xdg