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 <geoffw_AT_cis.upenn.edu> 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: 0D73F361Received on Tue Jun 06 2006 - 16:14:32 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:08:01 UTC