[MPlayer-users] playlist file syntax

[Reimar =?UTF8?Q?D=F6ffinger?=]

Hi,

First of all, sorry for confusing people,I didn't pay enough attention to the names :-(.

> > > >Where comes the point to point out that you didn't answer the question
> > > >what the feature you offer is. At least I didn't see it, only a proposal
> > > >of a different playlist format.
> > > >And by defending the current format is a way to make sure a new one isn't
> > > >just a different piece of crap, but something really better. I guess we've
> > > >had
> > > >enough of that "let's replace that bug with another one" :-(.
> > >
> > > I do agree with not changing things for the sake of it, however I
> > > haven't yet seen what I would call a good reason for keeping the
> >
> > Which was my point: You are asking for a good reason to keep the current
> > format, whereas I (and probably some others) have not yet seen the reason for
> > a new format. This seems the wrong order to me.
> 
> Because the current format uses every available character other than linefeed as
> a part of the filename, there is no room for any kind of extension. If every
> suggestion will be refused if it breaks the current format then mplayer
> playlists can never improve. I was questioning this reasoning, not suggesting a
> new format. (The original suggestion was not mine.)

It usually (always?) can be done without breaking old behaviour by adding options. I added OSD and aspect scaling to the gl vo, but you can still make
it behave exactly as before...

> > > >>I am having this rant because I've seen a lot of derogatory comments made
> > > >>to
> > > >>people asking innocent and often valid questions on this list. It is
> > > >>foolish
> > > >
> > > >Some people might see it as derogatory that you decide what is innocent
> > > >or valid...
> > >
> > > I don't see your point. I see comments that appear to me to be innocent
> >
> > that "appear to me" is what was missing in your first post IMHO.
> 
> I think I am capable of having a reasonable opinion of what is innocent and / or
> valid. People might not always agree with me, I don't expect them to. If I

Well, my personal opinion is that opinions on such things can't be reasonable, but well ;-)

> believe something is valid then I will say it is valid, just as I will say
> grass is green, rather than grass appears to me to be green. Fortunately most
> people don't take offense to this level of brevity; else the english language
> would be even more verbose than it already is.

Normally yes. But in some cases it is a good idea to add that verbosity.

> > > and valid, and people get flamed for writing them, like they are "lower"
> > > beings than the "developers". That's out of order. I know it can get a
> > > little bit frustrating when someone hasn't read and understood the right
> > > section of the manual, but in that case the right thing to do is either
> > > help them or shut up. I no way is it the right thing to be hostile, and
> > > I've seen that on this list recently. I am not going to cite examples
> > > because I don't want this to become personal.
> >
> > I can understand that, but I'm not sure if people would prefer being ignored
> > - something I personally find worse...
> 
> I guess not wanting to choose between being ignored or being flamed is one
> reason I haven't posted any patches yet.

I don't think a patch will get you treated any worse as these mails ;-)
Especially as we are getting off-topic...

> > > >>for the core mplayer team to believe that everyone else is incapable of
> > > >>coming
> > > >>up with useful ideas and writing good code for them. If it is made too
> > > >>hard for
> > > >>people to submit patches that are accepted, then mplayer development will
> > > >>simply
> > > >>fork.
> > > >
> > > >I fail to see a fork as a threat.
> > > >Anyway, quite a few people are active a few months
> > > >and then aren't reachable by email forever, meaning that we are stuck with
> > > >maintaining their patches. I have little motivation for applying a
> > > >patch when I think that it will be a pain in the a** to maintain it, no
> > > >matter how well it may work at the moment.
> > >
> > > If a fork occurred and several people decided they were interested in
> > > improving the "other" version, then these people are a resource you have
> > > lost access to. It won't make the original mplayer any worse, but it
> > > won't help it improve either.
> >
> > Yes, but if they are good they will try other aproaches and make some things
> > better (but I'm certain that there will be lots of things we will do
> > better ;-) ). And if they aren't good it won't exist for long.
> 
> If they are good then they will develop features or fix bugs that you would wish
> you had the resources to have done. As the forked code progresses it becomes
> harder to integrate changes from the "other" version.

If they are that good that won't be neccessary for too long because then the "original" will probably disappear.

> > > A patch that will be difficult to maintain is not usually the best way
> > > of solving the problem the patch was written for. However, quite a lot
> > > of the mplayer code has clearly evolved much since it was originally
> > > architected, and this alone can make for difficult maintenance.
> >
> > It does for sure! We are quite busy with fixing old bugs and bugs that show
> > up because other bugs were fixed etc. That was one of the reasons why G2
> > was started afaik. And it also is another reason for being reluctant to
> > accept patches unless they are really convincing, we sure have more than
> > enough bugs and ugly code.
> 
> Sounds like you need some more maintainers to share the workload. I know too
> many can lead to communication problems though. How many are there at the
> moment?

I agree we need more. See DOCS/tech/MAINTAINERS...

Greetings,
Reimar Döffinger