Hello all…
Today I had my first contact with AgOpenGPS. The project is very interesting and I downloaded the latest version. One of my friends (farmer) told me about it. He would like to use it.
But
- why is it still Framework 4.6??
- why still Winforms (it’s ok, but actually it should be WPF or MAUI in combination with .NET6)?
Are there any plans for refactoring?
Is someone maybe even working on it already??
I didn’t find any libarys, everything is in classes…? Why??
I think the code could be made much more performant and clear.
Thanks in advance for some details and some background informations about the project…
3 Likes
First of all, Brian and his associates on the dev team are doing an amazing job with all the features AOG has and is getting. I cannot speak for them.
But in my opinion it’s still winforms because that is what was used when AOG was first developed and the Winforms event loop and winforms windows essentially forms the structure of AOG. Furthermore WinForms is still a supported platform in .NET, even under the current . NET Core version, although on Windows only. Microsoft has been plenty wishy-washy about what is the blessed way to do GUI development in .NET. For a while they said WinForms was dead, use WPF, but now I get the feeling WPF has fallen out of favor and Xamarin Forms is being promoted, especially for mobile (iOS and Android) targets. But what about next year?
A code base of any significant size like AOG is going to have a steep curve in understanding how it works. The control flow is quite simple actually, although it’s spread over several method functions in several files. Everything is “clocked” by the GPS positions coming in.
As for performance, I used to run AOG on a cheap $200 tablet and it performed well. Remember everything is clocked based on the GPS sentences. So you’ll never see tractor animations smoother than 10 frames per second unless you wrote some code to estimate the in-between GPS positions, which might be fun to do some time. Given that everything AOG does easily fits within the 10ms between GPS positions currently, I am not sure much needs to be done in the performance area just yet.
Sure there are things that could be done to reorganize the code and make it clearer. In my C++ port of the AOG code base (which I can’t commit to working further on at this time), I did reorganize some things to eliminate the need to have various methods in external classes referring back to the main form instance directly.
I actually have many thoughts on how AOG, or an AOG-like program, could be structured, but since I lack the resources to actually put them into code, I am hesitant to say very much.
2 Likes
Sorry…
please don’t misunderstand my question.
I don’t want to blame the developer. I just want to know some background. The project is great and there is a lot of stuff in it.
Btw… just had a quick look at the code and saw the Discord link. I am a C# developer and was just giving my impressions.
I think OpenSouce projects live from the active cooperation of many.
2 Likes
Hopefully some of what I said explained some of that background. That was my intent, not to act defensive.
If you have experience with one of the .NET GUI frameworks, I’m sure that help adapting AOG to a more cross-platform toolkit would be wonderful. Perhaps Xamarin Forms or Avalonia? I find the choices for .NET to be a bit confusing. A couple of years ago. AOG would compile under .NET Core; I assume it still can be. At least as far as Linux is concerned, the only thing preventing AOG from running natively on other platforms is the WinForms thing. A minor issue is the use of immediate-mode OpenGL calls which aren’t supported on most Linux platforms, but it’s not that hard to write simple shaders and use pipelined OpenGL ES to work on a Pi or other SoCs. I wrote some shaders to do this a couple of years ago that anyone in the community is welcome to steal. I haven’t looked at the OpenGL code in a long time, so maybe it is pipelined now. Not sure.
I’m not a .NET developer so I can’t comment on the class organization of AOG. I’m not sure what you meant by libraries instead of classes?
1 Like
You could join the development team by consulting with brian, and you can migrate step by step.
Currently there is no more support, if it is not migrated to NET 6 or NET 7, it will be obsolete, the biggest problem with the migration is the front, which has to be done from 0.
But at the Backend level, it can be improved using libraries instead of classes, it will surely be more fluid.
.NET maintains backwards compatibility, though. Compiling AOG under a newer .net version shouldn’t be very hard at all, especially as WinForms will be supported in .NET Core for the foreseeable future. Microsoft’s track record for backwards compatibility is very impressive. I’m not worried at all about that particular thing.