[BasicUI] Align and optimize available space for switch with mappings

[jimtng]

• Should only affect switch with mappings, not player control
• Utilise the wasted space instead of wrapping the buttons into multiple rows, if possible.
• Right align the buttons. This makes it look much neater.
• Instead of limiting the width of the buttons, reserve a minimum width for the label
• However if the label is shorter than 6 characters (including blank labels), reduce the label's minimum width to just what's actually taken up by the shorter label. This gives more space for the buttons with shorter labels.
• When buttons wrap to multiple rows, make sure that each row contains almost the same number of buttons, instead of having the first row filling up the horizontal space, move the buttons down. By doing this, there is more space for the label to occupy.
• Squeeze extra space for more buttons in "condensed layout" by reducing padding, inter-button gaps, min-width, etc.
• The reduced padding in condensed layout also affects buttons in buttongrid.

Before:

After:

[lolodomo]

The idea was to keep a minimum of place for label and value.

[lolodomo]

Your commit of vscode settings is probably unexpected ?

[jimtng]

The idea was to keep a minimum of place for label and value.

I haven't tested this with various widths of labels.

Your commit of vscode settings is probably unexpected ?

oops, removed now.

[jimtng]

The idea was to keep a minimum of place for label and value.

Reserving space for the label and value has merits too. I see that simply removing the width here is not enough.

Before:

After (bad for the label):

I'll play with it a bit more, and I'm open to ideas

[lolodomo]

Using 4.2 M1, I can see that I have to increase the zone for buttons to not have controls for a Player item cut on 2 lines on a phone.

And I also see that the buttons in the new settings page are not rendered perfectly on a phone when cut on 2 lines.

[jimtng]

I haven't had a chance to look into this yet, and I'm generally clueless with css. If you have a fix, feel free post it and close this PR.

Ideally, the buttons can take up as much horizontal space as possible, especially when there are no labels or the label is short. This way user can set a blank label to maximise the space for the buttons. But when there's a label, then reserve some space for the label.

[lolodomo]

Even with your change, I have strange result like this one:

If I increase just a little the window, it is then OK:

Maybe the problem occurs when the label is truncated and "..." is injected ?

[lolodomo]

I would like to find the proper CSS properties to at least have player controls always on one line when there is enough place for that.

[lolodomo]

If I reduce the length of my label, this is then fine:

The problem seems to be when the label is truncated.

[jimtng]

The solution would probably include changing the css of the labels and/or the container.
Could we perhaps turn it into two lines (dynamically) when there's not enough space? So the label on top, then controls below it, but if there's enough space, keep them both in one line.

[jimtng]

Original post updated with the latest result.

[jimtng]

@lolodomo this still reserves some space for the label / value, but also tries to make the buttons take up as much space as possible, but if it must wrap into multiple lines, maximise the space for the label again. See the original post with updated screenshots

[jimtng]

For anyone interested in testing, you can put this jar file in your addons folder, then disable the built in org.openhab.ui.basic bundle, and restart/enable this bundle.

Note: rename the file and remove the .txt extension.

org.openhab.ui.basic-4.3.0-SNAPSHOT.jar.txt

[GeVaSta]

New JAR is worse I think. Even wider screen does not put the buttons on one line.

[jimtng]

New JAR is worse I think. Even wider screen does not put the buttons on one line.

Make sure you do a force refresh (Cmd+Refresh on mac, shift+reload or something - depending on your browser).

[GeVaSta]

I did a refresh (Shift+F5 on Windows).
Looks like it could be something with the number of colums setting of the browser. I have mine on one (1) column.

[jimtng]

Works fine for me, both 1 column and 2 columns.

[GeVaSta]

After playing with the number of colums it changed a bit but still plenty of room to add button to the right instead on two lines.

[jimtng]

I suspect it hasn't fuly refreshed. What's your O/S, browser version? I'll try it on BrowserStack

[jimtng]

This is on BrowserStack running on Windows 11, Edge 125:

[GeVaSta]

The difference is, I think, I use a much smaller window. Thats for me the whole point. I like the window as small as possible to put it right side of my screen to keep it visible.

[GeVaSta]

Can you show a screenshot of the smallest browser window where one button moved to a second line? And the smallest on one line please?

[jimtng]

I see, so when the window is narrowed, it does wrap. Thanks! I'll make some adjustments to fix that.

[jimtng]

@jimtng : the last version is worst I think because now labels are truncated even when there is place to not truncate them.

I'm back!

I had a look at this again, rebased my branch and recompiled without any changes, and I can't see any problems.

