change layout by omgubuntu mockup

Yes, looks nice, yet I'm not sure that this is possible to implement

I think, it is now impossible, but you can implement some ideas from mockup (maybe all mockup, but this things work)

I was the original designer for this project, and recently i made a new mockup for this. If you like I could pass it along to you.

Hi, of course ;-), I am not dev, but I would like to see it, my mockup is not my idea, I just modified omgubuntu mockup

Ok then, so here is the updated mockup. I hope you can find this useful.

mockup is missing :/

After investigation it seems that for now these mockups could be implemented in python - need libido python bindings

Implementable after Bug #582985 is fixed

Hi,
I don't think any of this is implementable, with the way libappindicator works.
With appindicator, any applet menu is parsed and served as the server side of a dbusmenu. The libapplication.so is the client side, which constructs regular gtk menus out of the served dbusmenu.

In the dbusmenu framework, the server side can declare the type of a menuitem as a custom type (apart from the regular, separator, image and toggle menuitems) and it's the client side's responsibility to declare that can can handle and create such a custom menuitem widget. This is the way libido is used from other indicators (datetime, sound etc) built outside of appindicator.

However in appindicator framework, there is no way to declare a custom menuitem in the server (indicator-application-service) and there is no way to create a custom menuitem in the client side (libapplication). It only knows & deals with standard menuitem types. It's not Python limitation, you cannot do it in C either.

What is needed to put custom menuitem widgets in the menu, is to leave appindicator behind and deal directly with libindicator and libdbusmenu. However you cannot do this in Python. The panel indicator placeholders load only modules from shared libraries installed currently in /usr/lib/indicators/4, which provide a subclass of an Indicator.Object.

I had an itch of putting custom widgets in my custom indicator applet, so I investigated this a lot and recoded my little Python applet to Vala. It took a while to get familiar with libdbusmenu and libindicator, but now I can happily put any custom widget I want in my menus.
Vadim, if you are interested in porting this indicator to Vala, I can help you out.

A document from Cullen Maglothin with several implementable ideas.

@Panagiotis: there two possible ways to move further:
1) Implement Python/GObject bindings for ido library (used in Sound and Me indicators)
2) Port Weather Indicator to Vala.

I have no expirience in creating bindings, but have a strong desire to learn Vala and involve more people in Weather Indicator development.

So I suggest to create another branch for porting the indicator to Vala. There are still several bugs to fix in the next Weather Indicator release, I guess, I'll be mostly busy with them.

Panagotis, could you please create a separate branch with a most basic implementation of the applet? Please, contact me if need any details on the structure of Weather Indicator indicator.

Fine, I'll create the branch. I don't have much free time so please be patient :)
Very roughly, what is basically needed is a service and a client. The client must be a shared library, so Vala/C is required.
The server side could still be implemented in Python, but currently libdbusmenu-glib gir bindings are broken. But trust me, once you get familiar with Vala, you will forget about Python :)
Finally, all this applies to Natty & Unity. Because current gnome-panel indicator applet, only loads specific client indicator libraries.

The option number one is not possible, forget about it. Even if there will be Python bindings for libido, you cannot use the widgets that libido provides with appindicator. You can only use them in the client side of dbusmenu as I explained above. Also, there is not a widget there (in libido) that weather indicator could find directly useful. But, once the app is in Vala, we can create any custom widget we want and there is no need for libido anyway.

>
> >Fine, I'll create the branch. I don't have much free time so please be
> patient :)
>
Don't rush, quality is the key in such sensitive process. I'll keep on
working on bug fix and internal service code.

> Very roughly, what is basically needed is a service and a client. The
> client must be a shared library, so Vala/C is required.
> The server side could still be implemented in Python, but currently
> libdbusmenu-glib gir bindings are broken. But trust me, once you get
> familiar with Vala, you will forget about Python :)
>
Agree, lets leave a service as a python lib (we'll reuse old code and keep
integration with couchdb and pywapi). The best way, I guess, will be DBus
integration - still, investigation required.

Can't wait for working code!

> > Very roughly, what is basically needed is a service and a client. The
> > client must be a shared library, so Vala/C is required.
> > The server side could still be implemented in Python, but currently
> > libdbusmenu-glib gir bindings are broken. But trust me, once you get
> > familiar with Vala, you will forget about Python :)
> >
> Agree, lets leave a service as a python lib (we'll reuse old code and keep
> integration with couchdb and pywapi). The best way, I guess, will be DBus
> integration - still, investigation required.

