Potential Roadmap for AgOpenGPS

Projects Software modifications on AgOpenGps (c#)
1

Hi

As mentioned in my other thread Contributing to AgOpenGPS, I think it would be very valuable to have some kind of idea about the future of AgOpenGPS.
It may not be very appropriate of me to make a proposal of such a future, because I’m just now learning about the project, but maybe this can serve as an initial basis for further discussions and/or clarifications.

The goal

One of the main drivers of evolving AgOpenGPS is most likely the desire for cross-platform compatibility.
More specifically, as mentioned elsewhere, it would be beneficial to be able to run AgOpenGPS on other platforms than Windows (e.g. Linux, Android, iOS?) to have a wider range of devices available to run the software on.

The proposal

This is my suggestion on how to naturally evolve the current state of AgOpenGPS towards a cross-platform application:

  1. Modernize the tech-stack:
    Migrate to a recent .NET version (e.g. .NET 9) in order to have the entire application be able to benefit from any technological advancements in the framework (e.g. performance, APIs, …)
    Even though this is probably not absolutely necessary for the next steps, it certainly wouldn’t hurt either.
  2. Split frontend logic from backend:
    By introducing a concept like MVVM, the currently tightly coupled code living inside the various forms could be decoupled and refactored in a way that would allow the next step.
  3. Introduce a new frontend technology:
    Because WinForms is (and probably will be forever) a Windows-only framework, in order to achieve the cross-platform goal, a different frontend technology should be introduced. I believe that this can be done alongside the existing WinForms application, such that there is always a working, deliverable version of the software available. Only after finishing the migration (and thorough testing), the WinForms code can be removed.
    At the time of writing, I would suggest using Avalonia UI as the new frontend framework, because it would support all the desired target platforms.

Alternatives

Of course this proposal is heavily opinionated and there are many different “roads” that could lead to the desired goal:

  • Use a different frontend technology (maybe web-based?), but still evolving the current code base towards that stack.
  • Abandon the .NET ecosystem and go with the Qt based QtAgOpenGPS project once it is mature enough.

As mentioned above, I just want to give some inspiration about where this project could be heading and if this is not something that is up for discussion, then feel free to close this thread.

Best regards,
Matthias

4 Likes
2

Thanks for your thoughts, Matthias. If you’ve got some C# experience (or any programming language really; c# isn’t that hard to pick up), I’m sure the developers will welcome assistance towards those three goals. There are some architectural changes in the works which are unfortunately private at this time, so it might be that some of this sort of contribution will have to wait for AOGv7 (.net 9 support might come with that). In the meantime I welcome you to go through the source code and become familiar with it. It’s not easy but it’s not quite as complicated as it looks. Regardless of what happens, contributors need to be able to understand and work with the existing code.

Brian and the AgOpenGPS developers (as well as a few interlopers such as myself) have discussed these issues at length. Brian is well aware of the limitations of using WinForms as far as cross-platform compatibility goes. Although there are several contributors to AgOpenGPS, the primary driving force behind it in terms of understanding the algorithms and rapid feature development is one man, BrianTee. WinForms and C# continue to be the easiest and fastest way for him to develop his ideas (and he comes up with new features weekly). He’s not opposed to talented farmer programmers coming forward and refactoring AOG and building new GUIs. He’s not opposed to other languages too, but at present it seems like C# is the winner since the majority of people interested in working on AOG know that language best.

In my C++ port I have mostly transferred over the same object structure that AOG uses, but I’ve separated the GUI somewhat from the backend code, so I know we can refactor the C# code a bit even with WinForms to provide a degree of separation, to prepare the way for an eventual GUI transplant. Also the OpenGL code needs to be adapted to use pipelined calls if we want to run AOG on Android. One could borrow some of the OpenGL stuff I put in QtAOG as it’s all OpenGL ES code with some simple vertex shaders.

1 Like
3

I do have several years of experience in .NET development, otherwise I would not have dared to make those kinds of suggestions :wink:

There are some architectural changes in the works which are unfortunately private at this time, so it might be that some of this sort of contribution will have to wait for AOGv7 (.net 9 support might come with that).

This is great news, that .NET 9 may come bundled with the refactor from @Jozef. However, it is still very unfortunate, that this is happening privately.
For me personally, I would have had some free time over the holidays to maybe help out a little, but now I just have to wait and may not have time anymore to contribute later.

Brian and the AgOpenGPS developers (as well as a few interlopers such as myself) have discussed these issues at length. Brian is well aware of the limitations of using WinForms as far as cross-platform compatibility goes.

This is why I created this roadmap. If those discussions are already happening, this is great but having a publicly available roadmap helps to convey a vision of the future of AgOpenGPS. Everyone (not just the ones part of the secret discussions) can then work towards this vision and will not be faced with statements like “this does not align with our goal for the project”.

Although there are several contributors to AgOpenGPS, the primary driving force behind it in terms of understanding the algorithms and rapid feature development is one man, BrianTee. WinForms and C# continue to be the easiest and fastest way for him to develop his ideas (and he comes up with new features weekly). He’s not opposed to talented farmer programmers coming forward and refactoring AOG and building new GUIs. He’s not opposed to other languages too, but at present it seems like C# is the winner since the majority of people interested in working on AOG know that language best.

I think @BrianTee_Admin is doing an awesome job at pushing this project forwards and I think there are no big changes needed to streamline the experience for himself and everyone else that is willing to contribute.

If new GUIs are being developed, this is awesome and can show different ways for how to achieve certain goals, but the main AgOpenGPS project will most likely be the entry point for all farmers interested in this ecosystem. And this is why I think it is very valuable to know how to integrate any of those new GUIs if they are successful.

In my C++ port I have mostly transferred over the same object structure that AOG uses, but I’ve separated the GUI somewhat from the backend code, so I know we can refactor the C# code a bit even with WinForms to provide a degree of separation, to prepare the way for an eventual GUI transplant.

I don’t quite understand what you mean by this. Isn’t your C++ port a complete rewrite, meaning there is no more C# or .NET involved?
How could you then make a GUI transplant without replacing the original entirely?

Also the OpenGL code needs to be adapted to use pipelined calls if we want to run AOG on Android. One could borrow some of the OpenGL stuff I put in QtAOG as it’s all OpenGL ES code with some simple vertex shaders.

This is a very good point and also should be on such a roadmap. The nice thing about this problem is, that it could be done at any point in time and does not need to happen in a particular order like the other ones.

4

Who is going to code all this? No one is interested.
Dotnet is not a good solution for Android.
How to use OpenGL? This is an open source project…

5

How do you know this? Apparently progress for my first bullet point is already done by the refactor of @Jozef. And I wouldn’t suggest all this, if I wouldn’t consider contributing to this myself.

Dotnet is not a good solution for Android.

Why?

How to use OpenGL?

Avalonia supports OpenGL, even if it is not very well documented.

This is an open source project…

… so? This is the beauty of open-source: a lot of people are out there that could potentially help move the project in this direction if this is what we all agree on.
If the community is able to create entirely new GUIs like the Qt port, I think it is not unreasonable to imagine, that such a transition is possible as well.

6

I spend thousands of hours on this project and many others.
Avalonia supports OpenGL. But its working in another thread.
Microsoft is no longer supporting Xamarin. So you need MAUI.
I run Vulkan and OpenGL (Silk.net) on Avalonia(Linux desktop).
It’s not something for an amateur programmer.

7

Okay, does this mean that the proposed goal of becoming cross-platform is incorrect?

Avalonia supports OpenGL. But its working in another thread.

Forgive my ignorance, but how is this a problem? If anything I would imagine this being an advantage?

Microsoft is no longer supporting Xamarin. So you need MAUI.

So we have MAUI and Avalonia, which are already two frameworks that support Android using .NET. Why is it still not a good solution?

I run Vulkan and OpenGL (Silk.net) on Avalonia(Linux desktop).
It’s not something for an amateur programmer.

Migrating the project towards cross-platform compatibility is itself not an “amateur” task. However, I believe that once the project is migrated and setup for all the different target platforms, the architecture will have evolved such that it will be easier and not harder than before.

8

Lot of options mentioned here already, but I’d still like to mention one more: Godot game engine. It has quite comprehensive set of UI-components (for example Godot editor itself is made using it’s own UI-components). And being a game engine, it also has good 3D-support. Godot’s native scripting language is python-like GDScript, but you can also use C# with a .NET-version that supports C# in addition to GDScript.

Multi-platform support in my experience comes pretty much free with Godot. For example the external simulator-PoC works in at least Windows, Linux and Android (not counting steering wheel / force feedback. Haven’t tested if UDP works in Android either, but I think it should). It should also support C# on Android, but I haven’t tested it.

From the perspective of an occasional modder/contributor Godot would also be beneficial in that the editor doesn’t even need installing, just downloading a less than 100 Mb editor-zip, unzipping and running it is enough to get one going. Exporting the project (so that it runs without the editor) needs some additional downloads, though. And for an occasional coder GDScript could be easier than C#. For “higher level” operations it’s performance should also be good enough, although heavier operations probably should be done with C#.

Considering the precision needed for location, Godot editor may need to be compiled with double-precision floats (the internal classes can be compiled to use either 32 or 64-bit floats). In C# you can of course just use doubles, but GDScript, the engine itself and those classes will use the precision set when compiling. Currently there’s no ready-compiled editor executables for double-precision to download.

That said, there are still annoying issues with touchscreens that currently makes Godot unusable with at least some tablets’ touchscreens (like Panasonic FZ-G1).

Not sure about safety related issues, but don’t remember when Godot last crashed when running a project or so either. Editor has had some issues, although rarely.

The text above might be biased as for some things I have lately been using Godot as my “hammer”, so every problem looks like a nail. :smiley: Sorry if it feels far-fetched.

2 Likes
9

Have you reached out to Jozef to see about helping him with the refactor?

Refactoring high visibility projects happens in private fairly often. The teams are usually moving pretty quickly. Random PR’s from folks for dev code that has changed in the last day or two may not be helpful. It takes time away from other tasks to review and provide feedback to the PR submitter.

I don’t know you or what type of dev you are but some get very butt hurt when their PR is rejected or not looked at for several days or weeks. Some folks then cause more drama and distraction in forums etc. Again not saying this something you would do, just adding why sometimes these major refactors are done in private.

1 Like
10

I have not, but this is a good point. I will do that.

Refactoring high visibility projects happens in private fairly often. The teams are usually moving pretty quickly. Random PR’s from folks for dev code that has changed in the last day or two may not be helpful. It takes time away from other tasks to review and provide feedback to the PR submitter.

I can see this argument, but usually the project is not being actively worked on, while the private refactoring is done.
Here, there are quite a few changes happening (not from random PRs, but from Brian himself) and I did not yet get a satisfying answer, how those changes will be preserved when the refactor is done.

I don’t know you or what type of dev you are but some get very butt hurt when their PR is rejected or not looked at for several days or weeks. Some folks then cause more drama and distraction in forums etc. Again not saying this something you would do, just adding why sometimes these major refactors are done in private.

For me, this all boils down to transparency: If I know beforehand, that a project is undergoing a heavy refactoring, I can estimate that any contribution bears the risk of not being accepted because of that.
The only thing that would make me a little “butt hurt” is, when a PR gets rejected without any reason given.
Time delays however, are different (at least for me): I do not expect that any contribution (especially if it is my first one) gets looked at in a timely manner, or in fact at all. This is a risk that I fully accept when contributing to open-source.

11

@GNSS-Stylist: I think using Godot as a potential alternative could be an interesting idea.
However, I was trying to outline a migration path from the current WinForms application to something else, without requiring a full rewrite, such that there is a usable product during the transition.
I’m not sure if such a transition is possible to a Godot version of AgOpenGPS.

12

As Godot supports C# I don’t see how migrating the UI to it would be much different from migrating to Avalonia. OpenGL-migration, however might be a bit different matter. Godot uses it’s own abstractions over lower level APIs, but also provides some classes with OpenGL-like interfaces, like ImmediateMesh and SurfaceTool. Although I have used these to create some geometry, I don’t really know how difficult would it be to migrate OpenGL-related things to Godot. My experience on direct use of OpenGL is practically non-existent and I haven’t really taken a look on AOG’s OpenGL-usage either. On the shader-side, “Godot uses a shading language based on GLSL with the addition of a few quality-of-life features” so migrating them should be easy. Not sure how heavily shaders are used in AOG, though.

These are more like random thoughts and I have no intention to push development in one way or another.

Seconding FantasyTeddy about transparency. It would be nice to see on GitHub or something what is going on on the project. In Telegram groups etc. things will just bury under the flood of messages.

1 Like
13

Why say such horrible things? Try it out.

14

AgConn uses Avalonia? (found references in some files that looked like it does)? Didn’t find any build instructions or like there.

Who said “horrible things”? What I wrote was just “random thoughts” that rose to my mind while reading this thread. I’m not opposing using Qt (I’m actually using it myself in some projects) or Avalonia or any other framework etc.

1 Like
15

In fact I don’t know if it would be that different. I just assumed that Godot will most likely use a very different project structure, which would not allow the coexistence of the existing WinForms application and the new Godot variant (and therefore not allowing for a gradual transition).

But in general I also do not care too much about the solution that will be chosen.
I would appreciate however, if any decision about seriously considered solutions would be made public, such that the community is aware of what is planned for the future.

16

I like Godot. Its not horrible. You must ask FantasyTeddy how to build AgConn. I don’t know.

17

What “horrible things” were you referring to then?

You must ask FantasyTeddy how to build AgConn.

Why do you assume that I would know? I don’t even know this project.

1 Like
18

So 1000 of hours. And its still not working???

1 Like
19

Do you really think I’m giving away the best. This is your project. I only want to help. I don’t earn anything with this.

20

How to build agio? Very interesting. It’s qt project?