In your screenshot above, is it the "Espa..." that you think behaves the wrong way? IMO, it's correct because the last button wouldn't fit in one line. Yes, after it's wrapped, it "seems" that there is a lot of space but it's just not quite wide enough to accommodate that button.

[lolodomo]

In your screenshot above, is it the "Espa..." that you think behaves the wrong way?

Bot at all! The current problem is that now all my labels are truncated and only 3 or four characters are shown. This happens even when there is a lot of place to show the full label. Look at my screenshot, except for the label "NR", all others are truncated.

[jimtng]

The current problem is that now all my labels are truncated and only 3 or four characters are shown. This happens even when there is a lot of place to show the full label. Look at my screenshot, except for the label "NR", all others are truncated.

I tried but cannot reproduce this. Can you paste me a sitemap that I can use to test it?

[GeVaSta]

I noticed something very strange. At every screen update the values of a setpoint label, move from left justified to right justified.
see the two pictures of every state.

[jimtng]

I noticed something very strange. At every screen update the values of a setpoint label, move from left justified to right justified.

did this happen on this branch's build but not on the main milestone / snapshot?

If so, can you please provide a sitemap for me to test, along with details about your basicui settings.

[GeVaSta]

Wait! False Alarm. This problem has nothing to do with your adaptions in the Basic UI.
The problem I have are in the IOS app! So why I bothered you stays unclear.
Will report it in IOS branch. Sorry.

[lolodomo]

Ok, here is how to reproduce the problem in IDE with the Demo sitemap.

Update the demo sistemap by adding two new elements:

sitemap demo label="Demo Sitemap" {
	Frame label="Demo Items" {
		Text item=DemoContact label="Contact [MAP(en.map):%s]"
		Text item=DemoString label="Message [%s]"
		Text item=DemoDateTime label="Date [%1$tA, %1$td.%1$tm.%1$tY]"
		Group item=DemoSwitchGroup icon=icon1
                Switch item=DemoString label="Switch demo long label" mappings=[1="Value 1", 2="Value 2", 3="Value 3"]
		Switch item=DemoString label="Switch demo long label" mappings=[1="Value 1", 2="Value 2", 3="Value 3", 4="Value 4", 5="Value 5", 6="Value 6"]
	}
	Frame label="Magic Test Items" {
	   Colorpicker item=MagicColor
	   Switch item=MagicOnOff
	   Slider item=MagicDimmer
	}
	Frame label="Location" {
		Mapview item=DemoLocation height=10
	}
}

Starts openHAB. Here is the initial rendering that is fine for labels and buttons rendering:

Now click on DemoSwitchGroup to open the sub page and go back to the main page. Here is the new rendering with truncated labels and different dispatching of buttons on the two lines !

Now click Ctrl+F5 and the initial and correct rendering is back.

It is not specific to browser, I reproduce it with Firefox and Chrome.

[jimtng]

It seems that onload event didn't fire when navigating to a subpage (Text element) and back. I've added an extra call to run minimizeWidth immediately.

[lolodomo]

My tests with my current sitemap in production are all positive now.

Will run again tests with specific cases leading to your changes in september and start again a final review.

[lolodomo]

Will run again tests with specific cases leading to your changes in september

Done.
There is still one case on my phone with bigger font set and value displayed where buttons are shifted too much to the right.
But I think you have probably no choice, you defined a minimum size for the label and that is expected.
So for me, tests are considered as OK.
By the way, all this is better than before.

Remains to do a new quick review.

[lolodomo]

LGTM, thank you

[lolodomo]

I will have to check if this does not impact the new buttons containing a square color (Colorpicker and Colortemperaturepicker widgets).

[lolodomo]

Thank you @jimtng for this work and your patience.

[jimtng]

There is still one case on my phone with bigger font set and value displayed where buttons are shifted too much to the right.

Let me know how to reproduce that and I'll have a play with it. It'd be much easier (I hope) now that this is merged, thanks!

[lolodomo]

Let me know how to reproduce that and I'll have a play with it. It'd be much easier (I hope) now that this is merged, thanks!

With the following element:

Switch item=DemoString label="Demo String [%s]" mappings=[ VALUE1="Val 1", VALUE2="Value 2", VALUE3="Val 3", VALUE4="Value 4", VALUE5="Val 5", VALUE6="Long value 6", VALUE7="An ultra mega long value 7"]

Select the second button to have a value and on a a phone, set bigger font as preference.
If I correctly remember, you explained that there is a case while due to label and value, you cannot prevent from shifting the buttons to the left.

[jimtng]

This?

[lolodomo]

Yes, exactly