DBusmenu usage is really mandatory for the service side, and I'm not
sure that it can be done in Python, in a successful way. Using Couchdb
in Vala should be no problem. And as a weather backend, GWeather could
be used. I saw a blueprint that you wish to integrate it. Is GWeather
more advanced than pywapi, or at least at the same level?

I suggest using python backend, which will give exchange data via DBus with Vala indicator. CouchDB integration can also be moved to Vala code.

GWeather has a rather small location DB and only one weather provider - Weather.com.
So it is less powerful than the current solution - geonames.com DB + PyWAPI with Google, NOAA and Yahoo backends. Other backends can be implemented in PyWAPI - I guess, it would be much easier contributing in this project.

Couchdb and Vala is big problem now :-)

Service and client can communicate over DBus, so server can be written in python and client in Vala

On Fri, 2011-03-18 at 11:38 +0000, Vadim Rutkovsky wrote:
> I suggest using python backend, which will give exchange data via DBus
> with Vala indicator. CouchDB integration can also be moved to Vala code.
>
> GWeather has a rather small location DB and only one weather provider - Weather.com.
> So it is less powerful than the current solution - geonames.com DB + PyWAPI with Google, NOAA and Yahoo backends. Other backends can be implemented in PyWAPI - I guess, it would be much easier contributing in this project.
>
Alright agreed, I'll try to use Python in the service side and reuse the
current code base. I'll keep you posted on the progress.

Created a separate blueprint to track progress there - see
https://blueprints.launchpad.net/weather-indicator/+spec/port-vala

Here's a screenshot from the new Vala indicator client.
The upper part (until the separator) is one custom "conditions" widget, which is inactive.
Location, condition summary, temperature and condition icon are always displayed (per the omgubuntu mockup).
It follows a table with customizable fields (which the user selects).
We could add there whatever info is accessible.

The location selection menuitems are also custom widgets and can display an icon and temperature.

The refresh menuitem is another widget with the info aligned on the right.

What do you think?

Vadim, in the document you attached, there are temperatures in parentheses.
Do you know what they mean?

And another screenshot with the refresh and forecast items rearranged. I like this one better.

Wow. That is mental.

first one is better, because refreshing is for all locations, so second is bit misleading

but excelent job Panagiotis

And another one, with the row spacing between the condition info fields increased to 6px, so that they have the same distance as the normal menuitems have. I'm not sure though that we should do this. Perhaps the more dense table is better?

Please suggest anything that you would like to get corrected in the ui.

Notice that there is no quit button, just like the standard indicator.
Read on the blueprint comments, where I explain more.

The server part is half done, the elements in the screenshots are static.
When it's ready I'll upload the code to the branch.

Glad you like it :)

> first one is better, because refreshing is for all locations, so second is bit misleading
You are right, the "refresh" should go below. But the "forecast" can stay up there I think.

yes, I think a little bit and

it should be highly configurable what should be shown
Sunrise and sunset are smart? (I think people don't care, about sunset and sunrise at once, after dawn, there should be sunrise and same for sunset)

Most people need to know (IMHO):
how weather will change (not know what weather is now [for location, where I am, I can look from window ;-)])
actual temperature
feeling temperature (windchill and so on)
and wind speed

Here is the latest mockup for weather indicator. It was passed along to Vadim to see that it made it to the right places. It also came with a rather large document exllaining the features and the reasoning behind them. If you would like to see the doc, just email me and I will send it to you.

Thanks Cullen, I have the doc, Vadim attached it to the bug.
As you can see in the screenshots I posted, I have mainly used your mockup and just added the upper part of the omgubuntu mockup.
I think that the enlarged condition image gives a nice effect and the "Temperature" label is not really needed.
Let's discuss here for all these details.
Can you please explain me, what the temperatures in parentheses mean, as I can't find an explanation in the document.

