[FEATURE] Noctalia as an optional shell/bar layer

Is your feature request related to a problem? Please describe.

ML4W currently uses Waybar and Quickshell as its status bar/shell layer.

I've been experimenting for several weeks with running Noctalia 5 as an isolated shell/bar layer on top of ML4W/Hyprland instead.

What I found interesting is that Noctalia does not need to replace or modify ML4W's core Hyprland configuration at all.

ML4W can continue to handle the workflow and underlying configuration, while Noctalia provides the visible shell.

The few overlaps I encountered were mainly cases where both sides tried to own the same function, rather than actual compatibility problems.

Describe the solution you'd like

Since ML4W already supports different Status Bar Engines, including Waybar and Quickshell, perhaps Noctalia could eventually be offered as another optional choice:

Status Bar Engine: Waybar | Quickshell | Noctalia

The idea would be to treat Noctalia as an isolated presentation/shell layer without replacing ML4W's core configuration.

In my current setup the division works like this:

ML4W handles:

• Hyprland configuration
• keybindings and workspaces
• monitor and input configuration
• hypridle / lock / DPMS / suspend
• SwayNC notifications
• Sidebar, Welcome, Settings and HyprMod

Noctalia handles:

• bar
• OSD
• media controls
• system monitoring
• weather and calendar
• launcher/panels
• wallpaper

For the cleanest coexistence I use:

• Noctalia Notification Daemon OFF → SwayNC handles notifications
• Noctalia Idle actions OFF → ML4W/hypridle handles idle, lock and suspend
• Noctalia Hyprland template OFF → ML4W remains in control of Hyprland
• No Noctalia hooks or glue scripts are required

Noctalia's Caffeine/idle inhibitor still works correctly with this arrangement.

The integration may therefore mainly require startup/lifecycle handling and sensible defaults to avoid overlapping ownership, rather than a separate Noctalia-specific ML4W configuration.

Describe alternatives you've considered

The alternative is the manual setup I'm currently using: let ML4W start normally, keep Waybar hidden and start Noctalia afterwards.

This already works very well, but an official option would make the setup reproducible and avoid users having to maintain their own autostart changes.

Whether Waybar should actually be stopped or simply hidden when Noctalia is selected could be an implementation detail. In my current setup it remains running but hidden without causing any noticeable problems.

Additional context

I've been using this setup as my normal daily environment for several weeks.

To make sure it wasn't accidentally relying on remnants from an earlier Niri/Noctalia installation, I also tested it in a completely clean VM:

Fresh CachyOS → ML4W → install only the noctalia package

Niri had never been installed in that environment, nor had any of the CachyOS Noctalia desktop profiles.

Noctalia connected directly to the existing ML4W/Hyprland session and worked without requiring any additional Noctalia/Niri environment.

In normal use I've tested it with dual monitors, workspaces/special workspaces, MPRIS, PipeWire/WirePlumber, NetworkManager, Bluetooth, OSD, notifications, logout/login and suspend/resume.

During the test period both Noctalia and Hyprland have received package updates, and so far the setup has survived those updates without requiring any changes to the integration.

So this isn't only a feature idea — the manual proof of concept is already working very well.

The basic idea could perhaps be summarized as:

ML4W keeps the workflow and configuration – Noctalia provides the visible shell.

Support or Contribution

• I am willing to contribute or support this feature