-
-
Notifications
You must be signed in to change notification settings - Fork 313
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
Icons misplaced #3786
Comments
The switch-with-mappings icon issue likely is #3773. The 'white background' one likely is one I also have seen once, but didn't have a chance of investigation yet: It looks like the icon and the loading placeholder ('glowing' frame) are both shown simultaneously. |
Then I guess we can close this as duplicate and/or should create an issue for
|
We can keep this one for that issue. As far as I can tell, this placeholder (skeleton) + image issue happens due to race conditions when views are reused, because
The solution for this, as far as I can tell, is avoiding the magic implicit skeleton creation. Will think about it further, though. |
Evidence of speculation above: I've added some debug statements to
One can see clearly that
|
The 'automagic' skeleton addition caused two issues: - Misplaced icon in section switches (openhab#3773) This was caused by constraints in the widget's ConstraintLayout referencing the WidgetImageView's ID, which was no longer present after replacing it by the SkeletonLayout - Skeleton and image shown at the same time (mentioned in openhab#3786) This was caused by WidgetAdapter and SkeletonLayout both simultaneously modifying the visibility flag of the WidgetImageView, again caused by silent replacement of WidgetImageView by SkeletonLayout Fix both issues by changing the approach: Instead of silently replacing the view, make WidgetImageView inherit from SkeletonLayout and make it redirect external calls to an internal ImageView instance. Fixes openhab#3773, openhab#3786 Signed-off-by: Danny Baumann <dannybaumann@web.de>
The 'automagic' skeleton addition caused two issues: - Misplaced icon in section switches (#3773) This was caused by constraints in the widget's ConstraintLayout referencing the WidgetImageView's ID, which was no longer present after replacing it by the SkeletonLayout - Skeleton and image shown at the same time (mentioned in #3786) This was caused by WidgetAdapter and SkeletonLayout both simultaneously modifying the visibility flag of the WidgetImageView, again caused by silent replacement of WidgetImageView by SkeletonLayout Fix both issues by changing the approach: Instead of silently replacing the view, make WidgetImageView inherit from SkeletonLayout and make it redirect external calls to an internal ImageView instance. Fixes #3773, #3786 Signed-off-by: Danny Baumann <dannybaumann@web.de>
Fixed with #3787 |
Disclaimer: There are some open issues about icons but I am not sure weather any of these covers the following issue. If so please close this one.
Actual behaviour
Since a recent version of the android app the icons seem to be misplaced sometimes:
After scrolling in the window or reloading the icon seem to be placed where they belong.
Clearing the cache does not help.
In the following image I noticed that an icon got a background it should not have:
The original image has no white background.
On iOS the icons work as expected:
It does not matter whether the connection is local or via the cloud.
Expected behaviour
The icons should all be aligned the same way.
Steps to reproduce
See code below
Environment data
Client
Server
Logs
App log
Click to expand
---------------.txt
Code for first image:
Code for second image:
Code for third image:
The text was updated successfully, but these errors were encountered: