[Thread Prev][Thread Next]   >Date Index >Thread Index

Re: [wmx] WMX GNOME and other enhancements patch

James Montgomerie - Tue Nov 28 22:47:44 2000

I did reply to this a couple of days ago, but my reply appears not to have
got through.  Apologies if anyone receives this information twice.

----- Original Message -----
From: "Chris Cannam" <cannam@all-day-breakfast.com>
Subject: Re: [wmx] WMX GNOME and other enhancements patch
>
> I don't think I know anything about layering in the WM sense.
> Technical summary, please?

It's not really very advanced.  Basically there are 12 'layers' a window can
be 'in', from 0 at the 'bottom' to 12 at the 'top'.  In GNOME (though, as I
said, the original spec is from MWM [whatever that is - I'm not sure, I used
the GNOME spec documents as a reference], so it's not a GNOME-only thing - I
think KDE might use the same system), the desktop icons are on layer 0, apps
are, by default, on layer 4 and the panel (when in always on top mode) is in
layer 8.  Applications can request that their windows be in any layer, and
the information is used when 'stacking' the
windows.

For [not much] more information, se here:
http://developer.gnome.org/doc/standards/wm/c44.html

The way I handle this in WMX is to keep 12 lists of clients instead of one
[don't panic - there's hardly any memory overhead for a list, we only ever
need 12, and each client's only ever in one - in fact, in some cases, having
more smaller lists instead of one big one makes lookup time smaller], and to
move clients between lists when their layer changes.

As I mentioned in my original post, I'm also using layer information to
decide whether to give keyboard focus and a border to windows (note: I don't
think this focus issue has anything to do with the problem Chris is
experiencing) - for example, in GNOME, desktop icons and the panel shouldn't
take focus away from windows (but they should receive clicks) and shouldn't
have borders.  I'm pretty sure this is the wrong way to do it - I think
windows should have attributes set separately to govern these settings, like
they do for 'stickiness'*, but I can't find any information on it.  The
system I'm using now seems to work in all the situations I've come across,
and I've been using it for almost five months now, but it seems like a
rather 'unclean' way to do things.  I've coded the methods in the client
class to be easily changed when we find out the correct way to tell if a
window is borderless or 'keyboard focus'less.

*for example, the reason GNOME desktop icons and panels appear on all
channels is now because they're created with their 'sticky' attribute set,
not because of special-case code in wmx.

Hope this helps to clear it up,

Jamie.



Next: