Just wait for v6? Isn’t it planned to be cross platform?
1 Like
Really? Do you have more info about this? I am currently experimenting with AgOpenGPS on both amd64 and raspberry pi via wine or native mono, so I am curious.
I don’t know for sure, hoping someone smarter will confirm or deny
@torriem I see a lot of activity in this project again. Can you please share with us your plan or how/if we can help you somehow? I used your version before in field (with patches, but most of them were merged in your upstream) and it worked for me quite nice, so nice to see that the development continues.
1 Like
I sent you a private message. I think…
1 Like
David has been learning QML and motivated me to bring the backend code more up to date and start fleshing out the GUI to make it actually usable.
We’ve come a long ways but a long ways to go, particularly in QML to make everything function as it should. The backend is essentially up to date with the latest released version of AOG, and is compatible with the saved fields (but not saved vehicles). A new release of AOG will be out soon, and that does have some significant changes to the backend code regarding AB curves and lines. In the meantime I want to get QtAOG just working at its current level before I integrate the new AOG line code, which will also require some new QML code to do that GUI.
We could definitely use some help with the QML GUI. In particular we need to make it work on Android better. That means using slide-in panels instead of new windows, and making the views able to be resized and flickable so when the on-screen keyboard is showing, the various input fields are visible still.
Currently we have two primary ways of passing data into QML and causing things to update and change. One is an object called “settings” which follows the internal, persistent QSettings store. All vehicle parameters are in this store. When they are updated in QML, the backend sees the updates, and when the backend changes them, QML sees and reacts without any code.
The other interface is a QML class called AOGInterface. This is a list of properties, signals, and functions. The signals are used any time QML elements wish to communicate something with the backend c++ code (which are connected to FormGPS slots), for example to ask for an updated list of fields or vehicles. Also there are a number of properties (similar to class-member variables) that the backend can write to, that QML will automatically react to. Additionally some of the backend state variables have been moved from C++ into this QML object, so that the C++ code can also react to them. For example, the state of the autosteer button, which used to be a variable in the FormGPS class, is now in this AOGInterface QML class, so the front-end button can turn it on and the backend can react. Also if the backend cancels autosteer, the button will react to it.
By limiting the way the front and backends communicate to these two mechanisms, we are free to alter the GUI in any way without having to change much of the backend. Also the goal is to do as much of the logic that governs how the GUI works in QML (with some javascript) as we can. For example there is no unit conversion code in the backend. Everything is in standard metric units (m, m^2, km/h, etc). The QML gui transforms these units into either metric or imperial units depending on the value of settings.isMetric. The input fields are also unit aware and automatically convert back to base metric units even if they are being entered in imperial. This is done with very little code.
The immediate goal is to get QtAOG functional at the AOG 5.8.4 level, except for some features like Bing map integration, and ISOXML support, which will come later. This means fields, vehicles, boundaries, headlands, tram lines, autosteer, auto uturn, etc.
Once AOG Reffy is released and stable, we will migrate the unified AB line code over. And ongoing will be to change and refine the GUI to better support Android.
One thing that is currently missing is AgIO. This will need to be implemented at some point. For the Android version it will have to be integrated with QtAOG, which isn’t a big deal. Until we have our own version, AgIO.exe will have to be used, perhaps with wine for Linux users.
For the long term future, I do not have specific plans. Likely QtAOG will start to diverge from AOG’s code base, and at some point the data files may not be compatible. I’m certain the GUI will differ, although AOG’s GUI is getting quite refined. Perhaps Android’s material design will influence where it goes.
I’ve got a few more weeks I can devote evenings to this endeavor, and then time starts getting scarce for me. I hope by then with help from David and others it will closer to usable.
1 Like
I should add that currently the collaboration is happening on the “settingsdavid” branch of QtAgOpenGPS. Next week some time I’ll probably push everything we’ve got to “master” when it’s mostly working.
Is there any way that we can help with the testing?
I tried rebuilding the project locally but my attempts were unsuccessful.
Is there a way to get a release posted so it can be downloaded?
Thanks in advance!
What didn’t work?
I had problems with the versions of the plugins.
I’m sure we can post binaries to test on GitHub in a couple of weeks.
More concise build instructions will hopefully come soon.
Windows?
If you already have visual studio installed, with the qt installer all you need is to ensure the qt5 for vs2019 option is installed (qt6 can be unchecked).
If you don’t have visual studio, choose qt5 mingw64 or 32.
If on Linux let me know the distro.
QtAgOpenGPS requires Qt 5.15 currently. Older distros like ubuntu 20.04 don’t have that, the Qt installer for linux can give you a build environment that works fine on these older distro. I imagine that in the future we can create AppImage bundles that should work on any distro.
Future work would be porting the QML to Qt 6.
Thanks for the info.
I tried with Qt6 and then with Qt5 but with no luck.
I will try it with visual studio.
There’s build instructions on the repo README.md in my settingsdavid fork now
PR submitted for it.
1 Like
Using the Qt installer, install the following only
- Qt5, but customize and only select Qt5 for Mingw32 (or if you have VS, Qt5 for VS2019). 64-bit is fine. Should only be about 500 MB.
- Qt Creator
You should then be able to open the QtAgOpenGPS.pro file with Qt Creator, configure it for the mingw32 kit (or VS2019 if you went that route). You can then build and run from inside Qt Creator.
If you want to run QtAgOpenGPS from outside of Qt Creator, that requires an additional step, from the commandline, to run Qt’s "qtwindeploy " app which will make sure all the DLLs and shared plugins the EXE needs end up in the same folder as the EXE. Without this qtwindeploy step, running the EXE will just result in an error since it cannot find the Qt dlls.
@torriem I just joined so I don’t have the trust level to DM, so instead I’m posting here.
I’m very happy to see QtAgOpenGPS making progress. The cheap hardware caused by Windows 11 system requirements was too good to pass up, so I was looking for options given the Win 10 EOL later this year. I’m a fan of Linux, so I considered the Wine path, but seeing updates to your project got me excited about it.
Qt seems to me like a really good way to get AgOpenGPS on multiple platforms, and I would like to contribute to the project if you have need of more people. I’m a Qt noob, but an embedded C++ veteran. Qt is a framework I’ve had the itch to dig into for many years, and this project could be a good excuse to do so. I also have quite a bit of CMake and related tooling experience if you’d like to convert the project to CMake, as that seems to be the direction Qt is headed.
I’m assuming you can DM me if you’d like to contact me.
To keep this post somewhat on topic, and because the issue is still open, here are some name ideas:
I’m not a huge fan of Libre in project names, but there have been quite a few open source projects using that instead of Open or Free. So maybe use the Libre prefix?
Another idea - wordplay on existing guidance software package name? e.g. less replaces more. Instead of FieldBee, maybe AgriWasp? AgriBug?
Another idea - a name based on an animal that is famous for it’s navigation abilities, like an albatross or monarch butterfly. OpenAlbatross? Maybe a portmanteau like Agritross?
1 Like
Somewhere I kept a list of possible names. But for now Brian doesn’t care that much about having AOG in the name, so we’ve not worried about changing the name just yet.
But we welcome your assistance on the c++ code! We just finished updating to Qt6 and we’re currently bringing the C++ code to match the features of AOG 6.2.0. Brian revamped how the autosteer lines are done in AOG and I’m adapting that code to C++. This development is happening in my oneline_uturn branch on github. This branch does not compile currently, but if you wanted to check things out, I have a branch called “settingsdavid” that does compile and run.
Awesome, I’ll take a look at settingdavid. I had both master and the qt6 branch running. I fixed an annoyance with the Display menu, mostly to have an excuse to poke at QML. I can make a PR if you’re interested.
Is development discussion and coordination happening somewhere? This thread doesn’t seem like the right place.
I sent you a DM. Let me know if you didn’t get it.
Oh and if you’ll send me your github username, I’ll check out your change. We’ve been using git to share instead of github, then pushing to github.
I’ll go git remote add tenteen [url] in the terminal, then git pull tenteen [branchName] then git push to my github.
So instead of your git branch → your github → my github → my git branch, the sequence is more like:
Your git → your github → my git → my github.
Saves us having to do much with github, and has worked well so far.
1 Like
There is no such thing as multiplatform. Its a terrible and timeconsuming work to make connections work on all platforms. The code is full with if and else.