On Thu, Jan 30, 2014 at 6:31 PM, Bill Spitzak <spit...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel