Split from #90, remaining items so that this port can be used in place of the current GTK2 version:
XSETTINGSand root property support
--max-sizeoption (see #263 for GTK2)
work in progress patch for gtk3 + opengl support
dirty patch which sort of works if you ignore the stream of stacktraces!
working patch which breaks gtk2... so close!
working patch! just needs swap_buffers and packaging workaound for win32
cleaner version that works with single buffering only
opengl support merged in r7599, but some big issues remain:
swap_buffers, creating a new window just to be able to call it.. (that's because the gi bindings don't give us the methods we need to get to the window... maybe we should assign the gl window to a custom widget when it gets realized instead?)
The code is still an improvement I think, and may help with #608.
If gtkgl proves too problematic with GTK3, maybe we can use a different approach, like this one: gtkgl via X11 + ctypes (at least for X11..)
Warning: r7573 introduced a crash on cursor stuff..
Until it is fixed, run with
Much time wasted and still no clue: cursors are disabled on win32 until futher notice (done in r7625)
Summary of what's left:
some work in progress to try to support cursors on win32 using cairo (requires gtk 3.10)
RPM packaging for python3 in progress in r7673: we now generate 3 packages:
xpra(as before, the gtk2 client and server)
New TODO items:
/usr/binfiles should be neutral? (
It seems that there are issues with opengl + python3: Oh, addendum to PyOpenGL 3.1.0b3; Py_buffer on Python3 unsupported (more info on memoryview: numpy.getbuffer causes AttributeError: 'module' object has no attribute 'getbuffer')
r7599 broke opengl rendering on win32: it seems to revert to the
GDI Generic renderer, and fails to locate some required opengl functions (
More worrying is that no-one noticed for 200+ revisions!
Correction: the bug was spotted 3 days ago, see ticket:684#comment:3 where I suggested a way to get to the fix (playing with the manual double buffering toggle). As had been noted before (r2970, r2394), we MUST enable double buffering on win32: r7820 does this.
A new pygobjectwin32 release is out based on GTK 3.14. Hopefully this one will work a bit better without requiring too many changes (packaging or other).
Not too bad, r7931 allows us to build against this new release - sadly also breaks building against the older version...
Seems to work OK too. Downsides:
And still no development headers installed despite explicitly telling the installer we do want them, and even where we want them..
We still have to fix the cairo
set_image_surface_data with no data bug too.
As per #734, maybe we can re-instate the cursor code?
Not worth breaking the GTK2 build! see r8651
Some new sound problems, see ticket:669#comment:19
I am now also seeing some paint problems, both with the opengl and cairo backends... sigh.
I am seeing opengl rendering issues, so r9041 disables opengl by default on python3 (but it can still be enabled from the tray).
Also worth a try: updating to pygi-aio-3.14.0_rev16.
Minor build fixes in r9064. Tweaking the
distutils.cfg before building to match the compiler for each one of the BAT files is not longer required.
With the numerous tedious changes in r9069, r9070 + r9071, r9072, we can finally build with mingw or with msvc out of the box after installing the latest pygi bindings (see comment:19). It is almost certain that older versions of the bindings will not build correctly - despite using the same release as base... (3.14.0)
r9073 fixes some broken mouse events with these latest builds (only on win32 + py3k)
For msvc builds you will need:
C:\Python34\libsto allow the webp codecs to link properly
C:\Python34\Lib\site-packages\gnome\- somehow needed by the avcodec2 module (see r9074)? (why is the msvc build doing this?)
There is still a weird problem with the cairo workaround cython module:
We do need this module to make things fast enough to be usable.
It seems that the cairo workaround module actually does work, both with the msvc and mingw builds, just not on the build machine! (which makes it really tedious to test). On the other hand, setting window icon works on the build machine and not on other test machines... also very tedious. r9077 disables setting window icons with GTK3 on win32. I'll need to figure it out later. (I'm sure I had seen this before, but can't find out what we're supposed to do - fixed size? buffer problem?) Other new known problems:
etc.. Is GTK3 really worth the pain?
PS: as of r9076, we include the type of build in the setup filename, ie:
We'll have to see which one is best.
Stumbled upon these relevant comments (mostly on just how painful it is to move to python3): Pycairo.
Seeing how slow and poor the pycairo py3k bindings are (see r6394 for example), this could well be the solution we need. It has
create_for_data wrapped, including the stride argument we need.
Important note (I had to rebuild everything as the update from Python 3.4.2 to 3.4.3 just failed mysteriously every time), for gmp follow these instructions: ticket:373#comment:6
work in progress patch - fixes bencode for py3k
For the control-c handling, see ticket:626#comment:8
Useful links for py3k porting (see also ticket:90#comment:2):
GTK3 won't play nice with KDE by the looks of things: https://bugzilla.gnome.org/show_bug.cgi?id=735211: I'm actually happy that it's stopped working.
Already broke our fix for XPRA/winswitch windows suffer from the default drag on all empty parts window dragging behaviour. (API got moved to gobject then removed completely).
Constant API churn when it's not missing altogether. Ouch.
From what I am reading, the "proper" way of building GTK3 stuff is to use MSYS2 See also:
New items (mostly related to #885):
AssertionError: grok_modifier_map needs porting to GTK3: maybe do it in pure X11, remove "nuisance"?
XErrorclass can be common, world / wm / selection / gdk_bindings cannot be used with GTK3
HAS_X11_BINDINGSis too coarse
get_root_sizefor gtk3 is a workaround for win32, can we get rid of it now?
And maybe GTK3 handles max-size natively on win32? (so we could remove the window hooks we use as workaround - see #263)
This whole thread has useful pointers: Outdated win32 bundle
Workaround for the gobject3
SIGINT problems added in r9747, for details see unable to trap SIGINT.
Once this bug is fixed, we should probably add a version check and disable the workarounds if the gobject version has the fix... meh.
This is such a pain, going native might well be a quicker option. Re-scheduling.
There are newer GTK3 builds available: pygobjectwin32
Some work done on this for #1041, and some updates: where has gtkglext gone?
See this very good thread: http://markmail.org/message/umj6fzfimaptcxit: We have been asking for 15 years to include something like these 250 lines of code, that is ALL that is needed to bridge GtK and OpenGL. So they've merged some similar code to https://bugzilla.gnome.org/show_bug.cgi?id=707723. (NIH syndrome?)
It gets worse https://www.bassi.io/articles/2015/02/17/using-opengl-with-gtk/: the OpenGL support inside GTK+ requires core GL profiles, and thus it won’t work with the fixed pipeline API that was common until OpenGL 3.2 and later versions. And the GDK drawing model was simpler, in those days, so these libraries just took a native windowing system surface, bound it to a GL context, and expected everything to work - well yes, I use an API and I expect it to work, crazy isn't it.
Let's see how hard it is to do for X11: GTK3 Displaying OpenGL inside a drawing area, trivial. Ouch.
Time to ditch GTK3? It's a train wreck. Things that used to work fine in GTK2, don't work at all: performance, opengl, win32 port, osx port?, API stability, etc..
Found some build scripts for the full GTK3 stack: https://github.com/wingtk/gtk-win32 (based on the hexchat ones)
GL still does not work in GTK3 on osx: https://bugzilla.gnome.org/show_bug.cgi?id=740199
Some python3 fixes in r14839.
It seems that the GTK3 gtkglext bindings have already been removed in Fedora 25. To support opengl with GTK3 we would have to change the opengl code... and lose compatibility with the well supported and undoubtedly much more stable GTK2 backend. YUK.
Whatever the solution is, it is going to take a lot of work.
Minor improvements and fixes for 2.1:
As of r16251, the python3 client (and also python2 with cairo backend via
XPRA_USE_CAIRO_BACKING=1) works as well as the pixmap backend.
The X11 bugs have been fixed, etc - see comment:43 for details.
Minor fixes and improvements:
Changed ticket scope: just the client is tracked here, so we can close this. (there are too many fixes, so the backport is likely to just disable GTK3 in older branches)
Follow up python3 tickets:
btw, r14839 added hashlib.algorithms_available, but that's only available in Python 2.7.9 (and I'm still on Trusty with 2.7.6), so for now I've just edited it to read 'hashlib.algorithms' :-)
hashlib.algorithms_available, but that's only available in Python 2.7.9
Thanks, see #1674. (this not related to python3 or GTK3)
Follow up ticket: #1717
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/640