<div dir="ltr">Hi Pekka<div><br></div><div>I have another question about the fullscreen NULL buffer display black surface. Why the fullscreen App call hide(commit Null buffer), then start another App, only the fullscreen App can show normally? Is  the normal screen App's layer below on the black surface?</div><div><br></div><div>Best Regards</div><div>Nancy</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-20 17:31 GMT+08:00 zou lan <span dir="ltr"><<a href="mailto:nancy.lan.zou@gmail.com" target="_blank">nancy.lan.zou@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi pekka<span class=""><br><br>>Or are you asking for instructions on how to fix the alleged Weston<br>
>desktop-shell bug where the black surface is not removed when attaching<br>
>a NULL wl_buffer to the wl_surface?<br><br></span></div>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. <br><br></div>I want to implement the function like "background" or "home", just hide the UI.<br><br></div><div>Thank you.<br><br></div>Best Regards<br></div>Nancy<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-11-20 16:03 GMT+08:00 Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, 20 Nov 2015 10:52:54 +0800<br>
zou lan <<a href="mailto:nancy.lan.zou@gmail.com" target="_blank">nancy.lan.zou@gmail.com</a>> wrote:<br>
<br>
> Hi Pekka<br>
><br>
> How to not use the black surface behind the fullscreen surface? I want to<br>
<br>
</span>Hi Nancy,<br>
<br>
are you looking for disabling the black surface in a way that would<br>
work on upstream Weston or be upstreamable, or something you hack just<br>
for yourself?<br>
<br>
Or are you asking for instructions on how to fix the alleged Weston<br>
desktop-shell bug where the black surface is not removed when attaching<br>
a NULL wl_buffer to the wl_surface?<br>
<span><br>
> have a try for the special needs to switch the apps. I can't use the<br>
> minimize because it can't restore to its original shape.<br>
<br>
</span>Oh that's the real problem here. Obviously restoring to original size<br>
and position after minimization should work, so I think that is the<br>
primary issue to be solved. However, I'm not sure if it is possible<br>
with wl_shell, but it should be possible with xdg_shell.<br>
<br>
You have to note, that both desktop shell protocols are still far from<br>
being finished. Switching the active window from clients is still on<br>
the drawing board, AFAIK.<br>
<br>
Hmm, or is the fundamental problem really that you want to reassign<br>
which window is active and on top from the client?<br>
<br>
There is a continuum of possible solutions, ranging from<br>
non-upstreamable quick hacks on one end to joining the work on<br>
designing the family of desktop related protocol extensions on the<br>
other end which can take at least months.<br>
<br>
I think we should go back to the original use case you are trying to<br>
make work:<br>
<br>
App1 launches App2. App2 appears on top and active (by the current<br>
policy implemented in Weston's desktop shell, which is subject to<br>
change). Then App2 wants to put App1 on top and active again. Is this<br>
right?<br>
<br>
Should App2 stay up but behind App1? Or should App2 be hidden or<br>
minimized?<br>
<br>
Note that hiding and minimizing are two different things: minimizing<br>
leaves a window handle in something like a task bar, while hiding does<br>
not. (Hiding with wl_shell probably triggers a (mis?)feature in Weston<br>
where it forgets the window position, IIRC.)<br>
<br>
And you want App2 to be able to come back later in the original<br>
position and size, active and on top of App1?<br>
<br>
I'm afraid on short term, all workable solutions will be more or less<br>
hacks, because the desktop shell protocol extensions just do not exist<br>
yet for this sort of things.<br>
<div><div><br>
<br>
Thanks,<br>
pq<br>
<br>
> > > 2015-10-09 9:29 GMT+02:00 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>>:<br>
> > > > On Fri, 9 Oct 2015 10:04:49 +0300<br>
> > > > Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>> wrote:<br>
> > > ><br>
> > > >> You get a black surface because weston puts a black surface behind the<br>
> > > >> fullscreen one even if it has the right size, and it seems like it<br>
> > > >> doesn't remove the black surface when the client surface attachs a<br>
> > > >> NULL buffer. That's a weston bug, i'd say.<br>
> > > ><br>
> > > > Giulio's analysis sounds good to me. I think no-one has tried - or<br>
> > > > reported - to hide a window using wl_shell that was also fullscreen, so<br>
> > > > probably we have never considered that case in the code.<br>
> > > ><br>
> > > > Very likely a Weston bug indeed, specifically in the case of committing<br>
> > > > a NULL wl_buffer when using wl_shell. Transparency was a red herring<br>
> > > > all along.<br>
> ><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>