I’m playing with a small revamp of the Item editor so the input values all line up.
The non semantic tags are non collapsible
All Parent Groups are clearly shown
Group type goes up to under the Type
Semantic Class selection
The drop down selection for group type, semantic class, can still be searched by typing the first few letters
The “Non semantic tags” are not collapsible so they’re always visible.
Maybe it doesn’t make sense for Call, but where is the option to define the aggregation function for the Group example? Can I assume it would line up with “Members Base Type”? Same for Groups with a Number:X type and Dimension.
Beyond that question it looks good. I like the order and how everything lines up.
I’ve added two more screenshots in the original post above
What happened to Unit and State Description?
Be aware I am working on a PR to improve the units in these editors. A first part of it is Suggest unit on item creation based on channel unitHint if available by mherwege · Pull Request #2312 · openhab/openhab-webui · GitHub, but I am currently extending it to auto suggest a curated list of units.
Unit is there. It’s called “Dimension” for some reason (I didn’t follow the PR that closely but think there was a discussion and reasons for choosing that). This is true even in 4.1 release so it’s not changed by @JimT’s PR (and probably shouldn’t be). I don’t know why it’s called “Dimension” instead of “Unit” but it’s consistent in all three places where an Item can be created.
State Description is not and has never been a part of the Item creation dialogs. I’m ambivalent on whether it should be or not (Item creation is a great time to set the state description but state description is as complicated as the Item itself to configure) but either way adding it is probably something for a different PR from this one.
Never mind, I’m just being thick this morning.
They are only shown during item creation, at least that’s how it is right now. Is your PR going to show it when editing an existing item?
No, it is not the same thing. Dimension goes first, unit afterwards. The dimension field only shows the system default.
No, I am not. All my focus so far has been on item creation. However, if we allow to change the dimension of an item in the UI, we also have to be able to set the unit afterwards. It looks like the UI does not allow it at the moment.
Yes it should show it also when editing an existing item. It should be pretty straight forward to make the change.
Here’s my PR. I’m still tweaking the group membership. I think it should show the groups in a list.
I’ve changed the Parent Groups section. This lets you see all the parent groups at a glance whereas previously you’d have to scroll up and down to find which ones are ticked.
I’ve added “Save” / Cancel (or Create / Cancel) buttons on the bottom. I’ve always found the top right link a bit peculiar / non standard. But it’s still there because I know people are used to them by now, and it’s quite consistent throughout openHAB’s UI.
I also show the number of non semantic tags and parent groups as badges (circled numbers)
@rlkoshak wdyt?
@Mherwege here I’ve included the unit / state description when a dimension is set. It’s the same behaviour as when creating a new item, so when switching to a different dimension, the Unit and State Description will get overwritten with the default for that new dimension.
@jimtng Thanks for this. I had done the same in my PR, except that the logic for the unit goes beyond system default (looking at, in sequence: unitHint from binding channel type, webui default unit configuration, system default). When changing, unitHint would not be available (as it does not have a link to channel to work from), so that would be skipped.
How do you want to proceed? I think there may well be a good number of conflicts between the PR’s, so I assume one of us will have to rebase at some point in time.
EDIT: by the way, when changing the item, the info field for unit and state category should probably be hidden (like for other info fields). I did that in my PR.
I’ll be happy to rebase after yours gets merged, although mine I think is ready now, I might still tinker with it more.
I don’t mind rebasing either. So let’s see what is ready first. Mine is function complete as well from my perspective, but it wouldn’t hurt to get some extra testing.
I’m thinking that they could stay on there regardless, but in would look like this, also for item creation:
Although there’s a risk that some people would never notice / see it.
Also I’m thinking it would be super handy to provide a link to a documentation page that explains in great detail about the formatting syntax, but I don’t know how to do that. A link? A little button?
@JimT Why not show it with the text fully visible at creation (like it is now), and in this bubble format when changing? It would make it more likely to be read at initial creation, and still have it available (but less prominent) at change.
For the documentation, I did not follow all, but was @florian-h05 not working on dynamically linking to the user documentation (Help sidebar: Move docs to docs repo & Integrate them into the UI by florian-h05 · Pull Request #2253 · openhab/openhab-webui · GitHub)? I don’t know how granular that can be, and it would allow linking to a specific page.
That can be done too. Might be more relevant to do that on your PR.
AFAIK, it’s just per “page” help link, not a “per field” help.
This would be opening up a whole different dimension. But one could imagine a button on the help doc. When clicked it changes the pointer to a question mark. A pointer click with this question mark pointer on a field would not do anything in the field, but update the help in the help doc.
I really like that you can remove a group with the “x” too!
I like it at a lot. For consistency, can the same be done on the Group’s page to show the Group’s members?
And this is the edit page for the Item right? Will they show the same on the “regular” page for the Item or stick with the current representation?
Aside: I never understood why some things (e.g. metadata) can be edited from the “regular” page for an Item but other things (all the stuff above) requires clicking into a separate form.
That is one of the things that needs to be refactored in the docs right now. Currently the only place that is documented is in the “Label” section of the Items docs. And it’s not at all clear that it applies to MainUI.
But I do know you can provide links in the descriptions of fields. It’s been done elsewhere (e.g. the icons field for some of the MainUI widgets link to the F7 and Material icons).
