[vlc-devel] [vlc-commits] xcb: support for WM_DELETE_WINDOW(WM_PROTOCOLS)

[brezhoneg1]

Yes, as the default window provider, it ends up being used in very 
different situations, and therefore it's not obvious to provide  a 
generic  "close feature" that suits all needs.

For the time being, do you suggest a full revert of these patches (Linux 
and Windows)  or trying to find a better tradeoff ?

Actually, the missing brick is the ability for a vout_window_t object to 
pass information back to the vout_display_t object, since a 
vout_display_SendEventClose is already available. (Though it also ends 
up in a playlist_Stop with a FIXME ..., problem is passed and what to do 
remains unclear)


Regards


On 28/01/2011 20:52, Rémi Denis-Courmont wrote:
> I disagree and I purposefully did not implement this. I dont see why closing one video window should terminate the whole instance.
>
> ----- Message d'origine -----
>> vlc | branch: master | Erwan Tulou<erwan10 at videolan.org>  | Fri Jan 28 13:03:29
>> 2011 +0100| [95b63292214d81df212edafc7a228f8ec66d7958] | committer: Erwan Tulou
>>
>> xcb: support for WM_DELETE_WINDOW(WM_PROTOCOLS)
>>
>> When the default window provider is used (dummy, rc, ... interfaces),
>> rather decide what to do when the user closes the video window than let
>> the WM blindly destroy it. Till now, this led to an error message, input
>> dying and the playlist being stopped. For -I dummy, it also meant leaving
>> vlc hanging since no interface could then be used to stop vlc.
>>
>> Action taken is to stop vlc, but feel free to change/improve/make it
>> more configurable if need be.
>>
>>> http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=95b63292214d81df212edafc7a228f8ec66d7958