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

[Paul A Norman]

Hi,

Here is a TeXworks script that does a prof of concept for the thread here.

Temporarily it points at a page on twscript.paulanorman.info

http://code.google.com/p/texworks/issues/detail?id=261#c74

I think that we need some sort of easier exposure to script of release and
version strings please. You'll see what I mean if you look at the TeXworks
script.
(I don;t think version is at all available as yet.)

Paul

On 16 January 2012 21:51, Paul A Norman <paul.a.norman at gmail.com> wrote:

>
>
> 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/20120117/681939d8/attachment.html>