Makes sense to bundle this together since python3 is only really supported with gtk3 and vice versa.
Main work items:
encode(..) and decode(..) does not adversely affect performance
gtk.Window have changed, client.py will need to provide wrapper methods:
gdk.get_default_root_window().get_pointer() (removed)
gdk.get_default_root_window().get_size() (removed)
gtk.Window.__init__(win, wintype) (removed: no arg constructor now)
window.set_geometry_hints(...) (signature changed)
window.flags() (removed - must call get_$FLAGNAME)
window.window.set_cursor(..) (renamed to window.override_cursor?)
window.window.invalidate_rect (now window.queue_draw_area)
do_expose_event(event) is now do_draw(context)
window.window.get_geometry (removed, must now call get_position() and get_size()?)
gdk.keymap_get_default (removed?)
gdk.Cursor can no longer use pixbuf..
GdkPixmap and GdkImage, we're supposed to be using cairo but cairo.ImageSurface.create_for_data is not implemented in pycairo and there are no alternatives (ouch!)
More done in r626, r627, r628, r629 and r630: most of the code is now python3/gtk3 compatible, except for:
Some useful links:
rough patch for gtk3/python3 support
The patch above "works" in the sense that one can get something on screen with gtk3, but it has a number of important shortcomings:
StringIO class, which fails because of a missing fileno()
jpeg and rgb24 have to be parsed using PIL then exported to PNG to then be loaded by cairo as cairo is incapable of loading anything else (seriously!? gtk devs, this is not an upgrade by a giant leap backwards). For rgb24 it seems to require an unnecessarily large rowstride (RGBA? according to this answer it uses 32 bit per channel data no matter what) - which we do not control as it is generated by gdk on the server side. This means making png the default and finding a solution for the mmap case: possibly using cairo server side to export with the rowstride expected by cairo on the client? Maybe also moving the draw/expose code to a utility class so we can use the current code on gtk2 and the new horrible mess on gtk3 only.
r640 makes python3 + gtk3 almost usable by providing two different window backing mechanisms (we keep the old/fast code for gtk2, cairo for gtk3). But there are still many issues remaining:
client.py are still missing an actual implementation (no cursors, no keyboard support, etc)
display = gdk.display_get_default() and watching for screen changes has been hacked out with a if not is_gtk3() guard
get_modifiers_mask, set_geometry_hints and is_flag_set vs MAPPED/REALIZED
There are serious compatibility issues between the new io.StringIO module and PIL, r697 reverts back to StringIO.StringIO in order to fix window icons - this will cause problems when trying to port the server to gtk3/python3.
delayed, this is hard!
Worth updating and getting the basics to work properly (keyboard, etc)
And maybe also: transparency, GL, cursors, ..
too much work, too little time
Lots of updates, this may be a better option than #300:
It is in a much better shape now, including some keyboard support.
Things that just need more work:
Things that won't work out of the box with python3:
pygobjectwin32 installer.
GTK (what a mess):
Things that install OK on win32 via installers (preferred):
Things that install OK on win32 via scripts\pip.exe install or py -3 -m pip install:
Things that need a C compiler to install on win32. Note: I have used mingw32 as per http://stackoverflow.com/questions/3297254/how-to-use-mingws-gcc-compiler-when-installing-python-package-using-pip instead of Visual Studio 2010 normally used with Python 3.4 because I already have Visual Studio 2008 installed for Python 2.7... for now.
chmod.exe on the PATH)
fixes netifaces to build with python3
Using Porting Extension Modules To Py3k, it was relatively easy to port netifaces. Now builds on both Linux and win32 with Python 3.4.
I have sent the patch to the author, who said he was going to look at it. Alternatively, netifaces-merged could be used.
with this patch I can build with python3.4 and mingw
More fixes:
Harder (delayed):
Many build updates in r6233, r6236, r6237, r6238, r6239, r6240, r6241, r6242
We can now build all the cython modules properly easily with unmodified build files:
set PYTHON=C:\Python34 set PATH=%PATH%;C:\MinGW\bin set PKG_CONFIG_PATH=C:\MinGW\lib\pkgconfig;C:\MinGW\msys\1.0\local\lib\pkgconfig;C:\MinGW\msys\1.0\lib\pkgconfig win32\MAKE-INSTALLER.BAT /silent
You must build ffmpeg and libvpx into the mingw environment to use them via pkg-config:
./configure (...) --prefix=C:\MinGW make make install
And... cx freeze (stub added in r6243) is not available for Python 3.4 on win32, it does not build either. So I will start again from the top with Python 3.3.5 instead.
Things to install using pygobjectwin32:
gobject-introspection (replaces pygtk)
gst-plugins
gdkglext
gst-plugins-extra
gtk+
pango
gstreamer
gdk-pixbuf
dbus-glib
gtkglext
More build updates in r6245, r6246, r6247, r6248, r6249, r6250, r6251. Big change in r6252 allows us to build correctly again on all (?) platforms (fixes buffer compilation issues with Visual Studio)
Lots more build updates up to r6280 means that we now have the ability to build GTK3 / Python3 installers from the same source tree as the regular GTK2 / Python2!
Notes:
PNG encoding (which has native support in cairo), the others crash.. (horrible / inflexible API decisions in cairo)
OSSBuild from %PATH% and %PYTHONPATH% (though r6273 means this may no longer be strictly required, still better / safer)
Many more build updates, cleanups and fixes up to r6290, keyboard support in r6291.
It works well enough in PNG encoding that you can actually almost use it.
Still TODO:
Gdk-WARNING **: gdkwindow-win32.c:1976: GetClientRect failed: Invalid window handle.
PNG) cause crashes, the RGB codepath needs fixing
access violation reading 0x0000000 from libc.memcpy in decode.py
do_get_pixbuf and do_get_image should be moved to gtk util
WINDOW_TOPLEVEL: use type if we have one (a better one than POPUP for OR windows)
sys.stdout is None when running in GUI mode, causing alert box popups on error (ie: "no mode"). We need to ensure we always have log file redirection, even for early errors, and send the message there
lib/* and share/* with whitelist (too much cruft)
OpenGL support: big
CTRL_C needs event to exit main loop, force one?
DLLs for tortoise are the same, so skip them rather than overwrite?
etc..
Warning: make sure you remove all references to OSSBuild installations from your environment before building!
Updates:
CTRL_C works, sort of, it exits without cleaning up - which is better than hanging: r6302
etc..
Some useful porting links:
With r6337, I can now build a python 3.4 version too!
r6347 makes the sound fully supported with gstreamer 1.0
r6370 reduces the installer size by half (now almost the same as the GTK2 version), removing most of the bits we don't need and adding support code to easily pick and choose which components to include or not.
With all the changes up to r6379, it should now be usable in png and jpeg modes. We still have corrupted pixels in rgb (and with mmap), but at least now it should not crash! (webp is disabled completely in r6377 as it would crash reliably - will fix this later). The csc decoding step has a number of issues (mostly those pedantic py3k string conversions), so h264 and vpx are not usable yet.
New beta GTK3 build uploaded.
getting cairo to paint rgb pixels with python3 / gi is a nightmare, this almost does it
Despite a lot of time and effort spent on this, I see no way of painting with cairo without doing a roundtrip via PNG client side, what a waste! (details in r6394)
At least video decoding should now works (just a shame that it ends up doing: video decoding -> CSC -> RGB -> PNG -> cairo!)
I'll try to finish off this horrible mess ASAP, and hope that the OpenGL rendering will work better.
Many more refactorings and improvements in r6399.
The cairo backing now works well with both gtk2 (use XPRA_USE_CAIRO_BACKING=1 to activate it) and gtk3. It is interesting that all the backings behave slightly differently when resizing:
Remaining issues:
OpenGL support (so painting the screen won't be so agonizingly slow)
pycrypto fastmath #373
CTRL_C needs event to exit main loop, force one?
OpenGL)
XSETTINGS and root property support
RPMs?
--max-size option (see #263 for GTK2)
Enough for a first round of testing:
(re-assigning)
Note: Sustaining support for GTK+3 under Win32 - looks like GTK3 on windows isn't as well supported as we would have hoped..
For the python extensions:
C:\Python34\Lib\distutils\distutils.cfg:
[build] compiler = msvc
Cython, then everything else, ie: for pycrypto (without fastmath.. see #373), from a Visual Studio Command Prompt do:
CD pycrypto-2.6.1 C:\Python34\Python.exe setup.py build C:\Python34\Python.exe setup.py install
extra_compile_args with something like:
["/Ot", "/Wall", "/DLZ4_VERSION=\"r119\""]
Eventually, we may also want to compile all the dlls using msvc rather than a mix of msvc and gcc:
etc.
Please confirm that you can build a GTK3 version as per the instructions in this ticket then close this against milestone 0.14, the remaining issues are now tracked in #640.
Note: as of r7571 you need the cairo header file (preferably matching the DLL version installed) in C:\pycairo-1.10.0\pycairo\pycairo.h.
Note this ticket is only about testing the GTK3 build to make sure that the it runs on real hardware.
I have moved the need for a proper build system to #678.
Testing the beta 0.15.0-r7639 gtk3-py34 win client (against a fedora 20 0.15.0 r-7543 server, which seems to be running some gtk 2.24.24 - which hopefully isn't a problem?)...
Launch Xpra box which triggers the GUI launcher, I got a fail message (will attach a screen shot).
--opengl=on, OpenGL fails with the message: some required OpenGL functions are not available: glActiveTexture, glMultiTexCoord2i
Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\window_backing_base.py", line 266, in do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gtk_base\cairo_backing_base.py", line 100, in _do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gtk3\cairo_backing.py", line 85, in _do_paint_rgb File "cairo_workaround.pyx", line 83, in xpra.client.gtk3.cairo_workaround.set_image_surface_data (xpra/client/gtk3/cairo_workaround.c:1022) AssertionError: pixel buffer is too small for 1170x824 with stride=3520: only 0bytes, expected 2900480 2014-09-17 17:12:36,905 do_paint_rgb24 error Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\window_backing_base.py", line 266, in do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gtk_base\cairo_backing_base.py", line 100, in _do_paint_rgb24 File "E:\xpra\trunk\src\xpra\client\gtk3\cairo_backing.py", line 85, in _do_paint_rgb File "cairo_workaround.pyx", line 83, in xpra.client.gtk3.cairo_workaround.set_image_surface_data (xpra/client/gtk3/cairo_workaround.c:1022) AssertionError: pixel buffer is too small for 1170x824 with stride=3520: only 0bytes, expected 2900480
... launching with --opengl=on, in conjunction with either --encoding=png or --encoding=rgb, produces the same OpenGL failure message as with default encoding.
--encoding=png also resulted in a sound error and traceback:
2014-09-17 17:19:37,488 Unhandled error while processing a 'sound-data' packet from peer using <bound method XpraClient._process_sound_data of <XpraClient objec t at 0x4127558 (xpra+client+gtk3+client+XpraClient at 0x2a970d0)>> Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\client_base.py", line 585, in process_packet File "E:\xpra\trunk\src\xpra\client\ui_client_base.py", line 1623, in _process_sound_data File "E:\xpra\trunk\src\xpra\client\ui_client_base.py", line 1586, in start_sound_sink AssertionError
--encoding=rgb, aside from the awful performance, something is causing a Gdk-CRITICAL warning (I seem to have stumbled across it while trying to open the windows tray icon, but not reliably enough to reproduce at will, maybe only when the sound delay elapsed time is over 3000 at the time I click?):
2014-09-17 17:29:22,162 push-buffer error: <enum GST_FLOW_FLUSHING of type GstFlowReturn> 2014-09-17 17:29:22,166 stopping speaker because of error: push-buffer error: <enum GST_FLOW_FLUSHING of type GstFlowReturn> 2014-09-17 17:30:21,623 re-starting speaker because of overrun (Xpra_cmd.exe:3864): Gdk-CRITICAL **: gdk_device_get_source: assertion 'GDK_IS_DEVICE (device)' failed (Xpra_cmd.exe:3864): Gdk-CRITICAL **: gdk_device_get_source: assertion 'GDK_IS_DEVICE (device)' failed
With the png encoding though, it is functional, if without OpenGL.
xpra gtk3 py34 r-7639 gui launcher error message
Almost forgot to mention, when using a control-c to induce a SIGINT from the client command line, I am seeing an error message saying
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
There is also a windows application crash message box that opens (will attach another screenshot)... I feel like I saw another ticket related to this, but a semi-cursory search didn't turn any up (and I'm not certain if this is specific to the gtk client builds or not... will test some more when I get a chance).
xpra 0.15.0-r7639 gtk3-py34 client side control-c crash message
server, which seems to be running some gtk 2.24.24 - which hopefully isn't a problem?
Not a problem. Those are completely independent.
You can run the client against a server which does not even have GTK at all (assuming you can build such a server, I believe the OSX shadow server is not far off that), and you can run a client without GTK either (the html5 client, the defunct Qt client, the Android clients are all examples of this)
.. the GUI launcher, I got a fail message ..
Known issue: see comment:25
.. OpenGL fails with the message ..
Damn. That's the one I was really interested in.
I think I will just have to bite the bullet and buy some hardware (and run windows on it.. shudder) to be able to test.
Launching with
--encoding=pngalso resulted in a sound error and traceback:... instart_sound_sink
Probably not directly related to png encoding, but maybe png just makes it more likely we'll encounter this situation.
It looks like a real bug where we're trying to start receiving sound more than once.
If you can reproduce this one, please file a new ticket for it.
Attaching a full -d sound log sample would help.
Gdk-CRITICAL **: gdk_device_get_source: assertion 'GDK_IS_DEVICE (device)' failed
Looks like a GTK3 bug fixed upstream: gnome bug 696756.
We'll get the fix for this one when we build a newer GTK3 version.
Almost forgot to mention, when using a control-c to induce a SIGINT..
Known issue. And one that is hard to fix (I haven't found a way yet).
We may just have to live with it, at least for a while. Most users don't use the command line anyway, and those that do get to pick up the pieces.
But really, this ticket is old, and was meant to be tested in the 0.14 milestone. So, as long as the existing GTK3 0.13 or 0.14 builds run no worse than this one, please close this ticket and we can follow up in #640 and #678.
Unfortunately, testing with xpra-gtk3-py34_setup_0.14.1-r7376 windows client against the same fedora 20 server, with --opengl=on and with either --encoding=png or with no encoding specification, when trying to type into an xterm I can't seem to get any keyboard focus, instead getting the following error messages client-side whenever trying to interact with the xterms:
2014-09-18 17:32:03,185 do_paint_rgb24 error Traceback (most recent call last): File "C:\Python34\lib\site-packages\PIL\ImageFile.py", line 454, in _save AttributeError: '_idat' object has no attribute 'fileno' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Python34\lib\site-packages\PIL\Image.py", line 426, in _getencoder AttributeError: 'module' object has no attribute 'zip_encoder' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\window_backing_base.py", line 283, in do_paint_rgb24 File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\gtk_base\cairo_backing.py", li ne 145, in _do_paint_rgb24 File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\gtk_base\cairo_backing.py", li ne 196, in _do_paint_rgb File "C:\Python34\lib\site-packages\PIL\Image.py", line 1663, in save File "C:\Python34\lib\site-packages\PIL\PngImagePlugin.py", line 619, in _save File "C:\Python34\lib\site-packages\PIL\ImageFile.py", line 459, in _save File "C:\Python34\lib\site-packages\PIL\Image.py", line 430, in _getencoder OSError: encoder zip not available
Also, for an added bonus, I get the following error upon connecting:
2014-09-18 17:32:02,628 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 ( r7543) 2014-09-18 17:32:02,631 Unhandled error while processing a 'server-event' packet from peer using <bound method XpraClient._process_server_event of <XpraClient o bject at 0x3dc7b70 (xpra+client+gtk3+client+XpraClient at 0x2a690d0)>> Traceback (most recent call last): File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\client_base.py", line 583, in process_packet File "E:\xpra\tags\v0.14.x\src\Temp\xpra\client\ui_client_base.py", line 1116, in _process_server_event TypeError: sequence item 0: expected str instance, bytes found 2014-09-18 17:32:02,850 Attached to tcp:10.0.32.53:1201 (press Control-C to deta ch)
I can test again with a 0.13 GTK3 client if you'd like, but should I continue to use the 0.15 trunk server or an older version?
afarr: just use plain RGB, that's a PNG packaging bug.
Hmm... I seem to be running into the same problem even with plain RGB.
With: 0.14.1 r7376 windows 7 client (beta Xpra-GTK3-py34_Setup_0.14.1-r7376) 0.15.0 r7543 fedora 20 server
TypeError: sequence item 0: expected str instance, bytes found (..) AttributeError: '_idat' object has no attribute 'fileno' (..) AttributeError: 'module' object has no attribute 'zip_encoder' (..) OSError: encoder zip not available
Full (long and mostly redundant with the same errors repeating) log moved to attachment/ticket/90/pillow-errors.log
The xterms that launch are blacked out and show no cursor - clicking on a blacked-out xterm produces more of the same error.
--opengl=on:
More of the same: attachment/ticket/90/pillow-errors2.log
replace long quote with attachment
replace long quote with attachment - part2
The reason why you still hit those errors is that you set the main encoding to rgb, but png and jpeg were still enabled and ended up being used, causing the errors.
To force only rgb to be used: --encodings=rgb (not --encoding)
Now for the fix (long).
To build pillow from source with the 3 codecs we want on win32, do all this from a VC 2010 shell:
cd contrib
cd masmx86
bld_ml32.bat
Release|Win32 line from the preSolution GlobalSection (or you should be able to do the same from the VC gui if you have access it: select 'release' win32 build)
ZLIB_WINAPI; from the vc10 directory (!) - see http://stackoverflow.com/a/6559315/428751
msbuild contrib\vstudio\vc10\zlibvc.sln
These instructions are actually "nice" compared to the ones I found researching this.
Ensure that VC is configured as the default compiler for distutils, if not:
-c msvc to the python distutils build commands, OR:
You can now build pillow:
C:\Python34\Python.exe ./setup.py build C:\Python34\Python.exe ./setup.py install
After the build step, it will print a summary. Verify that all 3 codecs are enabled.
Next, verify that you can load images with pillow in each of the 3 formats:
C:\Python34\Python.exe -c "from PIL import Image;print(Image.open('E:\example.jpg')"
C:\Python34\Python.exe -c "from PIL import Image;print(Image.open('E:\example.png')"
C:\Python34\Python.exe -c "from PIL import Image;print(Image.open('E:\example.webp')"
For the record, we can ignore those warnings:
gdk_device_get_source : assertion `GDK_IS_DEVICE(source)` failed
which are already fixed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=696756
Testing again with same client (with windows 8.1 client w/4K monitor), with encodings=rgb & --opengl=on, playback seems to be pretty good... until I tried to test fullscreen on a 4K monitor. (I guess I shouldn't be too surprised.) The session locked half rendered and had to be quit, but behaved well up until I went crazy with a fullscreen command.
firefox from an xterm, I did see the following client-side output:
Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\ui_client_base.py", line 1942, in _process _window_icon File "E:\xpra\trunk\src\xpra\client\gtk_base\gtk_client_window_base.py", line 527, in update_icon File "E:\xpra\trunk\src\xpra\gtk_common\gtk_util.py", line 401, in get_pixbuf_ from_data TypeError: cannot use a str to initialize an array with typecode 'B'
Testing with the latest beta (0.15.0 r7856) I got the following client-side output upon starting a chrome window from an xterm:
(Xpra_cmd.exe:5740): GdkGLExt-WARNING **: wglMakeCurrent() failed
2014-10-07 16:02:53,326 gtk3.GLWindowBacking(3, (2560, 1378), YUV444P).gl_paint_
planar(..) error:
Traceback (most recent call last):
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 593, i
n gl_paint_planar
File "E:\xpra\trunk\src\xpra\client\gl\gtk_compat.py", line 48, in __enter__
AssertionError
2014-10-07 16:02:53,408 gtk3.GLWindowBacking(3, (2560, 1378), YUV444P).gl_paint_
planar(..) error: argument 2: <class 'TypeError'>: wrong type
Traceback (most recent call last):
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 603, i
n gl_paint_planar
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 672, i
n render_planar_update
ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type
(Xpra_cmd.exe:5740): GdkGLExt-WARNING **: wglMakeCurrent() failed
2014-10-07 16:02:53,494 gtk3.GLWindowBacking(3, (2560, 1378), YUV444P).gl_paint_
planar(..) error:
Traceback (most recent call last):
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 593, i
n gl_paint_planar
File "E:\xpra\trunk\src\xpra\client\gl\gtk_compat.py", line 48, in __enter__
AssertionError
2014-10-07 16:02:53,498 do_paint_rgb24 error
Traceback (most recent call last):
File "E:\xpra\trunk\src\xpra\client\window_backing_base.py", line 266, in do_p
aint_rgb24
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 478, i
n _do_paint_rgb24
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 549, i
n _do_paint_rgb
File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (sr
c\latebind.c:1201)
File "C:\Program Files (x86)\Xpra\OpenGL\GL\exceptional.py", line 46, in glEnd
return baseFunction( )
File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChec
ker.glCheckError (src\errorchecker.c:1218)
OpenGL.error.GLError: GLError(
err = 1282,
description = b'invalid operation',
baseOperation = glEnd,
cArguments = ()
)
Then, when I tried to navigate to a website from the start screen I got the following over and over:
Traceback (most recent call last):
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 595, i
n gl_paint_planar
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 648, i
n update_planar_textures
File "latebind.pyx", line 32, in OpenGL_accelerate.latebind.LateBind.__call__
(src\latebind.c:989)
File "wrapper.pyx", line 318, in OpenGL_accelerate.wrapper.Wrapper.__call__ (s
rc\wrapper.c:6561)
File "wrapper.pyx", line 311, in OpenGL_accelerate.wrapper.Wrapper.__call__ (s
rc\wrapper.c:6439)
File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChec
ker.glCheckError (src\errorchecker.c:1218)
OpenGL.error.GLError: GLError(
err = 1281,
description = b'invalid value',
baseOperation = glTexSubImage2D,
pyArgs = (
GL_TEXTURE_RECTANGLE_ARB,
0,
0,
0,
2560,
1378,
GL_LUMINANCE,
GL_UNSIGNED_BYTE,
<memory at 0x077ED880>,
),
cArgs = (
GL_TEXTURE_RECTANGLE_ARB,
0,
0,
0,
2560,
1378,
GL_LUMINANCE,
GL_UNSIGNED_BYTE,
<memory at 0x077ED880>,
),
cArguments = (
GL_TEXTURE_RECTANGLE_ARB,
0,
0,
0,
2560,
1378,
GL_LUMINANCE,
GL_UNSIGNED_BYTE,
<memory at 0x077ED880>,
)
)
I don't think we currently have a system to build GTK3 clients, so I'll need betas to test any further.
2014-10-07 17:53:39,299 client Protocol(SocketConnection(('10.0.32.53', 1201) -('10.0.11.129', 59823))) has requested disconnection: exit on signal SIGINT
2014-10-07 17:53:39,299 Disconnecting client Protocol(SocketConnection(('10.0.32.53', 1201) - ('10.0.11.129', 59823))): client request
2014-10-07 17:53:39,301 xpra client disconnected.
2014-10-07 17:53:39,307 internal error: read connection SocketConnection(('10.0.32.53', 1201) - ('10.0.11.129', 59823)) reset: [Errno 104] Connection reset by peer
windows 8.1 local error message pop-up on control-c exit client side
TypeError: cannot use a str to initialize an array with typecode 'B'
This one I failed to reproduce - which is strange seeing that this looks like the correct fix for it: r7907.
ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type
This one should be fixed in r7908. Then I found more instances of this same issue, fixed in r7909.
with a control-c, I'm getting an error pop-up locally
Yes, there are still lots of build problems (causing scary warnings), lack of proper control-C support in GTK3 (for which I have yet to find a suitable workaround), etc..
I have uploaded a new win32 beta build, which works OK with opengl enabled.
I still have to fix the cairo non-opengl fallback case, which seems to get a bit confused about the pixel buffer size: ... only 0 bytes, expected XXXXX
Then there is also the problem that the PyOpenGL rpm packages for python3 seem to have a problem... spent a lot of time on this, and then found that re-installing using easy_install-3.3 instead of RPM worked fine.
Is there anything new that I should be testing with this? It looks like yes, but I haven't seen any sign of any GTK3 client builds on our end, nor any newer than August 2014 on yours.
I have uploaded a newer GTK3 beta 0.15 build. Not sure how much things have regressed since this ticket was updated though - so there just to try out.
Then I tried to fix the 0.14.x branch - with some success (r8662, r8663, r8664, r8665), but ended up making things so much worse: I hit a cx_freeze problem that looked like it might be fixed with an upgrade.. which broke things even more. And downgrading doesn't help either!?
It is now stuck on one of the most unhelpful error message ever invented: cx_Freeze bug 28) What a waste of time.
OK, I hate having to do this, but I give up. Not going to bother with the GTK3 for the 0.14.x branch.
Hmmm... not pretty.
Tried to test with Xpra-GTK3-py34_Setup_0.15.0-r8663 (windows 8.1) against fedora 20 0.15.0 r8661.
Tried first with no flags, and again with --encodings=rgb, two xterm start-childs.
In both cases, the application promptly crashed with a windows error dialog box, and the following client-side output:
C:\Program Files (x86)\Xpra>xpra_cmd.exe attach tcp:10.0.32.53:1201 --encodings=rgb 2015-02-23 17:36:10,475 cannot load enc_vpx (vpx encoder): Encoder missing from xpra.codecs.vpx.encoder: currently broken with python3.. 2015-02-23 17:36:10,475 Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\codecs\loader.py", line 40, in codec_import_check File "xpra\codecs\vpx\encoder.pyx", line 478, in xpra.codecs.vpx.encoder.selft est (xpra/codecs/vpx/encoder.c:6083) AssertionError: currently broken with python3.. 2015-02-23 17:36:10,806 xpra client version 0.15.0 2015-02-23 17:36:12,477 OpenGL_accelerate module loaded 2015-02-23 17:36:12,477 Using accelerated ArrayDatatype 2015-02-23 17:36:12,477 OpenGL accelerate missing: numpy_formathandler 2015-02-23 17:36:12,492 Error loading OpenGL support: 2015-02-23 17:36:12,492 'tuple' object has no attribute 'red_float' Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\client\gtk_base\gtk_client_base.py", line 442, in init_opengl File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2237, in _find_and_load File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2226, in _find_and_load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1191, in _load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1161, in _load_backward_compatible File "E:\xpra\trunk\src\xpra\client\gl\gtk3\gl_client_window.py", line 11, in <module> File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2237, in _find_and_load File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2226, in _find_and_load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1191, in _load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1161, in _load_backward_compatible File "E:\xpra\trunk\src\xpra\client\gl\gtk3\gl_window_backing.py", line 10, in <module> File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2237, in _find_and_load File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 2226, in _find_and_load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1191, in _load_unlocked File "X:\Python34-x32\lib\importlib\_bootstrap.py", line 1161, in _load_backward_compatible File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 41, in <module> File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 40, in get_fcolor AttributeError: 'tuple' object has no attribute 'red_float' C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:461: Warning: The property GtkSettings:gtk-menu-images is deprecated and shouldn't be used anymore. It will be removed in a future version. 2015-02-23 17:36:12,713 detected keyboard: layout=us 2015-02-23 17:36:12,713 desktop size is 5120x2160 with 1 screen(s): 2015-02-23 17:36:12,713 '1\WinSta-Default' (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-02-23 17:36:12,713 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120 2015-02-23 17:36:12,713 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680 2015-02-23 17:36:13,196 enabled remote logging, see server log file for output
... on the plus side, it looks like the remote logging flag wasn't objected to.
Oh, that's interesting:
cannot load enc_vpx (vpx encoder): Encoder missing from xpra.codecs.vpx.encoder: currently broken with python3..
This one is a known issue, will eventually fix and remove the scary warning.
File "E:\xpra\trunk\src\xpra\client\gl\gl_window_backing_base.py", line 40, in get_fcolor AttributeError: 'tuple' object has no attribute 'red_float'
That's a bug with the border colour code with the opengl renderer code, only in GTK3, and since I don't have opengl enabled on my test systems... I never saw it. Will fix. Until then, you can try with opengl disabled to see if you get any further.
The colour bug is fixed in r8693 (briefly tested with virtualbox by forcing opengl on)
Retested with the r8890 GTK3 Py34 Win8.1 client against an 14.22 r8936 Fedora 21 server:
--opengl=yes and I get a really weird rendering issue. Will attach a screenshot
retesting with a .15.0 (latest) beta build from /beta (we don't have newer Fedora 21 builds yet):
edit:
C:\Program Files (x86)\Xpra>Xpra_cmd.exe attach tcp:10.0.32.137:2200 --opengl=ye s --encodings=webp,png,h264 2015-04-16 15:36:36,261 cannot load enc_vpx (vpx encoder): Encoder missing from xpra.codecs.vpx.encoder: currently broken with python3.. 2015-04-16 15:36:36,261 Traceback (most recent call last): File "E:\xpra\trunk\src\xpra\codecs\loader.py", line 40, in codec_import_check File "xpra\codecs\vpx\encoder.pyx", line 478, in xpra.codecs.vpx.encoder.selft est (xpra/codecs/vpx/encoder.c:6083) AssertionError: currently broken with python3.. 2015-04-16 15:36:38,796 xpra client version 0.15.0 2015-04-16 15:36:39,342 OpenGL_accelerate module loaded 2015-04-16 15:36:39,342 Using accelerated ArrayDatatype 2015-04-16 15:36:39,342 OpenGL accelerate missing: numpy_formathandler C:\Program Files (x86)\Xpra\library.zip\xpra\gtk_common\gtk_util.py:461: Warning : The property GtkSettings:gtk-menu-images is deprecated and shouldn't be used a nymore. It will be removed in a future version. 2015-04-16 15:36:39,499 detected keyboard: layout=us 2015-04-16 15:36:39,499 desktop size is 2560x1080 with 1 screen(s): 2015-04-16 15:36:39,499 '1\WinSta-Default' (677x285 mm - DPI: 96x96) workarea: 2560x1040 2015-04-16 15:36:39,499 DISPLAY1 (670x280 mm - DPI: 97x97) workarea: 2560x10 40 2015-04-16 15:36:39,686 server: Linux Fedora 21 Twenty One, Xpra version 0.15.0 (r8988) 2015-04-16 15:36:39,686 Attached to tcp:10.0.32.137:2200 (press Control-C to det ach)
Rendering bug when connecting to a 14.22 server
Client complained about no disk in Drive: E?
Something from the build environment must be leaking. I use drive E for the source code.
Some visual corruption would be expected until #465 is properly fixed. We'll have to test again after that.
after getting all the windows it crashes with the following traceback
There is no crash traceback in the output. The vpx one is a startup warning (which we may be able to re-enable already, or after #465 is fixed).
As for the opengl thing, see ticket/640#comment:17.
I have uploaded 3 beta win32 builds of the same svn revision with the fixes from ticket:640#comment:21 and ticket:640#comment:22 :
I hope this works well enough (with the caveats in the comments), close this ticket, and follow up in #640.
Retried with the following builds against an r9087 Fedora 21 server:
MSVC:
Got the following output from the server:
2015-04-20 11:35:25,311 client Protocol(SocketConnection(('10.0.32.137', 2200) - ('10.0.11.113', 59162))) has requested disconnection: CTRL_C
2015-04-20 11:35:25,311 Disconnecting client Protocol(SocketConnection(('10.0.32.137', 2200) - ('10.0.11.113', 59162))): client request
2015-04-20 11:35:25,328 internal error: read connection SocketConnection(('10.0.32.137', 2200) - ('10.0.11.113', 59162)) reset: [Errno 104] Connection reset by peer
MinGW:
edit: I see the caveat on #640 now. I'll refrain from posting the obvious and leave this be.
---
Closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/90