Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: changes to theming? #254

Open
nyanpasu64 opened this issue Sep 30, 2021 · 1 comment
Open

Idea: changes to theming? #254

nyanpasu64 opened this issue Sep 30, 2021 · 1 comment
Labels
appearance Concerns visuals

Comments

@nyanpasu64
Copy link
Contributor

nyanpasu64 commented Sep 30, 2021

Not sure if you're currently focused on implementation or cosmetics. If you're open to changing the theming, I have some suggestions:

Moving away from the shaded theme

I don't like the shaded theme, and I didn't look at this UI framework for months, partly because the example screenshots didn't look good. From asking around, some but not all people are put off by the current visual theming. I personally believe that switching the examples and screenshots to the flat theme will cause more people to check out this UI framework. What do you think? (Perhaps the shaded theme could be altered to look better, but I didn't try improving it. The buttons are acceptable, but the radio boxes are especially bad and plasticky.)

Background colors

Is there a way to use different global background and button colors in the flat theme?

I'm actually not sure how to design a button color scheme and style options. I think real-world toolkits (Breeze, Android, WinUI, Windows 11 Win32, etc.) may use no-outline, outlined, or filled buttons, and background-colored, lighter or darker gray, and/or primary-color buttons.

Button shadows?

I don't know how shadows are rendered, but I feel the current appearance of button shadows in the flat theme is suboptimal (the shadow's center doesn't move to the bottom-right, so it seems like the shadow "surrounds" the top-right and bottom-left of the buttons, which looks ugly IMO). If I change DIMS.shadow_rel_offset to Vec2(1.0, 1.0) or Vec2(6.0, 6.0), then the shadow's center doesn't move, only the bounding box does. I think these issues have the same root cause where the button/checkbox shadow's center doesn't move, like the radio/slider circular shadows do. (Also increasing shadow_rel_offset past 1, 1 makes the top-left corner of menus disappear.)

(Also I dislike the button glow on dark themes, but that's more subjective.)

Screenshot of shadows with button borders disabled (which honestly looks better than I expected):

Screenshot_20210930_160152_Widget Gallery

Screenshot_20210930_155851_Widget Gallery

Reducing menu shadows?

I find the menu shadows slightly strange on the flat theme, and far too dark on the shaded theme.

@dhardy
Copy link
Collaborator

dhardy commented Oct 1, 2021

You certainly aren't the only one who doesn't appreciate the "shaded theme", no. If you want to make a PR against either of the existing themes, or adding a new one, please go ahead.

The existing drawing API is documented here but fairly limited. Shadows are achieved via draw.rounded_frame_2col(outer_box, inner_box, inner_col, outer_col) where outer_col.a == 0 (transparent) and the inner box might be smaller than the button border (this is why the circular shadow under the slider knob is much fainter). This is very hacky and reliant on the draw order.

Regarding shadows: see #238. Probably it would be worth adding proper drop-shadows eventually, though those are also imperfect (essentially just the mask layer and the shadow layer, thus not accounting properly for a vertical edge). The technique used depends on the effect desired: hard-edged directional shadows or a soft blur with an offset? Or maybe a combination of both? To achieve either of these some type of masking is required: either assigning each pixel a depth/height value or using the alpha channel.

Otherwise... the existing draw API is still very limited, and may well get extended in the future (e.g. using Lyon). It does have the advantage that custom effects using GPU shaders are possible, though each shader does need a new pipeline.

Reducing shadows

The simplest way of achieving this is likely to reduce the alpha value on the inner edge (currently always 1 I think).

If I change DIMS.shadow_rel_offset to ...

From dim.rs:

        let shadow_size = params.shadow_size * scale_factor;
        let shadow_offset = shadow_size * params.shadow_rel_offset;

            shadow_a: shadow_offset - shadow_size,
            shadow_b: shadow_offset + shadow_size,

And from flat_theme.rs:248:

            let (mut a, mut b) = (self.w.dims.shadow_a, self.w.dims.shadow_b);
            if state.hover() {
                a = a * SHADOW_HOVER;
                b = b * SHADOW_HOVER;
            }
            let shadow_outer = Quad::with_coords(a + inner.a, b + inner.b);
            let col1 = if self.cols.is_dark {
                col_frame
            } else {
                Rgba::BLACK
            };
            let mut col2 = col1;
            col2.a = 0.0;
            self.draw
                .rounded_frame_2col(shadow_outer, inner, col1, col2);

Indeed, those things only affect the outer edge.

Also worth noting: dim.rs is used for both themes, and the parameter names don't always quite match their use. It may be better eventually to implement sizing (SizeHandle) directly for each theme instead of the shared implementation.

@dhardy dhardy added the appearance Concerns visuals label Feb 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
appearance Concerns visuals
Projects
None yet
Development

No branches or pull requests

2 participants