Would this project be a candidate to port to MAUI?

[eastshores]

I just found this project and it looks pretty fantastic as far as maturity. I suppose I can dig deeper into the code but I was wondering if there might be any interest in porting this to a MAUI based project that could modernize the UI and make it available to run on any device? I assume if there are hooks into the classic windows .net framework it might be around the COM port comm.. and maybe the 3D view

[cbaugher]

Late last year I started investigating the possibility of making Iosender work on non-Windows platforms, specifically Linux desktop. I even posted a discussion topic about it here:

#344

Sadly no one at all has responded. :-(

I'm not a Windows programmer but from what I understand MAUI doesn't support targeting the Linux desktop environment. That seems like kind of a huge deficiency if you want to support non-Windows environments.

My conclusion was that for Iosender, Avalonia would be the best toolkit to use because it would make the best use of the existing code base. It's something I would certainly like to contribute to, but there's no way I could lead such a project.

If you're interested, by all means feel free to post in the above thread!

[terjeio]

Sadly no one at all has responded. :-(

I should have responded earlier, sorry for not.

Currently I am spending a lot of time on grblHAL - ioSender is suffering from that.
I am keen to make ioSender run on Linux as Windows 10 is the last version I intend to use myself - since I do not like the direction Windows is moving in. If, and how, this can be done needs some research to be done. The primary issue is if the .Net MVVM model is supported or not - the application is built using that paradigm, a change in this will require a complete rewrite. Controller communication is abstracted and can easily(?) be implemented using different libraries - there are in fact two different serial port libraries supported already. The 3D viewer code is in a separate subproject and can be replaced a well. IMO the "business logic" is fairly well separated from the UI so a new UI might not be too hard to implement - coming up with a design is another story.

Anyway - if porting to new framework is to be done the way to go will be to move the sender to a separate repository and get more developers to join in the effort?

[cbaugher]

Sadly no one at all has responded. :-(

I should have responded earlier, sorry for not.

Hey, no worries! I totally understand. GrblHal is already a huge project, so being able to handle that and IOSender is approaching hero status!

Currently I am spending a lot of time on grblHAL - ioSender is suffering from that. I am keen to make ioSender run on Linux as Windows 10 is the last version I intend to use myself - since I do not like the direction Windows is moving in. If, and how, this can be done needs some research to be done. The primary issue is if the .Net MVVM model is supported or not - the application is built using that paradigm, a change in this will require a complete rewrite. Controller communication is abstracted and can easily(?) be implemented using different libraries - there are in fact two different serial port libraries supported already. The 3D viewer code is in a separate subproject and can be replaced a well. IMO the "business logic" is fairly well separated from the UI so a new UI might not be too hard to implement - coming up with a design is another story.

Exactly, all of that. The nice thing about Avalonia is that it is designed to use MVVM, so there shouldn't be much re-architecting needed. From what I can tell most of the real work will involve converting all the "Windows" controls to Avalonia. My guess is that this wouldn't be terribly difficult for a reasonably experienced Windows programmer.
But anyway this is why I started the discussion thread. To get started looking at it and lay out a plan for taking IOSender to the next level.

Anyway - if porting to new framework is to be done the way to go will be to move the sender to a separate repository and get more developers to join in the effort?

Yes, I think that's probably it. A big question though is how to approach the port. My own investigation used sort of a bottom up approach where I started with the existing code and plopped it all into a blank Avalonia project. This was ok until I started looking at all the controls. Now I'm wondering if it might be better to go top down instead and recreate just the interface (view) first and then add in the logic (model) behind it once the view is mostly worked out?

[Jay-Tech]

I have looked into this for other projects and work Avalonia in my opinion is better fit its really close to WPF xaml, But a big issue with windows and their new big thing is they will often abonden the project or move projects such as Avalonia in a complete differenent direction within a few years and drop support. I do not know and or do much web developement but senders like gsender form sienci labs that are javascript based probably offer a bit more flexability when it come to what platform they are running on. But here is a link to a UI shell based on IOsender in Avalonia https://github.com/Jay-Tech/AvaloniaTestSender.git

[cbaugher]

It is an important question, what is the predicted lifespan of the language/framework that IOSender is based on? To my knowledge Avalonia is not owned or controlled by MS, so they are free to do whatever they want essentially. Of course MS will EVENTUALLY stop supporting WPF, but it doesn't appear that will happen any time soon. And even when they do Avalonia can keep going since it's a replacement for WPF.

Then there is the larger more philosophical question of where IOSender should go in the future? Is it always going to be a "desktop" application targeted to Windows/Mac/Linux desktops? Or should it be able to run on any device? Would a web based app be better, like Klipper for example? I think if IoSender is going to undergo any significant changes these need to be considered.

This also to some extent depends on what the future of GRBLHAL is.

[Jay-Tech]

WPF was once an open source project called Avalon. Avalonia still relies on .net 6 or higher which is also open source but its the framework for Microsoft and c#. Wpf will probably be around a very long time even if its not officialy supported anymore much like VB and winforms are, but still get used everytday. Think it really comes down to the need or desire for IOsender to be OS dependent and is it worth the effort for some one or group to do it and not so much a end of life issue The point of my other post was not sure I would really count on anything new from Microsoft to accomplish cross platform.

[cbaugher]

Moving IOSender to another language/architecture would be a major undertaking. Whether or not it would be worth it; I have no idea. I agree it seems unlikely that C#/.net/WPF will go away any time soon. So I would say sticking with them is probably ok, though it does limit the pool of developers to some extent. That would be an argument for moving to a more agnostic language/framework.

Is MVVM used anywhere else besides C#/.net?

[terjeio]

My own investigation used sort of a bottom up approach where I started with the existing code and plopped it all into a blank Avalonia project. This was ok until I started looking at all the controls. Now I'm wondering if it might be better to go top down instead and recreate just the interface (view) first and then add in the logic (model) behind it once the view is mostly worked out?

Bottom up is, IMO, the correct approach. The core project is UI-less and is the foundation. To create a basic working app only a few controls has to be added plus a main application that binds everyting together. Then expanded the app by adding controls/projects.
I deliberately splitted the application in several projects to make the parts replaceable. E.g. the CNC Core project does not reference any of the other projects, the next layer is CNC Controls which the rest of the controls and the app depends on.
E.g. the Config App only references the the CNC Core and CNC Controls projects.
I have to admit that not everything is strictly conformant with the MVVM pattern - after all the sender is my first and only such project. But I do not believe this should cause any major issues when moving to a new UI.

Moving IOSender to another language/architecture would be a major undertaking. Whether or not it would be worth it; I have no idea.

I am surely not going to do it. If it is worth it depends on whether a new sender offers anything that makes it desirable over other senders? I do not even know what specific features ioSender has that makes users want to use it.

Is MVVM used anywhere else besides C#/.net?

I think so, I would say I even use the paradigm in some of my embedded code.

So how to move forward? Start with the @Jay-Tech project? And if someone else than me want to drive it I am happy with that.

[Jay-Tech]

First, I think IOsender is great and offers more features than any other sender I have come across, so I get why people push for Mac and Linux support.
I broke a lot of things from Iosender when I made a touch version of it. I was primary focused on making a somewhat specific purpose 3 / 4 axis mill or router sender and I do not have the ability to test stuff like lathe, 5 axis to name a few of the larger items so I shut them “off”. So might not be a good start basing it off what I linked as a reference which that was started from the spinoff of IOsender.
If people are into the idea of trying Avalonia or Maui I think the first thing to do is check what type of communication it offers and make sure it is solid, mainly serial comms I do not know for sure but guessing web socket is supported and not an issue. Next would be the ability to render or draw things. I have a feeling this might be an issue or not fully supported on all platforms yet, but might not be a showstopper to get the project started? I would not even build a UI for a while get the communication setup and the ability to parse the data from GRBLHAL then build data object off that to drive the UI much like IO sender with the GRBL View Model and Grbl Settings if these are the correct names. Next thing I see as something that can be time consuming and a pain is testing to make sure the app actually works on Linux, windows and mac OS? As I only have windows and visual studio, as far as I know Jet brains rider is just about the only cross platform IDE that can be used to develop Avalonia desktop apps, but I do not think that is free? I am not attempting to discourage people, just wanting to throw out somethings that I see as some issues or might be some road blocks for people if they decide to start this. As I get free time, I have been attempting to learn embedded C and play with hardware. I only bring this up to say I do not have the drive to spearhead this project and would not make any real progress in a timely manner.

[cbaugher]

Bottom up is, IMO, the correct approach. The core project is UI-less and is the foundation. To create a basic working app only a few controls has to be added plus a main application that binds everyting together. Then expanded the app by adding controls/projects. I deliberately splitted the application in several projects to make the parts replaceable. E.g. the CNC Core project does not reference any of the other projects, the next layer is CNC Controls which the rest of the controls and the app depends on. E.g. the Config App only references the the CNC Core and CNC Controls projects. I have to admit that not everything is strictly conformant with the MVVM pattern - after all the sender is my first and only such project. But I do not believe this should cause any major issues when moving to a new UI.

It was when I got to CNC controls that it really started going sideways. My thought was to "convert" the existing controls code to Avalonia, but I think it would be better to basically recreate the controls in Avalonia first and then link them to the core functions. So basically like you said. Start with the core inside a basic Avalonia shell, then add view elements and link to the core one at a time.

I am surely not going to do it. If it is worth it depends on whether a new sender offers anything that makes it desirable over other senders? I do not even know what specific features ioSender has that makes users want to use it.

Specifically I need a lathe mode, which I think only one other sender offers. I forget which one now but it wasn't really what I was looking for.

First, I think IOsender is great and offers more features than any other sender I have come across, so I get why people push for Mac and Linux support. I broke a lot of things from Iosender when I made a touch version of it. I was primary focused on making a somewhat specific purpose 3 / 4 axis mill or router sender and I do not have the ability to test stuff like lathe, 5 axis to name a few of the larger items so I shut them “off”. So might not be a good start basing it off what I linked as a reference which that was started from the spinoff of IOsender. If people are into the idea of trying Avalonia or Maui I think the first thing to do is check what type of communication it offers and make sure it is solid, mainly serial comms I do not know for sure but guessing web socket is supported and not an issue. Next would be the ability to render or draw things. I have a feeling this might be an issue or not fully supported on all platforms yet, but might not be a showstopper to get the project started? I would not even build a UI for a while get the communication setup and the ability to parse the data from GRBLHAL then build data object off that to drive the UI much like IO sender with the GRBL View Model and Grbl Settings if these are the correct names. Next thing I see as something that can be time consuming and a pain is testing to make sure the app actually works on Linux, windows and mac OS? As I only have windows and visual studio, as far as I know Jet brains rider is just about the only cross platform IDE that can be used to develop Avalonia desktop apps, but I do not think that is free? I am not attempting to discourage people, just wanting to throw out somethings that I see as some issues or might be some road blocks for people if they decide to start this. As I get free time, I have been attempting to learn embedded C and play with hardware. I only bring this up to say I do not have the drive to spearhead this project and would not make any real progress in a timely manner.

I don't think Avalonia manages serial comms at all. Pretty sure that's all .net stuff. Same with web sockets.
Drawing/rendering capability is there using Skia. Looks to be supported on Windows/Linux/MacOS.

I think you're right about the development approach. Start with the core, make it work with minimum interface under Windows/Linux/MacOS? Then build out the GUI a little at a time. In fact I had started with the configuration app and not the actual sender, to keep things simpler.

From a quick search it appears you can in fact build for Linux under Visual Studio. I have not tried this but I might see what I can do over the weekend. I have a spare machine or two I can put Linux on to play with. Also have a PI4 I intend to use as a lathe controller once I get that built. MacOS... ??? I know virtually nothing about Apple stuff, so that will have to be someone else. I suspect usage of MacOS will be pretty low, so probably not a high priority.

It's been awhile since I've looked at the code, but I'll try and dig out what I have this weekend.

[cbaugher]

Bottom up is, IMO, the correct approach. The core project is UI-less and is the foundation. To create a basic working app only a few controls has to be added plus a main application that binds everyting together. Then expanded the app by adding controls/projects. I deliberately splitted the application in several projects to make the parts replaceable. E.g. the CNC Core project does not reference any of the other projects, the next layer is CNC Controls which the rest of the controls and the app depends on. E.g. the Config App only references the the CNC Core and CNC Controls projects. I have to admit that not everything is strictly conformant with the MVVM pattern - after all the sender is my first and only such project. But I do not believe this should cause any major issues when moving to a new UI.

Hi Terje,

I've been studying the code to get an understanding of how everything works. There is a lot to understand! Lol

Specifically I'm trying to work out the structure and how it fits into the MVVM pattern. It looks like the model/viewmodel are essentially contained in the "core" project, with the view being the "controls" project plus IOSender and config app projects at the top levels. Could you elaborate a bit on what parts don't fit the MVVM pattern?

[terjeio]

Since this project is the one I have used dip into the MVVM pattern it may be considered not "pure" since there are still local code behind in some of the controls. I have also a bunch of static classes (in grbl.cs) that represents the controller configuration - this may be considered a bad approach?

There are also a bunch of viewmodels found in some of the subprojects which I opted to keep out of the main viewmodel, done so because I want to keep them replaceable. Probing and lathe wizards are the main ones.

So some of the code should ideally be moved to the core viewmodel? At least some of the code behind, such as event handlers?

[cbaugher]

Since this project is the one I have used dip into the MVVM pattern it may be considered not "pure" since there are still local code behind in some of the controls. I have also a bunch of static classes (in grbl.cs) that represents the controller configuration - this may be considered a bad approach?

This is my first foray into MVVM as well, so I'm not at all qualified to critique your approach. Lol!
In terms of putting "stuff" in code-behind, my understanding is that it's totally fine if the "stuff" is related to view management only. The problem is it's hard to figure out what qualifies as view management vs. application logic. For example, would configuration file management be considered part of the view? I could see it going either way.

There are also a bunch of viewmodels found in some of the subprojects which I opted to keep out of the main viewmodel, done so because I want to keep them replaceable. Probing and lathe wizards are the main ones.

I think having some things separated out makes sense, especially if they're functionally independent. Probing and lathe wizards are good examples of this because they may be completely absent depending of the machine being used.

So some of the code should ideally be moved to the core viewmodel? At least some of the code behind, such as event handlers?

Ideally I'm thinking probably yes. But for a first attempt at porting, no. IMO it's probably more important to get something working first. Then later worry about restructuring and streamlining. Trying to port and restructure at the same time I think is too large a task. And in order to do any restructuring intelligently, it would be better to have a deep understanding of the project first.

Anyway, I'm making decent progress with Avalonia and understanding how IOSender works. Avalonia unfortunately doesn't have the depth of control types that WPF has. The primitives are there, so it just means more work to build up the interface from basic controls. Fortunately it's under active development and will get better as time goes on.

One piece I can see that is going to be a challenge, is the tree for the Grbl settings. I haven't really dug into it yet but it looks like it's dynamically generated? It makes sense to do it that way, but also seems very complicated.

[terjeio]

One piece I can see that is going to be a challenge, is the tree for the Grbl settings. I haven't really dug into it yet but it looks like it's dynamically generated?

The tree is generated from data read from the controller, any treeview control should be able to handle the data which is provided by the core. What is a bit complicated is the presentation of the indiviual settings, they are rendered dynamically based on the data.

[cbaugher]

• there are in fact two different serial port libraries supported already.

I'm still plugging away at Avalonia, mostly on the UI side, but am now running into some problem with serial comms. I remembered there was some mention of this here so I wanted to check back. This second serial library is EltimaStream? I only just now started looking at this. Is it a replacement for SerialStream?

[terjeio]

This second serial library is EltimaStream? I only just now started looking at this. Is it a replacement for SerialStream?

Yes, it is.

[cbaugher]

I'm trying to compile with USEELTIMA defined, but it can't find a reference for "SPortLib". Is there an external package to install?

[terjeio]

Eltima is a commercial package that I had access to earlier.

[Jay-Tech]

What is your issue with serial ? setup a quick test and serial was working you will need to change over all the dispatcher stuff and bring in package System.IO.Ports I used 8.0

wpf you will see
Application.Current.Dispatcher
Avalonia this becomes
Dispatcher.UIThread

Changes in Serial.cs
SerialPort_DataReceived
wpf
Dispatcher.BeginInvoke(DataReceived, Reply);
Avalonia
Dispatcher.Invoke(() => DataReceived(Reply));

just as quick test I put this in GrblViewModel in place of the startup that the APPconfig does

pollThread = new Thread(Poller.Run);
pollThread.Start();
var testSerialPort = new SerialStream("COM7:115200,N,8,1,,DTR", 1000, Dispatcher.UIThread);
Comms.com.DataReceived += DataReceived;
Poller.SetState(400);

I was able to recieve

checkd in the an example
https://github.com/Jay-Tech/AvaloniaTestSender

[cbaugher]

I'm not sure what's going on. It opens the port but only fires the DataRecieved event once, and then never again. The data received is correct so the port settings are right. And I can use IOSender or any other comm program and see that the controller is sending data.

The app is not hanging because you can manipulate controls. The serial stream thread is still running and it is keeping the port open. Just no data events. I'm sort of stumped at the moment.

[cbaugher]

For the curious... I did figure out what was going on with the serial comms. The first problem was that the poller was in the wrong state, because some lines were commented out that shouldn't have been.

The other thing I discovered is that for some reason, when SerialPort_DataReceived invokes the thread to process the received data, it only works with Invoke() and not InvokeAsync(). With InvokeAsync() it loses data, even when set to the highest priority. I think this probably has something to do with how Avalonia is by default single threaded and always runs everything on the UI thread, whereas Windows threading can create non-UI threads.

Anyway, I can see the communications happening in the console window and send MDI commands to the controller. Still a long way to go but progress is being made. :-)

[cbaugher]

Alright! Despite still being mostly inept at WPF/Avalonia I've managed to hack something together that connects to a controller and runs a simple program. It looks terrible and there are a million things still broken, but it's a start.

https://github.com/cbaugher/ioSender