Sorry if this has been asked elsewhere on here but I couldn’t find anything. But what is the latest on running this on Wine or something down that line? I have seen it talked about on different forms but the latest I saw was in 2016. Have people been doing it or does it just not work?
Thanks
If wine can support .net framework 4.5 then it may work but I have not tried myself. I’m sure there’s some libraries that Wine isn’t going to like.
Let us know!
Hey,
I ran it on Ubuntu 19.10 with latest Wine and Wine-Mono (4.9.4).
Please note I haven’t tested hardware with it yet but all the UI elements I tried seemed to work.
Cheers,
Peter
Interesting! I ran the latest aog on wine the other day but I had used winetricks to install dotnet 4.6, at least to satisfy the installer. I just tried it now with a wine prefix that had no dotnet stuff in it, and AOG seems to work.
If it works with wine-mono, then I wonder if it would run on regular mono now. Opentk can be built on mono in Linux. However it probably only run on systems with graphics drivers that supported immediate mode opengl.
There’s also dotnet core, which is where they want everyone to go, but there’s I don’t think it has any winforms implementation for non-Windows platforms.
I played more and found several bugs. Not sure about regular mono. At this stage I am only at the playing stage while I build a steering motor etc but would be great if we can get it working reliably.
Re. installer - I actually just dumped it with msiextract. The full steps I followed should be something like below if anyone else wants to try…
sudo apt install wine
cd Downloads
wget https://dl.winehq.org/wine/wine-mono/4.9.4/wine-mono-4.9.4.msi
wine64 uninstaller # install wine-mono from GUI
cd ..
mkdir AgOpenGPS
cd AgOpenGPS
wget https://github.com/farmerbriantee/AgOpenGPS/releases/download/3.0.9/AgOpenGPS.msi
sudo apt install msitools
msiextract AgOpenGPS.msi
wine AgOpenGPS.exe
Bugs in wine, wine-mono, or agopengps itself? Could be tricky!
I doubt they are bugs in AOG per se- more a combination of unimplemented and imperfectly implemented functions in and/or mono. E.g. unless running maximised there are sometimes drawing imperfections- e.g. RHS toolbars below! (maximising seems to cure it though). Also bottom toolbar background can be red (I guess a colour mask that isn’t getting treated properly).
Also the first time I loaded a KML field boundary the program crashed. When I reloaded it worked fine.
Some settings don’t seem to be saved, e.g. last field used.
Example of toolbar drawn correctly (when maximised)-
Yes I noticed that too. Definitely mono-related. You could try using the real dot net runtime. You can install that quite easily with the winetricks script.
Out of curiousity I tried building directly with mono.
From memory:
There are issues with transparency of the buttons but this might be a consequence of me running everything through pngcrush.
There are big problems with windows paths (\). I started fixing some and can load a few dialogues now.
Oh there’s my fields directory 
Fixed that one. Unfortunately grep -F -I \\\\ -r * is quite long…
And grep \\ isn’t even the end…
Am I being stupid or is there really nothing in mono to translate Windows paths to something sensible on Linux?
Directly with mono it ran but not overly functional on my PC. (Opensuse 15.0)
No not being stupid at all, you have to use combinePath() function - i think.
Like this would be more linux friendly:
string directoryName = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location);
string text = Path.Combine(directoryName, "Dependencies\\images", "Landscape.png");
The “@” is very dotnet ish for string literal that is all windows
Thanks Brian, yeah I saw that ( Path.Combine )
The transparency issue appears to be because some .png only have 8bit palette with simple index transparency rather than true alpha channel transparency. Anyway fixed with a one liner of ImageMagick convert and looks good.
Soon I’ll fork with
This will (hopefully!) not break anything on Windows.
Alan, yeah I’m not surprised it was not overly functional out of the box (I assume it was not even possible to load a .kml to define a field)
Will you continue the QtAOG?
Hi @Munkhtamir I personally have no intention of resurrecting the Qt version.
Edit: whoops sorry, I realise this wasn’t directed at me!
Generally I think a Qt version would be great. However I have no time to contribute to it, especially as the WinForms / OpenTk seems like it should work ok with tweaks.
I’m in the same boat. If I had a lot more time to devote to it, and if there were several other people able to actively contribute to development, I would continue QtAOG for sure. At the moment, AOG’s development is several years beyond where QtAOG’s port was. So it will take quite a long time to catch up and port all the changes.
In the shorter term, the simplest path to running AOG on other processors and operating systems might be to use dotNet core, and port the GUI to something other than Winforms, such as the Winforms-like Avalonia toolkit. There was talk about bringing Mono’s webforms implementation (which is nearly sufficient for AOG’s needs) to dotNet core. But that’s unlikely to happen. Mono itself is no longer under development since dotNet core is officially supported, and it’s winforms implementation has languished.
It will be at least six months until I have the time and shop to work on a couple of AOG-related projects (next Winter is more likely). Trouble with farming is it takes up all my time!
Good point about other processors, which I hadn’t really thought of. There are the cheap-as-chips* Allwinner boards for example. Further down the line a $15 orange pi + $10 tft touch screen + AOG PCB all in a single box might be interesting.
*I live in the city atm for work so that’s not just a bad pun…
Edit: I briefly tried the serial comms, but was pumping test NMEA GPS data through a socat virtual serial . Turns out mono SerialPort has a known issue with that but I think it’s be fine on real hardware. On that topic, to rationalise the code base and make unit testing easier I would probably split off the simulator so it directly feeds data to virtual serial ports (however I haven’t studied the code so not sure how easy that would be)
Now that you mention it I remember running into that mono bug.
I have been playing a bit with a Pine64 board I’ve had for a couple of years. Not a bad board. It actually supports some form of power management, which is interesting. Unlike the raspberry pi which has nothing at all (can’t even power itself off). Power management is one of those details that’s often overlooked. Can the system power itself on when the key turns on, and then properly power itself off when the key turns off? A tablet is nice here because it has its own battery and can sleep so doesn’t have to worry about all that.