Re: multiple strut at same edge?

[John Yates <john yates-sheets org>]

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.

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 pobox com> 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