minimized and stick windows

[Rafael Antognolli]

On Wed, Jun 12, 2013 at 6:25 AM,  <sardemff7+wayland at sardemff7.net> wrote:
> 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.

For EFL we are just waiting for the new API and implementation (which
I hope to actually work on it). The idea is to use the new interface
ASAP, but the already released versions would keep the old one, I
guess.

--
Rafael Antognolli