On Wed, 05 Dec 2012 15:43:18 -0200 Tiago Vignatti <[email protected]> wrote:
> Hi, > > On 12/05/2012 12:32 PM, Pekka Paalanen wrote: > > > > I have not even thought about sub-surfaces' implications to input > > handling or the shell yet. Sub-surfaces probably need to be able to > > receive input. The shell perhaps needs a bounding box of the set of > > surfaces to be able to pick an initial position for the window, etc. > > indeed. On my "less intrusive" draft of subsurface, I've first started > brainstorming the input focus behavior [0]. That's quite useful for the > video player example that wants some kind of input control or a dialog > stick window that might not. So we'll need a way to tell which > subsurface gets the input focus. The way I did was enumerating methods > for the subsurface, like "transient" for passing away the focus and > "child" for a regular surface that wants it.. not a nice name, I agree. > > That being said, I'm afraid that the input focus together with the > configuration, positing and stacking, belongs more to the shells than > the compositor itself, which should only control the attach -> damage -> > commit. Just the concept of "windows" itself doesn't sound that good for > a simple shell for instance, so at the moment it's being hard for me > draw the picture why this is not an extension of the shell_surface. > That's why I started drafting from this other direction. Well, my first attack on the input management would be to do nothing special. :-) I.e. a sub-surface and a parent surface are all just wl_surfaces, and would not differ at all from a "window in a single wl_surface" case. On the input side, the client would just deal with a set of surfaces instead of one surface. It would get leave and enter events as usual, when the pointer or kbd focus changes from sub-surface to another. If a sub-surface wants or does not want input, the client sets the input region accordingly. The client (toolkit) just needs to be prepared to combine input events from the sub-surfaces, and e.g. direct keyboard events to the "whole window" first, rather than starting with just the one wl_surface. On the compositor side, I would not have to modify the input code at all. Weston's core would not need to deal much with "composite windows", i.e. a collection of a parent wl_surface and a set of sub-surfaces. It only needs to maintain the associations, and maybe offer helpers like the bounding box computation. Therefore it should not really need the concept of a window. Window management is the shell's job, and for instance the force-move binding is a shell feature, which can look up and move the whole composite window, when the user tries to move a sub-surface. So, instead of trying to be smart about input foci between the sub-surfaces and the parent, I would just punt that to the clients' input handling. I hope that works also in practice. > Anyways, nice write-up and summary Pekka. Thanks for bringing this up! Thank you! > [0] http://cgit.freedesktop.org/~vignatti/wayland/commit/?h=xwm-client-OLD > http://cgit.freedesktop.org/~vignatti/weston/commit/?h=xwm-client-OLD I see, right. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
