OH3 BasicUI switch button size

OH3.2.0M5 on Docker Pi4 64-bit

Hi!

I’m manually migrating from OH2.5 to OH3 by setting OH3 up from scratch. Sticking to BasicUI for now, will look into the OH3 UI when everything works.

I’ve just come across a problem, likely an unforeseen consequence of the new BasicUI style in OH3.
The Switch button minimum size has greatly increased since OH2.5, and so the items I need for minimum functionality no longer fits on my phone screen.

Here’s how it was represented in OH2.5:

2022-01-05_11-34-52

…and here’s how the same item is represented in OH3:

2022-01-05_11-35-29

I tried changing the first two buttons to a single character label but the size stayed the same anyway.

I would like the buttons to be smaller, the way they were in OH2, so that they fit on my screen. :slight_smile:
Suggestions appreciated.
I’d be happy to modify a CSS file in the docker container if you point me in the right direction.

If I’m not mistaken the first screenshot is taken from the android app displaying the sitemap while the second one is from a browser.
I do see the same when displaying the sitemap via browser, however when displaying it via the app the switches are displayed as a dropdown selection.

Oops. I didn’t think of that. You are correct. However, I’m not looking for a dropdown selection, I do need direct buttons. Do you mean the openHAB app will display 3.2.0 like it displays 2.5.0?
Selection is different from Switch.

If so, I should just continue the migration so that I can start using the app with 3.2.0 instead of 2.5.0 :slight_smile:

I’m on 3.2.0.M4

My sitemap uses a switch which is displayed on the app as a selection. Can’t say/remember how it was on 2.x.

I just installed the app on a different android device, pointed it to 3.2.0 final, and it displays like before! Switch is displayed as discrete buttons and the single letter label buttons are smaller than the longer label buttons.

So, it works fine, always has – the only was me, I was indeed comparing the web browser to the app. My bad.

Thanks for responding, @opus!

Ups,
I missed the used version of the app. I’m on the Beta version, using that one the switches are displayed as a dropdown selection on smaller screens.

I hope that is an option? It would be a huge regression in functionality to force a Selection when the sitemap specifically calls for a Switch.

I use selections for more rarely used things which need many options, and Switch for frequently used items that call for instant, easy access – sometimes two or three lines of Switches to cover the different necessary options.

Nope, as said before the sitemap file tells Switch, the app does that automatically.

That’s… not good?
If the app now equates Switch with Selection, do we now need a third control type that presents as a Switch then?

You mention this is the Beta app – does that mean we can expect this anti-feature into the regular version at some point in the future?
That seems like a bad thing on its face – do you know what the motivation is for this? Is there at least some intelligence to it so that it only does it if the buttons would otherwise not fit?

No!

As it does it only on a small screen, there is “some intelligence” behind it.

It could depend on UIs but in Basic UI for example, this is the number of options which trigger the switch from buttons to selection. You have buttons until 4 options. That makes sense, a UI will not be able to render with buttons in case you have 50 options for example.
I believe there is a similar implementation in the Android app.
No change of behavior since a very very long time.

1 Like

Okay! That is fair. Thanks for clarifying. I was worried that this was new behavior that would completely break my existing setup, but if it works the way it always has, there is no problem. :slight_smile: