On Fri, 10 Aug 2012 13:23:34 +0800 Juan Zhao <juan.j.z...@linux.intel.com> wrote:
> Thanks for your reply. > Still don't understand why not implement wl_shell on tablet_shell to > customize it for a embeded system. Sorry, I don't think I can explain it any better, but I'll try. > wl_shell interfaces were defined in compositor side, in > wayland/src/wayland.xml. > Most client applications used them. Yes, because so far we have been targetting only the desktop. There once were plans to move wl_shell out of the core protocol file, but it didn't happen. I still do not consider wl_shell as part of the core Wayland. It is just a too important extension on the desktop to be moved out now, and that is also why it fell under the protocol freeze and stability requirement with 0.95. > Desktop shell implement one for desktop enviroment. And it works cool.I > like it. > > For embeded environment, implement a special one according to its usage. > And allow the client applications works cool here too. > Why should we force the applications for tablet-shell to be special, and > not to use that general wl_shell interfaces? And raise a bar for them? > For example, calculator, memo, or even webkit. > > Do you mean, there is some problems with this direction? Yes, I tried to explain that with the help of the Gimp. Have you ever tried any application that is using more than one top-level-like window? Or even apps with dialogs on tablet_shell? > BTW, GIMP is a window with several sub-windows. So we send a event to > tell the client: please set fullscreen to avoid such conditions. I think you have only seen the new(?) Gimp GUI. The traditional one looks like this (the WM is fluxbox): http://people.collabora.com/~pq/gimp-gui.png (1.6MB) How would you manage the windows of such an application on a tablet, given that the application is using the wl_shell interface? If you implement wl_shell in the tablet-shell environment and it works fine, then what do you need the tablet_shell protocol for? Desktop-only apps won't use it anyway. You ended up creating another desktop window manager, not a new shell. The point of tablet_shell, as it is in the Weston repository, is to be a new *shell*, not another desktop window manager. If apps did use tablet_shell protocol, then your point is moot: the application is already explicitly modified to use tablet_shell. Also, the same reasoning applies, if apps need to change their way of using wl_shell, when they run on tablets. It introduces tablet-specific code into the application, except it will be messier. My postulate is, apps using wl_shell cannot work fine on a tablet environment. The GUI will be somewhat unnatural the least, if not misbehaving. I am starting to believe, that you want to write another desktop window manager. The problem with that is that you are trying to do it in tablet_shell, which is another shell, not just a window manager. Would it not make more sense (conceptually) for you to fork desktop-shell instead? You are still free to replace the private desktop_shell protocol with whatever, as long as you keep the public wl_shell. Hmm, or what about this: you use the desktop-shell plugin, and let it handle wl_shell protocol, but replace only the desktop-shell client? The configuration of desktop-shell plugin could say which special client to launch. Then you could write a tablet-shell client replacing the desktop-shell client, and get a tablet-looking *desktop*. It would still be the same desktop window management, but with a different GUI. How'd that sound? Thanks, pq > > Thanks, > Juan > > On Thu, 2012-08-09 at 10:07 +0300, Pekka Paalanen wrote: > > On Thu, 09 Aug 2012 03:04:53 +0800 > > Juan Zhao <juan.j.z...@linux.intel.com> wrote: > > > > > On Wed, 2012-08-08 at 12:18 +0300, Pekka Paalanen wrote: > > > > > > > > The applications, i.e. the normal clients, are yet another thing. > > > > > > > > What I meant was that the two different protocol extensions were not > > > > separated properly in tablet shell. In the desktop shell, the public > > > > protocol extension is wl_shell, and the private protocol extension is > > > > desktop_shell. > > > > > > > > > > When a client initialises, the set of advertised global interfaces > > > > > > will > > > > > > contain either wl_shell or tablet_generic, or at least the client > > > > > > should > > > > > > bind to only one of the two. If it binds to tablet_generic, if > > > > knows > > > > > > it > > > > > > has to be full-screen always, it doesn't need an event to tell it > > > > > > that. > > > > > > How does it know what size to make its surface, I don't know. > > > > Looking > > > > > > at outputs or add a configure event? > > > > > > > > > > Do you mean the client itself should know it was working for > > > > > tablet-shell and need some modification? > > > > > > > > Yes, exactly. As the very first thing, it needs to know to expect the > > > > global interface "tablet_shell" instead of "wl_shell". > > > > > > > > If the server indeed advertises only tablet_shell, and not wl_shell, > > > > the application cannot use any of the window management or other > > > > features offered by wl_shell (or by wl_shell_surface). > > > > > > > > Right now, if the application does not know how to use "wl_shell", it > > > > will never get its window shown in a desktop-shell environment. That > > > > is > > > > intentional. > > > > > > > > > I think the client should not have to know that, or take some > > > > action. > > > > > If the client response to the the event tablet-shell send, then it > > > > could > > > > > do some configuration to it. > > > > > If the client doesn't response, then it could work usually, then > > > > > tablet-shell will add a black surface under it, to make it looks > > > > like > > > > > fullscreen. > > > > > In this way, tablet-shell could easy to support the toolkits who > > > > don't > > > > > add support to tablet-shell, for example efl applications. > > > > > Then the application development will feel easy to support both > > > > > desktop-shell and tablet-shell. > > > > > > > > No, the application cannot work "as usual", if there is no wl_shell > > > > advertised. Applications (read: toolkits) have to explicitly support > > > > the > > > > different basic shells. Your use case is just one special case, and > > > > such "fallbacks" are not generally acceptable. Yes, the toytoolkit > > > > does > > > > not support tablet_shell, it simply tries to not crash if there is no > > > > wl_shell. > > > > > > > > Tablet_shell is not simply a desktop adaptation for a tablet. It is > > > > supposed to be a completely different environment. A smartphone might > > > > be a better example, since tablets just might work with a desktop-like > > > > environment. > > > > > > > > Now, this does *not* mean that toolkits need to explicitly encode > > > > support for all the possible shells out there. I expect Gnome, > > > > KDE, Xfce, Enlightenment, etc. to provide their own desktop > > > > environments with their own "shells", but the difference to > > > > tablet_shell is, that they are all desktop shells. Therefore they all > > > > will support the basic desktop shell protocol extensions (that is > > > > wl_shell), and they can add more for their special needs. None of the > > > > special needs will conflict with the basic desktop shell concepts. > > > > Tablet_shell on the other hand does conflict, and cannot support all > > > > the basic desktop shell operations. > > > > > > > > That is the idea, at least. > > > > > > > > As a summary to everyone considering the above tl;dr and wanting to > > > > write a WM: > > > > > > > > Tablet_shell is *not* the example to base your own "desktop window > > > > managers" on. Instead, you want to fork the desktop-shell plugin, > > > > the special client, and the private desktop_shell protocol, and keep > > > > the public wl_shell protocol. > > > > > > > > Also note, that the wl_shell protocol extension can still be developed > > > > further, inspite of the freeze, in a backwards compatible manner. > > > > wl_shell is not complete yet in any sense. > > > > > > The window manager could run on desktop environment and can also run on > > > embeded environment. For example, when in embeded environment, it would > > > set all clients fullscreen by setting WM state. And the client don't > > > need to know where it is. > > > > Like I said, if you want to do that, then you are not writing a > > tablet_shell. You will be writing a wl_shell implementation, that just > > acts slightly differently depending on which kind of device it is being > > run on. > > > > Tablet_shell is for devices where wl_shell does not make sense. > > > > Actually the difference in when to use wl_shell and when to use > > tablet_shell is not so much about the device, but more about the > > graphical environment. You want a desktop-like environment on a tablet? > > Sure, implement wl_shell. Want something special and completely > > different, like for a TV? Invent your own basic shell like tablet_shell > > does. > > > > TV is actually a nice example, since in the most basic setup, the only > > input device you have is the remote control, which could be handled as > > a keyboard. No pointers, no touch devices. The GUI would not have > > arbitrary windows like a desktop does. That is a case where you would > > really want to do a wholly new shell. > > > > Now, the difference between shells can be a lot more subtle. Take Gimp, > > for instance. Traditionally it opens several windows, for canvas, > > toolboxes, etc. In a tablet_shell environment that simply cannot work, > > since every top-level window is fullscreen. Gimp must explicitly adapt > > to tablet_shell and remake its GUI. If instead you used wl_shell, and > > modifed it to always request every window as fullscreen, and tried to > > mimick the tablet_shell behaviour, Gimp GUI would be unusable, because > > Gimp would not have any clear indication, that the desktop environment > > is acting weird here. Gimp would attempt to manage its windows like on > > a normal desktop shell, perhaps refusing to fullscreen toolboxes etc. > > and that would be a disaster. > > > > > And any of the client don't need to know which compositor it works > > > against. For example, efl and gtk clients could run on any window > > > manager. efl and gtk for Xorg only differenciate Wayland/Xorg, but not > > > pay attention to which window manager the platform would be. > > > > > > To make the application writer easier, I suggest to make clients running > > > on tablet-shell easier. > > > > > > I'm still open on this point, welcome to add any further comments. > > > > We need to distinguish three different things here (towards Wayland > > clients): > > > > - compositors > > All Wayland compositors are indistinguishable by definition, > > since they are Wayland compositors. They only differ in the > > global interfaces they advertise, and for general purpose > > compositors, we should aim to support the same minimum set of > > globals everywhere. For instance, all desktop compositors > > should implement wl_shell. > > > > - shells > > Explained earlier in this email. Different shells have > > fundamental differences. > > > > - "window managers" > > The X Window Managers correspond to different wl_shell > > implementations, not different shells, since they pratically > > all deal with a desktop environment. > > > > I understand there could be special purpose X Window Managers, that > > would better correspond to their own shells. These window managers > > might not implement e.g. EWMH by the spec. > > > > When you think about all this, and think about tablet GUIs for > > instance, aren't good tablet GUIs somewhat different to desktop GUIs? I > > would assume they are, since on tablets, you usually poke the screen > > with fingers, don't have a keyboard, etc. That means applications and > > toolkits must already explicitly adapt to tablet environment. In > > Wayland protocol, we simply make the distinction explicit: you get > > either wl_shell or tablet_shell. > > > > Then how to run an application written for the desktop, on a tablet? > > I'm not sure what the answer here should be. Should the server > > advertise wl_shell in addition to tablet_shell? If there are several > > shells advertised, how would the client know which to prefer, if it > > supports several? > > > > In that specific case of a desktop app on a tablet, the wl_shell > > implementation could be a "sub-shell" of the tablet shell. All windows > > from the wl_shell application would be mapped to a single tablet shell > > "view", within which they would work a bit like when you have the > > application alone on a virtual desktop, without loosing the tablet > > shell gestures and other UI. Or something like that, trying to think > > about how the Gimp multi-window GUI could work on a tablet. > > > > To me it seems there are no easy or simple solutions, if you want to > > have the roughly the best possible user experience in every case. > > > > The good news is that Wayland does offer a standard way to advertise and > > implement everything properly. The "bad" thing is that applications that > > try to fight against the server will invariably lose, which makes > > writing quick hacks near impossible (unlike X). > > > > > > Just my 2c, > > pq > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel