either libVLC 2.0.5 changed the semantics of their callbacks (they can be
invoked from the main thread, i.e. from the VLC method resulting in the event);
or GTK+ 2.24 silently changed the type of the GDK mutex from recursive to simple.

in either case to avoid GDK mutex deadlocks we must check whether the VLC
callback's thread already holds the lock or owns the main context

 * ensures that the fullscreen window will be on the correct screen (for some reason it was already displayed on the correct screen)
 * ensures that the toplevel window (i.e. the player window) cannot be put above the fullscreen window (this was already ensured by keeping the fullscreen window above all other windows)

this causes issues on Linux and is not necessarily required

a workaround was necessary: after playing a movie, poll every 100ms for
the availability of the event window created by libVLC (in another
thread!) and disable it when found (stopping the g_timeout)

when setting signal handlers in a class structure (e.g. when deriving the class), there is no user_data argument