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
consistent cases in filenames
Path.Combine
.pngs with alpha
layout fixes if I get chance (some of the bottom popout toolbar images overlap the text but that still needs investigation)
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)
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.
Hello there,
nice to see some people trying to run this app on Linux, too! My goal is to run AgOpenGPS on some cheap tablet. The most promising for me is the PineTab (ARM), which should be released soon and is able to run mainline Linux kernel. Or use some cheap Android tablet.
That requires:
AgOpenGPS working on Linux (@torriem and @ptd006 already started working on this, good job guys (although each chose different path))
Run app on ARM (should not be so difficult)
Run app on Androind ARM (I do not want to use Android, but who knows).
I just discovered this awesome app, but feel free to tell me if you want some help in this process.
P.S.: looks like this project required C# 7.1, which is not available on my VM Xubuntu 18.04 (Mono 4.6.2 only), I will try newer system in VM.
Another show stopper for anything based on ARM is OpenGL support. More specifically, AOG uses immediate mode GL calls, which are a part of OpenGL 2.1, and all Windows computers ship with an emulation of OpenGL 2.1, called opengl32.dll, that uses DirectX (much like Qt does, below).
Most desktop Linux machines are going to have Intel, AMD, or nVIDIA graphics cards and, so far as I know, they all support OpenGL 2.1, at least on Linux. Hence we can run AOG just fine in Wine or possibly directly with Mono with no issues. However ARM devices (including phones and tablets) only support OpenGL ES, which is a pipelined version of OpenGL and uses shaders to render the triangles. OpenGL ES is lighter weight but also faster than OpenGL 2.1, at least for the kind of things phones and tablets do (games).
When I started porting AOG to Qt, I started rewriting the OpenGL calls to OpenGL ES calls. Oddly enough, Qt on Windows doesn’t use OpenGL natively at all, but has an emulation layer that uses DirectX. That only provides an OpenGL ES interface there. Is your head spinning yet?
There are good reasons why Brian uses OpenGL 2.1, but that’s an area that some of us might contribute and Brian might not object to it that would ultimately lead to more portability. Aren’t we glad Brian used OpenGL and not DirectX!
I can speak more to the details of porting OpenGL calls to GL ES if anyone is interested in the details.
Qt may use directX, but windows dll does not. OpenGL is a direct API on the graphics card that is hardware accelerated. WINDCLASSEX class from the win32 API creates a device context and all required buffers directly since v1.4
If your video card was made in 1994 and had no opengl support, then software emulation was used.
whats the trick to get the program installed, i am new to linux as well as AOG, very interested in learning though as i have an old laptop, i would like to build the system around
I use an Ubuntu-based distro and installed wine through apt. You need to make sure you install the 32-bit version of wine:
sudo apt install wine32
Then wine should be able to run it. I like to put windows apps into their own prefix and I’ll often force it to be pure 32-bit. so I’ll do something like:
That will install aog into the ~/AgOpen/GPS prefix, and you can then run it with WINEPREFIX=~/AgOpenGPS WINEARCH=win32 wine ~/"AgOpenGPS/drive_c/Program Files/AgOpenGPS/AgOpenGPS.exe"
On my system, wine seems to automatically add any start menu shortcuts that an installer creates to the desktop menu, so you can reach it more easily through your normal linux desktop menu after installing, even with custom prefixes and special WINEARCH flags.
If you need to install MS dotnet runtime (it’s less glitchy than the mono runtime built into wine), you can download the winetricks script and then run it with your custom prefix: WINEPREFIX=~/AgOpenGPS WINEARCH=win32 /path/to/winetricks
Follow the menu prompts to install dotnet 4.6.3.
