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.
Uh, I didn't mean to start another bikeshedding party, but I guess I
didn't really understand Rafael's question.
Sorry. ^^'
--
Quentin “Sardem FF7” Glidic
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
