<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 9:14 PM, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Le 2016-03-19 01:08, Darrell Walisser a écrit :<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It is tricky to determine when the fullscreen switch is complete,<br>
</blockquote>
<br></span>
Kind of repeating myself, but you shouldn't second guess the windowing system. You'll have all sorts of races, bugs and platform variability if you do that. You should just look at the fullscreen state boolean, which is not hard.<br>
<br></blockquote><div><br></div><div>There is no fullscreen state boolean in the windowing system, and if there is, Qt is not exposing it. A fullscreen window from its perspective, is window that happens to be borderless, the same size as the screen its on, positioned at 0,0, and is layered above all the other windows. At what point all those things come together to make the window "fullscreen" is indeterminate because there is no single event supplied for that.</div><div><br></div><div>There is a state boolean that Qt manages (isFullScreen()), but it lies. It will tell you the window is fullscreen before it is has been resized, and moved to 0,0, etc. The event sequence with my configuration (X11/OpenBox) is a QWindowStateChangedEvent followed by  QMoveEvent and finally a QResizeEvent, at which point the window reports the correct size. I expect this could differ depending on the Qt backend or version.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I don't really see why the minimal view should care anyway. The fullscreen state of the main UI window should not affect the UI view (in particular, the window could have the screen size while not being fullscreen). </blockquote><div><br></div><div>I don't know why it is coded the way it is, however I can guess that it is not an option to make a subview of a window fullscreen, since it doesn't have to be a window object (depending on the window system).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The fullscreen state of the detached video window should not affect the UI view either - only the fact that the video window is not embedded.</blockquote><div><br></div><div>Detached windows still work correctly with this patch. I can also mash the "f" key and nothing gets messed up.</div><div><br></div><div>Since we don't have a reliable fullscreen flag, the only solution is to write some way to detect the event sequence (which is somewhat convoluted and may be platform-specific), wait for the switch (first patch), or do not rely on the flag at all, as in my new patch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im"><br>
<br>
-- <br>
Rémi Denis-Courmont<br>
<a href="http://www.remlab.net/" rel="noreferrer" target="_blank">http://www.remlab.net/</a><br></span><div class=""><div class="h5">
_______________________________________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="https://mailman.videolan.org/listinfo/vlc-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/vlc-devel</a><br>
</div></div></blockquote></div><br></div></div>