Weston : ideas about xdg_sell, and implementation for a taskbar
Jasper St. Pierre
jstpierre at mecheye.net
Thu Jan 30 16:27:17 PST 2014
On Thu, Jan 30, 2014 at 6:31 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>
> - When the compositor creates a shell_surface having the TOPLEVEL type,
>> it sets a numeral ID for it, and sends a "map" event to the desktop_shell
>> client ;
>>
>
> You must allow a "toplevel" to become a non-toplevel and vice-versa,
> otherwise useful api for rearranging windows is impossible. My
> recommendation is that a surface has a "parent" that can be changed at any
> time to any other surface or to NULL, the only restriction is that a loop
> cannot be created. In any case please do not make a "type" called TOPLEVEL.
>
This type already exists in wl_shell_surface_set_toplevel. It says nothing
about transient parents, only that it's a toplevel as opposed to a
subsurface.
Perhaps a misguided name, which is why xdg-shell removes the terminology.
However, weston's shell.c still contains a type called "TOPLEVEL" since it
started as an implementation for wl_shell_surface.
> - if it should be hidden, then the compositor sends the shell_surface to a
>> new
>> weston_layer named "taskbar_layer". This layer is not displayed at all.
>>
>
> NO! The compositor must only send a "hide request" to the client. The
> client MUST be in final control over when and how it's surfaces disappear.
> This is to allow it to atomically remove child surfaces or to reparent them
> to other surfaces that are not being hidden.
>
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!"
> When their "minimize" button is pressed, they now call a
>> taskbar_move_surface()
>> function which will do the former, and additionally send a hint to the
>> desktop_shell
>> that this has been done (so the corresponding taskbar button stays tuned).
>>
>
> I'm not clear on why the former api can't do this and you felt a new api
> had to be added.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140130/bf63d0ea/attachment.html>
More information about the wayland-devel
mailing list