[MPlayer-dev-eng] [PATCH-RFC] Removing the GET commands

Alban Bedel albeu at free.fr
Mon Jul 16 10:31:37 CEST 2007


On Mon, 16 Jul 2007 08:50:05 +0200
Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:

> Hello,
> On Mon, Jul 16, 2007 at 03:23:37AM +0200, Diego Biurrun wrote:
> > On Sun, Jul 15, 2007 at 12:43:07PM +0200, Alban Bedel wrote:
> > > 
> > > all the GET commands now have equivalent properties since
> > > sometimes, so we might start considering dropping the old
> > > commands. For ppl who just use plain mplayer it's probably not
> > > going to change much, however it will probably break quiet some
> > > frontends.
> 
> Do they do exactly the same thing with exactly the same output or only
> something similar?

For most stuff the output is strictly identical if the property name is
given in caps. However a couple properties will give a different ANS
name, as consistently naming the properties seemed more important
(ANS_VO_FULLSCREEN -> ANS_FULLSCREEN). And quering properties won't put
single quotes around the result like the metadata commands currently do.
But as they don't escape single quotes in their input, thus making the
outer quotes useless, I don't see that as a real problem.

So yes, there is a few differences, but imho they are minor enouth that
it won't be a big deal for properly maintained frontends.

> > > It would also be possible to use the cmd<->property bridge to
> > > support the GET commands while still getting rid of quiet some
> > > code. However I don't know if it is really worth it.
> > > 
> > > So what are you thinking, should we drop them right away, or
> > > still keep them for some time?
> > 
> > I think you missed the documentation update.
> 
> Yes, and every removed command absolutely should reference the command
> that it was replaced by.

Sure the final patch will take care of the docs. But this one is just
an RFC. It would be stupid to waste my time on the docs if most ppl
turn out to be against the change.

	Albeu




More information about the MPlayer-dev-eng mailing list