Linux support and decoupled UI

[Di3mex]

I and the guys on the PrintNC discord have been discussing Linux support and the UI of ioSender. Many of us would much prefer to run the gcode-sender on Linux for various reasons. Mainly stability and also increased performance and reliability of Linux on older lower powered systems that would be a prime candidate for a dedicated machine to be used to interface with a CNC.

We came to the conclusion that if the references to Windows libraries and the hard-coded parts are removed we could potentially code the UI in another language like python. Even if the new lightweight UI doesn't have all the features at the beginning I think it will still be really useful and can be expanded in the future. Getting the code into a state that it can be easily interfaced with will probably be easiest for someone already familiar with the code. Then someone else can step in and bolt a new UI on top and call it a day.

[terjeio]

If you look at the project you will see that it is split in several sub-projects, the CNC Core project beeing the central part. GrblViewModel.cs parses messages from grbl and dispatches changes in data via events to other parts of the program - the basis for using the C# MVVM design pattern. This means the UI is already well separated from the core business logic.

I have no idea how much work it will be to port this to another language, and if it is to be done it has be by someone who know that language and associated libraries well. However, I can try to support anyone who want to give it a go.

Then someone else can step in and bolt a new UI on top and call it a day.

It sound simple, but IMO it is not. I have spend an insane amount of time to get the sender to where it is today. A large part of that has been research for how to do stuff (it is my first WPF project) and testing. I am too old to start over with a new language/framework - and I, I guess like most of you, want to spend time in the workshop...

[Di3mex]

Well the core would have to be cleansed from references to Windows libraries to begin a porting process to Linux. The first file I opened had using System.Windows.Media.Media3D;

So I think we can switch from an idealistic future viewpoint to a more realist viewpoint to see what we can improve with a minimal amount of work. Let's focus on the main "grbl" view which one spends the most time in.

To me all these pop out views should be persistent in the left and right columns of the main view. There is enough space especially in the left column to add the MPos drop down and add the jogging view into the right view.

Adding colours to the UI will make it feel a lot more alive too. So as a simple start one could start adding colours to the axis that are consistently used throughout the UI. A simple suggestions would be to copy the colours from Fusion360 (x=red, y=green, z=blue). With these colors one could colour the labels in the DRO, MPos and the jogging buttons on the jog view.

I was using the center finder view yesterday for the first time. I didn't realise that the two images are selectable. They looked like images that are just explaining the movements. What would have helped me a lot is a clear visual indication that one of the options is selected. So instead of having the selection colour be a dark grey in the sea of grey a light blue box surrounding the option would have been a lot clearer. Of course you have the text there explaining that it is selectable. But whenever you have to add text to explain what the user needs to do that is a red flag. Instead you could think about what you could do to make it more clear what the user needs to do by changing the UI. I for example only read the red text and didn't process the black text at all.

[phil-barrett]

It would be fantastic to have a version that runs on Linux. I could see using a RasPi to connect to a grblHAL board, especially via Ethernet for better reliability. Hopefully, it could be constructed in such a way to allow add-on/plug-ins that could be used across different OSes.

[terjeio]

Well the core would have to be cleansed from references to Windows libraries to begin a porting process to Linux.

