[MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request.

[D Richard Felker III]

On Wed, May 14, 2003 at 10:36:39AM +0300, Andriy N. Gritsenko wrote:
> >> 2) For initializing a chain, the config system can just take in the
> >>    string, and return a chain of config structures. The player then
> >>    proceeds to load and initialize the filters along with the codecs.
> 
> >1000% aggree
> 
>     Ok. I'll try to explain you with an example. You have a Gui encoder.
> You didn't started encoding yet. You opened dialog box for filters. Are
> you surprised with that? Do you still think if Gui may only have string
> input for the filters? If you think so then Gui is just graphic command
> line for you and users will call us hellmakers.
>     So we are in that dialog box. It consists of two panels: on left we
> have created filters chain, on the right we have full filters list. What
> I want (I'm there an user)? I want take a filter in the right pane then
> drag it in selected place in the left (not only to end of list but in the
> some place there), drop, and after that doubleclick on it to configure.
> Any other behavior isn't understandable for me.
>     So our concept _must_ allow that. We _must_ allow get a command from
> UI to insert or delete filter in the any place then return to UI but
> don't start encoding yet. Do you understand me?

This has absolutely NOTHING to do with the config layer. It's
something for the gui app to implement, based on the available
functions in the mplayer lib(s) to list available filters and get
configurable properties for them. This last step -- getting the
configurable properties -- is the only thing remotely related to the
config system, and even then it's only minimally related, for
exporting the C variables for the filter config in such a way that the
gui knows how to make text boxes, appropriately ranged sliders, etc.

> >> 4) With that in mind, I think it might make more sense for the config
> >>    system not to handle filters at all during the initial parsing
> >>    phase, but just store filter chain strings provided from the
> >>    command line or whatever. Then, when we get to the relevant file in
> >>    the playtree, the player can split up the filter chain/tree, load
> >>    the appropriate filters and connect them, then call the config code
> >>    *again* with the config strings it has for each filter to
> >>    initialize them.
> 
> >this is what i want, and described in a long mail sent 3 mins ago.
> 
>     If we talking about command line interface only then this is ok. For
> UI it's bad - why user have to close dialog box to let player create all
> chain then open it again to configure filters? It's hell for the user. Do
> you want to deny Gui at all or you think Gui isn't like a parser?

Gui can work perfectly fine with what I described. It just needs to be
clueful about stuff.

The goal of mplayer g2 is NOT to have idiots writing guis that just
make a few calls to your config code and suddenly have "my own movie
player". The frontend needs to communicate with all parts of the
backend, not just the config system, and as long as it does that,
everything will be fine!

> >> 5) Perhaps you'll also consider this part of the config code, but it's
> >>    very different from the main options parser, IMO: There needs to be
> >>    code somewhere to allow interactive editing of the filter tree, so
> 
> >it's planned via control()
> 
>     How you plan to use that control() if you disallow UI/parser to know
> that control() exists?

OK, since you seem particularly dense tonight, let me spell it out.

Suppose your movie is running, with some filter chain, and the user
decides to change some filter's options in the gui-toy-thingie.

The player has pointers to the elements of the filter chain, since it
built the filter chain! So what does it do? It queries the filter
(with control(), or something new, whatever) to get the current
options exported to it in a structure. Then it displays a panel to let
the user modify the options. Then when the user hits apply (or
immediately, if desired), the player makes another call to the filter
telling it to update one or more options. Nice and simple.

Adding and removing of course has nothing whatsoever to do with the
config system.

> >but i guess stream path merging/splitting and graphedit cannot be expected
> >before g3. first we should cleanup g1 (actually reproduce some parts, port
> >the rest) to have something we can play (and not suck) with.
> 
> OOPS... we plan to deny API for UI before g3? It's too sad, we can die
> before that and don't see API for UI... :(((  All we need is to create an
> API function to pass these insert/delete commands to vf or af engine. Is
> that too hard? Only one function will solve all problems so UI can do
> callback without exiting.

Huh? What are we talking about now, with callbacks???

Rich