Skip to content

Refactor and Unify Volume Widgets into a Single MVA-Architected Widget - #496

Open
BeniaminK wants to merge 4 commits into
streetturtle:masterfrom
BeniaminK:volume_widget_generatlization
Open

Refactor and Unify Volume Widgets into a Single MVA-Architected Widget#496
BeniaminK wants to merge 4 commits into
streetturtle:masterfrom
BeniaminK:volume_widget_generatlization

Conversation

@BeniaminK

Copy link
Copy Markdown

This PR performs a major architectural refactoring and consolidation by unifying three separate, highly duplicate volume widgets ( volume-widget , pactl-widget , and wpctl-widget ) into a single, clean Model-View-Adapter (MVA) based volume-widget .
──────

🚀 Overview

Prior to these changes, the repository maintained three distinct volume-related widgets that shared substantial UI rendering and popup logic, differing primarily in how they interacted with their respective audio command backends (amixer , pactl , and wpctl ).

This PR consolidates them into a single volume-widget directory. By introducing an MVA / Adapter design pattern, we decouple UI presentation from underlying system commands, making the codebase drastically simpler to maintain, extend, and debug.
──────

🏗️ Architecture Design (Model-View-Adapter)

The new structure separates responsibilities cleanly:

    graph TD
        subgraph UI / View Layer
            V[volume.lua] --> W1[icon-widget.lua]
            V --> W2[icon-and-text-widget.lua]
            V --> W3[arc/bar-widgets...]
        end

        subgraph Orchestration Layer
            C[controller.lua] <--> V
        end

        subgraph Backend / Model Layer
            C <--> P[providers/ factory]
            P --> PA[providers/pactl.lua]
            P --> AM[providers/amixer.lua]
            P --> WP[providers/wpctl.lua]
        end
Loading
  1. View ( volume.lua & widgets/ ): Manages the Awesome WM visual elements, popups, and user-initiated mouse bindings. It delegates actions to the controller.
  2. Controller ( controller.lua ): Orchestrates the communication between the UI view and the underlying provider models. It acts as an event handler and updates the view when the model signals state changes.
  3. Providers ( providers/ ): Concrete adapter classes that encapsulate CLI command execution and stdout parsing for:
    3.1 pactl (PulseAudio / PipeWire Pulse)
    3.2 amixer (ALSA)
    3.3 wpctl (WirePlumber / PipeWire native)

@BeniaminK
BeniaminK requested a review from streetturtle as a code owner May 26, 2026 00:07
@Ryuno-Ki

Copy link
Copy Markdown
Collaborator

Out of curiousity: Has been „AI” used in writing this code / PR? If so, how much?

@BeniaminK

Copy link
Copy Markdown
Author

@Ryuno-Ki Yes, AI was used during this refactoring.

The core architectural vision—specifically the decision to transition to a Model-View-Adapter (MVA) pattern to decouple the UI from the underlying audio backends—was entirely manual. I used Gemini CLI (then Antigravity CLI) assistance to accelerate the boilerplate work: implementing the provider adapter classes, consolidating the highly duplicated Lua logic from the three existing, mostly duplicating widgets into the new unified structure, and drafting the PR description.

All backend logic mapping, regression testing against the various audio interfaces (pactl, wpctl, amixer), and final design validations were strictly human-driven to ensure stability and seamless integration.

@Ryuno-Ki

Copy link
Copy Markdown
Collaborator

So extra scrutinity will be required by @streetturtle.

FWIW: I'm strictly against generative „AI”. If I were to review it, that alone would be reason for me to close this PR.
Other collaborators might see this differently (worth a discussion perhaps - outside of this PR).

@BeniaminK

Copy link
Copy Markdown
Author

Extra scrutiny is always welcome, especially for a refactor of this size. I removed a lot of duplicate code (merging three essentially copy-pasted volume widgets into one clean, easily extensible solution).

Regarding the comment about closing the PR because AI was used: I understand you have a strict personal stance on this. However, I ask that this be reviewed on its technical merits. If there is any specific part of the solution that seems clunky or unclear, please point it out—I am more than happy to explain every part of the logic.

@Ryuno-Ki

Copy link
Copy Markdown
Collaborator

However, I ask that this be reviewed on its technical merits.

Understandably.

If there is any specific part of the solution that seems clunky or unclear, please point it out—I am more than happy to explain every part of the logic.

I'm more familiar with the weather-related widget.

There's not a CODEOWNER for volume ones yet:

* @streetturtle
/weather-api-widget/ @Ryuno-Ki
/battery-widget/ @utix
/calendar-widget/ @utix
/weather-widget/ @utix

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