Hey,
after tinkering with tm_dialog for a plugin[1] I have come to really wish you could embed an 'html output' webview into a NIB.
The idea being that instead of invoking 'returnArgument:your:arguments:' you could invoke 'htmlOutput:your_command:and:arguments:' and display the results directly in the dialog rather than outputting to an enclosing html view.
Note that I don't want to do async and then update the dialog with results (to go in a listview perhaps). The process I'm getting results from can take a long time to complete and can generate reams of information so I want to display the partial results as they come in.
Obviously you'd need to wire-up the WebView delegates to point to the File's Owner, as well as tell the File's Owner about the WebView and progress indicator etc etc.
I tried some cruel hacks by instantiating OakHTMLOutputManager in my nib and wiring it all together. Alas, I could only manage to evaluate a "TextMate.system" calling [[webview windowScriptObject] evaluateWebScript] via bindings. I also managed some other experiments to tell the OakHTMLOutputManager that it was busy (to update the progress control).
The only other behavior I cold elicit was some spectacular crashes trying to convince the OakHTMLOutputManager to invoke anything... yeah, I know I'm tinkering with stuff I shouldn't :-)
So... my question: is there any way in current TM to achieve my goal (embed html output in a dialog) - perhaps in DIALOG2 (that I haven't looked at yet)?
Assuming the answer is 'no' - I'd just like to say that capability could be an excellent bridge between the current tm_dialog+html_output and a full-blown plugin.
Thanks for listening, Trevor
[1] http://github.com/protocool/ack-tmbundle/tree/master
On 6 Jun 2008, at 00:29, Trevor Squires wrote:
after tinkering with tm_dialog for a plugin[1] I have come to really wish you could embed an 'html output' webview into a NIB. [...]
What functionality do you expect of such thing? The HTML output window is not much more than a WebView, no real API here. It is asked to load “tm-internal://«id»” which triggers a custom URL handler which is responsible for feeding the NSURLConnection with data from the command running.
So if I understand your goal correctly, you would probably be much more interested in this custom URL handler.
E.g. when you want to execute a search, you open whatever window you defined in your nib containing just an instance of a WebView, and you bind the URL of this WebView so that you can ask it to load something like: tm-run-command:///usr/bin/find?arg1=.&arg2=-name%3D*.rb/ (just making up URL scheme for illustrative purposes).
Hi Allan, thanks for responding.
My comments are inline below:
On 6/11/08, Allan Odgaard mailinglist@textmate.org wrote:
On 6 Jun 2008, at 00:29, Trevor Squires wrote:
after tinkering with tm_dialog for a plugin[1] I have come to really wish you could embed an 'html output' webview into a NIB. [...]
What functionality do you expect of such thing? The HTML output window is not much more than a WebView, no real API here. It is asked to load "tm-internal://«id»" which triggers a custom URL handler which is responsible for feeding the NSURLConnection with data from the command running.
There looks to be some other wiring in the html output nib file, setting up webview delegates, exposing 'TextMate' as a javascript object (I *think*), as well as connecting up the progress indicator etc. I've assumed that some of that is to ensure closing the window triggers sub-process termination.
My tiny mind can't see any way of *not* having those connections in place so I'm assuming they'd still be important. (more below)
So if I understand your goal correctly, you would probably be much more interested in this custom URL handler.
E.g. when you want to execute a search, you open whatever window you defined in your nib containing just an instance of a WebView, and you bind the URL of this WebView so that you can ask it to load something like: tm-run-command:///usr/bin/find?arg1=.&arg2=-name%3D*.rb/ (just making up URL scheme for illustrative purposes).
Yeah, on the surface that looks like the ticket except that WebView doesn't expose the MainFrameURL in a way that I can see to wire it up to the params controller.
At best you can tell a control to send takeStringURLFrom: to the WebView but that won't get sent if you just update the control's value via bindings.
And as you will be building the URL string based on input from the controls it means you'll have to return control to a script waiting on tm_dialog results so that the params can be updated with the new URL string. ... but the WebView won't respond to the params change.
So creating a tm-run-command URL handler would definitely be part of the solution but I think there's more to it. i.e. process management and some way to poke the webview into action based on a params change.
Regards, Trevor
-
Allan Odgaard -
Trevor Squires