Code Readability

[Neppity3303]

The code is admittedly very difficult to read and poorly structured. Improved readability will probably help MintpaperEngine improve already existing features as well as make it easier to implement new features.

[Cidolfas]

I'm currently refactoring some things in a local branch to make it easier to add new modes (because I wanted a slideshow mode and while hacking it in was easy it also felt like I could do it better).

Specifically, my thinking was that each MintpaperEngine would hold a MintpaperPlugin instance which encapsulates all the logic for what that mode does so that the logic (and settings) for the Webview, Video, and the new Slideshow modes are all split up. The MintpaperEngine still controls setting up the base GTK window and all the handlers for passing events through to the Plugin

[Neppity3303]

This is an interesting approach. I agree that the current structure is getting a bit crowded as we add more modes, and moving toward a Plugin/Strategy pattern seems like the right way to keep the codebase maintainable.

Before you go too deep into the refactor, I’d love to see a quick technical breakdown or a draft PR of how you’re handling a few specific areas:

• Event Propagation: How are you planning to pass the global mouse/keyboard events from the MintpaperEngine down to the MintpaperPlugin? (Specifically for interactive HTML wallpapers).
  

• Performance Mode: I recently implemented a 'Coma Script' for the WebView to kill the JS event loop when the window is covered. Would each plugin be responsible for its own set_paused logic?
  

• Config Mapping: How would the config.json determine which plugin to initialize for a specific monitor? Are you thinking of a mode key in the monitor settings?
  

• State Persistence: If we hot-reload the engine, how does the plugin maintain its current state (like the current index of a slideshow)?
  

I'm definitely open to this refactor if it makes adding things like your Slideshow mode cleaner. Looking forward to seeing what you've got in your local branch!

[Cidolfas]

* ```
  Event Propagation: How are you planning to pass the global mouse/keyboard events from the MintpaperEngine down to the MintpaperPlugin? (Specifically for interactive HTML wallpapers).
  ```

Currently, the WallpaperyApp instance still handles setting all the hooks. It just loops through the Engines and passes the input values down to a handler, and the Engine passes them down into input handling functions in the Plugin (if the base window is realized). The Webview plugin then handles passing those events down into javascript.

* ```
  Performance Mode: I recently implemented a 'Coma Script' for the WebView to kill the JS event loop when the window is covered. Would each plugin be responsible for its own set_paused logic?
  ```

Yeah, that's my thought for it. Like inputs, we propogate the set_paused call down to the Plugin who handles the specific logic. Keeping it simple.

* ```
  Config Mapping: How would the config.json determine which plugin to initialize for a specific monitor? Are you thinking of a mode key in the monitor settings?
  ```

I've just started working on settings so my thought may change as I implement things but yeah, each monitor gets a string key for current mode which corresponds to the Plugin's name.

I do have some thoughts about how to handle settings that I'm not 100% on. The basic idea is that we store settings on each monitor, and we keep those settings in json even when we change which plugin that monitor is using (so if you swap back to it, the original plugin's settings are remembered).

Plugins define an array of Settings objects that declare a setting key, display name, description, and control type. We generate the settings controls in the control panel based on those definitions. We feed the Plugin a settings dict with the key/value pairs that correspond with what we load from them.

I'm also playing around with treating any setting whose key starts with general. as shared settings that get saved to their own block in json, but which only get displayed if the Plugin's settings declares them. I don't know if the complexity of that is worth dealing with shared settings.

{
    "id": 0,
    ...
    "current_plugin" : "slideshow",
    "plugin_settings" : {
        "general" : {
            "is_muted": true,
            "volume": 50,
            "performance_mode": true,
            "fps_limit": 24,
        },
        "webview": {
            "html_path": "presets/circle/circle.html"
        },
        "slideshow": {
            "directory": "some/directory/",
            "filter": "*.gif"
        }
    }
}

* ```
  State Persistence: If we hot-reload the engine, how does the plugin maintain its current state (like the current index of a slideshow)?
  ```

I haven't given any thought to state retention on a hot-reload. It isn't a feature I was expecting to think about, either, though I'm sure a pair of grab_state/load_state functions that generate/consume a dict of state objects would be possible if we need it.

[Neppity3303]

I'm very glad to hear this. As you may be able to tell by my code, I'm very amateurish at software development. I do see that this architectural change is able to take this from a cool script to an actual platform. If there's anything you need from me, please let me know.

[Cidolfas]

It's not operational yet, but I'm headed out of town for a few days and at least wanted to give you an idea of where I wound up on my plugin refactoring so I pushed my working changes up to this branch: https://github.com/Cidolfas/MintpaperEngine/tree/plugins

[Neppity3303]

I'll take inspiration from it and work on my own rewrite with your improved architecture and see where I end up.