> yes, I think a little bit and
>
> it should be highly configurable what should be shown
> Sunrise and sunset are smart? (I think people don't care, about sunset and sunrise at once, after dawn, there should be sunrise and same for sunset)
>
> Most people need to know (IMHO):
> how weather will change (not know what weather is now [for location, where I am, I can look from window ;-)])
> actual temperature
> feeling temperature (windchill and so on)
> and wind speed
>
The important part here is to make the info field selection customizable
and the ui independent from them.
The information fields are coming from the weather service. Whatever
info they provide, the user will be able to select for display on the
info table.

The temperature in parenthesis is the "feels-like" temperature. So wind chill or heat index is shown there.

Great job, Panagiotis!

Started working on python service to see the new indicator in action!

Not sure whether we can implement "feels like" temperature, as Yahoo source
doesn't supply required information.

Those screenshots look really good. I'm excited about this!

I agree with the comment about only showing sunset or sunrise, depending on which is due next.

I would like to see today's min/max temperatures in the menu itself rather than just in an extended forecast window. Perhaps the min temperature could be (tastefully) coloured blue, and the max temperature could be red.

Maybe the icon in the menu, instead of just duplicating the indicator icon and showing current conditions, could show today's forecast weather conditions. The forecast max and min could be vertically positioned next to it (maybe on the right?). If you put the icon and the forecast temperatures inside a box slightly darker than the rest of the menu then it would be visually clear that this forecast data is separate to the rest of the menu, which is mostly current observations. To make this even clearer, you could have the word "Later:" in tiny letters at the top of the box. Or would this all be too cluttered?

I think the "Feels like" temperature should be a separate menu item, just above Humidity - if it is just a temperature in parentheses then it's not immediately clear what it is. (The "Feels like" temperature can be implemented - see bug #743553)

One other minor suggestion - "Wind speed" should just be "Wind" since there's a direction as well as the speed.

> I agree with the comment about only showing sunset or sunrise, depending
> on which is due next.
Hmm, personally I'd like to see both
>
> I would like to see today's min/max temperatures in the menu itself
> rather than just in an extended forecast window. Perhaps the min
> temperature could be (tastefully) coloured blue, and the max temperature
> could be red.
> Maybe the icon in the menu, instead of just duplicating the indicator
> icon and showing current conditions, could show today's forecast weather
> conditions. The forecast max and min could be vertically positioned
> next to it (maybe on the right?). If you put the icon and the forecast
> temperatures inside a box slightly darker than the rest of the menu then
> it would be visually clear that this forecast data is separate to the
> rest of the menu, which is mostly current observations. To make this
> even clearer, you could have the word "Later:" in tiny letters at the
> top of the box. Or would this all be too cluttered?
>
Yes I'd like to see a quick forecast too.
But better not mess with colours. They may not look right with user's
current theme.

Perhaps we could put the forecast info (min/max/condition/icon) on the
right side of the "Forecast" menuitem.

> I think the "Feels like" temperature should be a separate menu item,
> just above Humidity - if it is just a temperature in parentheses then
> it's not immediately clear what it is. (The "Feels like" temperature
> can be implemented - see bug #743553)
Agreed

>
> One other minor suggestion - "Wind speed" should just be "Wind" since
> there's a direction as well as the speed.
>
Agreed

Take a look at http://www.omgubuntu.co.uk/2011/03/indicator-weather-is-it-just-me-or/
Seems that a lot of people want a quick forecast in the menu

User Mind Bending submitted an excellent mockup that deserves implementation:
http://dl.dropbox.com/u/365419/weather.png

IMHO the display style should be optional.
Here is a proposed list of new options:

1) indicator display mode: icon,label or both
 Currently if the label should be hidden, is set to an empty string. But that causes an extra 3pixels margin to be added between the icon and empty label. I can handle what elements are visible on the client side.
Also scrolling on the indicator should cycle the display mode.

2) current condition fields:
In the preferences dialog we saw a list of available weather info and the user can pick some or all with custom order:
So far the fields available:
 - Humidity
 - Wind
 - Sunset
 - Sunrise
 - Feels like (per Felix's patch)
 - High (from the forecast info)
 - Low (from the forecast info)
 - Forecast condition & icon (from the forecast info)

3) Show forecast in menu.
If its is selected, we should display the forecast for 3 days as presented in the omgubuntu mockup

4) Show multiple locations in a carousel.
If its is selected, the location radiomenuitems should be hidden and a carousel like widget (as the new mockup above) can be used to select the active location.

