Plans for other UI in current debian (and future versions)?

Hi,

just out of curiosity I setup a virtual box with current debian (buster) and built there linuxcnc from git (master).
Build terminates without significant errors, but only tk-variants are able to run.

All gtk-Variants fail with missing gtkglwidgets - I installed the dev-package of that library, but build-process does not use it?
... and QT-Variants fail, cause kde in current debian is no more based on x-server, but on new wayland architecture.

... and even worse: end of this year is the end of python2.

So what are the plans of linuxcnc?

AFAIK there has not been an official plan made.
I see there has been work on python3
Python3 allows us to move everything to current libraries.

I don't know about Kde and wayland but it would make sense that Qt will fix that problem, or I guess we might have to use Gnome?

As you pointed out Tk (AXIS) works which, because it's very popular delays work on the rest.

Chris

I see there has been work on python3

Ok, is that work publicly accessible?
.

but it would make sense that Qt will fix that problem

Hm, I don't think, that Qt will see the resposability for that.
The point is, that communication between applications works different.
You might have a look at d-bus - guess that is the "new" communication layer.

regards Reinhard

I'm sorry I don't follow you.
AFAIK KDE uses Qt, So somehow Qt must work with wayland.
And then I would bet that pyqt works with wayland - or wow they are losing alot of programs.

What might not work is linuxcnc's current version of pyqt which is python 2 based.
So then we are right back to needing python 3 in linuxcnc.

Chris

Hi Chris,

you need a closer look to qt-variants of linuxcnc. Not everything, what happens there is the responsability of Qt!
These are the logs from terminal, running any of the qt-variants of linuxcnc: So the source of problems is the (python?)class xembed, which I believe is not from Qt but from linuxcnc. Right?

cheers Reinhard

Xlib is used for forwarding keyboard events to Qt when 'embedding' other programs into QT - so is not required unless you embed. I don;t know anything about Wayland but hopefully there is an equivalent (though the Xembed in pyqt doesn't work quite right at the moment either)
If you don;t use it then when focus is on the embedded panel keyboard events only go to the embedded program, so things like 'estop' and 'pause' etc won't work as expected.

It should be possible to detect that Xlib is not available and just lose the utility rather then error.

Chris