Who is working on the non-drawing parts?

[Dana Jansens]

2010/11/29 Fred Morcos <fred.morcos at gmail.com>

> 2010/11/29 Kristian Høgsberg <krh at bitplanet.net>:
> > 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
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>
> I second Kristian's opinion. Panels can request certain placements in
> sequence of their priorities (left, right, top-left, ...) and the
> compositor will be the best to decide which area is free
> (non-overlapping with any other panels already running) to contain
> that panel. I find that quite nice but also limiting.
>

One big problem in the current iteration of the wm-spec under X is that
multiple panels sharing the edge conflict and there is no nice way atm to
specify their positions properly.  The WM is in control of behaviour, but
then various WMs give various amounts of control to applications, which then
come to depend on it to work properly.  Which in the end means that apps
only work correctly under some WMs.  I think personally that all control of
behaviour should be in the WM.  It is only as limiting as the
protocol/interface which really is unbounded.


> I wonder, isn't that problem analogous to the client-side decorations?
> Allowing client-side decorations but rejecting client-side placement
> seems hypocritical to me.
>

They are completely orthogonal issues, so I don't agree.  One is visible
drawing of the window, and one is behaviour.


> I really think the X way (server, wm and clients) is the best way and
> truly is one-size-fits-all. A humble idea that I thought of was to
> have:
> wayland <-> [compositor <-> decorator] <-> clients (where <-> denotes
> talks-to)... But that looks awfully familiar...
>

Well, wayland is the compositor, so there is no use separating them out
here.  This is just describing the X server environment, which you stated
you like, but a wayland compositor is a different kind of environment.


- Dana


>
> Regards,
> Fred Morcos
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20101129/1a66dd1f/attachment.htm>