[vlc-devel] commit: libvlc: add mouse events as libvlc_MediaPlayerEvents ( Jean-Paul Saman )

[Rémi Denis-Courmont]

Le jeudi 11 février 2010 17:17:50 Jean-Paul Saman, vous avez écrit :
> 2010/2/11 Rémi Denis-Courmont <remi at remlab.net>:
> > On Thu, 11 Feb 2010 12:54:43 +0100, Jean-Paul Saman <jpsaman at gmail.com>
> >
> > wrote:
> >>> Attaching mouse-object to vout_thread_t seems a bad idea to me as it
> >>> used only by the logo filter.
> >>>  IMO, it should be moved to the logo filter instead.
> >>
> >> But how do I obtain the logo filter object then? Without
> >> vlc_object_find_name() ??
> >
> > In my opinion, the question is wrong to begin with. No matter the
> > mechanism, it will be at least as bad as vlc_object_find_name(). The
> > premise that the logo object must be found is flawed.
> > vlc_object_find_name() sucks. Fundamentally. If it were just an
> > implementation bug, I would already have fixed. But its design is wrong,
> > and that cannot be fixed short of using another design.
> 
> Can I conclude that you do not like Laurents suggestion?

AFAICT, no matter how you "get" the object, you will:
 - break encapsulation by crossing multiple layers
   that were not meant to be crossed,
 - loose early events from the object,
 - screw up if there is more than one object.

The only way to not loose events is to register even before the filter object 
exist. Otherwise, there is a risk that the object emits events before you 
actually found it, or before you added the callback. This is present because 
the video output thread is independent of the input thread.

By definition, this implies the object cannot be relied on. Instead, "contact" 
between the object and the listener must be made through some kind of pre-
existing reference. In this case, that can be either the input or its parent, 
the media player.

That's just the general idea. There are various ways to implement it. Probably 
the least invasive (but not cleanest) consists of declaring an object variable 
on the media player pointing to a custom structure. Then start playback. The 
filter object can find the structure with var_Inherit() (and do nothing if 
NULL). Finally, *after* playback has stopped, the structure can be destroyed.

A simpler alternative would be to var_AncestorSet() that would change the of a 
variable on the closest ancestor that defines said variable.

A cleaner option is to propagate events up step by step (filter->codec->es-
>input), but I suspect it would be too invasive for such corner use case.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis