Re: [Patch] Windows process creation

[Enrico Forestieri]

On Fri, Jun 18, 2010 at 08:41:31PM -0400, Joost Verburg wrote:

 On 6/18/2010 2:00 PM, Peter Kuemmel wrote:
 Wouldn't be the cleanest solution to use QProcess also for ForkedCalls?
 (Enrico, I hear you scream ;)
 
 Yes, the Systemcall code in LyX doesn't create any console windows
 because QProcess internally sets the CREATE_NO_WINDOW flag. I'm just
 doing the same in the other code that's not using QProcess yet.
 
 I'm not sure why there are so many different methods (Systemcall /
 ForkedCalls / runCommand). If you want to integrate this more that
 would be a good thing.

Maybe because they serve different purposes? I don't think that
changing something without having a clear understanding of why it
is as it is and only because it seems cool using QProcess, is the
way to go. Remember the mantra: if it ain't broke, don't fix it.

 So shall I go ahead and commit this patch? It's the last part that
 is needed for the new method to create Windows binaries with CMake.
 All the new/updated dependencies are already packaged and ready to
 use: ftp://ftp.devel.lyx.org/pub/contrib/windows/bin/

I hope you are aware that there is code assuming that LyX is a console
application on Windows. See, for example, bug #5525.

-- 
Enrico

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/19/2010 5:49 AM, Enrico Forestieri wrote:

Maybe because they serve different purposes? I don't think that
changing something without having a clear understanding of why it
is as it is and only because it seems cool using QProcess, is the
way to go. Remember the mantra: if it ain't broke, don't fix it.


I'm definitely not going to change anything there!
I was just suggesting there may be some room for improvement. I'm sure 
Peter knows a lot more about it.



I hope you are aware that there is code assuming that LyX is a console
application on Windows. See, for example, bug #5525.


I have been testing LyX for a while as a GUI application and did not 
notice any issues. The shutdown sequence appears to be handled properly 
by Qt when LyX is a real GUI app.


Note that this patch still allows you to compile LyX as a console app.
As you cas see in the MSDN docs, CREATE_NO_WINDOW is ignored for console 
apps. Therefore I would suggest to keep SetConsoleCtrlHandler for now.


The patch adds to option for LyX to be compiled as a GUI app without any 
hacks to hide the console. I think it would be good to test this during 
the 2.0 alpha stages rather than making a change just before the final 
2.0 release. I will soon create precompiled binaries so more people can 
test.


Joost

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Sat, Jun 19, 2010 at 09:33:22AM -0400, Joost Verburg wrote:

 On 6/19/2010 5:49 AM, Enrico Forestieri wrote:
 Maybe because they serve different purposes? I don't think that
 changing something without having a clear understanding of why it
 is as it is and only because it seems cool using QProcess, is the
 way to go. Remember the mantra: if it ain't broke, don't fix it.
 
 I'm definitely not going to change anything there!

I was not implying that. I meant it as a warning to not try to change
something that works without the need for fixing a real problem.

 I hope you are aware that there is code assuming that LyX is a console
 application on Windows. See, for example, bug #5525.
 
 I have been testing LyX for a while as a GUI application and did not
 notice any issues. The shutdown sequence appears to be handled
 properly by Qt when LyX is a real GUI app.

Good.

 Note that this patch still allows you to compile LyX as a console app.
 As you cas see in the MSDN docs, CREATE_NO_WINDOW is ignored for
 console apps. Therefore I would suggest to keep
 SetConsoleCtrlHandler for now.

Very good.

 The patch adds to option for LyX to be compiled as a GUI app without
 any hacks to hide the console. I think it would be good to test this
 during the 2.0 alpha stages rather than making a change just before
 the final 2.0 release. I will soon create precompiled binaries so
 more people can test.

As I said, there are no objections from me for the reason that I already
explained and also because the damage about batch files is already done :(

-- 
Enrico

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Fri, Jun 18, 2010 at 08:41:31PM -0400, Joost Verburg wrote:

> On 6/18/2010 2:00 PM, Peter Kuemmel wrote:
> >Wouldn't be the cleanest solution to use QProcess also for ForkedCalls?
> >(Enrico, I hear you scream ;)
> 
> Yes, the Systemcall code in LyX doesn't create any console windows
> because QProcess internally sets the CREATE_NO_WINDOW flag. I'm just
> doing the same in the other code that's not using QProcess yet.
> 
> I'm not sure why there are so many different methods (Systemcall /
> ForkedCalls / runCommand). If you want to integrate this more that
> would be a good thing.

Maybe because they serve different purposes? I don't think that
changing something without having a clear understanding of why it
is as it is and only because it seems cool using QProcess, is the
way to go. Remember the mantra: if it ain't broke, don't fix it.

> So shall I go ahead and commit this patch? It's the last part that
> is needed for the new method to create Windows binaries with CMake.
> All the new/updated dependencies are already packaged and ready to
> use: ftp://ftp.devel.lyx.org/pub/contrib/windows/bin/

I hope you are aware that there is code assuming that LyX is a console
application on Windows. See, for example, bug #5525.

-- 
Enrico

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/19/2010 5:49 AM, Enrico Forestieri wrote:

Maybe because they serve different purposes? I don't think that
changing something without having a clear understanding of why it
is as it is and only because it seems cool using QProcess, is the
way to go. Remember the mantra: if it ain't broke, don't fix it.


I'm definitely not going to change anything there!
I was just suggesting there may be some room for improvement. I'm sure 
Peter knows a lot more about it.



I hope you are aware that there is code assuming that LyX is a console
application on Windows. See, for example, bug #5525.


I have been testing LyX for a while as a GUI application and did not 
notice any issues. The shutdown sequence appears to be handled properly 
by Qt when LyX is a real GUI app.


Note that this patch still allows you to compile LyX as a console app.
As you cas see in the MSDN docs, CREATE_NO_WINDOW is ignored for console 
apps. Therefore I would suggest to keep SetConsoleCtrlHandler for now.


The patch adds to option for LyX to be compiled as a GUI app without any 
hacks to hide the console. I think it would be good to test this during 
the 2.0 alpha stages rather than making a change just before the final 
2.0 release. I will soon create precompiled binaries so more people can 
test.


Joost

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Sat, Jun 19, 2010 at 09:33:22AM -0400, Joost Verburg wrote:

> On 6/19/2010 5:49 AM, Enrico Forestieri wrote:
> >Maybe because they serve different purposes? I don't think that
> >changing something without having a clear understanding of why it
> >is as it is and only because it seems cool using QProcess, is the
> >way to go. Remember the mantra: if it ain't broke, don't fix it.
> 
> I'm definitely not going to change anything there!

I was not implying that. I meant it as a warning to not try to change
something that works without the need for fixing a real problem.

> >I hope you are aware that there is code assuming that LyX is a console
> >application on Windows. See, for example, bug #5525.
> 
> I have been testing LyX for a while as a GUI application and did not
> notice any issues. The shutdown sequence appears to be handled
> properly by Qt when LyX is a real GUI app.

Good.

> Note that this patch still allows you to compile LyX as a console app.
> As you cas see in the MSDN docs, CREATE_NO_WINDOW is ignored for
> console apps. Therefore I would suggest to keep
> SetConsoleCtrlHandler for now.

Very good.

> The patch adds to option for LyX to be compiled as a GUI app without
> any hacks to hide the console. I think it would be good to test this
> during the 2.0 alpha stages rather than making a change just before
> the final 2.0 release. I will soon create precompiled binaries so
> more people can test.

