[vlc-devel] [vlc-commits] commit: Fixed mouse buttons state for msw vouts (close #3519). ( Laurent Aimar )
fenrir at elivagar.org
Sun Jun 13 14:34:49 CEST 2010
On Sun, 2010-06-13 at 10:36 +0200, brezhoneg1 wrote:
> * [vlc-commits] commit: Fixed mouse buttons state for msw vouts
> (close #3519). ( Laurent Aimar )
> > vlc/vlc-1.1 | branch: master | Laurent Aimar <fenrir at videolan.org> | Sun Jun 13 00:44:31 2010 +0200| [0e9bb2b6027e3327cf00694cfef5aaa76f446602] | committer: Jean-Baptiste Kempf
> > Fixed mouse buttons state for msw vouts (close #3519).
> > Used SetCapture/ReleaseCapture to emulate what x11 seems to do by default.
> > (cherry picked from commit 2a1f2f0bf5f14963417fb758910db478ac407a62)
> These mouse input quirks are most probably due to the GUI being
> managed by mainly two (even three) different threads
In this case, I don't think so.
It's just that by default, MSW and X11 do not handle the mouse buttons
the same way (The issue is present even without the qt4 interface).
> - the main GUI thread (qt4) (owner of the parent windows)
> - the background thread (msw) (owner of the hwnd and
> hvideownd subwindows)
> - the vout thread (some windows interaction via
> Mouse input is a part of the win32 api that is subject to a set of
> warnings/limitations in a multiple thread (multiple event loops)
> environment (cf msdn doc)
> In addition, multiple threads prevent libvlc developers from easily
> (and legitimately) accessing mouse events when the mouse is over the
Yes I know, but I don't have the time/will to work on another solution
> Imho, a clean solution would be to merge the two main threads (qt4
> and msw) in a single one, i.e one single event loop, that just
> dispatches messages to their right window procedures. The third thread
> is less of a problem, but still part of the equation (beware of
> blocking calls)
> I do have a patch that does the following :
> - extend vout_window_t to request the vout window provider (qt4,
> skins2, libvlc dev thread, ...) thread to execute the code that is
> currently executed by the msw thread (basically, subwindows creation
> and configuration)
> - Since there is now only one single event loop, move message
> management in Windows Procs.
> This patch works satisfactorily. It just needs to be updated with
> latest vlc1.2 changes in msw. If this approach is deemed worth, I can
> update it and send it on this ml for review.
Could you just send the current patch that you have? This way I could
see what you mean exactly and the consequences.
More information about the vlc-devel