[MPlayer-dev-eng] [PATCH] support run command with specific osd_level

[Ulion]

2008/2/1, Ulion <ulion2002 at gmail.com>:
> 2008/2/1, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > Hello,
> > On Fri, Feb 01, 2008 at 12:42:53AM +0800, Ulion wrote:
> > > 2008/1/31, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > > Well, is the fact that it is something unrelated not a good reason not
> > > > to do half of the patch now and the other half later?
> > > > Especially since this code will almost certainly not stay like this when
> > > > you do the other patch, since I certainly would object to a patch that
> > > > duplicates the
> > > > >   while (str[0] == ' ' || str[0] == '\t')
> > > > >      ++str;
> > > > or equivalent 5 times (a guesstimate of how often this would be needed).
> > >
> > > ok, here's the code you want, check it.
> > > also moved the force_osd_level and force_seek_osd_level into mpctx as
> > > Uoti's request.
> >
> > I finally have been able to understand what your patch does, it did not
> > quite fit with what I imagined it would do.
>
> not exactly.
>
> > I imagined that it would just change the verbosity of osd messages for
> > the displayed command, but it seems that instead you tried to make it
> > behave mostly the same as setting the osd level, then executing the
> > command and the restoring the osd level, with some additional special
> > behaviour hacks for seeking (enabling the time display OSD that normally
> > has little to do with seeking).
> > What I mean to say, it seems to be coded specifically to one special
> > purpose.
> > You know how much I dislike that, thus I want to propose attached patch,
> > to compare behaviour and discuss how we can get something that is
> > acceptable for everyone with as few hacks as possible.
> > I think that the input.c and command.c (excluding the seek_osd_level
> > part) parts to be without problems, do you think it is okay to apply
> > these right away?
>
> An osd msg currently will be put into osd stack, and if it match the
> osd_level when update_osd_msgs get called, it will be choose and
> displayed. Normally an osd msg will keep in the osd stack for 5
> seconds.
> Check these lines of my patch:
>
> +    // Force to disable osd msgs.
> +    if (mpctx->force_osd_level == 0)
> +        return;
> +    // Force to display osd msgs matching the force_osd_level.
> +    if (mpctx->force_osd_level > 0 && level <= mpctx->force_osd_level)
> +        level = 0;
>
> This is expected behavior, but your patch missed it.
> osd msgs generated by an 'osd_level 0' prefix, should never get
> displayed even after the command the osd_level is restored to max 3
> immediately. Simply change the runtime osd_level to zero won't do that
> for us.
> And also, osd msgs generated by an 'osd_level N' prefix with the msg
> level lower or equals to N should keep be displayed for a while even
> after run the command the osd_level is restored to 0 immediately.
>
> Then your patch is suit here. If there's no other objection, I will
> commit my patch later of today.

Sorry, miss typo, I mean 'your patch is not suit here'


-- 
Ulion