As I said, there are no objections from me for the reason that I already
explained and also because the damage about batch files is already done :(

-- 
Enrico

Re: [Patch] Windows process creation

[Peter Kuemmel]

 Original-Nachricht 
 Datum: Thu, 17 Jun 2010 10:33:38 -0400
 Von: Joost Verburg jo...@lyx.org
 An: lyx-devel@lists.lyx.org
 Betreff: [Patch] Windows process creation

 Hi,
 
 Currently we're using a wrapper application (LyXLauncher) on Windows to 
 hide the command prompt windows that keep popping up when LyX starts 
 external applications for e.g. image conversion. These windows appear 
 due to the different concept of GUI/console applications on Windows.

Is this launcher also needed when you build LyX as GUI app? (cmake option
-Dnoconsole=1)

Peter

 
 However, this workaround causes problems with the Windows 7 taskbar. 
 Therefore I think we should fix the real issue by using the Windows 
 CreateProcess API instead of _popen/spawnvp, which has additional 
 features to deal with this situation.
 
 What do you think about the attached patch?
 
 Joost

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/18/2010 3:32 AM, Peter Kuemmel wrote:

Is this launcher also needed when you build LyX as GUI app? (cmake option
-Dnoconsole=1)


Yes. The command windows still pop up when LyX is build as a GUI app. 
With this patch, LyX can be build as a GUI app without the need for any 
launchers.


Joost

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/17/2010 9:00 PM, Enrico Forestieri wrote:

So, this patch does not help in this respect, as the launcher is needed
for hiding the initial console that would otherwise open.
I think that the solution could be hiding the console from inside
LyX itself. Once there was code for doing that, but I don't remember
anymore why it was nuked.


It does help. There is no initial console when LyX is build as a GUI app.

The code to hide the console from LyX itself also had issues and caused 
console windows to pop up during initialization.



Now, instead, you have to edit the
preferences and add cmd /c here and there, hoping that you get right
the way you have to quote the parameters (and in some cases it is very
difficult to get it right, believe me).


I investigated the code a little more and it appears that QProcess is 
used for the actual image/LaTeX conversions. ForkedCalls/runCommand are 
only used for internal Python scripts for display images / lyx2lyx etc. 
(please correct me if I'm wrong). So there will be absolutely no 
difference for the conveters when this patch is applied.


If you want support for batch files / ShellExecute in Systemcall / 
QProcess, the solution would be to send all the commands through 
cmd.exe. I found this piece of code that was used when USE_QPROCESS is 
not defined:


case os::CMD_EXE:
command = start /min  + command;
break;

This should be added to the USE_QPROCESS code as well I think. It's 
however a totally separate issue unrelated to this patch.


Joost

Re: [Patch] Windows process creation

[Peter Kuemmel]

 I investigated the code a little more and it appears that QProcess is 
 used for the actual image/LaTeX conversions. ForkedCalls/runCommand are 
 only used for internal Python scripts for display images / lyx2lyx etc. 

Wouldn't be the cleanest solution to use QProcess also for ForkedCalls?
(Enrico, I hear you scream ;)

Peter
-- 
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.  
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Fri, Jun 18, 2010 at 10:59:05AM -0400, Joost Verburg wrote:

 On 6/17/2010 9:00 PM, Enrico Forestieri wrote:
 So, this patch does not help in this respect, as the launcher is needed
 for hiding the initial console that would otherwise open.
 I think that the solution could be hiding the console from inside
 LyX itself. Once there was code for doing that, but I don't remember
 anymore why it was nuked.
 
 It does help. There is no initial console when LyX is build as a GUI app.

This is the bit I was missing. I think I remember that there were
problems building LyX as a GUI application. So, this is not the case
anymore, seemingly.

 The code to hide the console from LyX itself also had issues and
 caused console windows to pop up during initialization.

Using the code I posted, I simply almost see a flashing window that
is immediately closed.

 Now, instead, you have to edit the
 preferences and add cmd /c here and there, hoping that you get right
 the way you have to quote the parameters (and in some cases it is very
 difficult to get it right, believe me).
 
 I investigated the code a little more and it appears that QProcess
 is used for the actual image/LaTeX conversions.
 ForkedCalls/runCommand are only used for internal Python scripts for
 display images / lyx2lyx etc. (please correct me if I'm wrong). So
 there will be absolutely no difference for the conveters when this
 patch is applied.
 
 If you want support for batch files / ShellExecute in Systemcall /
 QProcess, the solution would be to send all the commands through
 cmd.exe. I found this piece of code that was used when USE_QPROCESS
 is not defined:
 
 case os::CMD_EXE:
   command = start /min  + command;
   break;
 
 This should be added to the USE_QPROCESS code as well I think. It's
 however a totally separate issue unrelated to this patch.

I only use the native version for investigating bugs and some such, so
it is your call deciding what to do, as I already said. I simply could
not resist seeing that nobody in the Windows world seems to care for
the possibility of using scripts.

-- 
Enrico

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Fri, Jun 18, 2010 at 08:00:57PM +0200, Peter Kuemmel wrote:

 
  I investigated the code a little more and it appears that QProcess is 
  used for the actual image/LaTeX conversions. ForkedCalls/runCommand are 
  only used for internal Python scripts for display images / lyx2lyx etc. 
 
 Wouldn't be the cleanest solution to use QProcess also for ForkedCalls?
 (Enrico, I hear you scream ;)

I am not going to accept your challenge ;-)
Luckily, shell scripts can be executed on posix systems through QProcess,
but I think that it is pretty stupid forking a new process for executing
a script (this is what happens on *nix when using QProcess).

-- 
Enrico

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/18/2010 2:00 PM, Peter Kuemmel wrote:

Wouldn't be the cleanest solution to use QProcess also for ForkedCalls?
(Enrico, I hear you scream ;)


Yes, the Systemcall code in LyX doesn't create any console windows 
because QProcess internally sets the CREATE_NO_WINDOW flag. I'm just 
doing the same in the other code that's not using QProcess yet.


I'm not sure why there are so many different methods (Systemcall / 
ForkedCalls / runCommand). If you want to integrate this more that would 
be a good thing.


So shall I go ahead and commit this patch? It's the last part that is 
needed for the new method to create Windows binaries with CMake. All the 
new/updated dependencies are already packaged and ready to use: 
ftp://ftp.devel.lyx.org/pub/contrib/windows/bin/


Joost

Re: [Patch] Windows process creation

[Peter Kuemmel]

 Original-Nachricht 
> Datum: Thu, 17 Jun 2010 10:33:38 -0400
> Von: Joost Verburg 
> An: lyx-devel@lists.lyx.org
> Betreff: [Patch] Windows process creation

> Hi,
> 
> Currently we're using a wrapper application (LyXLauncher) on Windows to 
> hide the command prompt windows that keep popping up when LyX starts 
> external applications for e.g. image conversion. These windows appear 
> due to the different concept of GUI/console applications on Windows.

Is this launcher also needed when you build LyX as GUI app? (cmake option
-Dnoconsole=1)

Peter

> 
> However, this workaround causes problems with the Windows 7 taskbar. 
> Therefore I think we should fix the real issue by using the Windows 
> CreateProcess API instead of _popen/spawnvp, which has additional 
> features to deal with this situation.
> 
> What do you think about the attached patch?
> 
> Joost

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/18/2010 3:32 AM, Peter Kuemmel wrote:

Is this launcher also needed when you build LyX as GUI app? (cmake option
-Dnoconsole=1)


Yes. The command windows still pop up when LyX is build as a GUI app. 
With this patch, LyX can be build as a GUI app without the need for any 
launchers.


Joost

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/17/2010 9:00 PM, Enrico Forestieri wrote:

So, this patch does not help in this respect, as the launcher is needed
for hiding the initial console that would otherwise open.
I think that the solution could be hiding the console from inside
LyX itself. Once there was code for doing that, but I don't remember
anymore why it was nuked.


It does help. There is no initial console when LyX is build as a GUI app.

The code to hide the console from LyX itself also had issues and caused 
console windows to pop up during initialization.



Now, instead, you have to edit the
preferences and add "cmd /c" here and there, hoping that you get right
the way you have to quote the parameters (and in some cases it is very
difficult to get it right, believe me).


I investigated the code a little more and it appears that QProcess is 
used for the actual image/LaTeX conversions. ForkedCalls/runCommand are 
only used for internal Python scripts for display images / lyx2lyx etc. 
(please correct me if I'm wrong). So there will be absolutely no 
difference for the conveters when this patch is applied.


If you want support for batch files / ShellExecute in Systemcall / 
QProcess, the solution would be to send all the commands through 
cmd.exe. I found this piece of code that was used when USE_QPROCESS is 
not defined:


case os::CMD_EXE:
command = "start /min " + command;
break;

This should be added to the USE_QPROCESS code as well I think. It's 
however a totally separate issue unrelated to this patch.


Joost

Re: [Patch] Windows process creation

[Peter Kuemmel]

> I investigated the code a little more and it appears that QProcess is 
> used for the actual image/LaTeX conversions. ForkedCalls/runCommand are 
> only used for internal Python scripts for display images / lyx2lyx etc. 

Wouldn't be the cleanest solution to use QProcess also for ForkedCalls?
(Enrico, I hear you scream ;)

Peter
-- 
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.  
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Fri, Jun 18, 2010 at 10:59:05AM -0400, Joost Verburg wrote:

> On 6/17/2010 9:00 PM, Enrico Forestieri wrote:
> >So, this patch does not help in this respect, as the launcher is needed
> >for hiding the initial console that would otherwise open.
> >I think that the solution could be hiding the console from inside
> >LyX itself. Once there was code for doing that, but I don't remember
> >anymore why it was nuked.
> 
> It does help. There is no initial console when LyX is build as a GUI app.

This is the bit I was missing. I think I remember that there were
problems building LyX as a GUI application. So, this is not the case
anymore, seemingly.

> The code to hide the console from LyX itself also had issues and
> caused console windows to pop up during initialization.

Using the code I posted, I simply "almost" see a flashing window that
is immediately closed.

> >Now, instead, you have to edit the
> >preferences and add "cmd /c" here and there, hoping that you get right
> >the way you have to quote the parameters (and in some cases it is very
> >difficult to get it right, believe me).
> 
> I investigated the code a little more and it appears that QProcess
> is used for the actual image/LaTeX conversions.
> ForkedCalls/runCommand are only used for internal Python scripts for
> display images / lyx2lyx etc. (please correct me if I'm wrong). So
> there will be absolutely no difference for the conveters when this
> patch is applied.
> 
> If you want support for batch files / ShellExecute in Systemcall /
> QProcess, the solution would be to send all the commands through
> cmd.exe. I found this piece of code that was used when USE_QPROCESS
> is not defined:
> 
> case os::CMD_EXE:
>   command = "start /min " + command;
>   break;
> 
> This should be added to the USE_QPROCESS code as well I think. It's
> however a totally separate issue unrelated to this patch.

I only use the native version for investigating bugs and some such, so
it is your call deciding what to do, as I already said. I simply could
not resist seeing that nobody in the Windows world seems to care for
the possibility of using scripts.

-- 
Enrico

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Fri, Jun 18, 2010 at 08:00:57PM +0200, Peter Kuemmel wrote:

> 
> > I investigated the code a little more and it appears that QProcess is 
> > used for the actual image/LaTeX conversions. ForkedCalls/runCommand are 
> > only used for internal Python scripts for display images / lyx2lyx etc. 
> 
> Wouldn't be the cleanest solution to use QProcess also for ForkedCalls?
> (Enrico, I hear you scream ;)

I am not going to accept your challenge ;-)
Luckily, shell scripts can be executed on posix systems through QProcess,
but I think that it is pretty stupid forking a new process for executing
a script (this is what happens on *nix when using QProcess).

-- 
Enrico

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/18/2010 2:00 PM, Peter Kuemmel wrote:

Wouldn't be the cleanest solution to use QProcess also for ForkedCalls?
(Enrico, I hear you scream ;)


Yes, the Systemcall code in LyX doesn't create any console windows 
because QProcess internally sets the CREATE_NO_WINDOW flag. I'm just 
doing the same in the other code that's not using QProcess yet.


I'm not sure why there are so many different methods (Systemcall / 
ForkedCalls / runCommand). If you want to integrate this more that would 
be a good thing.


So shall I go ahead and commit this patch? It's the last part that is 
needed for the new method to create Windows binaries with CMake. All the 
new/updated dependencies are already packaged and ready to use: 
ftp://ftp.devel.lyx.org/pub/contrib/windows/bin/


Joost

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Thu, Jun 17, 2010 at 10:33:38AM -0400, Joost Verburg wrote:
 Hi,

 Currently we're using a wrapper application (LyXLauncher) on Windows to  
 hide the command prompt windows that keep popping up when LyX starts  
 external applications for e.g. image conversion. These windows appear  
 due to the different concept of GUI/console applications on Windows.

I don't know whether Windows 7 broke something in this respect, but once
the console is hidden, launching external applications should not pop up
any console windows. It is so at least with Vista.

 However, this workaround causes problems with the Windows 7 taskbar.  
 Therefore I think we should fix the real issue by using the Windows  
 CreateProcess API instead of _popen/spawnvp, which has additional  
 features to deal with this situation.

I think this is a step backward, as much as the introduction of QProcess.
It is a step backward because until now batch files could be executed
using runCommand(), but with your proposed patch they would not anymore.

For example, the introduction of QProcess made it impossible to put a
batch file called latex.bat earlier in the PATH in order to perform some
further (or different) processing when compiling a document, because
batch files cannot be executed by QProcess.

 What do you think about the attached patch?

If I had no choice than using the native version of LyX, I would be
opposed to such patch (just like I would have been opposed to QProcess),
but having a choice, I really don't care if you cripple some more the
native Windows version.

-- 
Enrico

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/17/2010 5:17 PM, Enrico Forestieri wrote:

I don't know whether Windows 7 broke something in this respect, but once
the console is hidden, launching external applications should not pop up
any console windows. It is so at least with Vista.


The problem is that the application to launch LyX (which hides the 
console) is different from LyX itself. Just like on Mac OS X, this 
doesn't work with the Windows 7 taskbar. It makes it impossible to pin 
the icon.



I think this is a step backward, as much as the introduction of QProcess.
It is a step backward because until now batch files could be executed
using runCommand(), but with your proposed patch they would not anymore.


All the external converts are already being called using ForkedCalls, so 
I don't think this will make any difference.


But you can still use batch files, right? Just launch the command line 
interpreter. Something like cmd.exe /c batchfile.bat.


Joost

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Thu, Jun 17, 2010 at 07:53:41PM -0400, Joost Verburg wrote:
 On 6/17/2010 5:17 PM, Enrico Forestieri wrote:
 I don't know whether Windows 7 broke something in this respect, but once
 the console is hidden, launching external applications should not pop up
 any console windows. It is so at least with Vista.

 The problem is that the application to launch LyX (which hides the  
 console) is different from LyX itself. Just like on Mac OS X, this  
 doesn't work with the Windows 7 taskbar. It makes it impossible to pin  
 the icon.

So, this patch does not help in this respect, as the launcher is needed
for hiding the initial console that would otherwise open.
I think that the solution could be hiding the console from inside
LyX itself. Once there was code for doing that, but I don't remember
anymore why it was nuked.

 I think this is a step backward, as much as the introduction of QProcess.
 It is a step backward because until now batch files could be executed
 using runCommand(), but with your proposed patch they would not anymore.

 All the external converts are already being called using ForkedCalls, so  
 I don't think this will make any difference.

Probably, but going further in the wrong direction is not clever.

 But you can still use batch files, right? Just launch the command line  
 interpreter. Something like cmd.exe /c batchfile.bat.

You're missing the point. On Windows every application has its bin folder
and you should add it to the PATH in order to spot the application in LyX.
In this way, the PATH can become monstrously long and it is a nuisance.
You could instead add a single directory to the PATH and put batch files
in this directory that simply execute the right application. I was doing
that before QProcess, but now it is no more possible.

Another point is that if you want to perform some further processing when
using a given converter, you could put a batch file with same name earlier
in the PATH. Maybe you want to simply test what parameters are passed or
whatever. When you're done, you could simply rename your batch file and
the normal processing is restored. Now, instead, you have to edit the
preferences and add cmd /c here and there, hoping that you get right
the way you have to quote the parameters (and in some cases it is very
difficult to get it right, believe me).

I don't remember having any particular problem without QProcess, but I
have many after its introduction. Anyway, almost nobody on Windows uses
the command line (or even knows what it is), so only some expert user
may suffer from this. As I already said, there's luckily a choice, so if
the majority wants that the native Windows version behaves like that,
please go ahead.

-- 
Enrico

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Fri, Jun 18, 2010 at 03:00:52AM +0200, Enrico Forestieri wrote:
 I think that the solution could be hiding the console from inside
 LyX itself. Once there was code for doing that, but I don't remember
 anymore why it was nuked.

The attached patch hides the console window that would otherwise open.
It even closes the console window from which lyx is started, so maybe
a command line switch --hide-cmd could be added in case one wants a
visible console while running lyx.

-- 
Enrico
Index: src/support/os_win32.cpp
===
--- src/support/os_win32.cpp(revisione 34684)
+++ src/support/os_win32.cpp(copia locale)
@@ -87,6 +87,22 @@ BOOL terminate_handler(DWORD event)
return FALSE;
 }
 
+
+void hide_console()
+{
+   HMODULE lib;
+   HWND WINAPI (*GetConsoleWindow) (void) = NULL;
+   HWND console = NULL;
+
+   if (lib = LoadLibrary(kernel32.dll))
+   GetConsoleWindow = (HWND WINAPI (*) (void))
+   GetProcAddress(lib, GetConsoleWindow);
+   if (GetConsoleWindow)
+   console = GetConsoleWindow();
+   if (console)
+   ShowWindow(console, SW_HIDE);
+}
+
 } // namespace anon
 
 void init(int argc, char * argv[])
@@ -148,6 +164,9 @@ void init(int argc, char * argv[])
 */
 
 
+   // Hide the console window
+   hide_console();
+
// Get the wide program arguments array
wchar_t ** envp = 0;
int newmode = 0;

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Thu, Jun 17, 2010 at 10:33:38AM -0400, Joost Verburg wrote:
> Hi,
>
> Currently we're using a wrapper application (LyXLauncher) on Windows to  
> hide the command prompt windows that keep popping up when LyX starts  
> external applications for e.g. image conversion. These windows appear  
> due to the different concept of GUI/console applications on Windows.

I don't know whether Windows 7 broke something in this respect, but once
the console is hidden, launching external applications should not pop up
any console windows. It is so at least with Vista.

