Window configuration refactor

[elkowar]

In the scope of #176 a lot of discussion about a general rework of the window configuration and implementation structure has been discussed.
This discussion shall now continue here!

[elkowar]

@midnightexigent would be great if you could re-post your last comment here, so we can discuss it further here! Thanks!

[midnightexigent]

repost of original comment containing initial draft for the new Window config refactor:

[...] Very early WIP for now tho, but here's a general idea

1. Seperate backend-specific configs into 2 modules. Here will go the lite wrappers around display backend configs

#[cfg(feature = "x11")]
mod x11 {
    struct X11 {/*...*/}

    struct StrutDefinition{/*...*/}
    enum WindowType {/*...*/}

    /*...*/
}

#[cfg(feature = "wayland")]
mod wayland {
    struct Wayland {/*...*/}
    
    /*...*/
}

#[cfg(feature = "x11")]
type Backend = x11::X11;

#[cfg(feature = "wayland")]
type Backend = wayland::Wayland;

2. Have the Preset enum, which designed primarly to give a way for the user to generate sane predefined EwwWindowDefinitions with minimal effort

pub enum Preset {
    Bar{ /*...*/ },
    Floating{ /*...*/ },
    /*...*/
}

// generate EwwWindowDefinition attributes from the preset

impl TryFrom<&Preset> for Backend {/*...*/}

impl TryFrom <&Preset> for EwwWindowGeometry {/*...*/}

/*...*/

3. With the previous 2 points taken into account RawEwwWindowDefinition looks like this

// in the impl, for each field, if it is not provided, `preset` is the fallback (if applicable) 
struct RawEwwWindowDefinition {
      widget: WidgetUse, //preset can't help us here
      preset: Option<Preset>, 
      geometry: Option<EwwWindowGeometry>, // or preset.try_into()? or default()

      backend: Option<Backend>, // or preset.try_into()? or default()

      /*...*/
}

That being the general idea and what we discussed, I am now looking into making this more sophisticated using derive_builder and merge to allow for fine-grained overriding.

I think this is pretty much necessary since with the above layout, the user has to either use the value provided by the preset OR to spell out every single field - a bit cumbersome. One way to achieve fine-grained overriding is to apply #[derive(Builder)]; #[builder(derive(Merge))] on the types used in RawEwwWindowDefinition. Essentially, this allows any part of the WindowDef to be deep-merged from multiple sources (preset, inference from another attribute or user-override) . This changes a couple of things, here's a concrete example of how a Backend would be generated

struct RawEwwWindowDefinition {
    preset: Option<Preset>,
    backend_builder: Option<BackendBuilder>,
    /*...*/
}


let mut backend_builder = raw_eww_window_def.backend_builder.unwrap_or_default();

// infer some BackendBuilder attributes from WindowStacking and EwwWindowGeometry ? 
backend_builder.merge(BackendBuilder::try_from((raw_eww_window_def.stacking, raw_eww_window_def.geometry))?) 

// apply the preset if it is defined
raw_eww_window_def.preset.and_then(|v|backend_builder.merge(v))

backend_builder.build()

To summarize, here are the main advantages of this design:

• User has the option to use predefined setups and override them
• Infer/detect nonsensical configs in a structured/modular way by taking advantage of TryFrom<T> for *

Before I actually go on to fully implementing this, can I have your thoughts ?

Some further thoughts/questions

• How useful is gtk actually for this project ? Eww does some pretty low-level stuff, would it make sense to get rid of the middle man (gtk) ? Especially, if the design I am suggesting is used, it is possible let preset or the user do the heavy lifting when it comes to interacting with the display backend
• With the whole config rework, I was wondering if serde is gonna become an option ?

[elkowar]

I'd love the keep the separation between wayland and x11 as minimal as possible (as in, not have completely separate structs for everything, but keep the backend specific stuff in a single field of the window definition maybe?) specifically as otherwise, development get's kind of anoying as changes might unknowingly break other platforms code. Otherwise, the idea of a preset seems great!

My proposed approach here would actually be the following:

<window name="foo" type="bar">
  <x11 x11-specific-type/preset-overrides/>
  <wayland wayland-specific-type/preset-overrides/>
  ...
</window>
  

this would allow users to have their configs be compatible with both wayland and x11 at the same time, if they so desire, and would cleanly separate out the backend-specific stuff from presets.
The one point where this is questionable is struts:
here, I think the optimal solution would actually be to provide a "margin" field on the window directly that specifies the distance from the screen-border that should be reserved. I.e.: margin="20px" will say "from whatever side of the screen this bar is on, reserve the width/height (depending on orientation) of the bar + distance from screen edge, + 20 px".
This would require some fancy magic to figure out which side of the screen the bar is supposed to be on, and what orientation it has - but that should be relatively trivial

orientation: width < height or no?
side of screen: depending on orientation, which side of the screen is the thing closest too?
Then, struts could be made part of the x11 specific config. This would also more closely mirror how the config works in wayland, and thus it should be possible to use the same config properties for both backends here again (which would be the goal)

[midnightexigent]

so more something like ?

struct RawEwwWindowDefinition{
    /*...*/
    
    pub x11: Option<x11::X11>, 
    pub wayland: Option<wayland::Wayland>,
}  

and apply #[cfg(feature="...")] on the impls ?

[elkowar]

yea, very roughly - that part is now already done in my PR 👍🏻

[elkowar]

I started working on some initial cleanup in this direction in #217

[midnightexigent]

cool, want me to sync the initial Preset implementation on that PR ?

[elkowar]

Yea, that'd be great! That PR already implements the separation of x11 and wayland stuff code-side, so what's missing is the Preset and <x11 .../> and `<wayland .../> tags

[midnightexigent]

I couldn't figure how to merge my fork directly onto #217 so I created #219