2 posts tagged with "technical"

In a recent series of changes between Scarlet 0.3.0 and 0.4.0, I have been rewriting the backend based on libastal. Previously, Scarlet's backend was purely based on libastal, which was used for networking, audio control, battery management, notifications and everything in between. This was great at the beginning; it helped get Scarlet 0.1.0 out the door. This can no longer stand.

Brief history​

Scarlet's backend was build from the libastal library, a useful library that provides scaffolding for wayland shell implementations. This library was originally design for Vala, but can also be used with python, lua and any language that supports gobject-introspection, one such language happened to be Rust.

Using the gir tool, I was able to generate Rust bindings for libastal in a single weekend. At the time, it was great. I could spend most of my effort improving the frontend and let libastal deal with the backend.

This was until a series of unexplained errors started occuring. A prevalent bug in Scarlet 0.3.0 is a bug that causes the application the segfault when receiving events for bluetooth or wifi. I tried debugging it, but to no avail. After tirelessly spinning in circles, attempting to debug the unexpected errors, I was encountering, I decided to make a change.

The rewrite​

Originally, this decision was purely made to fix the segfault issues, but it quickly became more useful than anticipated. Primarily because it made Scarlet more portable, I could ship Scarlet to any Linux distribution without depending on packages that are not available for that distribution.

This rewrite has occurred over the span of Scarlet 0.3.0 and 0.4.0, with 0.3.0 detaching Scarlet from astal4, using gtk4-layer-shell and libadwaita. The latter release removes most of the astal-dependent backend, preserving network and battery, which will be rewritten in the next release.

Implications​

For package management, this is a big win, Scarlet now has less dependencies, making it easier to package. There have been no observable changes in performance or resource usage, with those metrics generally remaining static. This has marginally increased the maintenance burden of Scarlet, but it is a burden I am happy to shoulder.

Closing thoughts​

This round of changes marks the beginning of Scarlet's growth phase, moving away from the small project it once was to a larger, polished project. Scarlet 1.0 is still a long ways away. With this change, along with Scarlet's upcoming changes in the 0.5.0 release, Scarlet will take big step forward.

At the time of writing, Scarlet is still in early alpha. As the time of writing, Scarlet version 0.1.0 is live, marking the first step towards version 1.0.

The version scheme is still up in the air, I am currently torn between using a date-based naming scheme used by Niri, in that case version 0.1.0 would be 25.12, based on the month and year when of release.

Scarlet 0.1.0 is called Red Salvia, after the flower bearing that name. Scarlet's major version names are based on flowers that bear the color, well, Scarlet.

Upcoming features​

Multi-monitor configuration​

One of Scarlet's planned features is support for multi-monitor configurations. Each monitor should have it's own bar configuration, separate from the others.

bar "HDMI-A-1" {
    // configuration for this monitor
}
bar "eDP-1" {
    // configuration for this monitor
}

popups "HDMI-A-1" {
    // popups on this monitor
}

popups "eDP-1" {
    // popups on this monitor
}

Configuration inheritance​

Multi-monitor configuration comes with the consequence that each monitor will need to be configured separately, as the bar window can not be present on multiple displays at once. To mitigate that, the plan is to implement inheritance, where individual configuration options are inheritable from other configurations, much like the nix inherit keyword.

The following configuration serves as an example of a setup using configuration inheritance. Where the bar on the monitor HDMI-A-1 has a horizontal layout, anchored to the top and the one on the monitor eDP-1 has a vertical layout, anchored to the left. They both use the same modules in the end, but have different orientations.

bar "HDMI-A-1" {
    anchors "top" "left" "right" // anchored to the top
    orientation "horizontal" // Horizontal orientation
    modules {
        start {
            niri-workspaces
        }
        center {
            clock
        }
        end {
            sys-tray
        }
    }
}

bar "eDP-1" {
    anchors "top" "left" "bottom" // Anchored to the left
    orientation "vertical" // Vertical orientation
    inherit "HDMI-A-1" {
        modules // Inherit the same modules from HDMI-A-1
    }
}

Expect this feature come between 0.2.0 and 0.7.0.

Popover windows​

One core feature of Scarlet, inherited from the legacy of Crimson 0.2.0 is modular popover windows. These provide windows, much like the notification center or quicksettings provided by other shells.

The popup windows provide modular layouts. Modules will be available for these larger layouts.

This feature is planned for 0.3.0.

Configuration​

Popover windows are part of the group module.

bar {
    modules {
        center {
            group {
                // grouped modules
                modules {
                    music
                    clock
                }
                popover {
                    // Standard QS layout with a calendar, music widget
                    // and notification center
                    orientation "horizontal"
                    modules {
                        calendar
                        // sub groups act as boxes
                        group {
                            orientation "vertical"
                            modules {
                                music-player
                                notification-center
                            }
                        }
                    }
                }
            }
        }
    }
}

More system info widgets​

Slated for the 0.2.0 are also extended system info widgets. As of 0.1.0, Scarlet provides CPU info, memory usage and network statistics. The plan is to add more system info modules, notably disk info and GPU info.

Disk info will arrive as part of 0.2.0. GPU info may take a bit more time, as I learn how to obtain GPU information for different GPU vendors. This feature is planned for 0.7.0 at latest.

Custom widgets​

Custom widgets are an important feature missing from 0.1.0. As of writing, how this feature is implemented is largely undecided.

In the implementation of Crimson 0.2.0, custom widgets are configured in Lua, which allowed custom formatting. JSON parsing and formatting functions are provided to make the use of advanced data structures possible.

Right now, the Scarlet formatter only supports basic JSON formatting, which is perfectly fine for simple modules, but unfeasible for advanced modules. I want to provide a way to configure modules with Scarlet, without having to resort to bash scripts. A simple way at that.

I have considered Lua modules, dynamic Rust plugins and simple JSON based command output modules. None are particular superior to the others, and we could support all three, but focusing on binary size and maintainability, it would be wiser to choose from the bunch and optimize the chosen option.

This feature does not have a set release date. It is planned for release before Red Salvia, but the exact version is up for debate. An open issue about this problem is available on the main repository, at issue #1. If you have input on how this feature could be implemented, feel free to reach out.

Closing thoughts​

These are just the bigger features planned for Scarlet. Other smaller features are being implemented as time passes. Scarlet Red Salvia is set to be the most interesting release so far and I am glad to get it there.