> However, this workaround causes problems with the Windows 7 taskbar.  
> Therefore I think we should fix the real issue by using the Windows  
> CreateProcess API instead of _popen/spawnvp, which has additional  
> features to deal with this situation.

I think this is a step backward, as much as the introduction of QProcess.
It is a step backward because until now batch files could be executed
using runCommand(), but with your proposed patch they would not anymore.

For example, the introduction of QProcess made it impossible to put a
batch file called latex.bat earlier in the PATH in order to perform some
further (or different) processing when compiling a document, because
batch files cannot be executed by QProcess.

> What do you think about the attached patch?

If I had no choice than using the native version of LyX, I would be
opposed to such patch (just like I would have been opposed to QProcess),
but having a choice, I really don't care if you cripple some more the
native Windows version.

-- 
Enrico

Re: [Patch] Windows process creation

[Joost Verburg]

On 6/17/2010 5:17 PM, Enrico Forestieri wrote:

I don't know whether Windows 7 broke something in this respect, but once
the console is hidden, launching external applications should not pop up
any console windows. It is so at least with Vista.


The problem is that the application to launch LyX (which hides the 
console) is different from LyX itself. Just like on Mac OS X, this 
doesn't work with the Windows 7 taskbar. It makes it impossible to pin 
the icon.



I think this is a step backward, as much as the introduction of QProcess.
It is a step backward because until now batch files could be executed
using runCommand(), but with your proposed patch they would not anymore.


All the external converts are already being called using ForkedCalls, so 
I don't think this will make any difference.


But you can still use batch files, right? Just launch the command line 
interpreter. Something like cmd.exe /c batchfile.bat.


Joost

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Thu, Jun 17, 2010 at 07:53:41PM -0400, Joost Verburg wrote:
> On 6/17/2010 5:17 PM, Enrico Forestieri wrote:
>> I don't know whether Windows 7 broke something in this respect, but once
>> the console is hidden, launching external applications should not pop up
>> any console windows. It is so at least with Vista.
>
> The problem is that the application to launch LyX (which hides the  
> console) is different from LyX itself. Just like on Mac OS X, this  
> doesn't work with the Windows 7 taskbar. It makes it impossible to pin  
> the icon.

So, this patch does not help in this respect, as the launcher is needed
for hiding the initial console that would otherwise open.
I think that the solution could be hiding the console from inside
LyX itself. Once there was code for doing that, but I don't remember
anymore why it was nuked.

>> I think this is a step backward, as much as the introduction of QProcess.
>> It is a step backward because until now batch files could be executed
>> using runCommand(), but with your proposed patch they would not anymore.
>
> All the external converts are already being called using ForkedCalls, so  
> I don't think this will make any difference.

Probably, but going further in the wrong direction is not clever.

> But you can still use batch files, right? Just launch the command line  
> interpreter. Something like cmd.exe /c batchfile.bat.

You're missing the point. On Windows every application has its bin folder
and you should add it to the PATH in order to spot the application in LyX.
In this way, the PATH can become monstrously long and it is a nuisance.
You could instead add a single directory to the PATH and put batch files
in this directory that simply execute the right application. I was doing
that before QProcess, but now it is no more possible.

Another point is that if you want to perform some further processing when
using a given converter, you could put a batch file with same name earlier
in the PATH. Maybe you want to simply test what parameters are passed or
whatever. When you're done, you could simply rename your batch file and
the normal processing is restored. Now, instead, you have to edit the
preferences and add "cmd /c" here and there, hoping that you get right
the way you have to quote the parameters (and in some cases it is very
difficult to get it right, believe me).

I don't remember having any particular problem without QProcess, but I
have many after its introduction. Anyway, almost nobody on Windows uses
the command line (or even knows what it is), so only some expert user
may suffer from this. As I already said, there's luckily a choice, so if
the majority wants that the native Windows version behaves like that,
please go ahead.

-- 
Enrico

Re: [Patch] Windows process creation

[Enrico Forestieri]

On Fri, Jun 18, 2010 at 03:00:52AM +0200, Enrico Forestieri wrote:
> I think that the solution could be hiding the console from inside
> LyX itself. Once there was code for doing that, but I don't remember
> anymore why it was nuked.

