[MPlayer-dev-eng] [patch] fix compilation error in gui/win32/interface.c
Alexander Strasser
eclipse7 at gmx.net
Sat Nov 24 02:02:34 CET 2012
Hi Ingo!
Ingo Brückl wrote:
[...]
> Alexander Strasser wrote on Fri, 23 Nov 2012 22:57:05 +0100:
>
> > Ingo, I hope you don't mind.
>
> Not at all.
>
> > If you want to fix this in a different way, feel free to do so.
>
> No, it's ok, although I'm wondering what is more favourable - to use the same
> name for functions doing the same (in different ways) in both GUIs (even if
> one has to be non-static although it could and should be static) or to use a
> different name in order to sustain its static-ness?
Judging from quick intuition I would say it depends on the development
direction you want to follow for the future. Beware I do not know enough
details about the gui code to answer this precisely.
1) So if your goal is to have both GUIs evolve into a similar application
where the detail implementations differ to accommodate for the underlying
platform, I do think this solution is a good fit (sacrifice the restriction
to one implementation file and drop the static in favour of being more
similar with to the unix gui).
2) If you want the guis to become more different and evolve independently,
then continue doing changes this way might not be the way to go. Though of
course dropping the static does not hurt this time. But you might want to
start thinking about developing things differently in the future. Say for
example stop sharing most of ui related headers (IOW share only platform
independent stuff that does not touch the UI and does not try to integrate
with the desktop environment). Or even changing directory layout to reflect
the separation:
-+- x11 ---+- <x11 specific subdirectories>
| |
| +- <x11 GUI implementation files>
|
+- win32 -+- <win32 specific subdirectories>
| |
| +- <x11 GUI implementation files>
|
+- util ...
|
+- <probably others> ...
Where you would share headers and implementation of util etc. but there
would be no cross-sharing between x11 and win32 (not even headers).
Of course you would need to keep the functions called from mplayer
code unified because we do not want to call different GUI functions
depending on the platform from inside the regular mplayer code. This
might also be an argument that is currently speaking against pursuing
such a development direction.
Sorry for the long answer without really having a clue about the
mplayer gui code...
Alexander
More information about the MPlayer-dev-eng
mailing list