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