[SVN] Dialog2 API change

[Allan Odgaard]

I would like to change it so that all commands have argument parsing  
100% handled by the “framework” code (provided by Dialog2).

This means I want to change the window command’s sub command to an  
argument, so instead of:

    show/create «options» «nib path»
    update [-p «parameters»] «window token»
    wait/close «window token»

It will be:

    --show «nib path» [«options»]
    --create «nib path» [«options»]
    --update «window token» [-p «parameters»]
    --wait «window token»
    --close «window token»

Likewise the tooltip command which presently has -t/--transparent and - 
f/--format as options, and takes text/html from STDIN will be:

    --text «text» -t/--transparent
    --html «html» -t/--transparent

There might be a few other commands needing change.

The advantage should be consistency and less code in the various  
commands, also, I imagine with parsing 100% handled by the framework,  
we can introduce a declarative system for constraints as well so that  
constraints are handled by teh framework rather than let each command  
check if more than one mutually exclusive argument is used, etc.

One more change here, presently some commands read data or a property  
list from stdin, sometimes optionally. I want to standardize on always  
have stdin read, be interpreted as a property list where the keys  
correspond to command line arguments, with actual command line  
arguments augmenting what’s read from stdin.

So in case of tooltip, we now have 3 forms:

   1. "$DIALOG" tooltip --transparent --html "<h1>hello"
   2. "$DIALOG" tooltip               <<< '{ transparent; html =  
"<h1>hello"; }'
   3. "$DIALOG" tooltip --transparent <<< '{ html = "<h1>hello"; }'

I.e. in #1 we only use CLI arguments, #2 uses STDIN exclusively, and  
#3 mixes STDIN and CLI arguments.

One thing I am considering here is allowing ‘-’ to be given as an  
argument value, to indicate that the data parsed from STDIN should be  
used for teh value of this argument, but I am not sure if this is that  
useful (and by introducing it, we run into the problem of not being  
able to provide a literal dash as argument value).

Any comments?