multiple strut at same edge?

[John S. Yates, Jr.]

I am attempting to create a permanent Emacs minibuffer near the top of
my screen.  In many distributions this is also the location of a top
Gnome panel with a strut property. My understanding is that for my
minibuffer never to be obscured it too needs to be a strut.
Unfortunately I have not found any specification of how a window
manager should behave when multiple struts are specified requesting
the same edge.

Empirically I have found that Metacity interprets all struts relative
to the actual screen edge (so effectively overlapping) but then lays
out the strut windows without overlap.  Without care the net effect is
a window in the desire position but without proper strut protection.
Is this intended behavior or has my use case simply never been
considered?

This behavior requires an application to enumerate all struts along
the desired edge and to sum their window geometries.  Unless all strut
lifetimes are properly nested an application must also reevaluate this
computation every time a potential strut window disappears or empty
strut space may be left on  screen.  This seems complex, fragile and
more properly to be the responsibility of the window manager.

Thus it seems to me that struts should be specified to be additive.
Any comments?

/john
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[John S. Yates, Jr.]

Following up on my earlier posting on
http://fvwm-ewmh.sourceforge.net/man.html I have found the following
suggestion that fvwm believes that by default struts are additive:

====

*FvwmNetHints: MyStrut left right top bottom
    Where left, right, top and bottom are positive or null integer
which represent an area in pixels from the left of the screen to left,
from the right of the screen to right, from the top of the screen to
top and from the bottom of the screen to bottom. This area is added to
the strut area which is computed from the compilant application
WM_STRUT hint. The strut area is the area from which the working area
is defined: the working area is the complement of the strut area vs
the screen. This option is totally dynamic.

*FvwmNetHints: StrutOverride
    Where bool is either True of False. If bool is True, then
FvwmNetHints take in account only the MyStrut FvwmNetHints
configuration option to compute the working area. Default is False.
This option is totally dynamic.

====

/john
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Monday 29 of June 2009, John Yates wrote:

> I am attempting to create a permanent Emacs minibuffer near the top of
> my screen.  In many distributions this is also the location of a top
> Gnome panel with a strut property. My understanding is that for my
> minibuffer never to be obscured it too needs to be a strut.
> Unfortunately I have not found any specification of how a window
> manager should behave when multiple struts are specified requesting
> the same edge.
>
> Empirically I have found that Metacity interprets all struts relative
> to the actual screen edge (so effectively overlapping) but then lays
> out the strut windows without overlap.

 Are you sure it is Metacity who places the windows? I think it's usually the
panel apps themselves who do the placement.

> Without care the net effect is
> a window in the desire position but without proper strut protection.
> Is this intended behavior or has my use case simply never been
> considered?
>
> This behavior requires an application to enumerate all struts along
> the desired edge and to sum their window geometries.  Unless all strut
> lifetimes are properly nested an application must also reevaluate this
> computation every time a potential strut window disappears or empty
> strut space may be left on  screen.  This seems complex, fragile and
> more properly to be the responsibility of the window manager.
>
> Thus it seems to me that struts should be specified to be additive.
> Any comments?

 The spec says "The property contains 4 cardinals specifying the width of the
reserved area at each border of the screen". This does not explicitly say it,
but I read "reserved area at border" as meaning the struct needs to be
absolute. And that is also how the KDE3 panel used it and it worked. So
changing this could mean breaking backwards compatibility.

 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.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http://www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[John S. Yates, Jr.]

On Wed, Jul 1, 2009 at 9:56 AM, Lubos Lunak<l.lunak@...> wrote:
>
>  The spec says "The property contains 4 cardinals specifying the width of the
> reserved area at each border of the screen". This does not explicitly say it,
> but I read "reserved area at border" as meaning the struct needs to be
> absolute. And that is also how the KDE3 panel used it and it worked. So
> changing this could mean breaking backwards compatibility.

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.

>  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.

/john
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Nathaniel Smith]

On Wed, Jul 1, 2009 at 6:22 PM, John Yates<john@...> 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
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[John S. Yates, Jr.]

