Hi there,
I noticed a possible bug at the image widget:
I have a table with text and picture shown in my app. When selecting a record the text is shown and the stored picture should, but it’s always black.
Only if I load a picture into the image widget (or capture one) and store it in the record I can still load and display it in the widget.
I had the same issue… However, If the Image is captured in the widget some time ago, it will seems to also not display it.
It usualy works, if you register the image link with the API.
Hi @thorsten.langner
what do you mean with registering the image link with the API?
@Beth what’s the reason for this? It must be a new issue to the image widget, because I use this for a long time.
But so it brokes our picture management in our apps
I make that distinction just for clarity - The team looked at this and doesn’t believe this is a bug, but rather that that behavior has always existed where the image input widget will not display a preview unless it is an image that was captured with that widget, and image widget will display a preview regardless
Does this make sense or am I not fully understanding?
If you want, we could file this as a product suggestion that the image input widget display a preview always.
Not sure if it helps, but if you want to both visualize the photo from the Tulip table, and be able to set/update it, you can put the Image Widget in front of the Input Image Widget. I have used this work around myself, see below:
Hi @Beth
I’m not a developer, only an user and app builder.
but for me it’s definitively a bug, because the behavior can’t be so random to show a preview and then not. Your developers need to explain under which circumstances/environments the captured images will be displayed and when not.
If you say: the input image widget never should display a picture, then it’s a product suggestion - but a design bug.
But if the behavior is not the same for all circumstances - then it’s a bug - if they believe or not.
@seb.lorandel
when you need a workaround you know there’s something wrong.
But as long as the embed image widget can not handle the image aspect ratio, it can then really only be an emergency solution.
The registered link is then possible to display in the image input widget.
(registration allows to share the image link also to external usage and is valid for 3h)
@seb.lorandel I also started with this idea, but I was not happy with it.
I don’t like using unnecessary additional widgets
It feels to much as a workaround
the behavior in terms of aspect ratio is different in both widgets (the show image widget distorts the image, if its not the same aspect ratio as the image itself; the input widget doesn’t)
All widgets are placed with a 1:1 aspect ratio (square). Left: Variable widget (keeps aspect ratio, but may not cover the background completely) Middle: Image display widget (squeezes image into the aspect ratio of the widget) Right: Input widget (keeps aspect ratio, fills the background black, centers the image)
addition: The Iframe (Website widget) is a possible 4th option. The aspect ratio is retained, but the image size cannot be adjusted (the widget gets scroll bars).
I appreciate your input here and understand what you are saying - workarounds indicate a deeper issue that could be resolved natively in the product design!
That being said, I will turn this into a product request for you because I think it can be improved as you have pointed out.
In regards to image aspect ratio, I am checking with the team on that also
