> 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
> 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, which is an interesting subject of course and maybe
should be thought over together with the window manager issue. I spent
tool less time with berlin to know if there is some development in that
But You doubt right, it should do what a "standard" X
window mangaer does.
> 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?
> That wouldn't be exactly what GGI is designed for, but looking at the
> popularity of the screamingly colorful windowmanagers like WindowMaker or
> Enlightenment, it could give GGI quite a boost in interest.
That was one intention of mine.
> > 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.
> No, because GGI does not have such functionality. We had considered
> something like it for the resize stuff at least, but AFAIK it is not
> However there is libwmh that can be used to "remote-control" a
> windowmanager, if one exists. That is a LibGGI application can ask the
> windowmanager for placement, size, setting window titles, z-ordering
> and iconifying stuff.
I haven't checked this out yet, I'm still collecting wisdom.
> 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.
> 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. I want a smart,
fast, stable system. All instabilitys in the linux boxes I'm using comes
form X, I therefor would really like to get rid of that beast.