Skip to content

Allow for more style configuration - #925

Open
sulabi wants to merge 13 commits into
MalpenZibo:mainfrom
sulabi:style-config
Open

Allow for more style configuration#925
sulabi wants to merge 13 commits into
MalpenZibo:mainfrom
sulabi:style-config

Conversation

@sulabi

@sulabi sulabi commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

This PR allows for more in depth configuration of the bar.

Before you could only set the bar to either a BarSurface::Solid or BarSurface::Transparent, now you would be able to set the config and other bar fields individually within the config. Although BarSurface has been removed for this approach, I still allow for it to be within configs just for backwards compatibility for older configs though is labelled as deprecated.

BarAppearance is now defined as shown below and is configured through appearance.bar.

pub struct BarAppearance {
    pub opacity: OpacityAppearance,
    pub module_border: BorderAppearance,
    pub border: BorderAppearance,
    pub margin: BarMargin,

    pub inset: f32,

    /// Deprecated - set bar appearance directly instead.
    pub surface: Option<BarSurface>,
}

The previous appearance.opacity field has been removed in favor of a struct appearance.bar.opacity. Opacity is split into three values.

  • Button Opacity
  • Background Opacity (of the bar)
  • Module Opacity

Here are the defaults for the opacity field, making the appearance of the bar transparent by default.
Defaults are:

impl Default for OpacityAppearance {
    fn default() -> Self {
        Self {
            button: default_opacity(),
            background: 0.,
            module: default_opacity(),
        }
    }
}

It's now possible to configure appearance of individual modules through the newly added appearance.modules field:

pub modules: HashMap<ModuleName, ModuleAppearance>

ModuleName also now accepts a snake_case variant of the module name with deserializing, so that modules can be configured like system_info rather than SystemInfo.

Each module can configure the following appearance properties and there could easily be more to come:

pub struct ModuleAppearance {
    pub spacing: SpaceSize,
    pub grouping: ModuleGroup,
    pub padding: SpaceSize,
    pub border: Option<BorderAppearance>,
    pub background: Option<BackgroundAppearanceColor>,
    pub opacity: Option<f32>,
    pub text_color: Option<AppearanceColor>,
}

The new ModuleGroup enum is to change how a module and its members are grouped visually

pub enum ModuleGroup {
    #[default]
    Combined, // modules and members
    Individual, // only members (have its own container)
    None,       // no containers
}

Combined is default and has the same visual pre change.

Individual is when you want the members of a module to have their own background or border instead of the singular parent shared for all members.

For example:

[appearance.modules]
system_info = {
	grouping = "individual",
	border = {
		radius = "md"
	}
}

Which display as:
image

In order to allow modules for its members to be individually displayed the return for the view function declared in each of the modules had to be changed from iced::Element into the newly added ModuleView.

ModuleView allows multiple elements to not be converted into an iced::Element until after styling is applied to each member. Before this would not be possible because once the conversion of a Row be made into an Element children of that row could not be modified.

If there is anything you would like me to do please let me know as this is my first time doing such a large pull request, also docs are incomplete for now until everything else is ready.

@sulabi
sulabi marked this pull request as ready for review August 19, 2026 01:51
@MalpenZibo

Copy link
Copy Markdown
Owner

This is interesting, but we should discuss this before merging. We need to make a new release soon, so this cannot be included in the next release; the next release will include the new style configuration settings.

Also, the module configuration should live in its dedicated PR to simplify the review process. Let's try to split the changes into dedicated PRs

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