[texworks] SCRIPT Prototype: A work in progress - LaTeX xcolor colour names dialogue

[Stefan Löffler]

Hi,

Am 2010-05-28 01:14, schrieb Paul A Norman:
> I have been involved in seeing php used as a scripting language to
> Delphi projects. There quite often more generic top level  objects are
> exposed to script, that enabled script to do virtually anything that
> the host programme can do. I realise there may be real security fears,
> but defining a safe and  a stable approach to this might enable things
> to happen more easily.
>   

We may of course be able to provide php as additional scripting language
(if it provides all the interfaces we need), but this wouldn't change
the issue at hand. What is exposed and what isn't is not a question of
the scripting language - this is done in a central point in the C++ code
that all scripting instances share. The only thing that changes between
different scripting languages is _how_ data needs to be converted, _how_
functions are called, etc. But _what_ is available is always the same.

> For example if such a thing were done, could script create new
> widgets/forms etc on the fly?
> In the example I just quoted that was possible, as generic functions
> were prepared and made available to script, and some of the exposed
> objects in the executable provided those resources any way.
>   

Creating new widgets directly is not quite trivial, as they don't tie in
too well into the framework we use for exposing objects to scripts, AFAIK.
You should be able to create new widgets with the Ui loader, though. In
the worst case you'd have to create them in a dummy wrapper dialog. So
in that case, we'd only need to provide a way to reparent those widgets
so you can effectively "cut them out" of the dummy and "paste" them
wherever you want. Note that this doesn't change the situation for
predefined top-level dialogs (such as the color dialog) as they can't be
wrapped in a dummy - so for them we'd still need the functions mentioned
below.

Cheers,
Stefan