Quickview customization

[robertlong13]

I wanted to be able to edit the colors of the quickview fields (this addresses issue #2026), and to be able to adjust the precision as well. While I was at it, I decided to overhaul the quickview editing dialog. The massive window of checkboxes has always been hard to use.

I went about this in a slightly weird way. I'm using the config.xml to control the colors instead of the theme manager. Adding the ability to individually color an arbitrary number of quickviews seemed too cumbersome for the theme manager, unless you wanted to stick to a single color for all. I was afraid that too many people might be attached to the multi-color look, or that there might be an ease-of-use justification for that. The config.xml route was much easier to handle arbitrary numbers of quickview items.

The way I have implemented this leaves everything exactly the same as it is now by default. If you want to change the color for a single box, you can.

Additionally, you can set the precision to any level you desire. In theory, we could also modify this to have more advanced formatting options. It would be nice to implement arbitrary expressions to control formatting and even math operations (say to convert a centimeter rangefinder reading to meters).

The variable to display is now controlled by a combobox that you can type and autocomplete in. This makes it way easier to find variables.

[meee1]

ok, so you seem to have lost the isNumeric check. ie cs can have arrays, datetime's etc. and currently your not filtering the arrays out etc. likerly to cause exceptions

[robertlong13]

Ah, are you talking about the section where I populate the combobox with the field names? I pulled that snippet straight over from the preflight checklist editor (CheckListItem.GetOptions()), so that must suffer the same issue. Now that I say that, it's probably worth having that section broken out into its own function in CurrentState.cs so it's not repeated, and fix it to filter out arrays and datetimes while I do that.

[robertlong13]

No wait, it looks like that's not where I pulled it. I need to remember what I was doing there. (yes, I did; I should stop commenting this late at night, I misunderstood what I was looking at)

[meee1]

yes, and doesnt support the customfields either

ie

    if (!fieldValue.IsNumber())
            {
                if(fieldValue is bool)
                {
                    fieldValue = ((bool)fieldValue) == true ? 1 : 0;
                } 
                else 
                    continue;
            }

            if (field.Name.Contains("customfield"))
            {
                if (CurrentState.custom_field_names.ContainsKey(field.Name))

[robertlong13]

I see now. I'll work to bring that section in line with how it used to work. Is there an easy way to test customfields in SITL?

[robertlong13]

This restores it to more-or-less how it was previously handled in FlightData.cs.

One thing that might look weird is my explicit use of Tuple in the fields list. The (string name, string desc) makes a ValueTuple, which I painfully learned does not work with CMB_Source.DisplayMember and CMB_Source.ValueMember

[robertlong13]

I have made a massive update to this PR. I have added far more customization options to the form.

• You can now specify TimeSpan format strings
• Scale and offset can be applied the the data, allowing for unit conversions. You can also get clever with it and use it to convert fuel consumed to fuel remaining.
• You can add custom descriptions to the QuickView. Much needed for named floats. Also helpful for changing the name of the unit if you use the scale feature.
• The expected number of digits can be specified. This gives much more control over the text size. Now that we can get rid of the decimal places at the end, it's quite common for numbers to be one character wide, which makes them quite huge by default. This also allows you to make all quickviews next to each other the same font size, even if one tends to be 4 digits and the others are no more than 3 digits.
• I overhauled the way that the combobox search functionality works. It was a PAIN to get right, but I'm pretty happy with it now. The built-in autocomplete feature only searches the start of the word, and I wanted the ability for something like "alt" to return "targetalt".
• I changed how customfields are attached to quickviews in config.xml. It no longer uses a fixed customfield0, customfield1, etc, it specifies the customfield by name instead, e.g. customfield:MAV_FUELPRESS. This is very important because customfields do not always allocate in the same order if they come from incoming named-float messages.
• I added a helper function for returning the customfield variable name or allocating new customfields if not there. This can be very useful for plugins that utilize customfields.

And here's a picture demonstrating what's so nice about manually setting charWidth

I really need to overhaul how customfields are used by the HUD, warning manager, and tuning graph, but those are for another day/PR. Nothing in here breaks how those work (more than they are already broken).

Also, while I was here, I added DoubleBuffering to QuickView to stop the flickering. Outside the scope of this PR, but I didn't feel like opening a separate one for a one-line change.

[robertlong13]

Rebased and tested. I still believe this PR is a good improvement.