[texworks] Scripting + Updates (was: HELP: Integrated Tw LaTeX2e Help dialogue)

[Stefan Löffler]

Hi again,

Am 2010-07-04 15:03, schrieb Paul A Norman:
> I had assumed that a single string would cast to a single array
> element, I am still learning what Scripting will cast automatically
> and what is required implicitly.
>   

I don't know exactly what is cast to what, either, it was just a short
in the dark after reading that it's a QStringList ;). And in the end,
the documentation confirmed my speculation about casting lists.

> Yes that .ui xml .replace() will save us a few times in the futureI think.
>   

This makes me wonder: I'm currently in contact with Alain about updating
his manual. But we should eventually also create a scripting manual
(Jonathan started on the wiki, but that's pretty hopelessly out of date
by now, and I think we have more than we can reasonably put on the wiki.
Would you be willing to help with this? Especially a "Tips & Tricks"
section would be nice, and you have the most experience with this, I think.

> Re versions, what i am looking at here, is that some things are in 4.6
> but not 4.3, so should I limit myself to 4.3?  Or take it that
> eventually everyone with scripting dialogues will be on at least 4.6
> anyway?
>
> I was confused becasue I had it in the back of my mind that we were on
> or sticiking to 4.3, but in Scripting I was discovering some features
> that were from 4.6 that worked but others that didn't, and before you
> ask I can not remember which :)
>
> So in code for one thing I wrote `works, but not documented in 4.3'
> remmed it out and didnlt use it.
>   

Yes, everything should (ideally) work on Qt 4.3, because there are some
people out there who still use it. But many have moved on to Qt 4.6, for
example.

Unfortunately, Qt doesn't always stick to backwards compatibility: some
things are added, some are removed, some are changed. In general, most
stuff works pretty well. But of course if you're doing large-scale
dialogs for complete integrated help, you're bound to exploit everything
to the limit ;).
The bottom line is: the "accepted" version of Qt is 4.3 or later. I know
that this doesn't help you much, but we can't limit ourselves to one
particular version, as the range extends from conservative people using
Ubuntu 8.04LTS with the bundled Qt 4.3 to "crazy" developers living on
the bleeding edge of Qt 4.7beta2 (I think).

>> Maybe we should also expose a function similar to TW.platform() that
>> provides information about the Qt version available (i.e., min(Qt build
>> version, Qt runtime version))?
>>     
> You are ahead of me there, I was thinking that I should just code to
> an accepted Qt version, but maybe conditional coding may prove
> necessary.
>   

This will ultimately be the best practical solution, I suppose (it's
already used in the C++ source in some places). Whether you try to work
around all changes by conditional coding, omit some features for old
versions, or just present a message box saying "this script won't work
with your version of Qt" is up to you, of course. But in any case, the
script shouldn't fail silently (or with an error message about undefined
references or something), as that would utterly confuse most users, I guess.

> There will be so many people getting Tw through the MikTeX release, it
> would be good to have an automatic updater perhaps?
>   

AFAIK, updating in MiKTeX should be handled by the MiKTeX updater
automatically.
But you're right, of course. However, there's still the unsolved problem
of how to update the resource folder (templates, code completion, etc.)
without having the user to remove the whole thing. So I guess such a
feature won't land very soon (not before the release, anyway).
In addition, stable releases don't happen that often. The current one
has been around for about a year now. The situation is different for the
experimental versions, of course, but this was intended for use with
version control by people who build Tw themselves. This has changed a
bit, of course...

> Can CTAN or TUG help with a permananet site for stable releases, and
> an option for update to development releases?
>   

I think we discussed this briefly with Jonathan and Karl (Berry) some
while back. In principle, yes, but... ;). First of all, we'd probably
need builds for many different platforms, OSs, etc (the Linux universe
is nearly endless ;)). And secondly, this still doesn't solve the "how
to actually perform the update" problem.
But essentially, we have something like that, anyway, as Tw releases
seem to be timed with TL releases ;). So binaries should be available
from some TL mirror servers, but don't ask me how, exactly.

HTH
Stefan