The focus tracking method currently used is something like this:

struct WM {
    windows: Vec<WindowState>,
    focused_window: Option<WindowState>,
}

and then to set the focused window we do this:

fn set_focus(&mut self, window: Window) {
    if let Some(win_state) = self.windows.iter().find(|w| w.window == window) {
        self.focused_window = win_state.clone();
    }
}

but cloning it means that it's not gonna be up to date with the windows vector, so it requires additional bookkeeping or having to get it from the windows vector every time

one solution to this problem could be by using a different data structure like the Zipper.

I found out about it from the penrose from scratch series ep09 (thank you @sminez !)

the basic idea is to have this kind of structure:

struct Windows {
    left: Vec<WindowState>,
    focus: Option<WindowState>,
    right: Vec<WindowState>,
}

and that allows for direct access to the focused windows and no need to keep a separate manually updated focused_window field

also this can make it much easier for nesting the same structure for workspaces/tags like this:

struct Screens {
    left: Vec<Screen>,
    focus: Option<Screen>, // arguably should not be an option
    right: Vec<Screen>,
}

struct Screen {
    tags: Tags
}

struct Tags {
    left: Vec<Tag>,
    focus: Option<Tag>,
    right: Vec<Tag>,
}

struct Tag {
    windows: Windows,
}

struct Windows {
    left: Vec<WindowState>,
    focus: Option<WindowState>,
    right: Vec<WindowState>,
}

struct WindowState {
    // window data
}

then add methods to make accessing nested stuff easier

it's relatively more complicated than the current method, but I think it's worth adding.

it's better than just having a Option<usize> because the index is not guaranteed to be there, and even if it exists it could be pointing to another element, so it needs to be manually managed, also it might introduce lifetime issues when using the windows vector, not sure tho, so before doing that, experimenting with something like focus: Option<usize> on another branch could be worth doing

also could check out something like indexmap

UPDATE: after thinking about it for a bit I think using indexmap could be better than using a zipper, because zippers are better for relative movement, so if I want to have directional focus with MOD + k for example I would need to use the index or something like that, but if I use an indexmap I can get the handle to the window (which will be the window id from the x session) and then access it like that, while also being able to iterate through the windows since it preserves the insertion order (but still need to make sure it actually does, because the docs mentions it's ordered until you remove an element (?))

every monitor will have their separate tags/workspaces.

could look like this:

struct WM {
    tags: Vec<Tag>,
}

struct Tag {
    id: u32,
    name: String,
    layout_manager: LayoutManager,
    // other fields
}

or like this:

struct WM {
    tags: Vec<Tag>,
    layout_manager: LayoutManager,
}

struct Tag {
    id: u32,
    name: String,
    // other fields
}

maybe I would like to pin one of the tags to a specific monitor, but that's for later

TODOs:

• [ ] add tags
• [ ] change the _NET_NUMBER_OF_DESKTOPS property
• [ ] track the _NET_CURRENT_DESKTOP property
• [ ] unmap windows that are on other tags ( not sure if that's how you hide the windows from other tags )
• [ ] map windows on the current tag

layouts could have extra state.

for example the MainStack layout could hold a ratio field that specifies the width ratio between the main window and the sub windows

could look like this:

pub enum TiledLayout {
    MainStack {
        ratio: f32,
    },
}

usable if done means I could personally use the window manager if the features mentioned are there.

useful if done means the window manager is more useful, but not workflow impairing if not done.

usable if done:

• [ ] add EWMH to window manager
• [x] add keybinds ( like closing a window with the keyboard )
• [x] add buttonbinds ( like resizing a window with the mouse )
• [x] add base for layouts
• [x] add MainStack layout
• [x] tile windows
• [x] add floating windows and treat them different from tiled windows
• [ ] #4
• [ ] #2
• [ ] add SwapWithMain to WMCommand
• [ ] custom EWMH compliant status bar

useful if done:

• [x] #3
• [ ] scratch pads
• [ ] Add the ability to rotate layouts, or maybe only flip
• [ ] config file (could just make it without a separate config file, like dwm)