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. ;)
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev
