Weston : ideas about xdg_sell, and implementation for a taskbar

[Jasper St. Pierre]

On Thu, Jan 30, 2014 at 8:48 PM, Bill Spitzak <spitzak at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140130/b30a7506/attachment.html>