[MPlayer-dev-eng] printf -> mp_msg conversion (etc.), first patches

The Wanderer inverseparadox at comcast.net
Sat Aug 7 06:03:19 CEST 2004


Attila Kinali wrote:

> On Sun, Aug 01, 2004 at 12:19:13PM -0400, The Wanderer wrote:

>>> Leave the MSGTRs as they are. If somebody cares he would have
>>> spoken up until now.
>> 
>> I'm not sure I understand what you mean. Do you mean, don't change
>> the MSGTRs in CVS at all, or don't change the ones in my patch?

>> On the latter, Rich *did* speak up, he just wasn't specific enough.
>> For that matter, it's possible that someone else might have
>> objections but have not noticed because this has been lying here
>> essentially dead...
> 
> I meant the later. Yes, Rich wasnt really specific and nobody else
> complained. Beside, Rich is on vacation, thus he cannot complain at
> the moment ;)

Wakarimashita.

>>> One issue i've seen is, that you changed MSGTR_Exiting to
>>> MSGTR_ExitingHow, which is actualy a good thing[tm], but you
>>> should repeat that change everywhere where MSGTR_Exiting is used
>>> otherwise mplayer will segfault.
>> 
>> I believe I did. If memory serves, MSGTR_Exiting was used in
>> exactly one place, in mplayer.c - for which a patch was included. A
>> quick grep through current CVS confirms this.
>> 
>> In any case, I believe I attempted to compile my working tree after
>> making the changes (mainly to check for typos), and it went
>> through with no problems. Wouldn't the missing symbol
>> (MSGTR_Exiting) cause a problem at compile time?
> 
> yes, but dont forget the translations in help/
> Those define MSGTR_Exiting too.

I thought updating those was the responsibility of the translator?

That said, understood; I'll make those changes as well, and resubmit the
patches. (I do have the tree against which I made the previous versions,
but I'm not sure how well it would update from CVS, or how well my
previous patches would apply against current CVS.) If I cannot easily
make acceptable patches from the current state of things, I'll simply
delete my working tree and start over; it's a comparatively small amount
of work to redo.

>>> Same here, this printf->mp_msg work should be finished. mplayer
>>> defintily needs more overall consistency. To much stuff is still
>>> done the way how it was 3 years ago, which is bad.
>> 
>> I just want to be able to contribute, and this is one thing which
>> A) needs doing, B) I can certainly do, and C) no one else seems
>> interested in working on. Which is why it's a little frustrating to
>> be unable to proceed...
> 
> Gambatte! :)

Arigatou.

>>> Hmm.. i'd say go on with the one patch aproach, no need to make
>>> it overcomplicated.
>> 
>> By this, do you mean to keep both the MSGTR changes and the printf
>> changes in the same patch? I wasn't sure about this in the first
>> place, and when I brought it up Rich agreed that they should be
>> separate. The only other option I see is the one quoted above,
>> which is a little bit clunky as it involves a wait between patches.
> 
> Do it in one patch. As far as i am concerned, those two parts are
> related.

Understood. I agree that they're related, I just wasn't sure they were
related closely enough.

I'll probably also reinsert one change (moved message) which I'd
mentioned having removed, because upon third look I think it may belong
there after all. Patches should follow later this night/morning.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.




More information about the MPlayer-dev-eng mailing list