Weston : ideas about xdg_sell, and implementation for a taskbar

[Manuel Bachmann]

Hi Bill, and thanks a lot for sharing your thoughts,

> You must allow a "toplevel" to become a non-toplevel and vice-versa

That's true ; the current implementation doesn't address this case.

> My recommendation is that a surface has a "parent" that can be changed at
any time to any other surface or to NULL

So for an application having a "main" surface (let's say, the first that
has been created) and child (transient ?) surfaces, the schema would be :
NULL -> shell_surface -> shell_surface -> shell_surface
                                     |->shell_surface

In that case, an implementation *could* just display a button for the first
shell_surface on the left, and minimize it and all its children at the same
time. Well, I suppose it's really something up to the actual
implementation, so a sample impl. could just do it the easiest way.

> NO! The compositor must only send a "hide request" to the client. The
client MUST be in final control over when and how it's surfaces disappear.

Have just been reading the other (old) thread on this issue, so I get your
objection :-).
I suppose I'll have to write a sample client application able to process
such a request. GTK+ seems to have an impl, so I will check what it does.

> I'm not clear on why the former api can't do this and you felt a new api
had to be added.

Well it's just a demo, I don't really feel like it should be merged in this
state.In fact,  I'd like to avoid adding any API.
----

Taking your comments into account, here's what I think I should do next :

- write a sample client able to send "xdg_shell_set_minimized()" requests,
and process the responses to it ;
- write a minimal implementation for a "taskbar/main_shell_surfaces_list"
(?) in the "shell" directory, and allow it to be built on demand ;
- make sure these 2 components communicate and react well.

Thank you ; any further recommendation appreciated !

Regards,
Manuel


2014-01-31 Bill Spitzak <spitzak at gmail.com>:

>
>  - When the compositor creates a shell_surface having the TOPLEVEL type,
>> it sets a numeral ID for it, and sends a "map" event to the desktop_shell
>> client ;
>>
>
> You must allow a "toplevel" to become a non-toplevel and vice-versa,
> otherwise useful api for rearranging windows is impossible. My
> recommendation is that a surface has a "parent" that can be changed at any
> time to any other surface or to NULL, the only restriction is that a loop
> cannot be created. In any case please do not make a "type" called TOPLEVEL.
>
>
>  - if it should be hidden, then the compositor sends the shell_surface to
>> a new
>> weston_layer named "taskbar_layer". This layer is not displayed at all.
>>
>
> NO! The compositor must only send a "hide request" to the client. The
> client MUST be in final control over when and how it's surfaces disappear.
> This is to allow it to atomically remove child surfaces or to reparent them
> to other surfaces that are not being hidden.
>
>
>  When their "minimize" button is pressed, they now call a
>> taskbar_move_surface()
>> function which will do the former, and additionally send a hint to the
>> desktop_shell
>> that this has been done (so the corresponding taskbar button stays tuned).
>>
>
> I'm not clear on why the former api can't do this and you felt a new api
> had to be added.
>



-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140131/7fe6b405/attachment-0001.html>