Skip to content

Tree layout and focus direction - #147

Open
marcybelardo wants to merge 3 commits into
nferhat:mainfrom
marcybelardo:tree-layout-and-focus-direction
Open

Tree layout and focus direction#147
marcybelardo wants to merge 3 commits into
nferhat:mainfrom
marcybelardo:tree-layout-and-focus-direction

Conversation

@marcybelardo

Copy link
Copy Markdown

Hi! It's been a while, but I had a lot of personal matters that took me away from working on these features. I think this is in a good state. I've moved the binary space partition work to this branch instead, along with some additional stuff.

  1. "Binary Tree" and "Spiral Tree" layouts.
  2. Focus on tiles using directional input rather than "next" or "previous".

I've tested these features, the layouts work fine. Currently, focus direction switching is also good, but the algorithm can be refined a bit. I can come back to that. Additionally, I'm planning to implement window swapping by direction as well, but I'll add that another time. Let me know what you think!

Adding `activate_tile_by_direction` to `workspace.rs`.

When the `FocusWindow<DIRECTION>` key is pressed, we pass a normalized
direction vector into the function. Then we get the vector from the
center of our current window to the center of other windows in the
workspace. We calculate the dot product, which will let us figure out
how similar our direction vector is to the angle between our two
windows. We then pick the window that has the smallest difference.

In the case of a bunch of windows stacked together, we also factor in
distance so that nearer windows are prioritized over ones that are
further away.

Also made tree layouts available for config, as well as some other key
actions I hadn't included yet
@nferhat

nferhat commented Jul 1, 2026

Copy link
Copy Markdown
Owner

Hey, this looks amazing! I appreciate very much the effort.

Nothing to comment much on the implementation itself, you kept the interface as I would in Workspace, adding gesture binds with that is also really nice!

If needed, you can perhaps add a layout_data field in Workspace, that would be an enum.

enum LayoutData {
    BinarySpace(Tree),
    None, // other dynamic layouts, that don't need any data.
}

What I have planned is also to move stuff inside a layout.rs file, and not keep everything inside the workspace logic (all the default layouts that are currently available need tests), but that can be done at a later time.

Looking forward to using this btw!

@marcybelardo

Copy link
Copy Markdown
Author

I'm glad you like it! Can I ask for more info about the possible layout_data field? Like, is it so it's more integrated into the Workspace struct? I can try it out while I fix some more things. For me, once swapping by direction and documentation updates are finished, I'll be content with the branch. Just lemme know!

@nferhat

nferhat commented Jul 22, 2026

Copy link
Copy Markdown
Owner

I'm glad you like it! Can I ask for more info about the possible layout_data field? Like, is it so it's more integrated into the Workspace struct? I can try it out while I fix some more things. For me, once swapping by direction and documentation updates are finished, I'll be content with the branch. Just lemme know!

Nothing, just a suggestion really. If you wish to continue working on it, feel free todo so!

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