[vlc-devel] [vlc-commits] commit: Fixed mouse buttons state for msw vouts (close #3519). ( Laurent Aimar )

[brezhoneg1]

Hi,

Le 13/06/2010 17:25, Rémi Denis-Courmont a écrit :
> ----- Message d'origine -----
>    
>>          In addition, multiple threads prevent libvlc developers from easily
>> (and legitimately) accessing mouse events when the mouse is over the video.
>>          (the only solution is based global hooks, that are not really
>> straightforward)
>>      
> There is essentially no way to fix this, unless msw/* is rewritten to not need any window events. And I would assume this is not possible.
>    

     I sent earlier four patches (very bad quality ... just a proof of 
concept) to help clarify my ideas.

     I do think it is possible. msw will still provide the window 
procedure to manage its own events (the video hwnd), or even could use 
what Microsoft calls subclassing to spy on the parent events without 
interfering. Code is almost the same. It's just moved from the event 
loop to the window procedure.

> I actually plan to move the mouse clicks event handling from the display to the window, just like we already do for key presses, at least for X11. And it could be done for pointer position as well.
>
> But I would assume the msw displays still need some other events, say window resize... And there is no generic way to hook into the window proc of the application. We would need to require that a certain main loop is used (say Qt4). I can only imagine how unhappy the bindings developers would be.
>
>    

This point is another thing, that is not too great in msw. Window 
resizing is mostly done is the vout Manage function (a polling system), 
and not based on message detection (except when no vout window is 
present). Some optimisation could be done to ensure a faster refresh, 
but that is another matter


>    
>>          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)
>>      
> This is unlikely to work for libvlc. And it will be a PITA for non-embedded videos: the skins and Qt4 interfaces would have to provide the non-embedded videos too. And then what about when RC or HTTP is in use (but no "real" UI)?
>
>    

    Patch #4 creates a basic vout window that acts as a fallback when no 
other vout window is available (dummy, rc, http, ...). Of course, this 
basic vout window has got its own thread/event loop.  (Actually, it 
exactly mimics the xcb design in that matter)


Rgds
Erwan10