Open ssalonen opened 2 years ago
The counter argument is if you are in the Model View, only those properties of the Item that are relevant to the Item should be editable, which is what is the case here. Because part of the model is in fact implemented using Group membership, I can definitely see a case for being able to set that here. But Item metadata, Links, etc. I can see valid reasons why we wouldn't want to put those there.
@rkoshak thanks! Actually, almost everything is there (on the side panel, not in the item section -- but who cares) already, including the Item Metadata and links you brought up. I probably should have pasted full screenshots:
Quick comparison to Item view indicates that we are missing only the things in the Model view side panel
The reason why I bring this up: I find model view extremely good UI element to navigate the items I want to modify since everything is organized in logical groups. Would be great to have the full/familiar editing functionality within that same view.
I also find it confusing that we have several "different types of edit views" for item, but not necessarily having same things you can edit there. As a user I need to remember that "in this view you cannot edit that aspect of the item" and need to click further.
Interesting, the Model View has changed somewhat since the last time I used it.
"Sematic classification" (probably not relevant in Model view, that is why we have Model view in the first place!?)
When you click on "edit" you will be able to modify those. They are already represented in the tree view so I'm not sure they need to be shown when the edit view is collapsed.
(non-semantic?) Group membership
What would be really cool is if we could adjust the semantic Group membership by drag and drop in the tree view itself. The membership is already represented in the tree hierarchy through the structure of the tree. How awesome would it be if we could modify that structure graphically too? But even if that is not feasible, there should be some way to adjust the Group membership here I think. Adjusting the Group membership to fit preexisting Items into the model is one of the more frustrating parts of the UI and needing to go from the Model View to the Item to Edit on the Item to adjust it's position in the semantic model is a large reason for why that's frustrating.
I think the intent of the Model View is to only focus on the model and not all Items belong in the model nor are all properties relevant to the model. We would have to weigh the benefits of making it an "all things Item" configuration tool compared to a tool focused strictly on the model. There is already some non-model stuff creeping in with the access to the metadata and links. So I'm ambivalent on whether it's a good idea to add non-semantic model Groups to this. But depending on how it's implemented, it might be harder to exclude those Groups than to just include them.
+1 for drag & drop.
Indeed fair points, there is risk that having all in this one view will be messy. For me actually equally working setup would be a link to open item view in separate page. Especially if https://github.com/openhab/openhab-webui/issues/1480 would be fixed
The problem
In Model view, when selecting an item, there is an option to "Edit" Item in the side-pane (1)
Confusingly, this is not a full edit view and does not have all the settings. For example, "Group Settings" (Members Base Type and Aggregation Function) are not editable. Neither is Non-Semantic Tags.
(1)
(2)
Your suggestion
I find it would be more logical either to have full Edit view (2) in the side-pane or simply having Edit button to go the full view. I find this partial implementation confusing and I start to doubt myself where to find the property I want to edit.
Your environment
Additional information