If you define an Item in the UI, you can use other icons than the “classic” ones, for example F7 by setting “Category” to f7:<iconname>. Doing the same in an .items file results in an error in the log. It seems to complain about the colon, which apparently isn’t expected. I’ve tried to escape it with both ^: and \: to no avail.
Is there a way to do this, and if so: how?
Can you show your items file please.
I don’t have an .items file using this, since it doesn’t work, but I can show you an example that doesn’t work:
Switch DM7020Mute "Mute" <f7:ant> (gLivingRoomDreambox) ["SoundVolume", "Switch"] {channel="enigma2:device:a7851f4dff:mute"}
…which results in the following error in the log:
2022-07-19 14:35:57.416 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'stue.items' has errors, therefore ignoring it: [31,59]: mismatched input ':' expecting '>'
I think the f7 icons can only be used in the Main UI, if you want to assign them in a .items file, you have to add a cusomt widget with the icon in the metadata
Thank you for the reply, I know how to add custom widgets in .items files - but that’s “overkill” for what I’m trying to do here. I simply find that there are too many “classic” icons missing, and I want some kind of indication of the type of control or sensor/state to be shown both in MainUI (in the “auto-generated” views under location, equipment etc.) and in Sitemaps. <icon> works for this, but I can’t seem to go beyond the “classic” icons.
I know that mixing “classic” and other icons won’t be pretty, but to be honest I don’t think most of the icons are that pretty anyway, so I’m focusing on the functionality now, and if I’m up to it in the future I might find or make icons that I actually like.
When I check the JSON DB files after creating an Item in the UI, no custom widget is added if I specify a F7 icon. It’s merely set on “category”, which as far as I can understand is the same as what is specified with <> in .items files. Thus, I assume that it’s only a matter of .items file parsing, and I was hoping that there would be a way to escape myself out of the problem. That said, I don’t quite understand why it would be difficult to accept a : between < and > when parsing. Anything that shows up before the closing > should just be considered a part of the value in my opinion.
To elaborate a bit, sitemap based UIs would use the <icon> definition, but they are not able to use f7 icons, so even if you got over the syntax issue it would be an invalid usage anyway.
But I don’t think you can get over it; colon character is simply not allowed in (legacy) icon names.
Good point about the Sitemaps, I didn’t think of that. That said, I wouldn’t imagine that it would be terribly difficult to add that support to Sitemaps/BasicUI if there was an interest to do so. But, since it’s considered “legacy”, I guess there aren’t.
But, since .items files are still supposed to be supported, we still need a way to specify category that corresponds with what the UI does, to get them to work in MainUI at the least.
The <icon> part of the Item definition corresponds to the Category field for an Item in the UI. You can’t use an f7 icon for that field even in MainUI. Only OH Icons are allowed there.
See Items | openHAB for how to create your own OH icons if you are missing some from the built in icons.
Nope, the Category simply does not support any other source for icons. There isn’t any way around that. It’s not a matter of parsing, it’s a matter of changing a bunch of code in the core to support other sources for icons.
In general the whole icon situation in OH is a mess. We are half way between a more modern approach that lets us use multiple sources for icons and the legacy “category”. If you want to use the new approach that supports material, f7, etc icons, you have to create a custom default widget that specifies the use of that icon. Otherwise you have to use OH icons only.
I know how to add my own icons, but making them takes a lot of time (for me at least). Finding some online is possible with enough effort I guess, but I’m so tired of all the dead links and “tricks” to get you to buy a whole set to get a couple of icons etc, that I have quite looking after a relatively short times both times I’ve tried. It must be said that I really despise the whole “flat design” thing, which makes it harder to find something.
Ah, MainUI “fooled me”. You can specify F7 icons in the UI, and they show up. It even generates the following JSON:
{
"DM7020HD_TestMute": {
"class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
"value": {
"groupNames": [
"gLivingRoomDreambox"
],
"itemType": "Switch",
"tags": [
"SoundVolume",
"Switch"
],
"label": "Mute",
"category": "f7:ant"
}
}
}
But, when I try to use this by opening a “page”, there’s no icon. So, I see that you’re right that core doesn’t handle it. I must say that I don’t think MainUI should mislead us to thinking it does though 
While I don’t know a fraction of what you know about this, I must say my impression so far supports this. I think it should be a priority for somebody to remedy this, since it causes a lot of frustration to have to figure out and work around all these “quirks” when trying to configure the system.
I understand that icons are somewhat of a minefield when it comes to licensing, so it’s not easy to just enable “user icon sets”, but I think it should be easier to handle than it is now. I think icons are of at least “medium importance” for usability of a UI - I use it to “filter” with my eyes before starting to read the labels. It takes to long to actually have to read all the labels to find what you’re looking for. That’s the functional part that I consider most important, on top of that is of course the “nice to have” bonus nice icons can add to the look.
Step forward, that volunteer!
It’s not quite misleading but it could be better. When you start typing in the Category field it starts to show you a list of the valid options. You need to select from those. Where if falls down is by not generating an error if you type in something that isn’t in its list of known icons.
I don’t know if there is a technical reason for this (e.g. custom icons in the icons folder don’t show up in the list) or if it was an oversight. It’s worth filing an issue if you want to see this changed.
Everything done in OH is done through volunteer effort. Every volunteer has their own priorities. So far this hasn’t become one of them. I’m not sure this will ever become one of them. But you can at least raise an issue on Github and see what devs have to say (beware, it may be nothing at all) and you can sweeten the pot by offering a bounty through bounty source. But most of the time, if it’s something you really care about you need to take matters into your own hands and implement it yourself.
Not only that, it actually loads and shows the icon in the UI. That’s what made me believe it would work, not the mere fact that I didn’t get an error.
I know all the “challenges” that comes with open-source volunteer projects. I also know that if you want a usable result, there must be some form of “decision making” that decides what the project should evolve into. While you can’t “order” anybody to make anything, you can reject contributions that don’t fulfill certain standards or requirements, and making sure that functionality is working in a comprehensive way should be one of these. If not, the project will ultimately fail. Developers that only care for their own “needs” and don’t care about the project as a whole is probably the biggest threat to volunteer projects as I see it, as they will end up breaking stuff that used to work that they “don’t care about”, making it extremely frustrating for users.
Without a broad user base, you will also stifle recruitment of contributors. Most contributors will “tire” over time, so it’s necessary to maintain a certain level of recruitment. Personally I don’t understand the attitude, I’ve spend countless hours developing things that other people need that I will never use myself. It doesn’t bother me at all, as long as I find the functionality reasonable for the project.
This isn’t something that is that important to me either, I can find or make the icons I need. When I said I think it should be a priority it’s of concern for the project itself. I don’t think it’s good for the project to be full of many small “challenges” that each and every user must overcome. For each such obstacle, a lot of users will give up.
When it comes to doing things myself, I’m not foreign to that at all. On the contrary, it’s my “primary philosophy” with “collaboratory projects” that if I contribute the parts I need that aren’t there, and everybody else does the same, we will all benefit. There’s a number of obstacles that makes this very difficult when it comes to openHAB though, so I don’t consider it an option in this case. Otherwise, I would typically jump in and try to figure out what changes would be needed for core to handle this.
That really should be filed as an issue then. It shouldn’t do that. How to file an Issue
This is in place and frankly, it is a source of complaints from devs because it can take some time for PRs to get merged sometimes and some PRs get rejected because they break things, don’t meet certain standards, access things that are by policy forbidden, etc.
But also keep in mind that MainUI was written, from scratch, and introduced at the release of OH 3.0. It hasn’t been around that long and when it was released it was released as a MVP. It’s still under development and even if the relatively short time that OH 3 has been around it’s come a very long way but it still has a long way to go. In short, the icons handling wasn’t implemented on its own in isolation. It was part of that initial drop of the whole MainUI in the first place.
As for the attitude, we’ve had many many users file an issue or request a feature who then rage quit because no one implemented it for them. There seems to be a high degree of belief that having the idea is enough to get things done and then a disproportionate amount of anger when it’s not done.
I’ve dealt with my share of those too, believe me. But in my experience, they are a minority. I do believe that the way they are met also matters though, it’s very frustrating if the only feedback you get is very defensive or that you get none at all until you say something “stupid” that somebody can reject.
But believe me, I’m not in that category. I have already contributed a lot of Norwegian translations to various parts of openHAB, and I have made small contributions/PRs both to the Onkyo binding and to openHABian. I’m also currently doing proofreading for the Norwegian translations of the Android app. I would probably have done more too, were it not for that I have to keep things within the DCO exeption. It doesn’t take much to exceed it, so many things are “out of bounds”.