FernV, calling FernV

Hi All, I had some spare time today and *I think* I ported most of NativeCAM to python3 and gtk3.
I am currently testing it, but I have never used it, so I would appreciate anyone else testing it.

Here is my fork of NativeCAM:  github.com/BogdanTheGeek/NativeCAM

I've added a requirements.txt, but it might be incomplete

After spending a few more hours trying to get to the bottom of why it keep segfaulting randomly, I can only presume that somewhere in this 6000 line mess, there is a race condition in the element tree updating code ( It accesses both GTK and X11 somehow ). As I have never used the tool, and it doesn't seem to work for me, I think this is where I leave it. I have learned quite a bit from the code base, but I think that it's too (unnecessarily) complex to update, and a full re-write might be a better use of time.

For anyone with more masochistic tendencies skill:
To get the icons for the ToolBar to show up, i had to do a dirty hack at line 3616 to set a gtk-icon based on the label of the action. This is extra stupid because the  actions are used to create the menu items as well as the toolbar. A proper solution would use Gio.Action.
The pop up field editor is what is causing the segfaults. Converting them to a normal dialog might fix it, but i think the bigger issue is the TreeView implementation. I think somewhere in the code we are leaking the values, or they get freed.

On the bright side, this has finally motivated me to finish my (very basic) programmatic CAM library and maybe turn it into a fully fledged tool.

Shameless plug:
github.com/BogdanTheGeek/libccam - Generate gcode with C functions (Originally targeted to GRBL, but should work with LinuxCNC)
github.com/BogdanTheGeek/cginc - OpenGL gcode visualiser with the ability to import STL files

Just putting it out there, QtPlasmaC has wizards that work for plasma cutting, how hard would it be to modify those for a mill?
Chris is working on this, i think, already, but not public yet.

What is the consensus on LinuxCNC interfaces.
I use GMOCCAPY for all my machines because I don't particularly feel nostalgic about Windows 95.
That would probably dictate what is the best GUI framework to use. Personally, I don't like GTK that much, but QT is not much better. I would rather have a cross platform, stand alone tool instead of a plugin. I also especially don't think python is the right tool to create UIs ( I have been using it with Tkinter and GTK for work ), but i understand the reasons for using it.

I also don't want to program my mill from LinuxCNC and for the Lathe, I am trying out github.com/andypugh/LatheMacros

I don't think there is consensus about anything. If somebody feels motivated to create something and share it with other users then it may be adopted or it may not.
The main issue is support and bug fixes. In that sense a project with the complexity of NativeCAM and just a single developer looking after it runs a higher risk of being abandoned code then AXISGUI which may not be as polished as other GUIs but has been adopted as the defacto standard that has been around for many years.

I have used NativeCam quite a bit in the past and the point of using a conversational tool like it is that it supports the machine operator in creating programs on the controller. If I need to switch to another machine then I might as well startup my CAD/CAM package.

@BogdanTheGeek
How can I install your version?