> > 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.
O.K.
> > 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]> =
