On Wed, Jun 12, 2013 at 5:23 AM, <[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. > > > >> Shell surface types, exclusive: >> - top-level >> - transient (umm, what was this for, again?) >> - popup (menu?) > > > Transcient is for dialog (modal?) boxes, isn’t it? > Each type is a one-shot request on a new created surface. Again, simple and > efficient, love it too. > It may be a bit more clear, see below. > > >> Top-level shell surface states, each more or less toggleable on its own: >> - maximized >> - fullscreen >> - minimized >> - sticky >> - always-on-top or some equivalent layer thing >> ... > > >> Does this make sense? > > > Yes. > > > >> That is, only a top-level surface, which we should probably be calling >> as an application window, can be maximized etc., and I think the >> discussion was that it can be many things at once, like maximized and >> minimized. > > > Right, it is useful and not that hard to implement. > > > >> I don't think the states make sense as types, I would prefer the above >> hierarchy. A shell surface can only have one type at a time, but the >> states are not that restricted. It gives a nice tree-like hierarchy, >> instead of a directed graph where several surface types can have the >> same states. The tiling-WM developers would be concerned only about the >> top-level shell surface states, and could hopefully support all the >> shell surface types, which should make the difference between floating >> and tiling WMs more manageable. > > > I agree. > > > >> 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). >
Hmm... I'm still trying to understand this part, but are these calls used to create the shell surfaces? I also don't get exactly what would be the approach for passing parameters to the "state set" calls. Would we have a custom data field on the state_set call, or have specialized state set functions, each with its own set of parameters, like state_maximized_set, state_minimized_set, etc? I'll try to summarize things here: https://github.com/antognolli/wayland/wiki/Surface-States Feel free to edit it if you want, I think that it's open to anyone to edit. Regards, -- Rafael Antognolli _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