The attached patch hides the console window that would otherwise open.
It even closes the console window from which lyx is started, so maybe
a command line switch --hide-cmd could be added in case one wants a
visible console while running lyx.

-- 
Enrico
Index: src/support/os_win32.cpp
===
--- src/support/os_win32.cpp(revisione 34684)
+++ src/support/os_win32.cpp(copia locale)
@@ -87,6 +87,22 @@ BOOL terminate_handler(DWORD event)
return FALSE;
 }
 
+
+void hide_console()
+{
+   HMODULE lib;
+   HWND WINAPI (*GetConsoleWindow) (void) = NULL;
+   HWND console = NULL;
+
+   if (lib = LoadLibrary("kernel32.dll"))
+   GetConsoleWindow = (HWND WINAPI (*) (void))
+   GetProcAddress(lib, "GetConsoleWindow");
+   if (GetConsoleWindow)
+   console = GetConsoleWindow();
+   if (console)
+   ShowWindow(console, SW_HIDE);
+}
+
 } // namespace anon
 
 void init(int argc, char * argv[])
@@ -148,6 +164,9 @@ void init(int argc, char * argv[])
 */
 
 
+   // Hide the console window
+   hide_console();
+
// Get the wide program arguments array
wchar_t ** envp = 0;
int newmode = 0;