[SVN] RFC: async window support for tm_dialog

[Allan Odgaard]

On 28. Nov 2006, at 03:03, Chris Thomas wrote:

> This patch extends the dialog server with (partial) support for  
> allowing scripts to interact more directly with nibs. You can  
> instantiate a nib without blocking, and later update the binding  
> values.
>
> Three new options to tm_dialog:
>
>  -a, --async-window           Displays the window and returns a  
> reference token for it
>                               in the output property list.
>  -x, --close-winow <token>    Close and release an async window.
>  -t, --update-window <token>  Update an async window with new  
> parameter values.
>                               Use the --parameters argument (or  
> stdin) to specify the
>                               updated parameters.
>
> • This is sufficient for implementing progress dialogs and other  
> 'broadcast' information. For two-way usage, there is no way to  
> actually retrieve the parameter values from an async window. You  
> would generally want to retrieve parameter values on a user action,  
> and there isn't a way to perform a callback yet. Perhaps export a  
> new IBAction from the File Owner that dumps the parameters to stdout?

Exporting a new action sounds like the way to go. Though using a  
scheme similar to the returnArguments:«with variable arguments» --  
this turned out to be far more useful than the performButtonClick: I  
first did.

But when we open an async. window, where exactly is stdout?

I think for this to work, tm_dialog still needs to stall, but first  
write out the window token (on stdout), and then optionally the  
arguments to the exported method.

So we end up (in the using script) launching tm_dialog in a  
subprocess and do select() on its output pipe, to see if there is  
data -- but since “packets” are sent, we also have the job of  
determining boundaries (i.e. when have we read enough to parse it as  
a plist and pass that on).

> • There's a possibility that windows not attached to a process  
> could be orphaned, which would require users to kill the window on  
> the command line (if the window doesn't have a close box). If a  
> script is handling errors properly, this shouldn't be a problem.  
> You can already get into this situation now with CocoaDialog and  
> suchlike, but the remedy is slightly different in that you will  
> need to use tm_dialog to kill the window rather than killing an  
> external process.

We could maybe add a --list which lists ‘active’ tokens. I am sure  
the need to kill a window while debugging will come up ;)

> Comments? Code review? Break anything?

Looks good, I am a little vary about the complexity of having it pass  
back arguments, i.e. what I outline above -- but the ability is  
probably too good to give up just to avoid a bit of complexity, just  
let’s make sure we do find the simplest way to have tm_dialog return  
stuff.

As for the code: You would make me really happy if the style (i.e.  
wrt spacing and indent) would follow the rest of the source :) I try  
to do the same for you when I patch CommitWindow etc. ;)