Add a BoxShadow component. #205
Conversation
| @@ -142,6 +144,12 @@ buildUI wenv model = widgetTree where | |||
| filler | |||
| ] `styleBasic` [bgColor (grayDark & L.a .~ 0.5)] | |||
|
|
|||
| confirmDeleteLayer = case model ^.action of | |||
There was a problem hiding this comment.
The todo example now includes a confirm popup when deleting a todo, because the confirm alert was not previously in the examples anywhere (and I wanted to test because I added the shadow to it).
| @@ -52,6 +53,7 @@ instance Default Theme where | |||
| -- | Default theme settings for each widget. | |||
| data ThemeState = ThemeState { | |||
| _thsEmptyOverlayStyle :: StyleState, | |||
| _thsShadowColor :: Color, | |||
There was a problem hiding this comment.
To allow changing the shadow color via the theme.
| @@ -237,6 +237,10 @@ newRenderer c rdpr envRef = Renderer {..} where | |||
| gradient <- makeRadialGradient c dpr p1 rad1 rad2 color1 color2 | |||
| VG.strokePaint c gradient | |||
|
|
|||
| setStrokeBoxGradient rect rad feather color1 color2 = do | |||
There was a problem hiding this comment.
I added this for completeness, but it is not used inside Monomer, so could be removed.
There was a problem hiding this comment.
I think it's good to have it.
| @@ -65,6 +65,7 @@ data BaseThemeColors = BaseThemeColors { | |||
| dialogText :: Color, | |||
| dialogTitleText :: Color, | |||
| emptyOverlay :: Color, | |||
| shadow :: Color, | |||
There was a problem hiding this comment.
Should this type have some prefix on its fields, since they're all exported and may cause conflicts? It's something I've had in my mind for a while, but I've always postponed it.
Something like baseTheme...:
...
baseThemeEmptyOverlay :: Color,
baseThemeShadow :: Color
...What do you think?
There was a problem hiding this comment.
A prefix (and then some lenses) seems like it would be consistent with other record types I have seen in the Monomer codebase.
But no strong (or particularly educated) opinions here either way to be honest!
There was a problem hiding this comment.
Sounds good! I'll add prefix/lenses in a follow-up PR. Thanks for the recommendation!
|
@Dretch the PR looks great! My only question is if there's any configuration attribute to select the orientation of the shadow (based on the attached images). Thanks! |
I suppose this might be useful. Perhaps the shadow location could be specified with a pair of fields like Then, should these fields be config options on E.g. data ThemeState = ThemeState {
_thsEmptyOverlayStyle :: StyleState,
_thsShadowColor :: Color,
_thsShadowAlignV :: AlignV,
_thsShadowAlignH :: AlignH,
_thsBtnStyle :: StyleState,
... |
|
@Dretch I usually avoid exposing boxShadow_ [alignRight, alignBottom] $
...For the internal representation it makes sense to use I think having a default in the theme and the ability to customize it in the widget itself would be ideal. |
|
Hi @fjvallarino , I have pushed a commit to allow configuring the shadow location via theme or config, hopefully in the way you were thinking. |
|
@Dretch looks great! Thanks! |
|
Thanks @fjvallarino , Would it be possible for you to do a new release of Monomer? I'd like this mainly because I want to release https://github.com/Dretch/monomer-hagrid to Hackage and (because I used the new dot-record-syntax stuff) it needs GHC 9.2.x, which means it needs e7ea45f |
|
Thanks @fjvallarino 🚢 |
|
@Dretch have you released Hagrid? Would it be ok if I mention it in Monomer's Readme? Thanks! |
|
@fjvallarino I have released it to Hackage, yes (though not Stackage, until I get around to that). Feel free to mention it in the readme 👍 |
As proposed in issue #203.
Options for light location (i.e. shadow position)
I don't really have an opinion on this, but here are some options:
Light in the center (original proposal)
Light in the top center (MacOS-ish)
Light in the top-left (Android Material design ish)