Re: Re: About final cfg.h (config layer 0 discussion)

Hi,

> Sometime (on Sunday, May 25 at 15:18) I've received something...
> >> 2. Do you still have something to argue about CONF_TYPE_LIST option type?
> 
> >isn't my CONF_TYPE_SELECT the same?
> 
> no.
> CONF_TYPE_SELECT is to select _one_ option from list of available ones
> (for example, combobox). CONF_TYPE_LIST is box for selection, remove, and
> reorder options from list (box with two fields, for example - left is
> selected list, right is available options list). These are too different
> and CONF_TYPE_LIST may have items with different type (see my example
> earlier).

ah, now i see.
but why do we need such type? i can't imagine any use.

> >> 4. Let's change unsigned short type, version to unsigned short version,
> >>   type in module_info_t definition to have compatibility forever. :)
> 
> >no
> >i'm thinking about add type-specific versions
> >so if we change vf API we don't have to force demuxer, stream, vo etc plugin
> >authors/users to recompile their plugins just to get version number bumped.
> 
> Is there a difference between
> 
> unsigned short type, version;
> 
> and
> 
> unsigned short version, type;
> 
> anyway? This is anyway from this new API so I think it's easy. I'm
> thinkig about module loader only - putting unsigned short version as
> first member of struct will let us change that structure in the future
> and still have version check available.

but as i said, i want type dependant version, so version number without type
is useless.

> >>     Discussion about CONF_TYPE_GROUP isn't my concern right now since
> >> that option is application level only and it's marked as TODO anyway. :)
> 
> >actually i've added CONF_TYPE_MODULE which does the same as you expected
> >from CONF_TYPE_GROUP.
> 
> no. :)
> I've explained that by examples earlier - submenus in GUI aren't modules,
> are they? I'll try to explain a bit more - see the menu for video encoder
> GUI:
> 
>   File  Video  Audio  Tools  About
> +      ---------+
> | Open...       |
> | Save...       |
> |---------------|+----------+
> | Save stream...|  Audio... |
> | File info     |+ Video... |
> |---------------|| Text...  |
> | Quit          |+----------+
> +---------------+
> 
> You have menu group 'File' and subgroup in 'Save stream...' option in it.
> I've explained good now? :)

not
this example is not related to config layer at all.
such menus are built by gui and not by config stuff.

> Another example for using of CONF_TYPE_GROUP:
> 
> (*) constant quantizer [   ]
> ( ) variable quantizer ----------------------------
> minimum quant [  ]   maximum quant [  ]
> ...................
> ---------------------------------------------------
> 
> so we have CONF_TYPE_SELECT with two choises:
> 1) CONF_TYPE_GROUP including 'vqscale' integer.
> 2) CONG_TYPE_GROUP including 'vqmin', 'vqmax' and other options.
> 
> When we select constant quantizer then second group will be disabled,
> when we select second group then we cannot change value of 'vqscale'.
> Config of vf_lavc must have hints for that. Simplest way for it is just
> have "transparent" CONG_TYPE_GROUP type. Did you understand?

and how would you define the above situation with your types?
i can't see how you GROUP helps here.
also can't see what is the difference between yoru GROUP and my MODULE,
except the name.

> If we don't preserve that availability in config struct then GUI maker
> will have to create own config struct that will allow that by copying all
> from existing ve_lavc config but with changed a bit structure and then
> keep it up to date forever. It's too bad and we wanted to avoid that,
> aren't we?

of course

> BTW, this sample explaining why I wanted to have CONF_TYPE_SELECT as
> subconig type too - config_select_list_t doesn't allow us to have choises
> as CONG_TYPE_GROUP but these must be available for GUI. ;)

but it's a mess to allow different tyopes/pointers in each selection


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu