Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
Le dimanche 07 mai 2023 à 15:44 +0100, Richard Shann a écrit : > > I couldn't follow up this suggestion because I don't have a way of > building Denemo for Windows to experiment with. But it occurred to me > that I *could* test this idea just by swapping the executables > gspawn-win32-helper.exe and gspawn-win32-helper-console.exe around - > that is, running the opposite one that the > might_be_console_process (void) > call suggests. > I did this and it turns out that this doesn't prevent a terminal from > popping up, however there is a clue: the title of the program being run > in the title bar of the terminal changes from lilypond.exe to gspawn- > win32-helper.exe when that program is replaced by gspawn-win32-helper- > console.exe. > So it would seem that a terminal would pop up regardless of which of > those gspawn-win32 helper programs ran, but the title bar would name > the helper program rather than the lilypond.exe program. > If I were you, I would ask the GLib developers about this on https://discourse.gnome.org/c/platform/5 signature.asc Description: This is a digitally signed message part
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On Tue, 2023-04-04 at 12:03 +0200, Jean Abou Samra wrote:
> Le mardi 04 avril 2023 à 11:34 +0200, Jean Abou Samra a écrit :
> Le lundi 03 avril 2023 à 20:50 +0200, Jonas Hahnfeld via LilyPond
> user discussion a écrit :
> > This shouldn't be needed: g_spawn_sync internally uses a helper
> > executable that should take care exactly of this aspect. LilyPond
> > uses
> > it internally to call Ghostscript.
> Hmm, but Denemo is already using g_spawn_sync and still experiencing
> this issue, or am I missing something?
> You are right that the GLib sources contain a gspawn-win32-helper.c
> program with the comment
> /* We build gspawn-win32-helper.exe as a Windows GUI application
> * to avoid any temporarily flashing console windows in case
> * the gspawn function is invoked by a GUI program. Thus, no main()
> * but a WinMain().
> */
> Later, there is
> #ifndef HELPER_CONSOLE
> int _stdcall
> WinMain (struct HINSTANCE__ *hInstance,
>struct HINSTANCE__ *hPrevInstance,
>char *lpszCmdLine,
>int nCmdShow)
> #else
> int
> main (int ignored_argc, char **ignored_argv)
> #endif
> Apparently, there are two such executables, gspawn-win32-helper.exe
> and gspawn-win32-helper-console.exe, the latter compiled with -
> DHELP_CONSOLE.
> In gspawn-win32.c, I see
> if (might_be_console_process ())
> helper_process = HELPER_PROCESS "-console.exe";
> else
> helper_process = HELPER_PROCESS ".exe";
> which calls
> static gboolean
> might_be_console_process (void)
> {
> // we should always fail to attach ourself to a console (because
> we're
> // either already attached, or we do not have a console)
> gboolean attached_to_self = AttachConsole (GetCurrentProcessId ());
> g_return_val_if_fail (!attached_to_self, TRUE);
>
> switch (GetLastError ())
> {
> // current process is already attached to a console
> case ERROR_ACCESS_DENIED:
> return TRUE;
> // current process does not have a console
> case ERROR_INVALID_HANDLE:
> return FALSE;
> // we should not get ERROR_INVALID_PARAMETER
> }
>
> g_return_val_if_reached (FALSE);
> }
> Richard, maybe might_be_console_process is returning true inside
> Denemo for some reason?
I couldn't follow up this suggestion because I don't have a way of
building Denemo for Windows to experiment with. But it occurred to me
that I *could* test this idea just by swapping the executables
gspawn-win32-helper.exe and gspawn-win32-helper-console.exe around -
that is, running the opposite one that the
might_be_console_process (void)
call suggests.
I did this and it turns out that this doesn't prevent a terminal from
popping up, however there is a clue: the title of the program being run
in the title bar of the terminal changes from lilypond.exe to gspawn-
win32-helper.exe when that program is replaced by gspawn-win32-helper-
console.exe.
So it would seem that a terminal would pop up regardless of which of
those gspawn-win32 helper programs ran, but the title bar would name
the helper program rather than the lilypond.exe program.
Richard
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
Le mardi 04 avril 2023 à 12:56 +0100, Richard Shann a écrit : > I don't understand, I'm afraid. Denemo only makes calls to the g_spawn* > functions as documented. The function might_be_console_process() is > static - internal to glib - or rather to some executable that it calls, > apparently. > > The name and path of the lilypond executable is typed into Denemo and > the g_spawn call is made - so the only difference is that it is calling > lilypond.exe below the 2.24.0 folder rather than the lilypond- > windows.exe below the 2.22.0 folder. I've just tested this out by > downloading 2.22.0 to the home directory and telling the same Denemo > executable to execute lilypond.exe and lilypond-windows.exe > alternately. With the former I get the terminal popping up and not with > the latter. Yes, I understand that. What I'm saying is that as you can see from the GLib source code, whether g_spawn_sync opens a new console or not depends on the parent process, specifically, whether it detects the parent process as being a GUI or a console process. If Denemo were correctly detected by GLib as a GUI process, I would expect GLib to spawn the LilyPond process without an extra console. Therefore, I suppose that something in Denemo or GLib is this detection incorrect. You could try copying `might_be_console_process` into your own code and seeing what result it yields on Windows and why. signature.asc Description: This is a digitally signed message part
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On Tue, 2023-04-04 at 12:03 +0200, Jean Abou Samra wrote:
> Le mardi 04 avril 2023 à 11:34 +0200, Jean Abou Samra a écrit :
> Le lundi 03 avril 2023 à 20:50 +0200, Jonas Hahnfeld via LilyPond
> user discussion a écrit :
> > This shouldn't be needed: g_spawn_sync internally uses a helper
> > executable that should take care exactly of this aspect. LilyPond
> > uses
> > it internally to call Ghostscript.
> Hmm, but Denemo is already using g_spawn_sync and still experiencing
> this issue, or am I missing something?
> You are right that the GLib sources contain a gspawn-win32-helper.c
> program with the comment
> /* We build gspawn-win32-helper.exe as a Windows GUI application
> * to avoid any temporarily flashing console windows in case
> * the gspawn function is invoked by a GUI program. Thus, no main()
> * but a WinMain().
> */
> Later, there is
> #ifndef HELPER_CONSOLE
> int _stdcall
> WinMain (struct HINSTANCE__ *hInstance,
>struct HINSTANCE__ *hPrevInstance,
>char *lpszCmdLine,
>int nCmdShow)
> #else
> int
> main (int ignored_argc, char **ignored_argv)
> #endif
> Apparently, there are two such executables, gspawn-win32-helper.exe
> and gspawn-win32-helper-console.exe, the latter compiled with -
> DHELP_CONSOLE.
> In gspawn-win32.c, I see
> if (might_be_console_process ())
> helper_process = HELPER_PROCESS "-console.exe";
> else
> helper_process = HELPER_PROCESS ".exe";
> which calls
> static gboolean
> might_be_console_process (void)
> {
> // we should always fail to attach ourself to a console (because
> we're
> // either already attached, or we do not have a console)
> gboolean attached_to_self = AttachConsole (GetCurrentProcessId ());
> g_return_val_if_fail (!attached_to_self, TRUE);
>
> switch (GetLastError ())
> {
> // current process is already attached to a console
> case ERROR_ACCESS_DENIED:
> return TRUE;
> // current process does not have a console
> case ERROR_INVALID_HANDLE:
> return FALSE;
> // we should not get ERROR_INVALID_PARAMETER
> }
>
> g_return_val_if_reached (FALSE);
> }
> Richard, maybe might_be_console_process is returning true inside
> Denemo for some reason?
I don't understand, I'm afraid. Denemo only makes calls to the g_spawn*
functions as documented. The function might_be_console_process() is
static - internal to glib - or rather to some executable that it calls,
apparently.
The name and path of the lilypond executable is typed into Denemo and
the g_spawn call is made - so the only difference is that it is calling
lilypond.exe below the 2.24.0 folder rather than the lilypond-
windows.exe below the 2.22.0 folder. I've just tested this out by
downloading 2.22.0 to the home directory and telling the same Denemo
executable to execute lilypond.exe and lilypond-windows.exe
alternately. With the former I get the terminal popping up and not with
the latter.
Richard Shann
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
Le mardi 04 avril 2023 à 11:03 +0100, Richard Shann a écrit : > The documentation on -dlog-file doesn't specify where the file will > appear in the case that a full path is not given, I think it just gets put in the current working directory (as I would expect). signature.asc Description: This is a digitally signed message part
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
Le mardi 04 avril 2023 à 11:34 +0200, Jean Abou Samra a écrit :
> Le lundi 03 avril 2023 à 20:50 +0200, Jonas Hahnfeld via LilyPond user
> discussion a écrit :
>
> > This shouldn't be needed: g_spawn_sync internally uses a helper
> > executable that should take care exactly of this aspect. LilyPond uses
> > it internally to call Ghostscript.
>
> Hmm, but Denemo is already using `g_spawn_sync` and still experiencing this
> issue, or am I missing something?
You are right that the GLib sources contain a gspawn-win32-helper.c program
with the comment
```
/* We build gspawn-win32-helper.exe as a Windows GUI application
* to avoid any temporarily flashing console windows in case
* the gspawn function is invoked by a GUI program. Thus, no main()
* but a WinMain().
*/
```
Later, there is
```
#ifndef HELPER_CONSOLE
int _stdcall
WinMain (struct HINSTANCE__ *hInstance,
struct HINSTANCE__ *hPrevInstance,
char *lpszCmdLine,
int nCmdShow)
#else
int
main (int ignored_argc, char **ignored_argv)
#endif
```
Apparently, there are two such executables, `gspawn-win32-helper.exe` and
`gspawn-win32-helper-console.exe`, the latter compiled with `-DHELP_CONSOLE`.
In `gspawn-win32.c`, I see
```
if (might_be_console_process ())
helper_process = HELPER_PROCESS "-console.exe";
else
helper_process = HELPER_PROCESS ".exe";
```
which calls
```
static gboolean
might_be_console_process (void)
{
// we should always fail to attach ourself to a console (because we're
// either already attached, or we do not have a console)
gboolean attached_to_self = AttachConsole (GetCurrentProcessId ());
g_return_val_if_fail (!attached_to_self, TRUE);
switch (GetLastError ())
{
// current process is already attached to a console
case ERROR_ACCESS_DENIED:
return TRUE;
// current process does not have a console
case ERROR_INVALID_HANDLE:
return FALSE;
// we should not get ERROR_INVALID_PARAMETER
}
g_return_val_if_reached (FALSE);
}
```
Richard, maybe `might_be_console_process` is returning true inside Denemo for
some reason?
signature.asc
Description: This is a digitally signed message part
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On Tue, 2023-04-04 at 11:32 +0200, Jean Abou Samra wrote: > Le mardi 04 avril 2023 à 10:29 +0100, Richard Shann a écrit : > > The situation on Windows without lilypond-windows.exe is even worse > > than I thought - the option -dlog-file no longer generates the log > > file > > into the prescribed place - instead the log is splashed onto the > > terminal box (which then vanishes when the typesetting is > > finished). > > It means no error reporting to the unlucky Windows users of Denemo. > For me, -dlog-file still works. Do you have a reproducer? I've just run lilypond.exe from a "Windows Power Shell" in the lilypond bin directory targetting a file on the user's Desktop. It *did* indeed generate a log file with the -dlog-file option, the file appearing in the bin directory where the executable was launched. No stderr appeared in the terminal. The documentation on -dlog-file doesn't specify where the file will appear in the case that a full path is not given, but previously run from g_spawn_sync it appeared in the same directory as the lilypond source. It doesn't appear there now, nor in the bin directory (this is under the user's home directory), nor (given my limited abilities searching on Windows) anywhere else. I should mention that the -dgui was a complete red herring here - I mistakenly thought Denemo was depending on it to capture the log output but in actual fact "-dlog-file filename" is always passed, the only thing Denemo has to do is append the ".log" and then open it to find the error locations. It is, of course still working under Unix - the log file appears under the /tmp/Denemo directory where the LilyPond source is written by Denemo. Thank you for looking into this! Richard
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
Le lundi 03 avril 2023 à 20:50 +0200, Jonas Hahnfeld via LilyPond user discussion a écrit : > This shouldn't be needed: g_spawn_sync internally uses a helper > executable that should take care exactly of this aspect. LilyPond uses > it internally to call Ghostscript. Hmm, but Denemo is already using `g_spawn_sync` and still experiencing this issue, or am I missing something? > > For now I'll disable the autocompilation option for Windows with > > LilyPond 2.24. Is there any chance the developers might re-instate > > the lilypond-windows.exe? > > > I wouldn't be a fan, really, because it would mean shipping the same > (statically linked) executable twice... +1, let's avoid it if possible. signature.asc Description: This is a digitally signed message part
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
Le mardi 04 avril 2023 à 10:29 +0100, Richard Shann a écrit : > The situation on Windows without lilypond-windows.exe is even worse > than I thought - the option -dlog-file no longer generates the log file > into the prescribed place - instead the log is splashed onto the > terminal box (which then vanishes when the typesetting is finished). > It means no error reporting to the unlucky Windows users of Denemo. For me, `-dlog-file` still works. Do you have a reproducer? signature.asc Description: This is a digitally signed message part
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
The situation on Windows without lilypond-windows.exe is even worse than I thought - the option -dlog-file no longer generates the log file into the prescribed place - instead the log is splashed onto the terminal box (which then vanishes when the typesetting is finished). It means no error reporting to the unlucky Windows users of Denemo. Please can we have lilypond-windows.exe back? It is indeed as far as I know just an extra target in the makefile with -mconsole in it, and given the size of a LilyPond installation not a enormous burden on the windows users disk space. Richard Shann On Mon, 2023-04-03 at 10:54 -0700, Aaron Hill wrote: > On 2023-04-03 10:31 am, Jean Abou Samra wrote: > > > Le 3 avr. 2023 à 12:21, Richard Shann a > > > écrit : > > > > > > Is there any chance the developers might re-instate the > > > lilypond-windows.exe? > > > > Maybe. Is it as easy as compiling with -mconsole ? Does that have > > other > > effects to take care of? Is there a use case where the current mode > > is > > important or could we just switch to the other mode? > > LilyPond would still need to be able to be run purely from the > terminal, > so the main target should continue to use the console subsystem. > This > importantly covers the scenarios of scripting and automation where > you > need standard I/O to be mapped properly. > > The use case for a third-party GUI application running LilyPond > behind-the-scenes is where the "windows" subsystem could be useful, > providing the application is unable to spawn the child process in a > hidden manner. > > This goes to my question of which application has the real problem. > Denemo relied on LilyPond providing two entrypoints, so it was not > really at fault. But Denemo probably should have been spawning the > worker process hidden to begin with, thus never relying on > lilypond-windows.exe in the first place. However, that would require > working around glib to use the Win32 API directly (and adding > platform-specific development overhead), or by getting the glib > developers to expose the underlying process creation flag. But for > all > I know, it might be out-of-scope for glib to support this scenario, > thus > pushing the work back to Denemo. > > It should be noted that this dual subsystem approach is very common > on > Windows. Take the Windows scripting host itself. It comes in two > flavors: wscript.exe and cscript.exe. The first is for use without > an > attached terminal, and the second is meant to be run from the > command-line. Java likewise has always shipped with two frontends: > java.exe and javaw.exe. So, LilyPond would not be doing anything > unusual by shipping two executables. > > > -- Aaron Hill
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On Mon, 2023-04-03 at 11:19 +0100, Richard Shann wrote: > On Sun, 2023-04-02 at 11:54 -0700, Aaron Hill wrote: > > I have never looked at Denemo or its source code, so what I am going > > to say might not be so trivially applicable. > > You were quite right to be doubtful - Denemo tries to off-load the > target machine dependent stuff onto libraries, in this case glib which > provides the routine to spawn a process, and sadly does not expose the > CREATE_NO_WINDOW part of the Win32 API. This shouldn't be needed: g_spawn_sync internally uses a helper executable that should take care exactly of this aspect. LilyPond uses it internally to call Ghostscript. > For now I'll disable the autocompilation option for Windows with > LilyPond 2.24. Is there any chance the developers might re-instate > the lilypond-windows.exe? I wouldn't be a fan, really, because it would mean shipping the same (statically linked) executable twice... Jonas > signature.asc Description: This is a digitally signed message part
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On 2023-04-03 10:31 am, Jean Abou Samra wrote: Le 3 avr. 2023 à 12:21, Richard Shann a écrit : Is there any chance the developers might re-instate the lilypond-windows.exe? Maybe. Is it as easy as compiling with -mconsole ? Does that have other effects to take care of? Is there a use case where the current mode is important or could we just switch to the other mode? LilyPond would still need to be able to be run purely from the terminal, so the main target should continue to use the console subsystem. This importantly covers the scenarios of scripting and automation where you need standard I/O to be mapped properly. The use case for a third-party GUI application running LilyPond behind-the-scenes is where the "windows" subsystem could be useful, providing the application is unable to spawn the child process in a hidden manner. This goes to my question of which application has the real problem. Denemo relied on LilyPond providing two entrypoints, so it was not really at fault. But Denemo probably should have been spawning the worker process hidden to begin with, thus never relying on lilypond-windows.exe in the first place. However, that would require working around glib to use the Win32 API directly (and adding platform-specific development overhead), or by getting the glib developers to expose the underlying process creation flag. But for all I know, it might be out-of-scope for glib to support this scenario, thus pushing the work back to Denemo. It should be noted that this dual subsystem approach is very common on Windows. Take the Windows scripting host itself. It comes in two flavors: wscript.exe and cscript.exe. The first is for use without an attached terminal, and the second is meant to be run from the command-line. Java likewise has always shipped with two frontends: java.exe and javaw.exe. So, LilyPond would not be doing anything unusual by shipping two executables. -- Aaron Hill
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
> Le 3 avr. 2023 à 12:21, Richard Shann a écrit : > > Is there any chance the developers might re-instate the > lilypond-windows.exe? Maybe. Is it as easy as compiling with -mconsole ? Does that have other effects to take care of? Is there a use case where the current mode is important or could we just switch to the other mode?
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On 2023-04-03 3:19 am, Richard Shann wrote: On Sun, 2023-04-02 at 11:54 -0700, Aaron Hill wrote: I have never looked at Denemo or its source code, so what I am going to say might not be so trivially applicable. But in the Win32 API, you can call CreateProcess and use the process flag CREATE_NO_WINDOW. You were quite right to be doubtful - Denemo tries to off-load the target machine dependent stuff onto libraries, in this case glib which provides the routine to spawn a process, and sadly does not expose the CREATE_NO_WINDOW part of the Win32 API. Ah, such is the bane of cross-platform programming. Often these edge cases get overlooked with API abstractions. For now I'll disable the autocompilation option for Windows with LilyPond 2.24. Is there any chance the developers might re-instate the lilypond-windows.exe? The question of the hour is: Is this a LilyPond problem or a Denemo problem? (Well, one could also ask whether this is a glib problem.) If another third-party tool like Frescobaldi is still working given the change in LilyPond, then the case could be made that this is something best addressed in Denemo itself. However, if LilyPond could easily provide both entrypoints as it used to, then the issue should be filed against LilyPond. This is something I have not tested, but there are some indications that the subsystem of a Windows portable executable can be changed after it has been built. There are two references to Perl modules that do this: https://metacpan.org/pod/Win32::Exe https://metacpan.org/dist/Tk/view/exetype It sounds like you could manually copy lilypond.exe to lilypond-windows.exe and then change the copy's subsystem. Not really a long-term solution, but it might help you keep auto-compilation as that really does sound like a useful workflow. -- Aaron Hill
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On Sun, 2023-04-02 at 11:54 -0700, Aaron Hill wrote:
> On 2023-04-02 8:38 am, Richard Shann wrote:
> > there used to be an executable lilypond-windows.exe in addition to
> > the
> > lilypond.exe which has also vanished. I suspect it was compiled
> > using
> > the option
> >
> > -mconsole
> >
> > passed to gcc as this is how Denemo is compiled to avoid leaving a
> > terminal around that would tempt the user to kill everything by
> > dismissing it (Windows users are generally not familiar with
> > terminals).
>
> Yup. On Windows, the executable takes two forms based on whether it
> is
> CLI-based or GUI-based. lilypond-windows.exe was in all practical
> ways
> identical to lilypond.exe except that it had WinMain as its
> entrypoint
> instead of main. This meant Windows did not automatically allocate a
> console window. Do note that even GUI-based applications are
> afforded a
> text console but they must explicitly call the AllocConsole API.
>
>
> > If I understand this correctly, it looks like I will have to spawn
> > a
> > process that runs a windows batch file that processes the command
> > line
> > parameters and synthesizes the names of the log file that LilyPond
> > used
> > to create and then calls LilyPond with re-direction of the output.
> > I'm
> > not sure that this can be done without a terminal popping up to
> > annoy
> > the user.
>
> I have never looked at Denemo or its source code, so what I am going
> to
> say might not be so trivially applicable.
You were quite right to be doubtful - Denemo tries to off-load the
target machine dependent stuff onto libraries, in this case glib which
provides the routine to spawn a process, and sadly does not expose the
CREATE_NO_WINDOW part of the Win32 API.
For now I'll disable the autocompilation option for Windows with
LilyPond 2.24. Is there any chance the developers might re-instate the
lilypond-windows.exe?
Richard Shann
>
> But in the Win32 API, you can
> call CreateProcess [1] and use the process flag CREATE_NO_WINDOW
> [2].
> This should prevent the console window appearing if the child process
> is
> CLI-based.
>
> [1]:
>
> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
> [2]:
>
> https://learn.microsoft.com/en-us/windows/win32/procthread/process-creation-flags
>
>
> > Is there anyway of spawning a LilyPond 2.24 process on Windows now
> > without plaguing the user with terminals?
>
> You might be able to shim with a VBS wrapper. I do this a lot for
> custom scheduled tasks that would normally run in the terminal but
> that
> I do not want to interrupt what I am doing by spawning a window at
> odd
> times. Something like this should work, passing arguments to the
> script
> along to LilyPond:
>
>
> ' Turn WScript.Arguments into a proper array.
> Dim args()
> ReDim args(WScript.Arguments.Count - 1)
> For i = 0 To WScript.Arguments.Count - 1
> args(i) = Chr(34) & WScript.Arguments(i) & Chr(34)
> Next
>
> Dim shell
> Set shell = WScript.CreateObject("WScript.Shell")
> shell.Run "lilypond.exe " & Join(args), 0, True
>
>
> NOTE: The important parameter here is the zero (0) to shell.Run.
> This
> hides the spawned process. The True waits for the child process to
> finish, which probably is what you need for this use case. But if
> you
> just want to fire off a child process and not have the scripting host
> stick around, change that to False.
>
>
> -- Aaron Hill
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On 2023-04-02 8:38 am, Richard Shann wrote:
there used to be an executable lilypond-windows.exe in addition to the
lilypond.exe which has also vanished. I suspect it was compiled using
the option
-mconsole
passed to gcc as this is how Denemo is compiled to avoid leaving a
terminal around that would tempt the user to kill everything by
dismissing it (Windows users are generally not familiar with
terminals).
Yup. On Windows, the executable takes two forms based on whether it is
CLI-based or GUI-based. lilypond-windows.exe was in all practical ways
identical to lilypond.exe except that it had WinMain as its entrypoint
instead of main. This meant Windows did not automatically allocate a
console window. Do note that even GUI-based applications are afforded a
text console but they must explicitly call the AllocConsole API.
If I understand this correctly, it looks like I will have to spawn a
process that runs a windows batch file that processes the command line
parameters and synthesizes the names of the log file that LilyPond used
to create and then calls LilyPond with re-direction of the output. I'm
not sure that this can be done without a terminal popping up to annoy
the user.
I have never looked at Denemo or its source code, so what I am going to
say might not be so trivially applicable. But in the Win32 API, you can
call CreateProcess [1] and use the process flag CREATE_NO_WINDOW [2].
This should prevent the console window appearing if the child process is
CLI-based.
[1]:
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
[2]:
https://learn.microsoft.com/en-us/windows/win32/procthread/process-creation-flags
Is there anyway of spawning a LilyPond 2.24 process on Windows now
without plaguing the user with terminals?
You might be able to shim with a VBS wrapper. I do this a lot for
custom scheduled tasks that would normally run in the terminal but that
I do not want to interrupt what I am doing by spawning a window at odd
times. Something like this should work, passing arguments to the script
along to LilyPond:
' Turn WScript.Arguments into a proper array.
Dim args()
ReDim args(WScript.Arguments.Count - 1)
For i = 0 To WScript.Arguments.Count - 1
args(i) = Chr(34) & WScript.Arguments(i) & Chr(34)
Next
Dim shell
Set shell = WScript.CreateObject("WScript.Shell")
shell.Run "lilypond.exe " & Join(args), 0, True
NOTE: The important parameter here is the zero (0) to shell.Run. This
hides the spawned process. The True waits for the child process to
finish, which probably is what you need for this use case. But if you
just want to fire off a child process and not have the scripting host
stick around, change that to False.
-- Aaron Hill
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
On Sun, 2023-04-02 at 13:57 +0200, Robin Bannister wrote: > Richard Shann wrote: > > There was an option -dgui which allowed Denemo to run LilyPond in > > the > > background on Windows, but this has vanished without, as far as I > > can > > see, any entry in the Changes to account for it > > > > See > https://gitlab.com/lilypond/lilypond/-/commit/0a7d54646be5566de53e2f7dd0c19a2c1df92156?merge_request_iid=1373 > Thank you for your quick reply. If I understand this correctly, it looks like I will have to spawn a process that runs a windows batch file that processes the command line parameters and synthesizes the names of the log file that LilyPond used to create and then calls LilyPond with re-direction of the output. I'm not sure that this can be done without a terminal popping up to annoy the user. However I think what this says is that the current problem of a terminal popping up and blocking progress is due something else that has changed: there used to be an executable lilypond-windows.exe in addition to the lilypond.exe which has also vanished. I suspect it was compiled using the option -mconsole passed to gcc as this is how Denemo is compiled to avoid leaving a terminal around that would tempt the user to kill everything by dismissing it (Windows users are generally not familiar with terminals). Is there anyway of spawning a LilyPond 2.24 process on Windows now without plaguing the user with terminals? Richard > > Cheers, > Robin
Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?
Richard Shann wrote: There was an option -dgui which allowed Denemo to run LilyPond in the background on Windows, but this has vanished without, as far as I can see, any entry in the Changes to account for it See https://gitlab.com/lilypond/lilypond/-/commit/0a7d54646be5566de53e2f7dd0c19a2c1df92156?merge_request_iid=1373 Cheers, Robin
