You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since OH 3.1 (#2123), it is possible to specify a system-wide sort order for items in groups (so that, for example, Basic UI always displays them in the exact same way).
This is great 🏅 for deterministic display of the UI, but often times it is the most useful to have items sorted by value (ASC or DESC).
For example, it makes sense to display device battery levels 🔋 as lowest first 📈 or energy consumption 🔌 from highest to lowest 📉 . Accomplishing it today (via rules) is cumbersome and may be brittle - ex. see this community thread.
Enhancement proposed
Extend Group:Number definition to allow for specifying per-Group sort order. ItemUIRegistry::getChildren() would keep providing sorted outputs for groups, but:
If there's a per-group sort order defined (also including by-value sort) - use that as primary sorting criterion,
system-wide setting (as-today) becomes a 2ndary sort criterion (ex. first by-value,descending, then by-name).
Enhance Group definition to allow expressing the sort order. For example:
[option 1⃣ ] - as metadata
Example group definition syntax:
Group:Number:MINGBatteryLevel"Battery levels [%.0f %unit%]" <battery> (gApartment) ["Battery"]
{
unit = "%",
item_sort_order = "BY_VALUE_ASC"//<-- new
}
The sort order direction could be an UI-only parameter (no impact on core). Not sure about it though, given the default sort has been implemented by core already and this could lead to split responsibilities.
[option 2⃣] Extend definition syntax itself for the grouping functions, ex. Group:Number:Energy:MAX(SORT_DESC) or Group:Number:Energy:MAX:SORT_DESC.
Notice also that functions such as MAX or MIN may imply the sort order on their own, so perhaps this could be exploited...
Add BY_VALUE_ASC and BY_VALUE_DESC item sort criteria.
[non-option ⛔] Note that simply adding a system-wide value-based sort settings somewhere here:
@cweitkamp - The PR looks a little stale though... Can you confirm if you plan to pursue it or if there's a newer PR with it somewhere❓
(Sorry for duplicate, missed it on initial search.)
BTW. Not closing this issue though, to allow a place for discussing the feature itself (vs. implementation discussion on the PR).
Since
OH 3.1
(#2123), it is possible to specify a system-wide sort order for items in groups (so that, for example, Basic UI always displays them in the exact same way).Currently supported options (#2417) include:
NONE
)LABEL
)NAME
)This is great 🏅 for deterministic display of the UI, but often times it is the most useful to have items sorted
by value
(ASC or DESC).For example, it makes sense to display device battery levels 🔋 as lowest first 📈 or energy consumption 🔌 from highest to lowest 📉 . Accomplishing it today (via rules) is cumbersome and may be brittle - ex. see this community thread.
Enhancement proposed
Group:Number
definition to allow for specifying per-Group sort order.ItemUIRegistry::getChildren()
would keep providing sorted outputs for groups, but:[option 1⃣ ] - as
metadata
core
). Not sure about it though, given the default sort has been implemented by core already and this could lead to split responsibilities.[option 2⃣] Extend definition syntax itself for the grouping functions, ex.
Group:Number:Energy:MAX(SORT_DESC)
orGroup:Number:Energy:MAX:SORT_DESC
.Notice also that functions such as
MAX
orMIN
may imply the sort order on their own, so perhaps this could be exploited...BY_VALUE_ASC
andBY_VALUE_DESC
item sort criteria.openhab-core/bundles/org.openhab.core.ui/src/main/java/org/openhab/core/ui/internal/items/ItemUIRegistryImpl.java
Lines 891 to 892 in 67303fa
would be the most straightforward... but unlikely to be useful at this high level (also, the compare would have to be by
string
repr.) 🙅.The text was updated successfully, but these errors were encountered: