[TxMt Plugins] Dialog API improvements

[Joachim Mårtensson]

I prefer having the following interface

tm_dialog <option> --flag1
--flag2=/usr/bin/no/spaces/between/path/equal/and/flag

possibly with the special case

tm_dialog help <option>

which could be written as the not so special

tm_dialog <option> --help

the above has the benefit of not require a more involved parser.  I think
we should wait with the show and create keywords until there are enough
commands to warrant wandering of the 'tm_dialog <option> <--flag> path. I
do not think that the normal usage pattern of tm_dialog requires anything
more involved, I would guess that people write a command once and stores
it in a {rb,py}. Calling it by hand from the Command Line is probably a
very uncommon behavior (except when debugging). What I am trying to say is
that while more involved schemas look cool they are more complicated to
write and in the end there will be very few cheering for our insane coding
skills anyway.

here is some data-structures I wrote for an overhaul of the system
yesterday. I made the decision to not support tm_dialog show-dialog
nibFile.nib but instead enforce tm_dialog show-dialog --file=nibFile.nib

struct subCommand {
    const char *commandName;
    void (*func)(std::map<std::string,std::string> strings,
    	std::map<std::string,bool> bools, int argc,  char * argv[]);
    const char* options[10];
    const char* mandatory[10];
};

static struct subCommand commands[] = {
/* name , call_funtion, optional flags, mandatory flags */
    {"create-alert", create_alert, {"parameters="}
    ,0},
    {"create-window",create_window,{"parameters=","center","defaults=","modal","quiet"},{"file="}},
    {"create-extended-popup",create_extended_popup,{"parameters="},0},
    {"create-menu",create_menu, {"parameters="},0},
    {"create-async-window",create_async_window,
        {"parameters=","center","defaults=","new-items="},{"file="}},
    {"close-window",close_window,
    {0},
    {"token="}},
    {"update-window",update_window,{0},{"token="}},
    {"wait-for-input",wait_for_input,{0},{"token="}},
    {"list-windows",list_window,{0},0}};
flags ending with = takes an argument.

I guess I could switch from stdlib types to cocoa ones, the struct
converted to some plist thing, perhaps the classes could conform to some
protocol so that they could supply which optional and mandatory flags they
support. and then a generic parser could be used if someone wanted that?

Joachim Mårtensson