On Wed, Jul 1, 2009 at 6:22 PM, John Yates<john@...> 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.

My bad.  After posting I realized I should have specified that the
earlier struct come from a distinct application.

On Thu, Jul 2, 2009 at 2:09 AM, Nathaniel Smith<njs@...> wrote:

> 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.

Sure.  Once a panel implementation allows multiple struts along
orthogonal edges it most likely already has logic to avoid corner
overlap.  Generalizing to parallel struts is probably very little
additional logic.  This is easy to do because it is all handled with a
single application.  That is _radically_ less work than figuring out
how to deal with struts from other application whose existence and
properties are communicated only via window messaging.

I confirmed and extended the Gnome panels experiment.  The behavior is
clearly that which I suggested in my earlier posting:
- panels never overlap, whether they are parallel or orthogonal
- panels always migrate as close to their configured edge as possible
- when a panel closer to the edge disappears all remaining panels
along that edge move outwards

There is a clear intended behavior here. Yet it break immediately when
one introduces panels supplied by a distinct application.

I installed LXPanel from LXDE.  LXPanel is equally scrupulous above
not overlapping other instances of LXPanel.  In fact once it has a
panel at a given edge the choice of that edge becomes greyed out when
positioning additional LXPanels.

Existence of a Gnome panel on the screen does not cause a similar
reduction in choices.  When I configure LXPanel to the same edge as a
Gnome panel they overlap entirely.  When I configure the panels to be
orthogonal corners overlap.

The breakage runs in both directions.  It makes no difference whether
I am reconfiguring a LXPanel or Gnome panel, neither is capable of
presenting the same behavior as when it is dealing with an homogeneous
population of struts of its own creation.

>> 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.

Sure... the WM is only entity with access to the global picture so let
it take responsibility :-)

> (Or, since at least the Gnome panel is able to do
> something kind of like what you want, it might contain such an
> algorithm.)

The experiments described above prove that when it comes to
interacting gracefully with other applications no such algorithm
exists within Gnome panel.

> 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.

Yes, the current strut definition is problematic.  It is an
essentially visual description of the screen.  There is a complete
absence of any expression of intent.  In this sense the design recalls
the critique of MOTIF hints that motivated the introduction of
_NET_WM_WINDOW_TYPE:

Rationale: This hint is intended to replace the MOTIF hints. One of
the objections to the MOTIF hints is that they are a purely visual
description of the window decoration. By describing the function of
the window, the Window Manager can apply consistent decoration and
behavior to windows of the same type. Possible examples of behavior
include keeping dock/panels on top or allowing pinnable menus /
toolbars to only be hidden when another window has focus (NextStep
style).

I think that what applications really want is to be able to decrease
the remaining workspace in the vicinity of a screen edge and to be
able to position a window relative to that carved out, protected
space.  In the most common case, namely no more than a single strut
window at each edge such a changed definition would be
indistinguishable from today's strut handling.

> 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.)

This is my very first foray into the world of windowing and its
standards.  For now I am simply striving for an acknowledgment of
existence of problematic scenario and perhaps some consensus on what
applications expect in the presence of heterogeneous struts.

My driving use case is that I want to have a single, sticky,
strut-like emacs minibuffer adjacent to a Gnome panel, a KDE kicker or
something similar.  You will notice that I am not dealing with a
Desktop Environment's thinking that it can justify the simplifying
assumption that it is the only source of struts.  My minibuffer fully
expects other struts to exist.  It just does not have a convenient,
reliable way of cohabitting correctly with them.  I really believe
that to solve this problem of heterogeneous struts and to compute the
size of my minibuffer strut I should not have to query the window
system to identify and analyze all existing struts.  I just want to
say here is a window, please make it this high, as wide as you can,
position as close to the top (or bottom) as possible and do not allow
other windows to overlap it.

I believe further that that description of my own intent more or less
parallels that of nearly any application creating a strut.  Can anyone
suggest a counter example?

/john
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list