[TxMt Plugins] Dialog API improvements

[Allan Odgaard]

There have recently been a few patches to the Dialog plug-in that I  
have yet to role in.

Mainly because the current architecture does not scale well with new  
functionality.

We have spoken a bit about it on IRC, but since not all contributors  
are on IRC, I am moving the discussion to this list.

The restructuring I am envisioning is to move to a command based  
system so that the basic syntax is:

     tm_dialog «command» [«options»]

Additionally there will be:

     tm_dialog help «command»

And just tm_dialog to get a list of commands.

Each command will be responsible for a certain function. Presently we  
have these things (including pending patches):

     Synchronous nib loading
     Asynchronous nib loading
     Pop-up menu
     Type-to-narrow pop-up list
     File dialog (open/save)
     System dialog (color/font)
     HTML tool tips

In my mind, each should be a fully self-contained file providing that  
functionality. From an architectural POV I imagine that tm_dialog will  
basically connect to the Dialog plug-in using distributed-objects (as  
now) and send it:

     1. The full command line (i.e. with arguments)
     2. File handles for tm_dialog’s stdin, stdout, and stderr

Basically all work will then be done in the Dialog plug-in. Which will  
conceptually do:

     1. Check what command the command line arguments contain
     2. Lookup a class/object to handle that command in a dictionary
     3. Pass on the info to that class/object (if found).

So the main thing that needs to be worked out is a super class for the  
commands to subclass. This has two jobs:

     1. Provide a method for the subclass to register a command  
(called e.g. in +load)
     2. Provide an interface for the method that is called when the  
command should go into action

All in all that should be quite simple. Though we probably want a bit  
of sugar, such as converting the arguments to an NSDictionary (rather  
than have each command use getopt_long etc.) and maybe a few other  
things.

A minor concern is how a command can signal tm_dialog to wait for a  
semaphore, as is presently required by the nib-loading command (when  
given e.g. the -w option)

A bigger concern is what to do with backwards compatibility. Maybe it  
would be possible to let $DIALOG point at a script that rewrites the  
arguments, and then introduce a new variable for the new tm_dialog  
command.