On Thu, Jan 30, 2014 at 8:48 PM, Bill Spitzak <[email protected]> wrote:
> Jasper St. Pierre wrote: > > Hiding windows should not have any influence over the client, as many >> desktop environments, including Weston, want to show live previews for >> minimized or hidden windows in alt-tab or Expose-alikes. >> >> Also, it matches user expectations. If the user clicks minimize on a >> window, they want it hidden, and they mean it, not get bested with >> "surprise! You tried to hide me but I resist by mapping my subsurfaces >> elsewhere!" >> > > The problem is that it makes window management very complicated, or > limiting. This is why no modern applications use overlapping windows, > instead doing their own tiled window layout inside one big window. They > cannot get the window system to overlay windows correctly except for > trivial temporary popups. > > A simple problem is a floating window shared by two main windows. Some > parts of the compositor want to know that the floating window belongs to at > least one main window (for instance to not show it in a toolbar). But the > client does not want it to vanish when that window is closed, yet it should > vanish when both windows are closed. > Can you give a concrete example of such a case? Not because I'm assuming none exist, but because I want a specific example to evaluate and think about. > This will require the client to tell the compositor that both of the main > windows are parents, thus giving rise to a Directed Acyclic Graph of > parents. I believe reliably updating this structure from the client is > enormously more complex and error-prone than a simple tree. Also I suspect > there are desirable window manipulations that cannot be described by a DAG > and thus even more complex api must be provided in Wayland. > > Kristin has proposed that nothing be sent from the client to the > compositor, I think he is worried about the api bloat this may cause. > > I feel that an intermediate solution that limits the data to a tree, since > only a "set parent" api is needed to manage it. When a client requests that > a window be raised or hidden then this tree causes children to do the same. > But this is only done after a request from the client, so the client can > first rearrange or delete the tree in order to get the behavior it wants. > The main reason for this is that I think it is necessary so wayland clients > can be displayed remotely on non-wayland systems that support such trees, > otherwise remote display may be very blinky when users raise windows. > > Both of these however require that all decisions about window > relationships be left to the client. There is no way around this, no matter > how much you want to pretend otherwise. > > A client that fails to hide the window after the request and a timeout can > get force-hidden, if you think this is a problem. But you cannot use > misbehaving clients as a reason for designing an api, since there are a > billion other ways a client can misbehave and you are not stopping them all > with this one api. > Like what? -- Jasper
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
