[texworks] New version 302/303

[Alain Delmotte]

Hi!

Ok the new build 306 is available on my site.
But making a test: there is an error *both* with and without any 
information for the path in the typesetting preference.
I mean in 303, when there was something for the path, it worked, without 
not; now it's not working at all.
The error message says:
=================
The program "pdflatex" was not found.
Searched in directories:
Check configuration of the pdflatex tool and path settings in the 
Preference dialog.
=================
if the preference path is empty, the "Searched in directories:" is 
empty; if there is something, that folder is shown one line below with a 
bullet (ex. [bullet]C:/attente ).

Thinking about it: with 303 when for the path in preference 1) there was 
nothing - error, 2) with something the path was replaced. So a 
comparison was done to see if there is something; shouldn't it be just 
to replace what is (or not) in the rpreference by what is in 
texworks-setup.ini?
But of course that you probably already discovered (once you get into 
technical discussions, I am lost! :-(( )

Alain


Jonathan Kew a écrit :
> Thanks for all your investigation, Tomek....
>
> On 5 Jun 2009, at 17:34, T T wrote:
>
>> I've done some more forensic work on this issue. I've added to 
>> texworks.ini:
>>
>> binaryPaths=
>>
>> This shows in the preferences dialog as an empty slot. With this in
>> place everything works, i.e. my test call to 'cmd /c path' returns the
>> PATH with leading ';'. If I have:
>>
>> binaryPaths=,
>>
>> then I get two empty entries in the dialog and 'cmd /c path' returns
>> the PATH with two leading semicolons, and so on. Now, if I remove all
>> those empty slots from the preferences, then I get the following entry
>> in texworks.ini:
>>
>> binaryPaths=@Invalid()
>
> Curious, but I guess this is how Qt represents an empty stringlist in 
> the .ini file (to distinguish it from a list containing a single, 
> empty string, as in your first example).
>
>> With this in place the call to 'cmd /c path' (or any other tool) fails
>> with program not found. This means that, if binaryPaths is @Invalid(),
>> adding the PATH to it fails (at least on Windows). Here's the relevant
>> piece of code from TeXDocument::typeset():
>>
>>  QStringList binPaths = TWApp::instance()->getBinaryPaths();
>>  QStringList env = QProcess::systemEnvironment();
>>  QMutableStringListIterator envIter(env);
>>  while (envIter.hasNext()) {
>>          QString& envVar = envIter.next();
>>          if (envVar.startsWith("PATH=")) {
>>                  foreach (const QString& s,
>> envVar.mid(5).split(PATH_SEPARATOR, QString::SkipEmptyParts))
>>                  if (!binPaths.contains(s))
>>                          binPaths.append(s);
>>                  envVar = "PATH=" + binPaths.join(PATH_SEPARATOR);
>>                  break;
>>          }
>>  }
>>
>> If binaryPaths key exists in texworks.ini, then its content is
>> returned by TWApp::getBinaryPaths() but if it doesn't exist then the
>> result of TWApp::setDefaultPaths() is returned.
>
> Right.
>
>> Now the question is:
>> what TWApp::setDefaultPaths() returns if tex is not found on any of
>> the predefined paths?
>
> setDefaultPaths doesn't care whether tex (or anything else) is 
> actually present in the predefined paths; it just returns the list of 
> paths, it's the typeset() function that will look for tools.
>
>> If the return value is @Invalid() as for
>> binaryPaths, then we have the same problem.
>
> setDefaultPaths shouldn't ever be returning an empty list, though even 
> if it does, an empty list ought to be harmless.
>
>> Another wierd thing I've noticed is that, w/o binaryPaths in
>> texworks.ini and using e.g.
>> PATH=..;D:\Software\LocalApps\miktex27\miktex\bin;C:\Windows\system32,
>> my test call returns (rev.303):
>>
>> PATH=D:\Software\PortableApps\PortableApps\TeXworksPortable;..;D:\Software\LocalApps\miktex27\miktex\bin;C:\Windows\system32;..;D:\Software\LocalApps\miktex27\miktex\bin;C:\Windows\system32 
>>
>>
>> Note that the original PATH is repeated twice in the one passed to the
>> spawned process, which should not happen, because of the condition
>> (see above):
>>
>>     if (!binPaths.contains(s))  binPaths.append(s);
>>
>> So something is not right here.
>
> Rev 303 did not include that condition, it unconditionally added the 
> PATH in typeset(). This was revised in r.306. So this part, at least, 
> is not a mystery.
>
>> Unfortunately I don't know enough
>> about Qt to troubleshoot this any further but I hope I narrowed this
>> down sufficiently that someone can figure this out now. Jonathan, does
>> it make any sense to you?
>
> Not really! :(  When you have cleared all the paths from Preferences, 
> so that texworks.ini has binaryPaths=@Invalid(), what paths show up in 
> the Program Not Found alert? I guess you'll need a new build from 
> Alain to see the new version of that alert, which lists the final list 
> of paths.... I'm very curious to see what happens with that.
>
> JK
>
>