Do you mean the AgConn project? This is a .NET project using the Avalonia framework.
@gameo: Maybe you could add the solution file (.sln) to the repository? It should then be easier to build.
Iām about aagio
Ha I have spent those kind of hours on QtAOG too, just because I wanted to. Our community is much smaller than AOGās. And it has been fun and Iāve learned a lot about how AOGās algorithms work. More on this is in a moment.
Having GL in another thread isnāt really an issue. With Qt using QML, the entire GUI is rendered in OpenGL and on most platforms that is in its own thread. All I had to do was break out the section lookahead code that was in oglBack_Paint() into a function that is run in the same thread as UpdateFixPosition(). Ended up cleanup up the code organization a bit. There are still some things in ogl_Paint() that alter MainForm objects and I should move those out too. I did implement a simple mechanism to limit oglBack_Paint() to only running after a new fix came in, so itās not trying to paint the section coverage map at 60 frames a second.
Yeah Avalonia.UI does have a steep learning curve and none of the current devs have experience with it. Joost does have a lot of experience with WPF, and Avalonia.UI is broadly similar to it. When I started QtAOG I considered just working on AOG and trying to port it to Avalonia, but I figured QtAOG was the quickest way to get where I wanted to go (no clue if that is true!).
A lot of work has happened in the last couple of years slowly making the C# code a bit more modular and more easy to separate from the GUI. And Iāve done some things in QtAOG to do this even more, such as moving the ABLine and curve objects from FormGPs into CTrack (instantiated as FormGPS::trk). It occurred to me the other evening that yt (CYouTurn) and bnd (CBoundary) probably should move into CTrack as well. then Iād move most of the event callback handlers for the unified Tracks interface into CTrack. Itās little changes like that that I feel are the best way forward. Another thing Iāve done that would help decouple Winforms is make high level methods in FormGPS (or in whatever class is appropriate like CTrack) to do things. For example, with regards to Tracks, Iāve defined the following methods:
void tracks_start_new(int mode);
void tracks_mark_start(double easting,
double northing,
double heading);
void tracks_mark_end(int refSide, double easting,
double northing);
void tracks_finish_new(QString name);
void tracks_cancel_new();
void tracks_pause(bool pause);
void tracks_add_point(double easting, double northing, double heading);
void tracks_select(int index);
void tracks_delete(int index);
void tracks_changeName(int index, QString new_name);
void tracks_swapAB(int index);
void tracks_ref_nudge(double dist_m);
void tracks_nudge_zero();
void tracks_nudge_center();
void tracks_nudge(double dist_m);
instead of having the GUI event handler reach into the various parts of QtAOG to manipulate or create a track, instead a GUI event handler wrapper calls into these functions. This might seem wasteful, but it ensures a separation of concerns. Doesnāt matter what the GUI is or does, as long as it calls these non-GUI methods.
Brian is open to reviewing pull requests to implement this sort of architecture change and Iāve been tempted to work on it myself. Maybe after Joost is farther along in his architecture changes.
Iām not a GUI programmer at all, and I donāt really care that much about the GUI, so enabling different forms of GUI through tweaking AOGās backend design appeals to me.
To make a long story longer, I was chatting with Brian the other day about section lookahead. Using OpenGL to draw coverage and then reading the pixels to determine if the section should turn on or off is nothing short of brilliant. But there are other non-graphical methods that might be worth exploring, thanks to modern processors. Section control being tied so closely to the GUI is a bit of a problem (although you can just implement a UI-specific version of the back buffer code, just as youād have to do with the maind display). It would be interesting if section control could be done effectively without any OpenGL at all, further reducing GUI coupling. In fact I have an old section control box from Raven with no GUI at all. Anyway Brian is exploring a simplified way of doing section lookahead that might make it feasible to explore other avenues.
Ha! Thatās nothing.
Iām glad AOG exists because itās a tremendous learning tool and a fantastic sandbox for exploration. And for doing things in a different, but better way. One example is how AOGās track reference lines work. In OEM systems, lines are typically done based on the the tractorās GPS receiver (which seems logical enough). And trying to get offsets to work right on my John Deere autosteer is an exercise in frustration. Never have figured it out. Whereas Brian (who hasnāt been sullied by many years of running OEM systems) rightly thought that itās the outside edge of your implement, or b boundary that should be your reference for creating tracks. Itās quite genius. As a practical example, I farm with center pivots. So every operation I do is done on half circles, where I always need my first pass to line up exactly with the pivot point. So for every implement width I have to create a whole new AB line, because otherwise that first pass would be way off (as it is on OEMs). With AOG, as long as my reference line goes through the pivot point, every implement width recalculates the AB lines. Brilliant. This concept makes headland passes from boundaries simple too, regardless of tool width.
Ha! 1000 hours and not working is nothing!
Iām glad AOG exists because itās a tremendous learning tool and a fantastic sandbox for exploration. And for doing things in a different, but better way. One example is how AOGās track reference lines work. In OEM systems, lines are typically done based on the the tractorās GPS receiver (which seems logical enough). And trying to get offsets to work right on my John Deere autosteer is an exercise in frustration. Never have figured it out. Whereas Brian (who hasnāt been sullied by many years of running OEM systems) rightly thought that itās the outside edge of your implement, or boundary that should be your reference for creating tracks, not where your tractorās GPS was when you made the line in the first place. Itās quite genius. As a practical example, I farm with center pivots. So every operation I do is done on half circles, where I always need my first pass to line up exactly with the pivot point. So for every implement width I have to create a whole new AB line, because otherwise that first pass would be way off (as it is on OEMs). With AOG, as long as my reference line goes through the pivot point, every implement width recalculates the AB lines. Brilliant. This concept makes headland passes from boundaries simple too, regardless of tool width.
I do believe that separating the GUI code from the backend code would really benefit the project. Not the least of which would be that it would enable writing tests against all those algorithms that are at the core of AOG.