Prevents JavaDoc tooling issues because these tools check comments
starting with `/**`.
Depends on #2987
Signed-off-by: Wouter Born <github@maindrain.net>
- 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:
<img width="1130" alt="image"
src="https://github.com/user-attachments/assets/6bb010b7-d8e3-42bf-a3ae-0236e3ca3601">
After:
<img width="1127" alt="image"
src="https://github.com/user-attachments/assets/395b2440-532b-41f1-8369-c9963ebe84b7">
---------
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Closes https://github.com/openhab/openhab-webui/issues/2675
HTML escape characters in input widgets were not properly supported,
leading to an escaped character sequence under certain conditions.
---------
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Several Button elements are accepted at the same place in the grid only
when they all have visibility conditions.
In this case, the user must define proper conditions so that only one
button is visible at any time.
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
When a Switch widget leads to the rendering with buttons, the value
should not be by default also displayed at the left of the buttons
(redundant information), except if it is requested through a state
pattern defined on the widget.
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Follow up #2535
The function reloadIcon is already called by the function setValue at
line 636 just before calling setValuePrivate.
The icon continues being refreshed while moving the slider except if
releaseOnly parameter is set.
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Same behaviour as in the Android app is now implemented for the "none"
icon. This icon means "no icon" and we don't want to request the icon
servlet. When this icon is associated to a sitemap element, the icon
servlet is no more requested. Instead, a simple empty SVG tag is
considered and inserted in the HTML page. There is also no dynamic
behaviour (with item state) applied for this icon.
Additionally, in case the loading of any OH icon fails, the IMG tag is
replaced by an empty SVG tag in the HTML page instead of updating the
IMG source with the none icon URL (triggering a potential new icon
servlet request).
Fixopenhab/openhab-core#3977
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
---------
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Fix#2525
Also related to openhab/openhab-core#4084 and openhab/openhab-core#3430
Two behaviour modes are now supported.
- If releaseOnly parameter is set, the new value is sent to the item
only when the slider is released.
- If releaseOnly parameter is not set, new values are sent to the item
while moving the slider. Events are sent at a certain frequency, this
frequency is defined by the sendFrequency parameter if set or every 200
ms by default. Event is not sent when the value is is unchanged (when
stopping the move but keeping the mouse pressed).
The brightness slider of the colorpicker widget is also updated to send
regular new color commands when moving the slider.
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Closes#1780
Colors are those defined by user through the labelcolor, valuecolor and
iconcolor parameters. The aim is to provide a good contrast n both
themes. For example white in light theme just leads to something not
visible. So black is used instead.
This behaviour is already implemented in the Android app with the same
adjustments.
Colors adjusted in light theme: yellow, pink, white, lime, aqua, silver
and gold.
Colors adjusted in dark theme: maroon, purple, green, navy, blue, black
and gold.
These color adjustments are controlled by a new Basic UI setting,
enabled by default. By disabling it, no adjustment is performed and the
old behaviour is restored.
Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Wouter Born
openhab-bot
Holger Friedrich
openhab-bot
lolodomo
jimtng
Florian Hotze
Mark Herwege
dependabot[bot]
Kai Kreuzer