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

[Diego Biurrun]

The Wanderer writes:
> Diego Biurrun wrote:
> 
> > The Wanderer writes:
> > 
> >> Diego Biurrun CVS wrote:
> > Heh, I went to sun.com and saw it written as "Sparc" on their front
> > page, go figure.  But SPARC is right.
> 
> It hasn't been corrected yet, though - which I wouldn't mention, except
> that the others I noted have, so it's possible that this was an
> oversight.

It's fixed now.

> > While we are at the subject: I'm unsure about the correct of spelling
> > of "vobsub" vs "VobSub" vs "VOBsub" vs "VOBSub" vs "VOBSUB" and all
> > five variants are used throughout MPlayer.  There is a VirtualDub 
> > plugin/filter called VobSub, so maybe that is where part of the 
> > confusion originates.  I'm inclined to use "VOBsub".  Since we use
> > VOB for Video OBject this seems like the most logical spelling for
> > me.
> 
> I've had problems trying to figure that one out myself; your suggestion
> makes sense, but I'd be content with any (sane) official pronouncement
> so I could be sure in future of getting it right.

I think I'll settle for VOBsub then so we at least have a little
consistency.

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

> > * 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 :)

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.

> 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

> As to poorly-done text output - I'll keep my eyes open, and if I see
> anything I can with confidence improve upon, I'll point it out.
> Code-diving (or even just -searching) in search of these things will
> have to wait at least until my work schedule slows down, which will
> happen no later than November (but probably much earlier).

ok

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

Diego