minimized and stick windows

[Pekka Paalanen]

On Wed, 12 Jun 2013 10:23:33 +0200
sardemff7+wayland at sardemff7.net 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.

> > 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.

> 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).

That is certainly a novel suggestion. I wonder what toolkit authors
would think.


Uh, I didn't mean to start another bikeshedding party, but I guess I
didn't really understand Rafael's question.

Cheers,
pq