[MPlayer-dev-eng] [PATCH] make vo_caca work with newer libcaca

[Corey Hickey]

Reimar Döffinger wrote:
> Hello,
> On Thu, Sep 21, 2006 at 08:48:22PM +0200, Gianluigi Tiesi wrote:
>> On Thu, Sep 21, 2006 at 11:40:53AM -0700, Corey Hickey wrote:
>>> MPlayer's vo_caca was written for libcaca 0.x. libcaca 1.0 will have a 
>>> different API, but it includes a compatibility header. The attached 
>>> patch makes mplayer include that header so vo_caca will work with recent 
>>> libcaca betas (tested with 0.99beta4).
>>>
>>> See:
>>> http://sam.zoy.org/libcaca/doc/migrating.html
>>>
>>> Eventually (maybe sometime after libcaca 1.0 is released) vo_caca could 
>>> be rewritten to use the 1.0 API, but I don't see any pressing need to 
>>> start on that now.
>>>
>>> This patch is very simple, so, if nobody objects, I'll apply it in one day.
>> There is already a patch that works with new api (not mine)
>> I splitted it in 2 files like for alsa:
>> http://oss.netfarm.it/mplayer/patches/xx_libcaca_split.diff
>> this replaces current vo_caca with new one and puts old in vo_caca9.c
>> for a minor size patch you must rename the old in vo_caca9.c and
>> add the new as vo_caca.c or change the configure patch
>> to do it in a different way.
>> The patch works is also tested on win32.
> 
> I personally would prefer the much simpler patch instead of (as I see
> it) needlessly creating another vo. Unless we in some way can profit
> from the new API (does it have new features we would want?)

 From http://sam.zoy.org/libcaca/doc/migrating.html:

------------
You have two ways to migrate your application to use libcaca 1.x:
     * Port your code using the function equivalence list. This is the 
preferred way because new functions are thread safe and offer much more 
features to both the programmer and the end user.
     * Use the legacy compatibility layer.
------------

I cannot comment on the relevance of either of those advantages to 
MPlayer. Personally, I don't deeply care which approach we take--I just 
want to make vo_caca work again one way or another. It seems to me, 
though, that if someone has already done the work to port vo_caca to the 
new API, then we might as well apply it eventually.

The approach that I was thinking of earlier was to:
1. Apply my compatibility patch.
2. Sometime in the future, when caca 1.x is widespread, port vo_caca to 
the new API and drop support for caca 0.x (with a helpful message in 
configure or something).

That would avoid any further complication with multiple caca VOs. 
Considering that mplayer's caca support is a just-for-fun feature, I 
wouldn't expect to generate much disgruntlement, if any. :)

I'm still open to futher discussion, of course.

-Corey