On Mon, Jun 05, 2006 at 06:29:02PM +0200, Denis Grelich wrote: > On Mon, 05 Jun 2006 10:49:25 -0400 > Geoffrey Alan Washburn <[EMAIL PROTECTED]> wrote: > > > Kris Maglione wrote: > > > No, there isn't. You can, however, most likely, achieve the desired > > > behavior by applying a minor patch to cmd/wm/wm.c. Since I know > > > virtually nothing about X11 on OSX, I don't know how to find the > > > height of the top bar, so you'll have to enter it manually (or I'll > > > go digging into Ion later, but no promises). > > If ion contains specialized code for MacOS X I can probably > > figure it out. > > > > > As long as wmii checks rect.y everywhere, rather than just assuming > > > it's 0 (no promises there either), this will work. > > > > Okay, I'll look into this. Would there be any reason not to make > > rect.x,rect.y,rect.width, and rect.height available via 9P in wmii-4? > > That way I can confine whatever modifications are necessary to the > > tools that I write. Though I have to admit that offhand I can't > > think of too many other cases where one would want to write these > > values, but there are probably a number of useful reasons for being > > able to read them interactively. > > I didn't look into the code, but I guess that it has to do with EWMH > hints. There are hints to bound the area managed by the wm. This is > used for example for various task bars, slits and dock-app bars in > other WM's. Afaik wmii does not support these yet, but iirc it is on > TODO. > > So, no need for exporting it. This should work automagically with the > hints.
The question is as always, what might be more flexible and consist of lesser code. Heavy EWMH support is definately not planned, because EWMH is one of the worst specs I have seen so far... Regards, -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
