On Wed, Jun 12, 2013 at 6:25 AM, <[email protected]> wrote: > On 12/06/2013 11:18, Pekka Paalanen wrote: >> >> On Wed, 12 Jun 2013 10:23:33 +0200 >> [email protected] wrote: >> >>> On 12/06/2013 09:57, Pekka Paalanen wrote: >>>> >>>> To get the big picture, let me reiterate the surface classification as >>>> a whole, the way I see it. >>>> >>>> Surface roles, exclusive: >>>> - cursor >>>> - drag icon >>>> - shell surface >>> >>> >>> Each role is an interface then? Simple and efficient, I love it. >> >> >> No, a role is just a concept. In protocol it is currently assigned by >> passing the wl_surface as an argument for a specific request, that >> assigns the role. >> >> Only shell surface has a new interface associated, IIRC. > > > That’s fine: if the role is complex enough, put it in an interface. > > > >>>> Shell surface types, exclusive: >>>> - top-level >>>> - transient (umm, what was this for, again?) >>>> - popup (menu?) >>> >>> >>> Transcient is for dialog (modal?) boxes, isn’t it? >> >> >> Tooltips and alike, rather. > > > Ok, so we should add something here for modal dialogs. > > > [snip] > >>>> Protocol-wise, this means that requests set_maximized and >>>> set_fullscreen would be deprecated as is, and replaced with the state >>>> setting request. Request set_toplevel would deprecate the part of its >>>> behaviour where it changes a surface into normal state. >>>> >>>> We cannot remove the deprecated functionality, I believe, so it must be >>>> kept working, and just plumbed into the new kind of internal state >>>> change machinery inside weston. >>>> >>>> However, it's not that simple. Some states need parameters. Maximized >>>> needs an output, and fullscreen a few things more. Always-on-top >>>> equivalent might want a layer number or something. Therefore I'm not >>>> sure a single set_state request will work. >>> >>> >>> At protocol level, we may be better using new interfaces. >>> >>> wl_shell will gain three requests: >>> — get_toplevel_surface(class, title): returns a new >>> wl_shell_toplevel_surface >>> — get_transcient_surface(wl_shell_toplevel_surface): returns a >>> transcient one >>> — get_popup(wl_shell_toplevel_surface): returns a popup surface >>> >>> That would duplicate some requests between the three interfaces (or >>> maybe two, if transcient and popup can share one). >>> Backward-compatibility would be both easier and harder than keeping >>> wl_shell_surface around, as we have to maintain a compatibility struct >>> in the compositor, but that would be a simple struct { type; union { >>> toplevel; transcient; popup; }; }. >>> >>> That would allow to extend the configure event in a nice fashion, that >>> tiling WM will love (e.g. for decorations). >> >> >> That is certainly a novel suggestion. I wonder what toolkit authors >> would think. > > > I would probably provide patches for GTK+ at least, to test the stuff, and > the old interface (less powerful) would still be there for a while.
For EFL we are just waiting for the new API and implementation (which I hope to actually work on it). The idea is to use the new interface ASAP, but the already released versions would keep the old one, I guess. -- Rafael Antognolli _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
