minimized and stick windows

[sardemff7+wayland at sardemff7.net]

On 12/06/2013 11:18, Pekka Paalanen wrote:
> 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.

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