Giters

labwc / labwc

A Wayland window-stacking compositor

Home Page:https://labwc.github.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

PR #1702 after thoughts

johanmalm opened this issue · comments

commented

@tokyo4j

Ref:

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:

  1. 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. 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.
  2. The border.color and border.width only take effect when fill is set to no (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.

asdf

commented

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 struct server, required for wlr_renderer_is_pixman(), is never used in theme.c currently. But that's an implementation detail. (nvm)

commented

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.

No strong preference here either.

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.

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 :)

commented

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).

commented

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).

commented

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.)

commented

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.