> > In what sense ? I.e. GGI is not a windowing system, so I don't quite see
> > what to manage.
> GGI should draw the windowframes, buttons, icons or the background (root
> window).

O.k. - I think that should be doable, however ... see below.

> > Or do you mean something like writing an X windowmanager that does its
> > rendering of decorations and stuff via LibGGI ?

> The basic idea is to start from concepts of known smart/small window
> managers like blackbox or sapphire. That means it should take care of 
> placing window within the screen, resizing, closing, iconifying,
> fullscreen windows or the visability hirarchy.  


> > Is it basically like opening additional Windows cleverly placed around the
> > application window, or drawing to the root window (I doubt that) or what ?

> Placing windows within an application window should be realized by a
> graphic toolkit, 

No - what I am talking about, is how the windowmanager places its
decorations _outside_ the application window.

> > I mean: If we can tweak the X target to render to such stuff, we could do
> > way cool stuff like program icons running your favorite GGI program or
> > titlebars and menus being interactive.

> Yeah, why not. But why should X render it?

See below ...

> > > Of course X Window programs should run also as well as programms with 
> > > graphic libs based on X Window.

> I guess this is the jumping point, if we have an application using e.g.
> Qt, it will need a running X Server. My imagionary window manager would
> run preferably with kgicon, so we'll get in trouble here. But a way out of
> it is to drop the X - server in the system completely and link Qt, gtk+ or
> what ever to XGGI. XGGI would need to map the XSetWM*****, XMoveWindow,
> etc. to GGI functions or maybe to a external library.

XGGI _is_ an X server. Nothing special about it.

> > Moreover, if you want to do what I propose above, that does not require
> > any such functionality. It would basically mean taking any existing
> > windowmanager and ripping off the widget rendering parts and replacing 
> > them with calls to ggi applications.

> This would require a running X server what I don't want to.

If you want to bypass the X server, I see only a single possible method:
You have to make kind of an LibX11-wrapper. 

However you should be aware that this is a huge task. Even when stripping
all the extension and undocumented stuff off, I count 523 functions exported
by libX11.so here. Total is over 1200 ...

> > Might be a bit ressource-intensive as it will eventually spawn off lots of
> > processes, but most of them should sleep in the normal case anyway ...

> This is exactly what I don't want. A major reason why I want to use GGI
> for this win. manager is that X is a resource killer. 

Then this is the only way. All X applications talk to libX11, which in turn
talks to the x server. The only place where you can intercept the
communications before it gets transformed into X protocol requests
(interpreting them would mean reinventing an X server), would be to
replace LibX11. Doable, but very much work.

The simpler approach would be to use a normal windowmanager, that happens to
use LibGGI to draw its own widgets. That is, it would directly talk to X as
usual, but after it has created the windows for its widgets, it will run
LibGGI plugins to draw on them.

This still requires an X server, but we can do quite some cool stuff in the
decorations, and :

> I want a smart, fast, stable system. All instabilitys in the linux boxes 
> I'm using comes form X, 

Regarding instability and ressource consumption, XGGI should help a great
deal. It is very lightweight and 100% stable for me.

CU, Andy

= Andreas Beck                    |  Email :  <[EMAIL PROTECTED]> =

Reply via email to