Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experimental XCSoar-based menu #199

Closed
wants to merge 1 commit into from
Closed

Experimental XCSoar-based menu #199

wants to merge 1 commit into from

Conversation

MaxKellermann
Copy link
Collaborator

This is a replacement for the ovmenu-ng shell script. It is similar to the KoboMenu program, also using XCSoar's GUI toolkit.
Being a quick hack, a lot of features are missing. This is just a tech demo, and maybe I can convince you that a C++ based solution built on top of XCSoar's class library delivers the best user experience.

@linuxianer99
Copy link
Member

Looks good to me!
May it be possible, to have a separate build target only for the menu ??
As far I a know, there was also a port of LK8000 to Openvario hardware. So maybe they can also use the menu ?

@MaxKellermann
Copy link
Collaborator Author

Fun fact: LK8000 uses the portable GUI toolkit I wrote. They copied thousands of lines of XCSoar code a few years ago.

@MaxKellermann
Copy link
Collaborator Author

MaxKellermann commented Jan 21, 2022

May it be possible, to have a separate build target only for the menu ??

Of course, everything's possible. Could be solved with a PACKAGECONFIG; that way, the "normal" XCSoar build could be made optional. But that's pointless until there's a LK8000 recipe in the meta-openvario repository.

The "menu" is already a separate package, so with this PR, you can install LK8000 and only the "ovmenu-x" package, without the "xcsoar" package, and have an image without XCSoar, but with XCSoar-based menu and LK8000. The only thing a PACKAGECONFIG could do is save CPU cycles while building, by not compiling a XCSoar package which will not be installed.

p.s. doing a separate recipe would not be useful, because that compile lots of XCSoar sources twice (for images with XCSoar).

@linuxianer99
Copy link
Member

ok... got the point.
I think most of the users will fly using XCSoar ... so this should be fine for 95% of OV users ...

Thanks for your work @MaxKellermann !

@mihu-ov
Copy link
Member

mihu-ov commented Jan 22, 2022

Thank you Max and thank you Timo for asking, I had exactly the same question. Most OV users fly with XCSoar but we should keep the option open for other software as well.

@MaxKellermann
Copy link
Collaborator Author

Tested with @mihu-ov's OpenVario, and the graphical menu works.

@MaxKellermann MaxKellermann changed the base branch from hardknott to master January 27, 2022 14:52
@lordfolken
Copy link
Contributor

This looks nice. For the file copy operations, do you plan to call shell scripts / binaries, or also implement that in c++?

@MaxKellermann
Copy link
Collaborator Author

With the latest XCSoar commit, this is nearly a full-featured replacement for the old ovmenu-ng. As soon as the remaining features work, I'll un-"draft" this PR, because I believe this is better than ovmenu-ng.

One major usability improvement is that all operations can be cancelled; for example, ovmenu-ng gets stuck if the file copy scripts stalls. There's no way to cancel it, and the user has to wait (or hard-reset the OpenVario). Now, for non-interactive shell scripts, the GUI remains open, showing the output live, and the "Close" button kills the shell script.

For the file copy operations, do you plan to call shell scripts / binaries, or also implement that in c++?

For now, those are invoked through the original ovmenu-ng-skripts recipe, i.e. no code change. Only the text-based menu (through dialog) is replaced with XCSoar's GUI toolkit.

If this PR gets accepted, we can improve from here, and rewrite some parts in C++ where we believe it's worth it. But that's optional.

Of course, other features will be available easily, for example the Wifi configuration dialog XCSoar already has on the Kobo. This will allow eliminating connman in favor of just wpa_supplicant / systemd-networkd (#175), which is much lighter and more reliable, while at the same time improving usability.

@MaxKellermann
Copy link
Collaborator Author

btw. what's missing is the OpenVario logo which should be displayed on the main menu. See #200 for why it's still not there.

@DanD222
Copy link
Contributor

DanD222 commented Jan 31, 2022

Here’s a quick ’n dirty live trace of the original raster file, in case it helps in any way. It however warrants a rework/cleanup. I’ll try and find time for this in the next few days, unless the proper thing is that this should come from the original author.
OV02

@iglesiasmarianod
Copy link
Contributor

Thanks @MaxKellermann for all the work you've done!
I've built an image with your menu and I think this is the way to go.
I was thinking to use LVGL some time ago to make a GUI.
I'm a user who tinkers with the code a little bit. Not a heavy developer.
We have lots of settings that are not accessible without a keyboard now, and would be great to have a GUI to set them up.
I think that carrying a keyboard around to make changes in the glider is a big inconvenience for a normal user.
You can not set audio vario and STF frequencies, deadbands and filters without editing a text file.
This requires some Linux knowledge not all glider pilots have.
The need to make a USB stick with special folder structure is another point normal users I know find very troublesome.
Thinking about menu compatibility with LK8000, if OpenVario is to be used with other gliding software, wouldn't it be easier if we installed Android and App Store?

@MaxKellermann
Copy link
Collaborator Author

wouldn't it be easier if we installed Android and App Store?

No, please please not. That would add unimaginable shitloads of complexity and overhead, but gains almost nothing in return. It would solve no problem at all, but create thousands of new problems.

@MaxKellermann MaxKellermann mentioned this pull request Feb 9, 2022
@Blaubart
Copy link
Contributor

Today I also compiled an image with the new menu. The Settings menu item didn't work for me. This is probably not finished yet, is it?
I particularly like the menu because it can be operated with the touchscreen! However, I have always found a few things unfavorably solved in the original menu that make Kedder's menu more pleasant. From my point of view the following functions are missing:

  • Setting up the WiFi connections and the general overview of the network connection
  • Kedder's extremely convenient backup and restore function. Not only the XCSoar data are backed up, but all settings!! I press a button and my OpenVario is completely set up as before. That's just great!
  • a logbook like the Kobo had. That was also extremely practical, because you could keep your flight log directly on the plane.

@Blaubart
Copy link
Contributor

I would very much like to use the menu in our club aircraft, because there are always problems with OpenVarios not shutting down correctly. If a touchscreen is installed, not everyone manages to use a different control element in the OpenVario menu. I wrote a backup and restore script with a friend that is pretty close to Kedder's. I'll post it here soon after a few tests. In order to be able to use the menu, however, I would have to rotate it. Would it be a lot of work to install it in the short term? Then we could quickly start testing and complete the rest bit by bit.

@MaxKellermann MaxKellermann closed this by deleting the head repository Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants