This affects way too many code paths. Let KDE fix their own crap.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This fixes cases where the stream length is unknown

Otherwise, when sending requests while already receiving data
(e.g. seeking) responses are not waited for properly

This reverts commit 7b18ec43.
This broke LibVLC and wall.

This reverts commit 95b63292.
This broke LibVLC and the wall filter.

Same rationale as previous patch about Linux.

fix trac #4440 (to be tested)

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.

An negative integer would make no sense here. I guess we could use an
unsigned char here, since it can only be between 0 and 127, as far as I
understand

This fixes opening of file names containing non-ASCII characters

Fixes Debian bug #600269

We still need to use it to stop VoD instances because the VLM waits
to join the input thread :(

For VoD, the synchronization is bad, but accurate synchronization would
require at least changes in the core to add support for some kind of
"instant pausing" to the stream output. Synchronous calls to the VLM
shouldn't cause delay problems, no operation waits for the input.

This way, we don't take the httpd lock when holding the vlm lock.
This will allow passing synchronous calls from the RTSP stack to the
VLM (as long as you don't use the old vod module at the same time,
which you can't anyway).

This will fix a bunch of crashes related to the buggy 10.5 64bit runtime.

On Linux, two scrolling events were generated for each wheel step
(one on ButtonPress, one on ButtonRelease). This led to scrolling being
twice faster on Linux than it is on Windows.

This patch ensures that only one scroll event is issued for one step at the
mouse wheel.

scrolling is coded twice in this file, because it contains two class
implementations (CtrlSliderCursor and CtrlSliderBg). Both need this code
since cursor can be on any one of these two controls when scrolling occurs.

It can be used to view an Xvfb as an example.
This supports both memory mapped files and old-style System V segments.