PR #1702 after thoughts
johanmalm opened this issue · comments
Ref:
- 5b1af2f
- #1702
- #1702 (comment)
- https://labwc.github.io/labwc-theme.5.html#entry_snapping.preview.edge.bg.color
Whilst reviewing recent commits I got to overlay: add theme settings for colors and border width
and tried to configure the border in accordance with the commit message.
snapping.overlay.[region|edge].bg.color: #8080b380
snapping.overlay.[region|edge].border.color: #ffffff,#000000,#ffffff
snapping.overlay.[region|edge].border.width: 1
I note two things:
- The man page and parser use
preview
instead ofoverlay
. We could simply just accept that we made a mistake in the commit message (no big deal) and when I updateNEWS.md
I usepreview
instead. BUT, in hindsight I wonder ifoverlay
is actually a better word because we usepreview
in other places (e.g.rc.xml
) to mean that the window content is shown. Welcome thoughts on that. - The
border.color
andborder.width
only take effect whenfill
is set tono
(it took me a while to work out why I couldn't get the border to show 😄). I'm okay with this as an approach but we ought to describe it in the man page. As an after-thought consideration, would we want to ever support showing both fill AND border at the same time? If so that could easily be achieved by making show-border independent of the fill-boolean, and just set the default border.width to 0 or something like that.
It'd be good to conclude this before the next release to avoid regression.
The man page and parser use preview instead of overlay. We could simply just accept that we made a mistake in the commit message (no big deal) and when I update NEWS.md I use preview instead.
Sorry for the mistake and confusion in my commit message. As I respect the maintainability of this project, this is soooo regrettable.
BUT, in hindsight I wonder if overlay is actually a better word because we use preview in other places (e.g. rc.xml) to mean that the window content is shown. Welcome thoughts on that.
It seems the choice of preview
comes from what @Consolatis suggested as <snapping><preview>
in rc.xml
: #1652 (comment). I didn't have any strong preference on preview
/overlay
then so I used preview
both in rc.xml
and themerc
.
But I understand your concern and now I think changing preview
to overlay
is a better idea. In that case, I think we should change in both themerc
and rc.xml
to avoid confusion.
As an after-thought consideration, would we want to ever support showing both fill AND border at the same time? If so that could easily be achieved by making show-border independent of the fill-boolean, and just set the default border.width to 0 or something like that.
Yeah, I think that's a better idea.
I guess, when WLR_RENDERER=pixman
, we should change the default border width to 1 then to prevent the overlay from becoming completely hidden.
A small problem with it is that (nvm)struct server
, required for wlr_renderer_is_pixman()
, is never used in theme.c
currently. But that's an implementation detail.
It seems the choice of
preview
comes from what @Consolatis suggested as<snapping><preview>
inrc.xml
: #1652 (comment). I didn't have any strong preference onpreview
/overlay
then so I usedpreview
both inrc.xml
andthemerc
.
No strong preference here either.
But I understand your concern and now I think changing
preview
tooverlay
is a better idea. In that case, I think we should change in boththemerc
andrc.xml
to avoid confusion.
Fine by me, as it was not part of a release I also don't think that we need to support both.
This being a breaking change should be mentioned in the commit message however.
As an after-thought consideration, would we want to ever support showing both fill AND border at the same time? If so that could easily be achieved by making show-border independent of the fill-boolean, and just set the default border.width to 0 or something like that.
Yeah, I think that's a better idea.
Sounds good to me.
Also: welcome to the team @tokyo4j :)
Then do you think we can remove snapping.overlay.[region/edge].fill
?
Presence of this setting made sense because this worked as a switch to decide which of outlines or a filled rectangle to draw. We can now omit this if we draw them separately. If the user don't want the filled rectangle for edge-snapping overlay, he can just set like snapping.overlay.edge.bg.color: #00000000
(zero alpha).
If the user don't want the filled rectangle for edge-snapping overlay, he can just set like
snapping.preview.edge.bg.color: #00000000
(zero alpha).
Using a transparent color to indicate that something isn't wanted doesn't feel right to me. It also causes more work for the rendering (although I think the wlroots scene implementation does have an opacity check so its likely negligible).
Using a transparent color to indicate that something isn't wanted doesn't feel right to me.
Yeah, it looks more like a workaround and having a dedicated setting looks cleaner.
If we decide to leave it present, I think we should also support something like snapping.overlay.[region/edge].stroke
to show/hide borders. (EDIT: I'm not sure about this. Setting it to 0 to hide it looks clean enough to me.)
Sorry for the mistake and confusion in my commit message. As I respect the maintainability of this project, this is soooo regrettable.
Hey, 100% no problem and this is very minor 😄 and we all nodded, smiled and merged. We are very impressed by your methodical and thorough approach. If you were to look through the commit logs, you'll see me/others having written and committed things which have been much more regrettable (but easily fixed).
I find that doing regular releases is a good discipline which encourages us to take a holistic view of patches over a period to make sure we've updated documentation and that things generally seem consistent.
Looks like #1737 is shaping up well. I feel a bit guilty now - didn't realize the patch would be quite so big. Hope that's okay.