Skip to content

Conversation

@AKArien
Copy link
Contributor

@AKArien AKArien commented Jan 22, 2026

By default, icons of widgets will now follow the size of the panel.
Adds a css config for a default size for icons, which is overriden by the configuration entry for each icon if it is not 0. Meanwhile, the default becomes 0.
Adjusted the panel’s default height to keep icon sizes the same as the default configuration (32), and left the menu and launchers at 42. Personally, i would think that setting them all to 0 and setting the panel’s default minimal height to 42 would be preferable, it would also lead to other widgets being slightly bigger by default.

The icon size of launchers was getting applied to the menu widget as well, probably because it didn’t have a config option of it’s own. Added one.
This also fixes command-output’s size not actually being accounted for.

Example/default ini file has not yet been changed for any of this.

Also, potential breaking change we could for the sake for name consistency, if we value this more than not breaking things (probably not very wise but it annoys me personally) : rename laucher’s icon size launchers_size to launchers_icon_size.

Addresses #269

@trigg
Copy link
Collaborator

trigg commented Jan 23, 2026

I had previously considered using 0 or -1 as 'use panel size' but left it for another time as I wasn't sure how best to pass this changed information to existing users.

Overall a good implementation, but doubling up on the config reload logic should be avoided

@AKArien
Copy link
Contributor Author

AKArien commented Jan 23, 2026

What do you call « doubling up on the config reload logic » ? The reload_css function ? if so, i’d agree it seems pretty dumb, with the alternative being to make the widgets read the value themselves to choose what css class to apply, no ?

@trigg
Copy link
Collaborator

trigg commented Jan 23, 2026

ideally we should remove the reload_css function again and implement one extra CssFromConfig class

CssFromConfigIconSize::CssFromConfigIconSize(std::string option_name, std::string css_before, std::string css_after) :
    option_value{option_name}
{
    provider = Gtk::CssProvider::create();
    option_value.set_callback([=]
    {
        if (option_value == 0)
        {
            provider->load_from_string("");
            return;
        }
        std::stringstream ss;
        ss << css_before << option_value << css_after;
        provider->load_from_string(ss.str());
    });
    if (option_value == 0)
    {
        provider->load_from_string("");
        return;
    } else
    {
        std::stringstream ss;
        ss << css_before << option_value << css_after;
        provider->load_from_string(ss.str());
    }

    add_provider();
}

The rules for specific icons would need to be given a higher css priority (achieved by making it slightly more specific)
new CssFromConfigIconSize("panel/battery_icon_size", ".wf-panel .battery .widget-icon{-gtk-icon-size:", "px;}");

and the fallback could be relatively less specific
new CssFromConfigInt("panel/minimal_height", ".wf-panel .widget-icon {-gtk-icon-size:", "px;}");

This is paper napkin code, I've probably typoed a bit here.

@trigg
Copy link
Collaborator

trigg commented Jan 23, 2026

Also, not for this PR, and mostly as a reminder to myself... I think I should rethink the doubled-up code in the CssFromConfig classes as each one has a copy-pasted section

@AKArien
Copy link
Contributor Author

AKArien commented Jan 23, 2026

The rules for specific icons would need to be given a higher css priority (achieved by making it slightly more specific) new CssFromConfigIconSize("panel/battery_icon_size", ".wf-panel .battery .widget-icon{-gtk-icon-size:", "px;}");

and the fallback could be relatively less specific new CssFromConfigInt("panel/minimal_height", ".wf-panel .widget-icon {-gtk-icon-size:", "px;}");

Wouldn’t we still need essentially the same thing as the css_reload function though ? It is there to handle the case when, while the panel is changed, the user changes the configuration of one (or more)’s widget size from a non 0 value (so, one where there would be a css rule created for it) to a 0 (one without a custom rule). Am i missing something that allows what you are saying to handle this case ?

@trigg
Copy link
Collaborator

trigg commented Jan 24, 2026

That case is handled in my example by the if in our new CssFromConfig class. The rule enforcing a single widget resize gets set to an empty string, so CSS would revert its size to the default size we left in place with a lower priority

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants