[MPlayer-dev-eng] GUI and vo_x11 functions

Alexander Strasser eclipse7 at gmx.net
Fri Aug 26 18:22:16 CEST 2011


Hi Ingo,

Ingo Brückl wrote:
> I'm about to commit the vo_x11_ewmh_fullscreen() patch which adds a window
> parameter to the function, but I'm not quite sure whether this really is ok,
> although I got permission.
> 
> The question is whether vo_x11_ewmh_fullscreen() and all the other vo_x11
> functions should only operate on the global vo variables (like vo_window in
> that case) or whether they should be reusable functions, offering services
> for whoever wants to call them (the GUI in my case).
> 
> The reason why I raise this issue is that the GUI does call three other
> vo_x11 functions (with relative success), namely
> 
> vo_x11_decoration()
> vo_x11_sizehint()
> vo_x11_setlayer()
> 
> While vo_x11_decoration() seems to be problem-free (it has some useful
> parameters, but uses global variables as well), vo_x11_sizehint() mostly uses
> global variables (which causes some X errors with the GUI then if called at a
> time when these variables aren't yet set). vo_x11_setlayer() is pointlessly
> called by the GUI, because it doesn't do anything in case of WinID >= 0.
> 
> So, what is the right way to continue? Setting all necessary global vo
> variables in the GUI - even prior to the vo driver (vo_window is known to
> become WinID later anyway, for example), trying to modestly patch these four
> functions so that they can be reused or copy the code and letting the GUI use
> its own copies?

  It depends.

  IMHO reuse of mplayer functions in the GUI is OK and should be
done if fruitful. The other way around is not OK and more GUI
specific code outside the gui/ subdir is obviously not OK.

  I think it is OK if you take a rather pragmatic approach and
generalize the functions where it is possible without messing
too much with the mplayer client code (code that uses the same
functions from the mplayer side). This would be even desirable
for the mplayer side too, as it is better to have non-tricky
functions that are easier to comprehend and it makes the code
easier to read. For other functions that are very specialized
or non-reusable it would be good to just declare them static
and remove their prototypes.

> All these four functions are window specific and window handling should be
> GUI's task although commonly used code is convenient.
> 
> Pros and cons should be obvious.

  You would only have obvious problems if you were to move into
a code base separate from MPlayer. But of course you would have
a lot of other problems currently if you wanted to do so, which
leads me to the conclusion that it is rather theoretical to reason
that way.

  Alexander


More information about the MPlayer-dev-eng mailing list