[Mplayer-cvslog] CVS: main ChangeLog,1.101,1.102

[The Wanderer]

Diego Biurrun wrote:

> The Wanderer writes:
> 
>> Diego Biurrun wrote:
>> 
>>> The Wanderer writes:
>>> 
>>>> Diego Biurrun CVS wrote:

>>> Definitely.  There are lots of things that need to be done in
>>> this area.  Off the top of my head:
>>> 
>>> * Completely review the docs - they are mostly still written in
>>> Hunglish and much of it is clumsy and/or hard to understand. Such
>>> a review would of course be a good opportunity to extend them.
>>> * Same thing but for the tech docs.
>> 
>> The problem with both of these is that, for some of the same
>> reasons as I don't understand the code, I don't really know how
>> most of the program works well enough to improve on what
>> descriptions I know about. I've been picking things up here and
>> there by mostly-lurking on the mailing lists, but my overall
>> knowledge is still quite limited.
>> 
>> I suppose I could go reading through the HTML documentation and so
>> forth, and see if I spot anything I could explain better... in my
>> copious spare time. :)
> 
> Just browse the docs for a moment, you will find many parts that are
> badly in need of being rewritten and/or reworded.  If somebody with a
> good command of English (such as you) could review them that would
> be a great help.

Will do. I have too many commitments already, but the way I figure it,
more things to choose from means a better chance of actually getting to
at least *one* of them. <grin>

>>> * Much of the output MPlayer prints to the console is poor with
>>> regard to spelling, wording and clarity.  Also we have many
>>> printfs that ought to be converted to mp_msg calls.  These tasks
>>> naturally go together.
>> 
>> I actually took on the latter of these (printf --> mp_msg) once,
>> but ran into the problem of choosing what MSGT and MSGL to use. It
>> was agreed to define MSGL_FIXME, so that people who actually know
>> that part of the code well enough to make the decision could more
>> easily find and change the problem spots, but the question of what
>> MSGT(s) to use was never resolved and I ended up stopping work on
>> the endeavour. If these two problems can be resolved, I could start
>> over again, but as things stand my lack of knowledge of the code
>> gets in the way.
> 
> Maybe a solution would be to define them all as MSGL_FATAL or
> MSGL_ERR then all the devs would fix the levels quickly to be able to
> use MPlayer properly again :)

...Yes, this was the idea of MSGL_FIXME, which could have been set to
equal whichever of the others would best get the job done (and would
leave no ambiguity about which ones were *meant* to have that message
level, and which needed to be fixed). The problem, however, was the
MSGT_; a MSGT_FIXME is also possible, but what target should it be
equivalent to (and how is the work then different from a simple
search-and-replace)?

> Maybe you should restart this project file by file.  Then you can
> feed things piecewise to the maintainers.  Fixing the levels should
> not be a big deal for them.

File-by-file was about the way I intended to do it, yes. But without
solutions to the above questions, I'm not sure exactly what information
I should pass on to the actual developers. I could certainly provide
filenames and line numbers, saying "there is a printf() here which
should be mp_msg()", but that would have value only as a nag, which
admittedly is not completely useless but tends to be annoying to the
ones nagged.

>> One thing I could do regardless is keep a watch on this mailing
>> list and point out any commits with printfs or similar (sort of
>> like I've been doing with mistakes in these spellcheck commits); by
>> itself this won't fix the existing problems in that respect, but it
>> would help prevent them from getting any worse.
> 
> yes

Will do, then.

>> Well, I'm not sure (as noted) how much help I could be, and my own
>> time is more limited than I'm used to (though much less than it
>> could be), but if there's anything specific I *can* do feel free to
>> ask; there's little I like more than helping out.
> 
> Right now the biggest help would be going over the documentation file
> by file and transforming it into good written English.  If you fix
> some bugs and extend it while doing, even better.  I'm convinced you
> know enough about the topic to tackle this job and if not this is a
> good way to learn.  Interested?

Yep. I'll get started later this morning, descending the
English-language parts of the DOCS/ tree; if I also need to look
anywhere else, just tell me where.

Ought I to join the -docs mailing list? It's the only MPlayer list I
know of which I'm not on, because I didn't think I'd be interested, but
if I'm going to be working on this kind of project then perhaps I should
subscribe. (I'm fairly sure that, at the least, this discussion doesn't
really belong on -cvslog.)

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