[texworks] Scripting: import libraries, retrieving saving text. web location, Api

[Stefan Löffler]

Hi,

I finally got to take a look over what you've put online so far. It's
really amazing! This definitely has the potential to become a great
source of information for script authors.

A few things I noted so far (these are mainly personal opinions, feel
free to ignore ;)):
 * The correct spelling is "TeXworks", you seem to be mixing some
spellings (TexWorks, TeXWorks, ...)
 * I'm personally not a big fan of the typesetting in the pdf (mainly
the spacing/kerning seems odd), but I'm probably spoiled by TeX ;)
 * I'd remove the "System requirements" in "Getting Started". They are
of interest only for compiling Tw, which is beyond the scope of the
manual. As far as scripting is concerned, the "system requirement" is to
have Tw (and possibly plugins) installed

Am 2010-11-08 12:17, schrieb Paul A Norman:
> Got a bit more done on the TW.target hierarchy.
>
> Stefan, I'll be able to pass you the source for all that once its
> useful - even as an Open Office document or LaTeX from there, but if
> you're not using MS Windows, the actual help generator may run under
> WINE but would require a couple of things if it would work there at
> all. If you still have access to Windows I can give you the .hnd file
> for HelpNdoc, that will all end up on the web with the 'finished' help
> any way.
>
> Any one with any Scripting Api or related notes, even if rough, please
> throw them at me.
>
> I'll do my best looking through the .cpp(s) but I am not a native C++ developer.

If you want, I can certainly give you a hand here (e.g., writing (some
of) the function documentation) if you send me the relevant sources and
tell me what conventions to follow. (and if I find the time ;)).

BTW: Two things I'd like to put up for discussion:
* Whether to use things like QWidget* or QString in the function
documentation. It exposes script authors to the underlying internal
implementation, which should not be necessary and is probably
contra-productive (at least for new scripters). Maybe call them just
"window", "string", etc. or something? Or does this require more effort
(e.g. in telling people what we mean) than it does good? (Also note that
ideally, this documentation should be implementation-independent, i.e.
be useful for Python/lua as well)
* What to do with functions that are not intended (or useful) for
scripting? Should these be included in the documentation (marked
"internal", for example)? Or just omitted to make things cleaner and easier?

Cheers,
Stefan