On Wed, 25 Jul 2012 14:37:47 -0700 Bill Spitzak <spit...@gmail.com> wrote:
> Kristian Høgsberg wrote: > > > We added wl_shell_surface, because we had a lot > > of requests on wl_shell that went like: wl_shell.set_fullscreen(shell, > > surface), ie, took the shell and a surface, and in effect were surface > > requests. So the wl_shell_surface is almost just protocol syntatic > > sugar, and I'm not always sure it actually makes things clearer. > > That is very informative! I have to say I was pretty mystified by the > wl_shell_surface object. > > Though this implies that there can be more than one shell. Because if > there is only one shell there is no need for that argument, and the api > can just be "wl_shell.set_fullscreen(surface)". The 'shell' in wl_shell.set_fullscreen(shell, surface) is just the "this" pointer to the wl_shell object. It is an object method invocation in pseudo-C. > What is the meaning of more than one shell? Or is there another reason > for the shell argument? A shell does window management. For your usual Linux desktop, we have wl_shell, or in the future probably wl_desktop_shell. This shell supports concepts like non-fullscreen, stackable windows, certain ways of assigning input foci to surfaces, it understands window types like top-level, pop-up, tooltips, transient stuff etc. Our desktop shell assumes you have keyboard and a pointer device. It has some hotkeys, and responds to pointer events in a certain way, the way people are used to when using desktop environments. The traditional X window managers would be something like sub-classes of the desktop shell. They may not need different protocol and hence applications would not need to particularly support different "window managers", but the behaviour would be different, e.g. a tiling window manager. But it would still be a desktop shell. We also have a tablet shell, which is very minimal for now. It is aimed for portable touch screen devices, that usually have no keyboard, but have a touchscreen (or a pointer). Window management is very different to a desktop shell. It has dedicated home screen, lock screen, etc., which concepts do not exist on a desktop shell. The following differences may not apply to tablet shell, but they are possible. Think about e.g. smart phone GUIs, TV set-top-boxes, car entertainment systems. - all applications are either visible fullscreen or hidden - set_fullscreen on/off request makes no sense - window positioning may be fixed, unmovable - user interaction with the GUI is based on a very different design, e.g. touchscreen only (more of an issue for the shell client component than the shell plugin). - window typing may be different, e.g. only "top-level" windows, and no pop-ups, or - window typing may be restricted, in that you may not have an arbitrary amount of windows. Maybe in a TV one could be restricted to the particular windows: tv-image, info-overlay, controls-overlay, PiP-image. For instance, when Android gets proper Wayland support, I suspect it will need an "android shell", because a "normal" desktop shell would be a poor match for the Android GUI concepts and window management. I hope these examples allow you to think about Wayland in other devices than traditional computers. When you realise that, many design choices you now think are strange will clarify. Wayland (core) is not only for desktop environments. And yes, applications will have to know the shell they are running with. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
