[Bug 1198312] Review Request: xpra - screen for X

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1198312



--- Comment #19 from Antoine Martin <antoine at nagafix.co.uk> ---
Upstream here. Sorry for replying late.
First, I would like to say that many of us are happy Fedora users and would
love to help in getting xpra in Fedora proper. So if you need us to do
anything, do let us know. Working with downstream distributions is always worth
the effort, we have greatly benefited from the feedback we have received so
far.

>> * gtk3                 : N
> I guess this is disabled because it is unstable, but please keep an eye out for this to change in future releases.
Indeed.
In 0.15 (which is running late), we have split the packages into:
* xpra-common
* xpra
* python3-xpra - which is the GTK3 version. Still not ready for prime time, but
at least getting the packaging in order by splitting things.

>> * qt4                  : N
> Same here.
This one has been dropped completely in 0.15 because of a complete lack of
maintenance.

Note: we're not going to unbundle jquery and websockets, because it would be
too costly for us to make builds for all the platforms we support (centos etc).
But if we can somehow make it easier, let us know.
The HTML5 client is making great progress in trunk.

Re CSC:
* you don't /really/ need pyopencl, we have the cython csc module as fallback -
which is usually fast enough
* I have experienced issues with pyopencl and the AMD icd, causing hangs
because of interference with the signal handlers... so we're unsure what to do
with this one (and in most cases, swscale is just as fast..)

> The wiki oddly says that opencl is enabled by default these days, but I guess the code is what counts so this can be skipped for now.
It is when built.
We have a "csc-modules" command line switch to be able to enable/disable csc
modules at runtime. I believe that what the wiki is meant to say is that it
will be used by default when present.

> Hmm... I am finding that when forwarding individual app windows (as opposed to the whole desktop) window resizing doesn't work properly.
It is meant to work properly... BUT, there are lots of issues in this area,
newer toolkits (especially GTK) seem to use server-side resizing. This is being
addressed in 0.15, at least with *nix clients for now.
> I am running F20 on the (remote) server, and F21 locally for the client, and when I resize the frame, the application itself doesn't resize properly. I tried this both with and without xdummy, and see the same thing. My client desktop is Gnome 3, and on the server I was simply running either xterm or gnome-terminal.
Well, that's very odd. I test with xterm hundreds of times a day, and I use
F21.. though no with Gnome 3.

> Package PyOpenGL-accelerate (or work with PyOpenGL packagers to build the
> accelerate module at the same time as the main package - even though they're
> separate tarballs, they are version lock-stepped as far as I can see).
Definitely MUST be in lockstep.
We have hit some very obscure bugs when those two packages had version mismatch
issues. I ended up adding version checks to prevent us using zero copy upload
in such cases (so it should now degrade well - at least as well as we can make
it)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component