On Thu, Jun 13, 2013 at 5:42 PM, Bill Spitzak <spit...@gmail.com> wrote: > sardemff7+wayl...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel