Add caret to indicate thumbnails that open in the image viewer#932
Conversation
|
From your screenshot it also marked the external link with the caret. While on Boost it doesn't do that. Is that intended change in behavior? |
The top link hasn't properly generated a thumbnail (that happens sometimes), but it's still an imgur link and correctly opens with the in-app viewer! The bottom link doesn't have a caret, because it redirects to the browser (verge article). It would be good to additionally change that "link" icon to a "broken image" icon like Boost does. |
MV-GH
left a comment
There was a problem hiding this comment.
Looks good and works fine. Regarding the colors, ill let the others decide if it should be part of the themes. If so you would have to do something like this https://gustav-karlsson.medium.com/extending-the-jetpack-compose-material-theme-with-more-colors-e1b849390d50
| val imageHighlight: Color | ||
| get() = Color(0xCCD1D1D1) | ||
| val videoHighlight: Color | ||
| get() = Color(0xCCC20000) |
There was a problem hiding this comment.
Yep, definitely use jetpack compose theme colors. Maybe primary and tertiary.
There was a problem hiding this comment.
I'm not so sure about using existing Material color entries, for a few reasons:
- The colors need to be immediately distinctive between each other.
- The colors need to be chosen specifically to show up properly over most thumbnails, and material theming doesn't intentionally provide that.
- Boost has white, green, blue, and red. If we want to work up to that behavior we'll run out of slots.
If we want to integrate these into theme colors, we should find a way to extend Material colors IMO. Thoughts?
There was a problem hiding this comment.
Yes i agree, and i posted a link how to extend Material colors
There was a problem hiding this comment.
Added custom color capability with the theming system according to that article; let me know what you think. The biggest diversion I made was storing a reference to the default material theme rather than mirroring each and every single property; I think it's more future-proof this way, because if Material gets an update with more/less properties we won't have to change that mirroring solution. (Plus there are just a lot).
Other than that it should be pretty straightforward.
|
Just getting back to this now, apologies for the delay. I pushed a proper color scheme implementation; let me know if this solution works! |
MV-GH
left a comment
There was a problem hiding this comment.
I tested this and it works well. Thanks !
| // Dynamic schemes crash on lower than android 12 | ||
| val dynamicPair = if (android12OrLater) { | ||
| Pair(dynamicLightColorScheme(ctx), dynamicDarkColorScheme(ctx)) | ||
| val jerboaImageHighlight = Color(0xCCD1D1D1) |
There was a problem hiding this comment.
This is wild that add custom colors requires this much code bloat. Is it really that necessary? Now all theme designers have to hack on these colors too, rather than just using the defaults.
The tradeoff of this massive code bloat is not worth it IMO. If our three options are:
- Use the existing colors: primary, tertiary, etc, but made semi-transparent for these carets.
- Less optimal - hard code the colors
- Add these custom colors into every theme, and extend jetpack-compose theming like you've done here.
Please use option 1 or 2, this extra complication is not worth it at all.
There was a problem hiding this comment.
Option 1 definitely won't work; we need new colors here (see #932 (comment) for my reasoning why).
A note on the implementation: Designers will still be able to use the default colors through MaterialTheme.colorScheme; it's just the new MaterialTheme.jerboaColorScheme that provides custom colors like these. I don't believe this issue will be unique; there may very well be other times we need colors that aren't present in Material Design 3. We can definitely hardcode each new color, but they will never be compatible with the theming system that users can select, if we do that.
I do agree that it's kind of bloaty, though. I'm fine with reverting to option 2 if it comes down to that.
Thoughts from @MV-GH since they requested the color theming?
There was a problem hiding this comment.
I was fine with the hard coding tbh. But since we already have this implemented with the theme might as well keep it. @twizmwazin wanna be the tie braker?
There was a problem hiding this comment.
In that case my vote is for hard-coding the colors, option 2.
There was a problem hiding this comment.
I am fine with the custom colors here, and its already implemented. I think in the future we will probably want to allow more customization of colors anyways (or at least I want to eventually), allowing customization of most colors throughout the app, like Boost. I don't think the code bloat is really that big of a deal, and we could easily reduce the amount of code used per theme. As an example we could write a function that takes every color parameter as optional, along with a base theme, allowing a new custom theme to only specify exactly what it wants to change relative to a base theme.
This feature is inspired by Boost, which has differently-covered carets for different types of media. There, images have white triangles, gifs blue, and videos red. This allows the user to easily predict what tapping the thumbnail will do, and make an informed decision on whether they want to follow a link or just open the image viewer.
The advantages of this feature include:
This feature is only applicable in Small Card and List views.
Screenshot:
Note the lack of border-radius on the bottom-right corner, when the triangle is enabled.
Note to reviewers: I awkwardly stuck the color in
Color.kt; I'm not sure how to integrate it with the current theming system. If there's a better way please let me know!