[texworks] SCRIPTING: global __FILE__ now only available when debugger on?

[Paul A Norman]

On 16 January 2012 19:42, Stefan Löffler <st.loeffler at gmail.com> wrote:

> Hi,
>
> On 2012-01-12 07:43, Paul A Norman wrote:
> > These new properties on TW.script  have made  something worthwhile
> > possible for checking for updates on scripts... in fact
> > "TW.script.date" may even be worthwhile?
>
> Yes, it may be worthwhile, but not too easy to implement. Which is why
> we have TW.script.version. If one uses, e.g., a "MM.NN.PPPP" format, the
> PPPP part can be incremented by one each time a new script is made
> available publicly (or any time a change is made, or whatever) - call it
> "revision number" if you want (or use a version control system to track
> your script files).
>
> To elaborate on the (potential) problems with a date field:
> For one thing, if it's a date, it should be stored internally in a
> QDateTime variable. This could cause problems with accessing it from
> scripts (though I haven't checked). What's more, people from different
> parts of the world specify dates differently (e.g., MM-DD-YYYY vs.
> DD-MM-YYYY). And different time zones etc. would have to be taken into
> account. Besides, if anyone ever would make several changes in one day
> (e.g., a new feature in the morning, and a bug fix in the evening), we'd
> have to include the time in that field as well. So the field would get
> quite long and for most (casual) script authors quite tedious to fill
> out / update.
>
> So, bottom line, for the moment I think a (well maintained) version
> field should provide enough information for all use cases I see right
> now. If I overlooked something, please let me know (as always, of course
> ;)).
>

Thanks Stefan, I agree entirely, I only saw it as descriptive for
additional visual comparison purposes (and upto the Script Author
what they were showing in there - not as a programmable piece of data) and
as you point out, we can entirely rely on the Version field.

Interestingly, due to the international nature of the TeXworks project, in
the TeXworks Script Api, in the descriptive text  I am actually frequently
adding superscripted th nd and rd to YYYY-??-?? dates to make it very clear
what form they are in, and what they mean.

>
> That said, I really liked your write-up! Maybe it would be beneficial
> for some users if you could add (simple) sample JS/php scripts.


Can you add an extra TeXworks sub page to the existing TUG TeXworks page on
TUG?

I had been thinking to actually do a simple page for there (with JavaScript
in it as you previously had shared that php is not available) that a Script
could call, which would show the User what their:

   1. current version +rev was,
   2. their release (TeXworks direct or say MikTeX - I think that is
   exposed to scripting?),
   3. what the current Official TeXworks release ver + rev was ( with link
   to downlaod page ),
   4. and what the latest Development version and rev was (with link to
   downlaod page).

Thought that might be an immediately useful example - what do you think?

It would require maintaining a simple external text data file along with
the new .html page on TUG.

Paul


> While
> such scripts may be obvious for a script-savvy web-programmer, they may
> be complicated to figure out for casual Tw script authors without much
> experience in web programming.
>
> HTH
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20120116/07bcbe2e/attachment.html>