From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 23 Aug 2006 15:42:05 +1000

Hey all,
This idea came to me driving home from uni today and I think it may
work, but it will be pretty massive to implement, so I want to check
if it would be at least looked at if it did work.

Assuming the biggest objection to "option bloat" is compiled size then
this idea could possibly solve it.

Currently every menu item needs to be individually coded and they are
all about them same..
e.g
static bool show_path(void)
{
    static const struct opt_items names[3] = {
        { STR(LANG_OFF) },
        { STR(LANG_SHOW_PATH_CURRENT) },
        { STR(LANG_SHOW_PATH_FULL) },
    };

    return set_option(str(LANG_SHOW_PATH),
                      &global_settings.show_path_in_browser,
                      INT, names, 3, NULL);
}

In my opinion this is massive bloat, but currently there really is no
way around it.

My idea in a nutshell is have a text file (xml, or whatever) which is
converted to const arrays of some stuct (this detail needs to be
worked out) during the compilation by perl or whatever.
using the example above that item might look like this in the xml file

<setting name=LANG_SHOW_PATH type=INT>
    <opt0>LANG_OFF</opt0>
    <opt1>LANG_SHOW_PATH_CURRENT</opt1>
    <opt> .....
    <variable>show_path_in_browser</variable>
</setting>
the script would convert the optx values to the correct lang id so we
keep lang support, the variable would automatically get
&global_settings. prepended to it, and all that would get put into
some struct/array for later use by the revamped menu function.

This would work for all the settings that change the global_settings
variable and not worry about anything else. I dont think there are
many that use a temp variable, but either they can be changed to work
with this, or we can have something like <setting
name=LANG_COMPLEX_SETTING type=FUNCTION>function_to_run</setting> to
handle those cases (which would obviously need function_to_run
accessable to menu.c and probably be bool name(void) like the current
menu functions)

This big question is would this affect the compiled binary size? My
guess is yes, because even if you still have to have an array for each
menu item (same as now) you would lose the overhead of having an
individual function for every item (expect for some exceptions)

So
Cons:
- lots of work to do it.
- no way to tell what it will do to binary size untill its finished
- possib;y increase compile time because of the text->c script
Pros:
- remove code complexity (no more *_menu.c )
- much easier to add/remove settings/menus (just add it to the
global_settings sturct and the text file)
- much easier to rearrange the settings order (although this ideally
shouldnt need doing)
- increase runtime because the entire menu system would be one loop,
not heaps of function calls

So, Does this idea sound workable and do you like it?

Jonathan
Received on 2006-08-23