-
-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Current Beta]: App ignores user-defined icons #455
Comments
I suppose that the icons are black with a transparent background. Resulting in pitch black icon fields when displayed in dark mode. Currently app in dark mode does not call themed icons. |
Or it would require inverting images: |
@Boby71 : Can you please upload one of your icons as an example? |
Hi, Thanks, |
Here's the item definition:
And here's the sitemap:
|
Sorry for the format, for some reason the formatter doesn't recognize my code as code... |
Additional hint: The app only provides the wrong icons when being used on groups (text {} or frame{} level) AND when there is a default smarthome icon available (e.g. "alarm" or "camera"). If there is no (embedded?) default icon, the app displays the correct (user provided) icon. When I use e.g. "camera1" as name for my PNG file, everything works as expected. When I use "camera", the wrong display is being displayed. |
Well that's strange. iOS app should ignore icons defined for frames. Also OpenHAB is very clear: Users may substitute their own icon for an icon from the default icon set by placing a file in the $OPENHAB_CONF/icons/classic/ folder with the same filename as the name of the icon being substituted. Simple solution for user-defined icons: let them have a different name to the standard names. |
You're right - my mistake, frames don't work. Sorry about that. But on grouping items the problem is still existing. Is there somewhere a list of those "predefined" icons and which names I have to avoid? I wasn't aware are some at all, since they are not visible in the icons folder where I can place my personal ones. Personally, I have no problem in using different names for my icons - it's exactly what I'm doing now (e.g. "camera1" instead of "camera") as workaround. But that doesn't explain the different behaviour between the web GUI and the app GUI. IMHO OH2 should render the GUI as similar as possible. And showing different icons is not similar (at least for me). If you want, I can close this thread - when I've changed all my affected icon names, my problem will be solved for me. |
Maybe this was just a caching issue (replacing stock icons). I noticed that the the "Clear Image Cache" setting was broken and didn't do anything. |
- fix image cache purging, refs #455 Signed-off-by: Tim Müller-Seydlitz <timbms@gmail.com>
@weakfl : Can we close this issue? |
I think so. We can still re-open if required. |
@timbms Did you re-open on purpose? |
No probably a mistake |
Signed-off-by: Tim Müller-Seydlitz <timbms@gmail.com>
Signed-off-by: Tim Müller-Seydlitz <timbms@gmail.com>
Describe the bug
I do use custom icons (PNG format) and they are displayed correctly in the web interface. But not in the app. It almost looks like that the app ignores user-defined icons in the app - but not all of them, only certain (maybe if there is a predefined icon available?)
To Reproduce
Steps to reproduce the behavior:
Try to use custom icons for a) elements which have predefined icons (e.g. "alarm") and b) for items which don't have predefined icons (e.g. "pool")
Expected behavior
I expect the app to render the same icons as I can see in the web frontend
Screenshots
![oh2_dark_PC](https://user-images.githubusercontent.com/22266373/66256859-c4880200-e792-11e9-92b0-feff89ec85cb.png)
![oh2_dark_ios](https://user-images.githubusercontent.com/22266373/66256861-c81b8900-e792-11e9-9460-5111e56cbd4a.PNG)
![oh2_bright](https://user-images.githubusercontent.com/22266373/66256863-c9e54c80-e792-11e9-8640-75c6984b7e12.PNG)
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
It does seem to be a general problem - no matter if I use dark mode or not.
"Clear image" cache didn't help.
The text was updated successfully, but these errors were encountered: