Draft "StatusNotifierIcon" broken by design

[Wolfgang Draxinger]

Am Wed, 19 May 2010 09:30:31 -0700
schrieb "Aaron J. Seigo" <aseigo at kde.org>:

> Excuse me if I point out the obvious irony of someone creating the
> Nth window manager who then goes on to complain about NIH :)

As far as I can tell it will be the very first AIGLX compositing tiling
window manager. Also I'm going to try out a lot of new concepts about
user interface design, and the existing WMs just don't cope with it.
Xmonad and awesome can largely be configured in how they layout, but
they cannot transform windows arbitrarily (by which I mean smooth
scaling, rotation), which is a feature I require: The whole thing will
be part of a multitouch UI. Compiz OTOH sticks to much to the classic
reparenting concept, plus I don't like it's overall design.

> I don't think anyone will be very interested in your rants unless the
> are constructive, reasoned and are paired with effort and action on
> your part. Please keep that in mind as you offer feedback.

Just fair, and I will gladly provide example code and patches as my
project progresses.

> The answer: use the xembed fall back. Legacy systems without DBus
> don't get to play as first class citizens in today's desktop world.

Yes, but only because DBus is a core component this doesn't imply
everything must be done through it. And one of the bigest caveats is,
that relying on DBus for UI stuff breaks X11 network transparency.

> See the recent thread about the status notifiers from the fellow
> working on the OpenGL driven dock.

Yes I've read this thread, and I still don't fully understand the OPs
problems. (Actually I skipped forward reading the StatusNotifierIcon
spec, due to that thread).

> That's part of it. DBus is also there for communicating between
> applications running even in the same session.

But it can't do this (yet) for all applications running within one
session. SSH tunneling is one example. Also, although it's on the
retreat XDMCP also has it's problems with it.

> It's more expressive, easier to work with and offers various useful
> features like introspection.

That's a really subjective view. I'm pretty sure, similar could be done
within a X session by using the existing transport mechanisms of X. It
might be a very good idea to have some DBus<->X plumbings, so that
within a X session everything happens through X, and if so, then allow
for multiple such adoptors running, one for every machine part of a X
session.

Some people might argue, that C++ is easier to work with than with C,
but ask people who have worked with GObject for some time and are then
forced to go back to C++ *shudder*

> I agree that we need to continue to work on, and in some cases
> re-work, the specificaton on fd.o. I hope you'll join, productively
> and constructively, in helping us achieve that. Thanks ... 
 
With pleasure.


Wolfgang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20100519/fc75a9b1/attachment.pgp>