Writing a GUI, what's current, what's the future?

And this is it embedded into Axis, but that really isn't a good idea, Tk buggers up keyboard focus and you need a global keyhandler to ensure vital keystrokes get through to Axis.

ArcEye wrote:

I have shelved the GUI for now, because the NML layer underlying Linuxcnc is in the process of complete change and I want to see what shakes out before I spend more time on it.

Arguably it makes no difference and the GUI will do the same no matter what the underlying calls do, but because I wrote a large Qt library of classes to make the Linuxcnc calls
using Qt types and classes to support it, I want something stable to work on before I continue.

I am now mostly through writing a qtVCP replacement for pyVCP, which already works fine, but the devil is in making it usable to non C++ programmers.

There is resistance to using any compiled language over a scripted, run-time compiling one, which hides the compile step from the user.

The push behind this and a replacement for gladevcp, is that gtk is at the end of its life and anyway the tk tcl widget set is tired.

Taster below
regards

Looks like a good start! I don't blame you for holding off until things stabilize. If I have time available when that happens, I'd like to lend a hand to the effort if you need it.

As for needing to support non-C++ programmers, a couple of thoughts come to mind. Have you seen Qt Script before? I haven't used it for a project yet, but I've been aware of it for a while. qt-project.org/doc/qt-5.0/qtscript/qtscript-index.html

Since the LinuxCNC crowd seems so hot on Python, another option might be a binding like PySide. qt-project.org/wiki/About-PySide ... I believe there are a few different Python language binding projects. Any of those solutions may fall into "run time compile" though - I don't know enough about how they work under the hood.

Regardless of specific implementation, my instinct would be to write the majority of the GUI in C++, and then allow for user configuration and add-ons via some type of scripting language.

I mentioned embedding Qt earlier. I realized I forgot to mention that it's possible to do this *without* the need for X11. You can build Qt for an embedded environment and target it directly for a framebuffer. Maybe I'm alone in this desire, but I like the idea of a truly embedded build for LinuxCNC - one which does not depend on having a R/W filesystem, and does not have the extra bloat of X11, etc. This is how I build robust embedded Linux systems for work, so I'm sure that influence has something to do with it.

Since the LinuxCNC crowd seems so hot on Python, another option might be a binding like PySide. qt-project.org/wiki/About-PySide ... I believe there are a few different Python language binding projects. Any of those solutions may fall into "run time compile" though - I don't know enough about how they work under the hood.

Someone else is looking at the qt-python bindings, but I am afraid it does not interest me.
I will try to make it a usable as possible, perhaps a configuration GUI to convert the .ui file and build the userspace component (I currently just have a script for this)

I am not interested in world domination and producing 'the VCP for Linuxcnc', just producing something for my own satisfaction.
If someone else wants to use it, they will have to put a little effort in, not just expect to be spoon fed

I mentioned embedding Qt earlier. I realized I forgot to mention that it's possible to do this *without* the need for X11. You can build Qt for an embedded environment and target it directly for a framebuffer. Maybe I'm alone in this desire, but I like the idea of a truly embedded build for LinuxCNC - one which does not depend on having a R/W filesystem, and does not have the extra bloat of X11, etc. This is how I build robust embedded Linux systems for work, so I'm sure that influence has something to do with it.

I used to program in QtEmbedded (qpe) for ARM embedded devices and wrote some programs for the Zaurus range.

However the embedding here is strictly one X widget into another X window, which should be simple with an X embedding compliant system, but unfortunately Tk isn't.
Will not be a problem when I have a GUI in Qt to embed into.

There is a lot of work going on with ARM and the BeagleBone Black for reprap machines.
This might be the area where a proper embedded system would shine
You can catch up looking at the developers list archives, if you are looking for a challenge!
sourceforge.net/mailarchive/forum.php?forum_name=emc-developers

If I have time available when that happens, I'd like to lend a hand to the effort if you need it.

Thanks, I will bear in mind.

regards

Interesting to see more details about others work, I have been doing a little bit here and there on my ideas, but it always seems I am waiting for other things to stabilise.

I have been compiling ARM real time kernels for rpi, but it seems that maybe its best to wait for RT_PREEMPT to mainline in 3.12.
I have also been looking at possible cross platform gui library, but seems there is not much available, so again waiting for that.
I have also found there are going to be a few changes to kernel support for DMA on the rpi, so that also needs to be waited for.

QT sort of sounds like a possible option but I have no experience of QT and so am waiting and hoping for pi3d for become a usable option.

I would like to avoid huge dependecy lists, I don't know what is required to have base QT system running, I am guessing python is fairly low overhead?


I did add some outline gui skecthes to the pi3d project and the maintainer tidied them up and added them to the last release, but I think pi3d still has a long way to go for good cross platform support, and android has only been talked about with no actually work done.

I am hoping to create a gui that can config and control and simulate hal simply by a text pipe, so the gui can connect from any device and possibly remote connect into linuxcnc system by halrmt or halcmd.

I was going to create something similar to vismach where all joint jositions are controlled by getting the value from the pipe 'gets jointn', not sure yet how I will create a preview of gcode, and not even sure how it all fits together with rs274 (does that module depend on OpenGL libs??). I am hoping to create something fairly light weight that only depends on a few libs and uses only GLES for display.

I messed around with some pi3d code that create the hal config but had the strrange problem that scripts/halrun would not run as sim when opened with the python popen command, this problem also shows in scripts/sim_pin and stepgen, but strangly running scripts/halrun from the command line runs okay???

The error from my test python script (and stepgen and sim_pin) is similar to the below:
I actually changed the python to pipe all the commands to a textfile then ran halrun on command line and copy pasted file to the console and it all ran okay, no idea why (I checked environment vars to see there were no differences)

I do all my development on a vmware machine in linuxcnc sim mode and running a realtime sys is not really viable.

Anyone have any ideas about the problem with halrun run from popen??

Hi

I would like to avoid huge dependecy lists, I don't know what is required to have base QT system running, I am guessing python is fairly low overhead?

As far as python version of Qt having low overhead, aside from all its own generic python libraries, it calls the Qt bindings library which then calls the the main Qt libraries, so more overhead

Afraid I have never tried running halrun through a fork, so can't comment on that.

regards

mungkie wrote:

Interesting to see more details about others work, I have been doing a little bit here and there on my ideas, but it always seems I am waiting for other things to stabilise.

Anyone have any ideas about the problem with halrun run from popen??

Stepconf and pncconf run halcmd thru a Popen fork.

cmorley wrote:

Stepconf and pncconf run halcmd thru a Popen fork.

And they seem to have the same problem if run when linuxcnc is compiled as sim mode??

Maybe I have made some mistake and also I forgot to say that I am using unified-build-candidate-3

What is the problem in SIM mode? I have not used UB3
Chris M

I don't know if the problem is UB3 or just linuxcnc in general?

as said above it does not load halrun commands properly, my guess is that the important part of error message is:

i.e., rtapi_app_posix is not loading correctly, I would guess that maybe popen sends the loadrt commands too quickly and the module is not loaded before the next command interferes with loading.

Of course this does not seem to be the case from testing from command line terminal as I copy pasted the exact text into the terminal after running halrun and it all loaded okay.

I also added some time.sleep(1) commands between each loadrt command wriiten to the popen pipe in the python test code and still the error occurs.

I also copied in the environment vars and rip-environment script, I have not really done full testing to try and trace things yet, any help would be appreciated as its something that has just been left not working while I get on with other projects.