Re: multiple strut at same edge?
- From: Nathaniel Smith <njs pobox com>
- To: John Yates <john yates-sheets org>
- Cc: wm-spec-list gnome org, Lubos Lunak <l lunak suse cz>
- Subject: Re: multiple strut at same edge?
- Date: Wed, 1 Jul 2009 23:09:07 -0700
On Wed, Jul 1, 2009 at 6:22 PM, John Yates<john yates-sheets org> wrote:
> Are you saying that the KDE3 panel was/is capable of positioning
> itself immediately adjacent to an earlier strut that had already taken
> up a position at the actual screen edge? That is the only case of
> interest. Otherwise I do no understand what you believe would be
> broken.
A quick check confirms that with the current Gnome panel (2.26.1) you
can happily place two panels on the same edge of the screen, and they
will arrange themselves next to each other without overlapping. They
set their strut property in absolute terms (as per the current spec),
i.e. for me the first one reserves 25 pixels and then the second one
reserves 50.
>> On the other hand I agree that this case isn't covered very well in the spec
>> and perhaps could use at least a clarification.
>
> It sounds like you are suggesting simply codifying the currently
> observed behavior. If you do go that route then I would request that
> you also provide description of an approved algorithm by which a
> window can reliably set and maintain its partial strut property so as
> to avoid overlapping struts while always maximizing the central
> workspace in the face of arbitrary other struts coming and going.
I don't see any simple algorithm for this, but you are welcome to
invent one. (Or, since at least the Gnome panel is able to do
something kind of like what you want, it might contain such an
algorithm.) Note that overlapping struts per se are not a problem; the
strut property just tells the WM to avoid using a bit of the screen,
and if there are two windows telling the WM to avoid the same part of
the screen then the WM doesn't really care.
It sounds like what you really want is for the window manager to take
over the positioning of panels. The problem is that struts and panel
window position are logically independent -- consider auto-hide
panels, that may take up more or less space on the screen without
changing the logical "workspace". (Also there's obviously a major
backwards compatibility issue with totally redoing how panels and wm's
interact, but you would need to at least solve the technical issues
before even trying to argue that breaking compatibility was worth it.)
-- Nathaniel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]