WIP: Implement Preset for Window Configuration

[midnightexigent]

This PR works with #217 to implement what's being discussed in #216

Target features :

• Generate relevant data-structures from preset
• Read user overrides
• Deep-merge everything

[midnightexigent]

@elkowar

Do you count on using something like lexpr-rs that supports serde for the new s-expression syntax ? If yes, shouldn't we implement the new window config directly with serde ?

[elkowar]

no, the s-expression stuff uses a fully custom parsing thing - that'll take some more adjustments, not much point in thinking about this right now. The config rework will still take some time for now.

[elkowar]

actually yea, what's the current state of this? the config rework was,... quite the change, that commit history on this PR is rather,.... well,... messy ^^'

[midnightexigent]

well, I kind of messed up the rebasing of this branch onto master, so I ended up overwriting it with master and I am in the process of porting the changes using yuck

[midnightexigent]

tho, seeing how many conflicts there are, I think it might be better to change this PR to directly merge with master

[elkowar]

I think so too - trying to rebase all of this sounds like utter pain

[midnightexigent]

hey I am back, I'm going to be implementing the last part of this PR (ie. generate the other structs from the preset)

There are 2 questions

• What presets should be initially supported ?
• For each preset, what are sane mappings for each part of the WindowDefinition ?

For the first question, off the top of my head, these come to mind, but I am unsure as to what params they should expose

enum WindowPreset {
    Bar(Side), // polybar-like 
    Embed{???},   // conky-like
    Float{???},
    Popup{???},
    Normal{???},
}

Got any ideas ?

[midnightexigent]

Also, I just remembered, since the preset is a high level abstraction, shouldn't the other configs now expose low-level api's ?

Once this is implemented, we can assume that anyone that uses directly BackendWindowOptions for example, knows what they're doing and wants full control (ie. the configs should provide direct mappings to the actual X11/Wayland options)

[elkowar]

Also, I just remembered, since the preset is a high level abstraction, shouldn't the other configs now expose low-level api's ?

Once this is implemented, we can assume that anyone that uses directly BackendWindowOptions for example, knows what they're doing and wants full control (ie. the configs should provide direct mappings to the actual X11/Wayland options)

how would those lower-level APIs look like? as in, what addtional options would you want to provide?

[elkowar]

hey I am back, I'm going to be implementing the last part of this PR (ie. generate the other structs from the preset)

There are 2 questions

• What presets should be initially supported ?
• For each preset, what are sane mappings for each part of the WindowDefinition ?

For the first question, off the top of my head, these come to mind, but I am unsure as to what params they should expose

enum WindowPreset {
    Bar(Side), // polybar-like 
    Embed{???},   // conky-like
    Float{???},
    Popup{???},
    Normal{???},
}

Got any ideas ?

Not sure if Popup and Normal need to be separate.
I'd say "Float" (not sure if I like the name, but I also can't think of anything better right now), "Bar", "Background" (instead of embed), and "Normal".

• Normal would just be a normal window, as much as possible.
• Float would be pretty much wm-ignore, I think - as that's the best way I've found to actually reach a always-in-front, absolute positioned window. If there's any cleaner way, do that ^^
• Background would need to not use wm-ignore, as setting stacking order won't work with wm-ignore. However, I've found that stacking is generally the most "never works" config currently, so looking closely at what conky does here would be the way to go
• Bar would be windowtype dock, and struts being set automatically, as well as the other things currently set by windowtype dock

[midnightexigent]

hey I am back after a while, I got done rebasing everything with master. In terms of progress, it isn't far off from I last left it off.

I made some changes to avoid relying on external crates (ie. derive_builder and merge). For now, doing it by hand isn't cumbersome, but might become tedious and hard to maintain in the future as the config gets more and more complex

If this feature is still relevant, I should be able to get something working fairly soon; just let me know

---

Also, I just remembered, since the preset is a high level abstraction, shouldn't the other configs now expose low-level api's ?
Once this is implemented, we can assume that anyone that uses directly BackendWindowOptions for example, knows what they're doing and wants full control (ie. the configs should provide direct mappings to the actual X11/Wayland options)

how would those lower-level APIs look like? as in, what addtional options would you want to provide?

I was thinking of exposing a 1 to 1 mapping to the backend configs (eg. these for X11)

eww/crates/eww/src/display_backend.rs

Lines 181 to 203 in fb0e57a

	self.conn
	.change_property(
	PropMode::REPLACE,
	win_id,
	self.atoms._NET_WM_STRUT,
	self.atoms.CARDINAL,
	32,
	4,
	&strut_list[0..16],
	)?
	.check()?;
	self.conn
	.change_property(
	PropMode::REPLACE,
	win_id,
	self.atoms._NET_WM_STRUT_PARTIAL,
	self.atoms.CARDINAL,
	32,
	12,
	&strut_list,
	)?
	.check()?;

But actually scratch that, that's out of the scope of this PR and probably unnecessary for now