[texworks] New script features (was: Help please with Integer constants and use in messageboxes)

[Paul A Norman]

Hi,

Just some quick thoughts -- "Kroll" down below in here, is possibly
timely, and quite worth mentioning  with some of what you are looking
at Stefan.  http://www.linuxjournal.com/article/10437

On 26 April 2010 12:21, Jonathan Kew <jfkthame at googlemail.com> wrote:
> On Sun, Apr 25, 2010 at 1:51 PM, Stefan Löffler <st.loeffler at gmail.com>
> wrote:
>>
>> Hi,
>>
>> Am 2010-04-25 11:24, schrieb Jonathan Kew:
>> > It's pretty neat that this works; however, I think we should expose a
>> > readFile() method to directly read the text of a file, rather than going
>> > through the "open document, get text, close document" sequence. That's
>> > pretty inefficient, and could become a significant overhead if you were
>> > loading a number of script libraries.
>> >
>>
>> I tend to disagree (partly). A general purpose readFile() is something
>> that may come in handy some times, but also can do a lot of harm.
>
> Could you explain a bit more about your concern here?
>
>>
>> In
>> particular, I'd prefer scripts to not use absolute paths as much as
>> possible.
>
> True, in general - although if the script is building the path by starting
> from things like its own path, or the path of the document it's working
> with, and modifying the file name/extension, etc, then the fact that it's an
> absolute path is not important.
>

Yep as described its absolute, but effectively absolutely unknown,
prior to script execution. :)

>>
>> In any case, it would probably be nice to have a runScript()
>> function that does what one would expect of it (i.e., as Paul suggested,
>> run a script identified by some name/label, rather than a TWScript
>> object we currently have no way of obtaining a handle to).
>
> Yes, that might be nice. Though it raises questions of context: does the new
> script execute in its own separate context, or can it be run within the
> current script's context (allowing sharing of globals, etc)? I suppose that
> could only work if the scripts are in the same language....
>

There is an interseting cross-platform,  cross-language, cross-compile
opensource project I've bneen following a bit that has devised a means
of running ruby, php, python, JavaScript and their own object system
together, quite facinating. You can actually mix language in scripts.

From: http://www.linuxjournal.com/article/10437 ...

"Kroll is the microkernel that powers Titanium and extends the
framework. This compact microkernel, written in C++, is a
cross-language, cross-platform “binding” and invocation framework that
enables mixing and matching code within the kernel. All the features
that Titanium exposes are accomplished via Kroll modules. By using
Kroll, Titanium gains the ability to support a multitude of languages
and technologies. And, because Kroll is fully extensible, anyone can
add more features to the platform, using any technology. You don't
need to be a C++ guru to extend Titanium. You can create new modules
using Python and Ruby, or even just plain-old JavaScript."

"Because Titanium is distributed under the open-source Apache Public
License v2, you can download the source code, play with it, fork it
and extend it. It's this extensibility that makes Titanium a platform
that developers can grow with in the future. The platform can morph
and evolve into different forms as new needs emerge. "

>>
>> To make a long story short, here's a list of things I'd like to see in
>> scripting (and for the most of them I even have an idea of how to code
>> them ;)):
>> 1) Give scripts a way to obtain a handle to their TWScript obj (the
>> pointer is in TWScriptAPI already, anyway)
>
> That's easy, I guess; what do you expect it to be used for?
>
I am also fascinated by this one, what have you got up your sleeve for
us here Stefan?

>>
>> 2) Provide a per-script list/hash of "globals", i.e. of QVariant
>> objects; this would give us the possibility to pass data between
>> successive invocations of the same script (need to think about data
>> lifetime here; possibly need to find a way to clone objects)
>
> How about also having an application-wide collection of such globals, so
> that it's possible for a group of related scripts to share data?
>

Introduce savable/persistent namespace objects that could be caled
from any script?

>>
>> 3) Add the possibility to call functions defined in a script from C++
>>

Would we need a standarised script format for such?

>> 4) Make it possible to connect C++ signals to script slots (it should
>> already be working for QtScript; for the others we need some tricks -
>> possibly create a dummy QtScript object to connect to which passes on
>> the signals to the real script)
>
> Yes; I presume this would allow non-modal script-created windows to do more
> interesting things in response to controls. (You can do a few things
> already, by connecting signals in the UI widgets to slots within the
> application. But that's very limited, as it doesn't allow the script to
> intervene and customize things.)
> I've been wondering if we should in some way allow scripts to be "attached"
> to the windows they create in this situation. But perhaps that's not
> necessary. If the script object is deleted/replaced while the connected
> widgets are still around, the connections will break, but no real harm
> should follow - the user would just have to close and re-instantiate the
> window to get it working again.
>

Sounds like wizards on the way :)

>>
>> 5) Introduce a new script type ("multi", "mixed", ... ideas welcome)
>> that defines only functions. There is one special function (e.g. init())
>> that gets called when the TWScript object is created. Its purpose is to
>> register menu items, toolbar items, hooks, ... (whatever comes to mind).
>> Each of them gets connected to a function provided by the script.
>
> ScriptType: library
> Defines functions for use as hooks, callback slots, whatever....
> No need for a magic init() function: the "main program" of the script is
> executed on load, and can do whatever setup is desired.
> Or maybe we should have both initialize() and terminate() functions; the
> latter provides an opportunity for the script library to do last-minute
> things before the app shuts down, such as saving its globals to a .ini file,
> to be read by initialize() next time it is loaded.
>

" saving its globals to a .ini file"  -- perhaps JSON if the scripts
need to read it, or would Tw handle this reinstantation (sp)?

Paul