You cannut just "cleanse" references to Windows libraries - either you have to code an alternative from scratch or find an existing one compatible with the language chosen for the project (I assume not C#). Or drop the functionality provided by the library...

To me all these pop out views should be persistent in the left and right columns of the main view. There is enough space especially in the left column to add the MPos drop down and add the jogging view into the right view.

There is not any space available with the minimum screen resolution requirement for the "standard" version, however the XL version has such a layout.

Adding colours to the UI will make it feel a lot more alive too.

Some may like that, I do not. More configuration options to add (skinning?).

So instead of having the selection colour be a dark grey in the sea of grey a light blue box surrounding the option would have been a lot clearer.

Yes, maybe so. Same argument as above? UI design is hard - I am not an expert on that.

It would be fantastic to have a version that runs on Linux

I agree, is there anybody out there ready for the challenge? I am smart enough to not start doing that myself as I have a fair idea of how much work it will be (for me at least - learn a new language, research libraries to use and what not)...

[tcurdt]

Just stumbled across this ticket. To me it seems to make much more sense trying to get it working using Mono than trying to bolt on some Python UI. Having a separate UI and "calling it a day" sounds very unrealistic. This is not quick task - but Mono might still be the easiest. Just my 2 cents.

[terjeio]

@tcurdt Mono does not support WPF (and neither the MVVM design pattern that is used?) so is not a way forward unless porting it back to a Forms application like the first version was.

[tcurdt]

Just to give some context: https://www.mono-project.com/docs/gui/wpf/

At this point, no group in the Mono project has plans to implement Windows Presentation Foundation APIs as part of the project. ... At this point, we strongly suggest that users interested in WPF adopt Xamarin.Forms instead as it offers a rich set of cross platform APIs and features (and has a WPF driver too).

Sad - but sounds like you might be right. Also a bigger task.

[hankecnccc]

Well the core would have to be cleansed from references to Windows libraries to begin a porting process to Linux.

You cannut just "cleanse" references to Windows libraries - either you have to code an alternative from scratch or find an existing one compatible with the language chosen for the project (I assume not C#). Or drop the functionality provided by the library...

To me all these pop out views should be persistent in the left and right columns of the main view. There is enough space especially in the left column to add the MPos drop down and add the jogging view into the right view.

There is not any space available with the minimum screen resolution requirement for the "standard" version, however the XL version has such a layout.

Adding colours to the UI will make it feel a lot more alive too.

Some may like that, I do not. More configuration options to add (skinning?).

So instead of having the selection colour be a dark grey in the sea of grey a light blue box surrounding the option would have been a lot clearer.

Yes, maybe so. Same argument as above? UI design is hard - I am not an expert on that.

It would be fantastic to have a version that runs on Linux

I agree, is there anybody out there ready for the challenge? I am smart enough to not start doing that myself as I have a fair idea of how much work it will be (for me at least - learn a new language, research libraries to use and what not)...

What a mistake to choose C# .NET, it is not cross platform

[phil-barrett]

What a mistake to choose C# .NET, it is not cross platform

Easy to say but consider the alternative. If the .net libraries and C# not been available, ioSender might not have been created. The portability issue is a far preferable outcome.

[shooter64738]

Having written software for several decades I onow takes a lot of effort. Terje did it on his own time for free. Windows is one of more popular operating systems for personal use. My HMI also runs on a windows platform.

Props to him for creating and maintaining it. If someone wants to port all of it to Java, have at it.

[hankecnccc]

What a mistake to choose C# .NET, it is not cross platform

Easy to say but consider the alternative. If the .net libraries and C# not been available, ioSender might not have been created. The portability issue is a far preferable outcome.

I did not criticize or accuse "Terje", but said that the decision to choose c# to develop iosender was a mistake, I chose candle2 developed by QT, it is cross-platform, it can run on windows, linux, especially on embedded linux Running, I have tested running on raspberry pi 4 with stm32 MP157, they work well and have 3D graphics

[hankecnccc]

What a mistake to choose C# .NET, it is not cross platform

Easy to say but consider the alternative. If the .net libraries and C# not been available, ioSender might not have been created. The portability issue is a far preferable outcome.

I did not criticize or accuse "Terje", but said that the decision to choose c# to develop iosender was a mistake, I chose candle2 developed by QT, it is cross-platform, it can run on windows, linux, especially on embedded linux Running, I have tested running on raspberry pi 4 and stm32 MP157, they work well and have 3D graphics

[phil-barrett]

What a mistake to choose C# .NET, it is not cross platform

Easy to say but consider the alternative. If the .net libraries and C# not been available, ioSender might not have been created. The portability issue is a far preferable outcome.

I did not criticize or accuse "Terje", but said that the decision to choose c# to develop iosender was a mistake, I chose candle2 developed by QT, it is cross-platform, it can run on windows, linux, especially on embedded linux Running, I have tested running on raspberry pi 4 and stm32 MP157, they work well and have 3D graphics

A bit sensitive? I was replying to the criticism of the choice of C#. Nowhere in my comment I did say anything about you criticizing Terje.

However, now that you bring it up, I find it hard not to see a criticism of him in your original comment.

[hankecnccc]

However, now that you bring it up, I find it hard not to see a criticism of him in your original comment.

What? On the contrary, I have always praised the original author of Terje and grbl as the greatest Norwegian

[hankecnccc]

grbl makes 3d printing very powerful

What a mistake to choose C# .NET, it is not cross platform

Easy to say but consider the alternative. If the .net libraries and C# not been available, ioSender might not have been created. The portability issue is a far preferable outcome.

I did not criticize or accuse "Terje", but said that the decision to choose c# to develop iosender was a mistake, I chose candle2 developed by QT, it is cross-platform, it can run on windows, linux, especially on embedded linux Running, I have tested running on raspberry pi 4 and stm32 MP157, they work well and have 3D graphics

A bit sensitive? I was replying to the criticism of the choice of C#. Nowhere in my comment I did say anything about you criticizing Terje.

However, now that you bring it up, I find it hard not to see a criticism of him in your original comment.

grbl makes the ecology of 3d printing development unprecedentedly powerful, but it is not optimistic in CNC. I want to contribute a little of my strength to help grbl in the development of CNC. I taught myself a little electronic technology and drawing PCB. I made esp32grbl and grblhal based The board is for sale, I recorded some grbl tutorials, should I be a good guy?

[hankecnccc]

What a mistake to choose C# .NET, it is not cross platform

Easy to say but consider the alternative. If the .net libraries and C# not been available, ioSender might not have been created. The portability issue is a far preferable outcome.

I did not criticize or accuse "Terje", but said that the decision to choose c# to develop iosender was a mistake, I chose candle2 developed by QT, it is cross-platform, it can run on windows, linux, especially on embedded linux Running, I have tested running on raspberry pi 4 and stm32 MP157, they work well and have 3D graphics

A bit sensitive? I was replying to the criticism of the choice of C#. Nowhere in my comment I did say anything about you criticizing Terje.

However, now that you bring it up, I find it hard not to see a criticism of him in your original comment.

Google Translate may bring some misunderstandings? My native language is Chinese

[tcurdt]

I stumbled across https://github.com/avaloniaui/avalonia and was just remembering this ticket. Could that maybe be an option @terjeio ?

[cbaugher]

Bumping this for show of interest. There seem to be no linux compatible gcode senders with a lathe mode.

[phil-barrett]

It's kind of unlikely. But have you tried running under wine?

[cbaugher]

It's kind of unlikely. But have you tried running under wine?

I haven't but I guess I could try. Thing is I intend to use an rpi4 8gb, which seems to be not as well supported being that it needs a 64bit OS.

[cbaugher]

So I messed around quite a bit trying to get iosender to run under wine, without any luck. In my case it's even more difficult because I'm trying to do it on a pi4, which is ARM based. That means wine has to run under an x86 emulator, and it ends up being too many layers of stuff to be a workable solution.

Now I'm looking at the above mentioned Avaloniaui. This is looking like a far more direct and therefore promising way to go. It's essentially a modern replacement for WPF that also supports the newer .NET versions. There is a blog post here that describes one developers experience porting from WPF to Avalonia.

https://www.jammer.biz/porting-wpf-to-avaloniaui/

I have virtually zero experience with Windows development and only some experience developing UIs, but from what I can tell this is almost certainly the easiest path towards a Linux version of iosender that there will ever be. There's no way I'll be able to do this on my own but I'm going to keep poking at it anyway.