[texworks] We've reached r700+; please test

[Stefan Löffler]

Hi,

On 2010-12-04 08:09, Paul A Norman wrote:
> /Q_INVOKABLE
> int TWScriptAPI::writeFile(const QString& filename, const QString&
> content) const
>
> 1. Ok, so const QString& filename is a fully qualified path?
>
> Through Qt internals, does the path default to anything if no path is given?

Duh, I don't know how I could have overlooked this - thanks for noticing
and reporting.
Starting from r703, relative paths are taken to be relative to the
folder containing the calling script's file. So if you have a script
file <resources>/scripts/test/abc.js, a call to TW.writeFile("xyz.log",
...) will create a file <resources>/scripts/test/xyz.log

Before, Qt would internally take the current working directory. In my
brief tests this seemed to default to the script file's folder, but if
this holds in general I don't know.

> Stefan, you mentioned that const QString& content is going to write as UTF-8
>
>   umBytes = fout.write(content.toUtf8());
>
> 2. If  QString& content is only ascii will that as expected only
> render as Ascii in that utf-8 doesn't kick in unil after ascii 127(?)
> - is that right? Ascii to 128 will still be saved as a single octet?
> Qt doesn't do anything unexpected here?

Yeah, ASCII should not change at all. As for anything beyond ASCII, it
depends on how the strings are constructed. Internally, Qt uses some
unicode encoding (don't ask me which exactly). So when constructing
strings, you have to be careful to make Qt convert the encoding in which
your string is given into its internal encoding. For QtScript files, I'd
expect this to work out-of-the-box, though, since all strings are stored
as QString objects (e.g., for python, however, there is a distinction
between "normal" strings and unicode strings at least in some version).

> 3. And the int returned on success/failure, is there some hint as to
> cause of failure available?
>
> Looks at moment like just   SystemAccess_Failed    or
> SystemAccess_OK  -  is that right?

Yes, and no. There are three return values:
        SystemAccess_OK = 0,
        SystemAccess_Failed = 1,
        SystemAccess_PermissionDenied = 2
PermissionDenied is returned when writing is disabled. If it is enabled,
though, and writing fails, there is no further distinction (e.g.,
whether you are trying to write to a folder that doesn't exist, or to a
file that is protected by some system's permissions, etc.).

> For text files returnFileContents() will be really really helpful :)

Yes, yes, this is planned and in the making ;).

Cheers,
Stefan