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

[The Wanderer]

I've been wondering if you'd get around to this. ^_^


Attila Kinali wrote:

> On Wed, Jul 14, 2004 at 08:47:00PM -0400, The Wanderer wrote:
> 
>> Gyaaaah. I don't know why I bother...
>> 
>> The Wanderer wrote:

>>> Do any of the MSGTRs I mentioned need to be moved back to the
>>> souce files to make an acceptable patch, or will making the
>>> MSGL_ERR-related changes be enough?
>> 
>> I still need an answer to this question in order to continue - or
>> rather
> 
> 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 former, someone did speak up, on the DOCS list; that's why I
started changing them in the first place.

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...

> 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?

>> I would, except that by this point if I ever resume the project I'm
>> liable to just start over from scratch.
>> 
>> I really don't *want* to abandon this, but at certain points
>> (including especially the early stages when I don't yet entirely
>> have my feet under me) I'm going to need feedback on exactly what I
>> need to do differently; if I'm not going to get it, I'm not going
>> to be able to proceed.
> 
> 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...

>>> Or am I doing something completely wrong?
>> 
>> This has been bugging at me off and on, and I honestly don't
>> understand what you were suggesting I do. Here are the
>> possibilities as I understand them.
> 
> Neither do i, and currently Rich is away so he cannot clarify this.
<snip my examples>
>> I simply don't see any way, other than waiting to make the second
>> patch until after the first one has been applied, to get around
>> either of these. If there is one, I'd be very glad to know it.
> 
> 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.

The rationale behind keeping them separate is, as I understand it,
restricting each CVS commit to a specific issue rather than making
multiple types of change with a single commit. (The reasoning behind
*that*, of course, is to make it easier to revert a specific problematic
change if necessary without taking out things which did *not* cause
problems - but that might not apply in this instance.)

-- 
       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.