Who is working on the non-drawing parts?

[Marty Jack]

Okay, let us take the setup I am running with.  I have two monitors

Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192
HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
HDMI2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 433mm x 271mm

I am running experimental non-released LXDE.  I have three panels configured.
One is on the bottom of HDMI1 so is at (0,1080-h) to (1920,1080)
One is on the bottom of HDMI2 so is at (1920,1050-h) to (3600,1050)
One is at the left of HDMI2 and configured to be of dynamic height so is at (1920,y1) to (1920+w,y2)

where y1 and y2 vary depending on what is in the window at any given moment.

I also have different backgrounds on the two monitors.

Moreover, for one example, when I pop up a task control popup or the volume control slider, I want it to be next to its button, but not covering anything on the panel.  I have it so that the entire panel is one X window and would intend for it to be only one Wayland window, so only I know where the button is.

If someone can explain to me how some simple hinting to the compositor will get this done, I am listening.  But I suspect you cannot.  I am confident there are other applications that will want the level of control that they have now.

I agree for simple application use cases, totally compositor controlled placement will work fine.  You may find you limit the rate of adoption of your new stuff the more you limit the use cases that it works properly with.

I do agree the Strut concept in EWMH is very weak in terms of semantics and being able to do all that is needed, especially with big virtual root.  That is one of the things we should discuss when I come out with the EWMH-for-Wayland proposal I have promised.

I have a screenshot of this with the task control popup and a regular dialog also popped up if anyone needed it to understand what it looks like.

On 11/29/2010 04:27 PM, Kristian Høgsberg wrote:
> On Thu, Nov 25, 2010 at 9:43 PM, Gerry JJ <trick at icculus.org> wrote:
>> Den Wed, 24 Nov 2010 13:01:06 -0500
>> skrev Marty Jack <martyj19 at comcast.net>:
>>> Also, I don't yet fully buy
>>> into the part about no client controlled window placement.  We need
>>> some way for docks to position themselves appropriately.
>>
>> Client controlled window placement is important.  Without it, you
>> can't restore multi-window sessions properly (or even single-window, if
>> position matters), splash screens won't be centered as they should be,
>> dialog boxes will pop up at random positions, and whatever else that
>> wants to put specific windows at specific positions on the screen for
>> other (possibly good) reasons won't work.  Some things may have less
>> valid reasons, but that's a tiny issue compared to not being able to do
>> all those things properly under Wayland.
> 
> All of those can be handled by the compositor.  The key is to let the
> compositor know what kind of window you're showing and how it relates
> to your other windows.  Once the compositor knows whether you're
> showing a new toplevel window, a dialog box for an existing window or
> a popup menu, the compositor/wm is always in a better position than
> the client to determine where that window should be.  The core of the
> issue is that the compositor may at any time be applying
> transformations to the clients windows that it can't express to the
> client.  If a client computes the exact location of a dialog box or
> popup menu, there is an implicit assumption that the client knows it
> current location and can compute from that a good location for the new
> window.  That's just not the case in a composited environment and it's
> one of the assumption that makes it impossible to really fix input
> redirection.
> 
> (Disclaimer: session management isn't even at the hand-waving stage
> yet, but I'm pretty sure we can deal with that without requiring
> clients to specific their position on screen).
> 
> Kristian
>