Change default metric system based on user locale

[stefandunca]

Set the default metric system based on user preferences. Use the user locale settings to decide between imperial and metric. If user changes any of the metric units to other value that takes precedence and it is used instead.

Give user the chance to accept or change the metric system at the first start using a generic first-time setup wizard that can be extended in the custom build by overriding QGCCorePlugin::startupPages() in order to provide other required first time setup experience e.g.: internet services login.

Changing the metric system will prompt user to restart QGC as it is in the settings.

Previously, the default metric system, if it was never changed in general settings, was set to metric system.

[dogmaphobic]

The logic seems correct. Whether someone in the UK wants temperature in Fahrenheit is another matter.

[dogmaphobic]

@stefandunca If you rebase this again master I can merge it.

[DonLakeFlyer]

@stefandunca Sorry for taking so long. Can you fix the merge conflict?

[DonLakeFlyer]

Other than that this all looks fine.

[dogmaphobic]

@stefandunca What about this one?

[hamishwillee]

Force the US to grow up I say :-)

[stefandunca]

Taking into consideration all the opinions the best way is to have user confirm/choose at first time run.
I plan to update this PR later on and extended it so user can acknowledge/change the locale in a first time setup wizard popup.

[DonLakeFlyer]

Taking into consideration all the opinions the best way is to have user confirm/choose at first time run.

Makes a lot of sense.

[DonLakeFlyer]

@stefandunca Any update on this?

[stefandunca]

Taking into consideration all the opinions the best way is to have user confirm/choose at first time run.

Makes a lot of sense.

@DonLakeFlyer I did the proposed changes. Can you please have a look?

[DonLakeFlyer]

Can you move the firstTimeStart setting to AppSettings and make it a normal setting. This provides custom build override capability as well which is important.

Also it would be good to make that value be an int instead of a bool. That way you can version first time start requirements. For example, this pull just asks for units, that would be v1 and marked as 1. Then after this goes through I"m going to add asking the user about what firmware type and vehicle type they normally use QGC with. That would be a v2 first time start which could then check for a 2 in settings. If it's not 2 and only 1 then it pops first time again since there is new information required.

[DonLakeFlyer]

Crap, sorry. After all that I forgot this part:
The height of the startup page needs to max at availableHeight which is the central portion of the window (below toolbar, to bottom of screen). And the contents of the popup need to be in a QGCFlickable.

[stefandunca]

Also it would be good to make that value be an int instead of a bool.

QGCCorePlugin::startupPages can be used to enable or not a page and the flag can be reset before starting the UI. This should be general enough to work with custom implementations. Otherwise, we clash in versioning.
Let's do this change when it is really needed if the private context of the custom/page functionality doesn't allow this.

The height of the startup page needs to max at availableHeight which is the central portion of the window (below toolbar, to bottom of screen). And the contents of the popup need to be in a QGCFlickable.

I made the change. However, I think that private handling of the maximum size would be better done based on the context of the content and not as a general implementation. It would be good to have a minimal supported defaultPixelSizes ratio to give some guidance to the specific controls instead of creating a general one size fits all implementation.

[DonLakeFlyer]

can be used to enable or not a page and the flag can be reset before starting the UI.

How exactly? Not possible as far as I can see with just a bool. When I want to add support for first time display of firmware/vehicle type how do I do it?

However, I think that private handling of the maximum size would be better done based on the context of the content and not as a general implementation. It would be good to have a minimal supported defaultPixelSizes ratio to give some guidance to the specific controls instead of creating a general one size fits all implementation.

I don't understand what you are saying here. You don't know the available real estate until run time. You need to handle it somehow. I thought that in the previous implementation the popup would end up just being clipped. Was I wrong, did it already handle unknown sizing?

[DonLakeFlyer]

I thought that in the previous implementation the popup would end up just being clipped. Was I wrong, did it already handle unknown sizing?

I took a look at this again today. And there is a flickable but I still think the flickable should be on the exterior of the of the ui. Otherwise you end up with things like this on small screens:

Which is not going to be as clear as to the scrollability if you miss the scroll bar coming/going away.

[DonLakeFlyer]

@stefandunca I'm in the process of creating a standard mechanism for popup dialogs in QGC. This will handle things like buttons and scrolling automatically. So after this goes in I'd probably just convert this dialog to that as well. Also if you want I can handle the first start settings thing. Since I'm going to be the one that needs to add the new next first time start thing. Given those two things I can merge this now. And I'll take care of the rest. Let me know what you want to do.

[stefandunca]

Was I wrong, did it already handle unknown sizing?
The initial implementation will center the dialog base on the content page size. However, if the content page size exceeds the availableHeight it will be clipped. The way to go will be that we fix a minimal screen estate available for content pages and the implementer should provide the scroll view if the content exceeds the available size. Otherwise, we complicate things too much-creating cycling dependencies on view sizes.

And there is a flickable but I still think the flickable should be on the exterior of the of the ui.
In this case, the confirm button will be hidden and the user won't have the option to quickly dismiss the dialog.