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). > > >> Anyway, that's just what came to my mind now. I don't recall any of the >> earlier discussions anymore, maybe there were solutions to some of >> these issues, maybe not. >> >> Did we ever discuss the possiblity of fullscreen being a special kind >> of maximized, btw? If you look at the state list above, everything is >> orthogonal (toggleable independently) except maximized vs. fullscreen. >> This is just as a concept, how it maps into protocol is a different >> matter. > > > Fullscreen, especially for games, is a completely different thing (e.g. > modesetting). We can have two cases here: “basic” fullscreen, which is just > maximize with panel removed (and the app will use the normal decoration > mechanism here, no fullscreen state), and plain fullscreen, which would be > another surface type. > I *think* most apps (games) already have heavy switching, so destroying and > creating a new surface should not be a problem here, imo.
If I'm not wrong, in the previous discussion we also discussed about the possibility of leaving fullscreen as a shell surface type itself. Though I don't have strong opinion about this, just trying to leave another possibility open. -- Rafael Antognolli _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