I guess these will keep everybody happy.

Btw, you can checkout the vala-port branch and test it (I've test it in Maverick so far)

To let to fix the typos, sorry!

I mean too late... arghhh

I'm generally wary of option proliferation - if we can find something that a large majority of people are happy with, then IMO it's better to go with that instead of confronting users with a huge preference window with lots of things they don't care about.

That said, I like 1), except I don't think scrolling on the indicator should change the display - IMO this is not a very logical behaviour. I think there'd be less people using this feature than there would be people who accidentally trigger it and get confused. Plus the information is only a click away.

2) I don't think that this should be customisable. We should choose a sensible set in a sensible order and format, and tailor the indicator's design to that. Maybe, maybe if people REALLY want to alphabetise it or change the order then we should let them customise it with a settings file, but as long as we put the 'right' data in I don't think people will desperately want to change the order or take things out.

3) and 4):
I like Mind Bending's mockup - it's a neat way of changing location. Reading through the comments on that page, only one person wanted "to see directly the weather in other locations". Everyone else wanted a forecast or "both" (i.e. to have easy access to a forecast and to the weather in different locations). I suspect that the majority of these people would be happy with the Mind Bending approach, as long as switching between locations is sufficiently fast. So my vote would be for implementing 3) and 4) as standard, and make people go through the carousel to see other locations.

The "Forecast" and "About" menu items could be removed. If it's essential that we have an "About" box (which I don't think it is), then it could be linked to from the Preferences window.

I'll check out the branch in the next day or two!

> That said, I like 1), except I don't think scrolling on the indicator
> should change the display - IMO this is not a very logical behaviour. I
> think there'd be less people using this feature than there would be
> people who accidentally trigger it and get confused. Plus the
> information is only a click away.
Ok let's forget the scrolling for the moment

>
> 2) I don't think that this should be customisable. We should choose a
> sensible set in a sensible order and format, and tailor the indicator's
> design to that. Maybe, maybe if people REALLY want to alphabetise it or
> change the order then we should let them customise it with a settings
> file, but as long as we put the 'right' data in I don't think people
> will desperately want to change the order or take things out.
The info available is a big list and I really believe that many users
will not care about some things like humidex or sunset/sunrise.
The list of fields to be displayed is already a couchdb setting in the
vala port. The only thing missing is the ability to be changed by the
user. One could use the couchdb command line tool to change it, but a
simple listbox with checkboxes in the preference dialog should not be
too overwhelming.

>
> 3) and 4):
> I like Mind Bending's mockup - it's a neat way of changing location. Reading through the comments on that page, only one person wanted "to see directly the weather in other locations". Everyone else wanted a forecast or "both" (i.e. to have easy access to a forecast and to the weather in different locations). I suspect that the majority of these people would be happy with the Mind Bending approach, as long as switching between locations is sufficiently fast. So my vote would be for implementing 3) and 4) as standard, and make people go through the carousel to see other locations.
Yeah seems like these are most popular.

>
> The "Forecast" and "About" menu items could be removed. If it's
> essential that we have an "About" box (which I don't think it is), then
> it could be linked to from the Preferences window.
The Forecast should be visible if the user has not selected to see the
forecast info in the menu

+1 for the About to go to preferences.

In regards to the design, I think that we should not just look at OUR design but the design and future plans of the other indicators.

To that effect, there should be NO scrolling.

Also, I agree with the mockup from omg. The original thinking behind the multiple locations was that people would want to know the places near them so as to formulate a more coherent picture of their local weather. But I do believe that the forecast is a much better idea and has the same overall effect.

The only question is, what are the intervals we use in the forecast? Days? Hours? If days, how many? These are the questions that must be answered BEFORE we make any decisions about the direction we pursue.

>> 2) I don't think that this should be customisable.
> a simple listbox with checkboxes in the preference dialog should not be
> too overwhelming.
Fair enough. It would need to be a new pane I think. I think everyone wants to see today's forecast info though, so I'd rather than be compulsory so that we can incorporate that information into a design.

