Hi pekka >Or are you asking for instructions on how to fix the alleged Weston >desktop-shell bug where the black surface is not removed when attaching >a NULL wl_buffer to the wl_surface?
Actually I ask for instructions on this. Because I use "hide" to switch the apps. But I met some problems of the black screen if I just hide the surface. I want to implement the function like "background" or "home", just hide the UI. Thank you. Best Regards Nancy 2015-11-20 16:03 GMT+08:00 Pekka Paalanen <ppaala...@gmail.com>: > On Fri, 20 Nov 2015 10:52:54 +0800 > zou lan <nancy.lan....@gmail.com> wrote: > > > Hi Pekka > > > > How to not use the black surface behind the fullscreen surface? I want to > > Hi Nancy, > > are you looking for disabling the black surface in a way that would > work on upstream Weston or be upstreamable, or something you hack just > for yourself? > > Or are you asking for instructions on how to fix the alleged Weston > desktop-shell bug where the black surface is not removed when attaching > a NULL wl_buffer to the wl_surface? > > > have a try for the special needs to switch the apps. I can't use the > > minimize because it can't restore to its original shape. > > Oh that's the real problem here. Obviously restoring to original size > and position after minimization should work, so I think that is the > primary issue to be solved. However, I'm not sure if it is possible > with wl_shell, but it should be possible with xdg_shell. > > You have to note, that both desktop shell protocols are still far from > being finished. Switching the active window from clients is still on > the drawing board, AFAIK. > > Hmm, or is the fundamental problem really that you want to reassign > which window is active and on top from the client? > > There is a continuum of possible solutions, ranging from > non-upstreamable quick hacks on one end to joining the work on > designing the family of desktop related protocol extensions on the > other end which can take at least months. > > I think we should go back to the original use case you are trying to > make work: > > App1 launches App2. App2 appears on top and active (by the current > policy implemented in Weston's desktop shell, which is subject to > change). Then App2 wants to put App1 on top and active again. Is this > right? > > Should App2 stay up but behind App1? Or should App2 be hidden or > minimized? > > Note that hiding and minimizing are two different things: minimizing > leaves a window handle in something like a task bar, while hiding does > not. (Hiding with wl_shell probably triggers a (mis?)feature in Weston > where it forgets the window position, IIRC.) > > And you want App2 to be able to come back later in the original > position and size, active and on top of App1? > > I'm afraid on short term, all workable solutions will be more or less > hacks, because the desktop shell protocol extensions just do not exist > yet for this sort of things. > > > Thanks, > pq > > > > > 2015-10-09 9:29 GMT+02:00 Pekka Paalanen <ppaala...@gmail.com>: > > > > > On Fri, 9 Oct 2015 10:04:49 +0300 > > > > > Giulio Camuffo <giuliocamu...@gmail.com> wrote: > > > > > > > > > >> You get a black surface because weston puts a black surface > behind the > > > > >> fullscreen one even if it has the right size, and it seems like it > > > > >> doesn't remove the black surface when the client surface attachs a > > > > >> NULL buffer. That's a weston bug, i'd say. > > > > > > > > > > Giulio's analysis sounds good to me. I think no-one has tried - or > > > > > reported - to hide a window using wl_shell that was also > fullscreen, so > > > > > probably we have never considered that case in the code. > > > > > > > > > > Very likely a Weston bug indeed, specifically in the case of > committing > > > > > a NULL wl_buffer when using wl_shell. Transparency was a red > herring > > > > > all along. > > > > >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel