Update colors based on latest libadwaita

[grulja]

Hi @TheBoctor and @LSeelig,

You have been both testing my changes recently so can you also test this one? It updates the colors trying to match recent libadwaita style. Thank you.

[TheBoctor]

Here is what the header bar now looks like, with active/inactive colors, in dark and light styles.

For comparison, here are the previous colors (as in spacing branch.) The light theme was noticeably different on an active window:

[grulja]

@TheBoctor I know how it looks like as I tested it. I just wanted a double-check from someone to verify the new colors match GTK4/Libadwaita apps.

[TheBoctor]

My bad, I've checked the RGB values of the colors across multiple screenshots. The buttons, background, icons and everything in the light theme exactly match Libadwaita colors. However, the dark theme's headerbars are now slightly darker than other apps, closer to the darkest elements like Nautilus's background. (RGB 30,30,30)

Previously, the active background was RGB 48,48,48 and the inactive was RGB 36,36,36, which exactly matched the standard Libadwaita dark headerbars.

[grulja]

@TheBoctor how about now? I previously did a screenshot of Nautilus and picked the colors from there. Now I used the libadwaita demo app. Thank you for testing.

[TheBoctor]

There are still some minor differences for the dark palette, as well as some subtle button hover color differences, in QAdwaitaDecorations::updateColors. For example, the active and inactive colors of the dark headerbar backgrounds are currently identical, where the active one should be lighter.

This snippet should fix it and make the colors as close as possible, if not identical. The only colors/rendering I'm not 100% sure about are the semi-transparent window borders, as I'm unfamiliar with the low-level differences in how Qt and GTK handle blending, anti-aliasing, etc.

void QAdwaitaDecorations::updateColors(bool useDarkColors)
{
    qCDebug(QAdwaitaDecorationsLog)
            << "Changing color scheme to " << (useDarkColors ? "dark" : "light");

    m_colors = { { Background, useDarkColors ? QColor(0x303030) : QColor(0xfafafa) },
                 { BackgroundInactive, useDarkColors ? QColor(0x242424) : QColor(0xfafafa) },
                 { Foreground, useDarkColors ? QColor(0xffffff) : QColor(0x2e2e2e) },
                 { ForegroundInactive, useDarkColors ? QColor(0x919191) : QColor(0x949494) },
                 { Border, useDarkColors ? QColor(0x3b3b3b) : QColor(0xdbdbdb) },
                 { BorderInactive, useDarkColors ? QColor(0x303030) : QColor(0xdbdbdb) },
                 { ButtonBackground, useDarkColors ? QColor(0x454545) : QColor(0xe6e6e6) },
                 { ButtonBackgroundInactive, useDarkColors ? QColor(0x2f2f2f) : QColor(0xf4f4f4) },
                 { HoveredButtonBackground, useDarkColors ? QColor(0x4f4f4f) : QColor(0xe0e0e0) } };
    forceRepaint();
}

Some of these constants are defined in this SCSS source file, if I'm not mistaken, and I'm carefully double-checking each color with an RGB picker. Hopefully, an elegant way to solve #12 shows up in the future, so that possible Libadwaita color changes do not require manual updates.

[grulja]

Hmm, I will double- check tomorrow. I made a screenshot of the libadwaita demo running on Fedora 40, where we have upcoming libadwaita 1.5. and I was picking colors with a picker as well.

[grulja]

I checked it again as I cannot let it go and I think what I have now is correct?

These are screenshots of libadwaita demo in version 1.5rc from Fedora 40.

[TheBoctor]

The colors in those screenshots are definitely consistent with the ones you already had. It looks like I only tested against Libadwaita apps with the traditional/separate header behavior: Window activation makes the background color different. If you try installing and running gnome-console and raising/lowering the window, the color values should be identical to those from my last comment. The "Overlay Split View" demo in the Libadwaita demo matches, as well.

However, some other Libadwaita apps (including core ones like Settings, Nautilus, Loupe, and the Libadwaita demo main window) do not tint their headers an active/inactive color. They share the main background, for a seamless look. If you run the Libadwaita demo again and raise/lower the window, the sidebar should change color instead, the same way a separate header bar might change on a different app.

I guess my only question, then, is which behavior you'd prefer to use for Qt apps. Honoring the Qt client's colors but sticking Libadwaita-styled decorations on it, using the traditional active/inactive tint behavior as with the visually separate headerbars, or using a single background color and only fading the buttons/title to indicate inactivity.

[grulja]

I think we should make it look like gnome-terminal or the overlay split view you have on your screenshot on the left side. I didn't realize apps might be using same colors for header bar and background. I updated it now based on the overlay split view in from the adwaita demo. I hope it is correct now. Thank you.

[TheBoctor]

Excellent, all colors now match the Libadwaita standalone header bar colors.

There is one more color that I forgot to mention, which is only visible while a button is pressed and held down. (This may be out of scope for this PR, since it would require adding new behavior.) For the light colors, the "pressed button" color is c2c2c2, and for dark mode it is 6e6e6e.

[grulja]

Excellent, all colors now match the Libadwaita standalone header bar colors.

There is one more color that I forgot to mention, which is only visible while a button is pressed and held down. (This may be out of scope for this PR, since it would require adding new behavior.) For the light colors, the "pressed button" color is c2c2c2, and for dark mode it is 6e6e6e.

This would require a bigger change as we don't currently track the "pressed" state. Can you open a bug for that?