>> The "Forecast" and "About" menu items could be removed.
> The Forecast should be visible if the user has not selected to see the
> forecast info in the menu
Yes, definitely.
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/703815
>
> Title:
> change layout by omgubuntu mockup
>
> Status in Indicator-Weather:
> Confirmed
>
> Bug description:
> please, I think, this is great idea
>
> http://www.omgubuntu.co.uk/wp-content/uploads/2011/01/weatherme.jpg
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/weather-indicator/+bug/703815/+subscribe
>

> The only question is, what are the intervals we use in the forecast?
> Days? Hours? If days, how many?
I would love it if the forecasts were for 1 hour, 3 hours, and 1 day into the future. BUT I don't think we can get that data from anywhere. Certainly we can't get that from Google's APIs. So I suggest that we deeply integrate today's forecast into the top part of the menu, and we have the next three days' forecasts further down the menu as per the mockup.

This is precisely what we get from google: four days of forecasts (including today's), for each of these days we get min/max temps and a description ("Partly Cloudy").
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/703815
>
> Title:
> change layout by omgubuntu mockup
>
> Status in Indicator-Weather:
> Confirmed
>
> Bug description:
> please, I think, this is great idea
>
> http://www.omgubuntu.co.uk/wp-content/uploads/2011/01/weatherme.jpg
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/weather-indicator/+bug/703815/+subscribe
>

Oh dear, first time sending emails to launchpad :-\

Regarding the "deep integration" of today's forecast into the top part of the menu: I would still like to see the large icon at the top of the menu turned into a "Today:"/"Tonight:" box with a large forecast icon and high/low temperatures next to it (or in small text underneath?) Panagiotis, I agree with your reluctance to use colours.

I think that one of our most important use-cases is someone at home wanting to know how warm to dress, and whether to grab an umbrella on the way out the door. They need to know the day's forecast, and the max and min temperatures. This "Today:"/"Tonight:" box would visually separate this essential information from the rest of the menu. I might have a play around in Gimp in 12 hours...

This mockup builds on Panagiotis and Mind Bending's mockups and my ideas from earlier. Apologies for my poor Gimp skills. What do you think?

While I like an enlarged forecast icon and the now & today labels, I find it a bit confusing imo, how the two sections (now and forecast) blend.
Perhaps it would make more sense to put the forecast section below (with icon on the right), just above the rest of the forecast info (as it is also done in web sites). This would effectively put the "Feels like" temp, directly below the current temp, which also makes sense.

+1 for the wind direction to be at the end and the sun data merged

I see how this is more logically structured, but personally I prefer the first mockup with all the vital information displayed at the top of the menu, in a format that doesn't look like a list. It just seems easier with the first design to locate the most important information: current temperature, current condition, forecast temperatures, forecast condition.

I've progressed a lot in the vala-port branch; you can see the blueprint for details and give the code a test run (it won't mess with current version).

I attach screenshot of the menu and the preferences dialog.
I've changed/added a lot of pieces, some of them are:
Forecast is by default in the menu. Google gives forecast for 4 days and Yahoo only 2 (This info is provided in the same report that provides the condition, so there is not any additional download).
The new carousel-like Location selector is always present and only shows the arrows when multiple locations are set.
The condition overview widget shows two rows (instead of 3) and a smaller icon (48 pixel size), I think it's much nicer this way.
The various condition fields can be set on the preferences dialog. Their values are aligned on the right per Felix' mockup. I too prefer it that way.
The complex "Sun" field can be quite long, so I think it's better to provide sunrise & sunset separately.
Arrows are used for wind direction and barometric pressure rising/falling status.
The menu is properly navigable by key/mouse (including the location selector arrows), only some elements can be clicked/activated and certain items do not dismiss the menu when clicked (like location switching & refreshing).

What do you think?

So, in this new version, what are the default settings? And why is there a slight indent of the condition?

For the new options I've set these defaults:
- Indicator icon only
- Show forecast in menu
- Do not show all locations in menu
- No notifications for all locations
- These fields checked: Feels like, Humidity, Wind, Sun

Of course we can change anything, this is still experimental.

I've put an indent because the condition text is a value, not a label.
IMO it looks nicer than the no-indent version, somehow it breaks the
kind-of-dull plain listing. It's only a padding internal setting that we can
reset to 0.

I see. I feel that the screen shots you sent were all a bit crowded. The one I feel would work the best is the fourth one from the left.

Now is there a way to make all of our values left align instead of right align? I would like to see a shot of this to see if it remedies some of the clutter.

Now our little forecast entries at the bottom. I feel that today's forecast should be left out. Also I think that what I can only assume are the highs and lows are a bit confusing, there must be a better way to convey this, but nothing instantly jumps out at me.

Is there a way to have those entries vertical? The attachment is the android weather app from google. This demonstrates the vertical aligning I was talking about.

That's really cool. Great work. The vala-port branch also now works on my computer, so I've had a bit of a play and seen this in action. Very nice stuff! I like how there's options to display thing like barometer and visibility and that they're not displayed by default. I also like the arrows to indicate direction.

Like Cullen, I think it looks a bit crowded, but I'm not sure what the solution is (we need to convey a lot of information in not much space). I agree layout 4 looks the best (and should be the default). In the version running on my computer, I can't see how to make three days of forecast (rather than just one) come up in the menu.

I'll have a play with the code over the next couple of days. It's looking really, really good!

It's true that it can appear a bit cluttered, but it also depends on how many fields the user is interested in.
With the defaults I stated, the fourth layout is the default appearance.
Felix, just select Google as the provider to see more forecast days (4 instead of 2).
Cullen, I'll try the vertical positioning and post screenshot with left aligned fields.

I don't think that today's forecast is irrelevant. In the morning it makes more sense than the current condition. You'll want to know if there will be rain. Perhaps we can show it depending on the time?

Here are screenshots with left aligned fields.
First is from Google (4 forecast items), then from Yahoo (2 forecasts).
The two last ones have reduced row margin to 3 pixels instead of 6, perhaps it's better that way?
The last one uses right aligned fields for comparison.

Also note that Google does not provide pressure and visibility.
Perhaps in the prefs list we should state something like "Yahoo only" and hide these automatically for Google source.
Currently any missing/error value is displayed as "--".

I'm also thinking to handle the sunrise/sunset info transparently.
If the time formatted result is short (5 chars) show them merged, otherwise use two separate rows.

The vala-port branch is now merged into foggy branch, so you can check that one out.
The condition fields have been reworked, see bug #743553.
The sunrise/sunset fields are handled transparently, as described above.
Weather source specific fields (like Barometer and Visibility) are visible only if they are provided by current source.
Culen, I've set the bases so that we can have a table widget with icons and now it'll be possible to align the forecast info vertically like you suggested. I'll try it.

Any opinions on the temperature precision? Do we want a decimal digit? Should we put it in preferences?

> Any opinions on the temperature precision? Do we want a decimal digit?
No decimal place for the temp in the indicator's label - and it's clever how you've dropped the "C"/"F". One decimal place next to the "Now:" label in the menu. Among other things, it makes the "Now:" temperature less redundant!

I really don't feel that infinitesimal fractions of a degree would be of use to anyone. And one should remember that the temperature will be for a place NEAR you, not your exact location. So a general temperature is fine because it would probably be closer to the average.

Just joined the Unity crowd and like th weather app -- great stuff.

One suggestion that I'd love to see. Add the ability to configure C vs. F for _each_ location. I am in the US, but also watch my wife's home city in Europe. When I look at my US city, I want to see F, since that is how I think. When I look at my wife's European city, I want C, since that is how her family thinks.

Παναγιώτη, η γηναίκα μου είναι από την Κύπρο.

That does seem like a reasonable idea. That should not be the default action though I don't think. Maybe another entry in preferences along the lines of "Show temp. in units based on location of origin."

Nice suggestion David. I too think that it should not be a default.
But is it actually possible to find the units used per country (geonames does not provide it)?
The other alternative is to present an "Override units" dialog if the user selects the option.

I'm about to start working on a new location assistant (and related location improvements) and this came on the right time.

What I had in mind was more like:

- Show all temperatures in same units (yes/no).

If no, then when you configure each location, you get the chance to choose for that location. If yes, then any time you choose, it applies to all locations.

However, I'm not married to that idea. Your suggestion, Cullen, of figuring it out based on origin is good too -- just a little less flexible for someone who wants to have it their own way.

We should not complicate the UI. I think the units section can stay as is.
In the new add/edit location dialog, there will be specific settings for the location, like label and weather source coverage. There we can add a setting "override units".
For example a combo box with "default"/"imperial"/"si".

That works for me. Thanks.