python3 and gtk3 support

[Antoine Martin]

Makes sense to bundle this together since python3 is only really supported with gtk3 and vice versa.

Main work items:

• backwards compatible python3 changes (via 2to3 mostly), most already done in r618, r619, r620, r621 and r622
• python3 strings: changes need testing on python2.5, also need to ensure that calling encode(..) and decode(..) does not adversely affect performance
• for other non-backwards compatible python3 changes, find a way to run 2to3 during build so we can keep a unified source tree in python2 format. (main issue here: catch exception syntax change)
• gtk3 imports have moved and now require annotation to silence pydev lint
• gtk3 methods on 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()?)
  • constants have moved
  • gdk.keymap_get_default (removed?)
  • gdk.Cursor can no longer use pixbuf..
  • ...
• gtk3 removed 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!)
• PIL (Python Imaging Library) is not available on python3 (so we can't use that to fix cairo either)

[Antoine Martin]

More done in r626, r627, r628, r629 and r630: most of the code is now python3/gtk3 compatible, except for:

• client.py (large changes due to cairo brokenness)
• protocol.py (string encoding changes - painful as this as repercussions elsewhere)

[Antoine Martin]

Some useful links:

• ​GObject Introspection
• ​Introspection Porting
• ​Migrating from GTK+ 2.x to GTK+ 3 (and in particular ​changes that need to be done at the time of the switch)
• ​GTK+ 3 Reference Manual
• ​The Python GTK+ 3 Tutorial
• ​Converting PIL Image to GTK Pixbuf
• ​pygi-convert.sh
• ​Ubuntu app indicators when using PyGObject (grrr)
• ​Convert PIL Image to Cairo ImageSurface
• ​PIL and Cairographics / PyCairo
• ​cairo.ImageSurface.create_for_data

[Antoine Martin]

rough patch for gtk3/python3 support

[Antoine Martin]

The patch above "works" in the sense that one can get something on screen with gtk3, but it has a number of important shortcomings:

• problems with the new 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.
• some re-drawing problems due to coordinates and clipping interfering with each other (shouldn't be too hard to fix)

[Antoine Martin]

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:

• most of the gtk3 function stubs at the top of 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
• the gtk3 version of the tray menu is mostly broken due to api changes: missing icons, about dialog errors, etc

[Antoine Martin]

• r654 fixes the about dialog
• r653 fixes the session info dialog

[Antoine Martin]

• r667 fixes get_modifiers_mask, set_geometry_hints and is_flag_set vs MAPPED/REALIZED

[Antoine Martin]

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.

[Antoine Martin]

delayed, this is hard!

[Antoine Martin]

Worth updating and getting the basics to work properly (keyboard, etc)

And maybe also: transparency, GL, cursors, ..

[Antoine Martin]

too much work, too little time

[Antoine Martin]

Lots of updates, this may be a better option than #300:

• misc fixes: r6205, r6203, r6194, r6192, r6191, r6190, r6208
• py3k string mess: r6189, r6184, r6183, r6181, r6179+r6180, r6178
• build updates: r6188, r6177, r6176 (broke rencode python build on win32 - fixed by r6211), r6210, r6213, r6214, r6215
• refactoring: r6202
• gtk3 x11: r6201, r6200, r6199
• mouse and beep support: r6206, r6207
• re-use new buffer code (see #465): r6198, r6212
• ugly cairo mess: r6197, r6196, r6187, r6186, r6185 (last three are candidates for backports)
• support for icons: r6195
• support for system tray: r6193

It is in a much better shape now, including some keyboard support.

Things that just need more work:

• transparency (should now work on osx and win32 without opengl?)
• window state (fullscreen, etc)
• spinner
• workspaces
• launcher
• session info and about dialog
• clipboard (oh joy)
• sound (gstreamer 1.x)
• osx integration work (..)

---

Things that won't work out of the box with python3:

• ​py2exe does not support python3 at all, maybe use ​cx_freeze (the python documentation claims to be able to generate installers directly, I doubt this will work well enough for our needs but worth a try: ​distutils builtdist: creating windows installers)
• ​gtkglext and ​pygtkglext aren't supported with gtk3... ​tegtkgl claims to be GTK+ 3.0 OpenGL widget, or maybe this ​gtkglext port to GTK+ 3 - Note: A git build is included below as part of the pygobjectwin32 installer.

• ​python netifaces does not support py3k

---

MS Windows issues

GTK (what a mess):

• ​pygobjectwin32 seems to be the place to get everything - the alternative would be to build from source with mingw and jhbuild...

Things that install OK on win32 via installers (preferred):

• ​pywin32

Things that install OK on win32 via scripts\pip.exe install or py -3 -m pip install:

• ​Pillow
• ​PyOpenGL (but PyOpenGL_accelerate needs a C compiler, see below)

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.

• ​lz4
• ​numpy (although binaries are available on their website, it is best to use pip to ensure we get clean and easy updates)
• ​PyOpenGL_accelerate
• ​Cython
• ​pycrypto (needs to have chmod.exe on the PATH)
• ​wmi

[Antoine Martin]

fixes netifaces to build with python3

[Antoine Martin]

Using ​Porting Extension Modules to Python 3 and ​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.

[Antoine Martin]

with this patch I can build with python3.4 and mingw

[Antoine Martin]

More fixes:

• gtk fixes (about and session-info now work): r6229, r6231, r6232
• encoders fallback / info improvements: r6217, r6218, r6219, r6220, r6221, r6222, r6223, r6227
• more string issues: r6225 + r6226, r6228, r6230

Harder (delayed):

• client launcher
• latency graphs (need porting to cairo..)

[Antoine Martin]

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

[Antoine Martin]

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.

[Antoine Martin]

Things to install using ​pygobjectwin32:

• gobject-introspection (replaces pygtk)
• gst-plugins
• gdkglext
• gst-plugins-extra
• gtk+
• pango
• gstreamer
• gdk-pixbuf
• dbus-glib
• gtkglext
• Development packages (use defaults)

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)

[Antoine Martin]

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:

• you will get a ​R6034 error on start (probably a missing DLL, or wrong compiler...) - update: now fixed
• you must use PNG encoding (which has native support in cairo), the others crash.. (horrible / inflexible API decisions in cairo)
• you probably have to remove OSSBuild from %PATH% and %PYTHONPATH% (though r6273 means this may no longer be strictly required, still better / safer)

[Antoine Martin]

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:

• the root window size reported by GDK is complete garbage and had to be sanitized at both ends. Maybe use the screen dimensions if the root window is wrong? (this error is visible from the process output: Gdk-WARNING **: gdkwindow-win32.c:1976: GetClientRect failed: Invalid window handle.
• mouse clicks seem to be off by some margin!
• most pixel encodings (except PNG) cause crashes, the RGB codepath needs fixing
• got this with webm: access violation reading 0x0000000 from libc.memcpy in decode.py
• session info is missing (needs a typedict to parse strings)
• some refactorings may be needed or useful:
  • the gtk2 client: 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
• win32 cx_freeze installer is too big: filter out lib/* and share/* with whitelist (too much cruft)
• OpenGL support: big
• clipboard and keyboard test tools need porting, will be useful
• enable server win32 builds?
• CTRL_C needs event to exit main loop, force one?
• transparency
• launcher
• gstreamer
• DLLs for tortoise are the same, so skip them rather than overwrite?

etc..

[Antoine Martin]

Warning: make sure you remove all references to OSSBuild installations from your environment before building!

Updates:

• sound works: r6315, r6308, r6306
• display geometry detection works: r6304, r6303
• work on launcher (incomplete): r6305, r6299
• CTRL_C works, sort of, it exits without cleaning up - which is better than hanging: r6302
• work on the clipboard tool: r6300
• keyboard tool works: r6299
• accelerators work: r6317
• window location fixed: r6318 (looked like it was a mouse position offset)

etc..

Some useful porting links:

• ​The Python GTK+ 3 Tutorial
• ​py gi docs
• ​Module zeroinstall.gtkui.pygtkcompat

[Antoine Martin]

• ​cx-freeze version 4.3.3 was released today and does include an installer for python 3.4 this time.
• ​pywin32 also got updated today, first update in almost 2 years. Definitely worth having.

With r6337, I can now build a python 3.4 version too!

r6347 makes the sound fully supported with gstreamer 1.0

[Antoine Martin]

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.

[Antoine Martin]

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.

[Antoine Martin]

getting cairo to paint rgb pixels with python3 / gi is a nightmare, this almost does it

[Antoine Martin]

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.

[Antoine Martin]

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:

• the gtk2 pixmap backing is very slow to resize (multiple expensive copies back and forth between pixbuf and surfaces which use different pixel orders)
• the cairo backing behaves very well (at least for this specific action - forgetting the awful paint codepath for a minute..)
• the GL backing is also slower than it should be (see #478)
• window icons are ignored - no idea why

Remaining issues:

• OpenGL support (so painting the screen won't be so agonizingly slow)
• clipboard support
• pycrypto fastmath #373
• the win32 cx_freeze installer could be trimmed down further (low priority)
• CTRL_C needs event to exit main loop, force one?
• fix transparency with cairo (or just use OpenGL)
• launcher
• fix webp
• mouse cursors support
• session info statistics are missing, graphs need rewriting using cairo (oh joy)
• XSETTINGS and root property support
• packaging: use separate RPMs?
• add --max-size option (see #263 for GTK2)
• maybe GTK3 will allow us to deal with grabs and application-modal windows?

[Antoine Martin]

Enough for a first round of testing:

• smo: build from source (most of the info is in comment:12, comment:15 and comment:18)
• afarr: check for crashes and other issues not spotted above (a GTK3 python 3.4 build at r6407 is in the beta area)

[Antoine Martin]

(re-assigning)

[Antoine Martin]

Note: ​Sustaining support for GTK+3 under Win32 - looks like GTK3 on windows isn't as well supported as we would have hoped..

[Antoine Martin]

For the python extensions:

• install the corresponding version of visual studio, ie: VS2010 for Python 3.4 (it can be installed side by side with VS2008, just install it afterwards)
• ensure that it will be used by placing the following contents into C:\Python34\Lib\distutils\distutils.cfg:

  [build]
  compiler = msvc
  

• build 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
  

• workaround for numpy: ​http://bugs.python.org/issue16296
• lz4: does not build with msvc at present (reported here: ​python-lz4 issue 27), you must replace the existing extra_compile_args with something like:

  ["/Ot", "/Wall", "/DLZ4_VERSION=\"r119\""]
  

• PIL: must be told where to find jpeg, zlib, webp, etc..

Eventually, we may also want to compile all the dlls using msvc rather than a mix of msvc and gcc:

• ​Building x264 on Windows with Visual Studio
• ​FFMPEG: Microsoft Visual C++ or Intel C++ Compiler for Windows
• ​VPX: Building For Windows Using Visual Studio

etc.

[Antoine Martin]

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.

[Antoine Martin]

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.

[alas]

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?)...

• Running the install and forgetting to uncheck the Launch Xpra box which triggers the GUI launcher, I got a fail message (will attach a screen shot).

• Launching from command line, with --opengl=on, OpenGL fails with the message: some required OpenGL functions are not available: glActiveTexture, glMultiTexCoord2i

• Forgetting aradtech's warning to use only png or rgb, and launching with auto encoding produces a nearly constantly repeating traceback which may be of interest:

  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.

• Launching with --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
  

• Launching with --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.

[alas]

xpra gtk3 py34 r-7639 gui launcher error message

[alas]

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).

[alas]

xpra 0.15.0-r7639 gtk3-py34 client side control-c crash message

[Antoine Martin]

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=png also resulted in a sound error and traceback:... in start_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.

[alas]

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?

[Antoine Martin]

afarr: just use plain RGB, that's a PNG packaging bug.

[alas]

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.

• Also having nearly the same problems without --opengl=on:

More of the same: attachment/ticket/90/pillow-errors2.log

[Antoine Martin]

replace long quote with attachment

[Antoine Martin]

replace long quote with attachment - part2

[Antoine Martin]

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:

• jpeg: ​OSError: decoder jpeg not available on Windows - fixes missing jpeg
• zlib (for png):
  • uncompress it
  • cd contrib
  • cd masmx86
  • bld_ml32.bat
  • edit contrib\vstudio\vc10\zlibvc.sln and only keep the 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)
  • remove all occurrences of ZLIB_WINAPI; from the vc10 directory (!) - see ​http://stackoverflow.com/a/6559315/428751
  • run msbuild contrib\vstudio\vc10\zlibvc.sln
  • copy zlib.h and zconf.h to Python34\include
  • copy zlibstat.lib to Python34\libs\zlib.lib (yes, you do have to rename the file)
• webp:
  • copy webp's include directory to python's include directory as webp (so you end up with Python34\include\webp\encode.h, etc)
  • copy webp's libwebp.lib to libs\webp.lib (yes, again, you have to rename the file..)

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:

• add -c msvc to the python distutils build commands, OR:
• ​How to use MinGW's gcc compiler when installing Python package using Pip? (reverse those instructions)

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

[alas]

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.

• Upon starting 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.

[alas]

• One other note, when disconnecting the GTK3 client, even in the absence of any client/server problems, with a control-c, I'm getting an error pop-up locally (will post screenshot) as well as the following message server-side:

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

[alas]

windows 8.1 local error message pop-up on control-c exit client side

[Antoine Martin]

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.

[alas]

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.

[Antoine Martin]

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: ​DLL load failed: %1 is not a valid win32 application: "%1", wtf? (upstream, just as unhelpful: ​cx_Freeze bug 28)
What a waste of time.

[Antoine Martin]

OK, I hate having to do this, but I give up. Not going to bother with the GTK3 for the 0.14.x branch.

[alas]

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.

[Antoine Martin]

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.

• this colour error:

  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.

[Antoine Martin]

The colour bug is fixed in r8693 (briefly tested with virtualbox by forcing opengl on)

[J. Max Mena]

Retested with the r8890 GTK3 Py34 Win8.1 client against an 14.22 r8936 Fedora 21 server:

• Client complained about no disk in Drive: E?
  • The E drive on this computer is the unused SD card slot - no card inserted
• On closing it terminates in "an unusual way" according to the cmd disabled
• Running with --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:

• Same no disk in drive E ouput

• Client successfully connects, but after getting all the windows it crashes with the following traceback (with and without Opengl enabled)on connecting, but no output when it crashes, just the generic Windows 'Program has stopped working, Microsoft is looking for a fix(heh)'

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)

[J. Max Mena]

Rendering bug when connecting to a 14.22 server

[Antoine Martin]

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).

[Antoine Martin]

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 :

• standard GTK2 build
• mingw GTK3 build
• msvc GTK3 build

I hope this works well enough (with the caveats in the comments), close this ticket, and follow up in #640.

[J. Max Mena]

Retried with the following builds against an r9087 Fedora 21 server:

---

MSVC:

• Client connected and gave me my windows (currently starting with Firefox, xterm, xterm), however, I was unable to right click on the tray icon to disconnect
  • in addition a CTRL-C to the CMD window started a disconnect but then the client hung, before closing but not exiting completely.

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

• However, a re-launch(closing the CMD window and opening a new one) with and without OpenGl? works as expected. Must have been a one-time fluke, but I can investigate further if needed

---

MinGW:

• I get a generic error ("blah" has stopped working, Windows isn't checking to fix it, etc etc) on disconnect every time. Other than that it works as expected.

edit: I see the caveat on #640 now. I'll refrain from posting the obvious and leave this be.

---

• No longer asking about the E: drive.
• Will mention the generic error in #640.

Closing.