Windows client 0.15.0 r8892 against fedora 20 0.15.0 r8872 server.
When launching with the GUI, in addition to the start-child
ren, I am seeing a windows style cmd window with no content (which sometimes flickers, maybe in time with server-side message output such as ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
- or maybe just coincidentally with similar timing).
Xpra info has no indication of a corresponding window (xpra info | grep window just gave info about my 2 xterm start child-ren).
The window will not take keyboard focus, but it can be minimized, closed, or re-sized at will.
apparent cmd window created on GUI connection, too re-sizable to be a "real" cmd window
I'm pretty sure that's the sound process window. You can confirm this by running without sound.
Can you include the full command lines you are using? Is this using one of my builds? And include -d util
client side, which should log the command line used for the sound process.
We have code to make sure we use the Xpra.exe
for this subprocess rather than the Xpra_cmd.exe
- this should ensure we don't get an extra shell window.
And suddenly it hit me: I'm testing from a shell window already, and you're not.
Using the command version without a shell window is not enough, I think we also need to use the startupinfo flags as per Launching a subprocess without a console window (Python recipe). But when I try this approach (will attach patch), I get constant overruns and even crashes... oh win32, why do you need to be so flaky.
tries to avoid showing the console window - causes more problems...
Well, it seems that the overruns I am getting are not necessarily related to this patch.
@afarr: can you try with r8902 which adds the XPRA_WIN32_SHOWWINDOW
env var. (defaults to "0" which hides the console window, set it to "1" to restore the previous behaviour)
For the record, I've also tried setting XPRA_SOUND_EXECUTABLE=xpra.exe
, but xpra.exe
being a non-console application, it does not have stdin or stdout and so we can't communicate with it and nothing happens at all (note to self: I need to add a timeout for such cases).
Another problem that I have seen is that if I get too many overruns (making us kill the current sound process and start a new one), xpra will eventually crash... which is bad! (no idea why, win32 must be leaking something with each process)
Testing by launching with the GUI/icon with 0.15.0 r8904 against the same 0.15.0 r8872 fedora 20 server, I'm no longer getting any cmd window.
Launching with the airgap.exe
from the command line with XPRA_WIN32_SHOWWINDOW=1
... (xpra.exe attach tcp:10.0.32.53:1201
) ... I do indeed get the cmd window.
This looks fixed to me.
Thanks for testing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/830