minimized and stick windows

[Rafael Antognolli]

On Thu, Jun 13, 2013 at 5:42 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> sardemff7+wayland at sardemff7.net wrote:
>
>>> This is a requirement so that non-trivial clients can be written
>>> that are not forced to blink the transient windows to change their
>>> parenting.
>>
>>
>> Do you have a use case for this scenario ? There are probably some I
>> cannot see, but maybe could we solve them another way.
>
>
> A "toolbox" that must remain all of the N document windows, no matter which
> is raised.
>
> I propose that rather than the client having to send a directed acyclic
> graph to describe this situation, it only has to send a tree but it can edit
> it . Before the client raises any document window it reparents the toolbox
> to the new top-most window.
>
>
>> Same question, do you have a use case for a popup surface that you would
>> reparent? For our current use case (menus, do we have another one?) this
>> is unlikely (afaict, I am not a toolkit guy).
>
>
> The exact same situation, because a client needs to be able to turn a
> "popup" into a "transient", for instance if the user can pin the menu.

Just in case people have some filters set, I've sent some patches to
the list, changing maximized and fullscreen to states. I don't real
reviews on that, but at least a quick look to see if the overall
approach is good, so I can continue. I want to know basically two
things:

1) Will we have 2 new APIs for *each* surface states, so we can add
the needed parameters to them, or a generic set/unset API with
something like a void * parameter that will be used for any state?

2) Is fullscreen staying as another state, or as a surface type?

After that I can add the events from server to inform that such states
should be set, and then work on the minimize itself.

Regards,
--
Rafael Antognolli