Am Wed, 19 May 2010 09:30:31 -0700 schrieb "Aaron J. Seigo" <[email protected]>:
> 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
signature.asc
Description: PGP signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
