Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save/Load grid layouts #203

Open
ramirezmike opened this issue Dec 5, 2020 · 2 comments
Open

Save/Load grid layouts #203

ramirezmike opened this issue Dec 5, 2020 · 2 comments
Labels
difficulty: hard enhancement New feature or request frozen Might be worked on in the future but not planned

Comments

@ramirezmike
Copy link
Collaborator

nog should have a feature to store/load layouts. I've been thinking about how this could work for a bit as this could be approached somewhat iteratively making it more and more robust.

Simple initial approach:

  • add keybindings for saving/loading layout
  • stores the layouts in a similar format to what is currently being used to persist the active workspaces
  • instead of window IDs there'll just be tags like A, B, C
  • On save, a popup could appear where the user supplies a name for the layout
  • Loading could be similar or maybe the load binding in the config takes a name of a specific layout the user has saved
  • When a layout is loaded on a grid with tiles, the tiles will re-organize to best fit the layout
  • Once a layout is loaded, all further grid behaviors are just handled in the manual way (how nog currently works)

Next iteration: launch apps

  • allow workspace configs to reference a layout and assign specific programs to the tags in that layout
    For example, something like this would load a 3-column layout on launch with the apps launching in each respective tile
    // in some layouts file
    MyFirstLayout: c[t0|40|A,t1|40|B,t2|40|C]

    // in config.nog
    workspace 4 #{
        layout: {                    // pseudo-syntax just to get the idea across
           template: MyFirstLayout,
           A: "vim.exe",
           B: "chrome.exe",
           C: "cmd.exe"
        }
    }
  • once loaded, all further grid behaviors are handled in the manual way (how nog currently works)
  • maybe also have a binding to that specific layout + apps so you can re-launch a workspace-workflow on demand on whatever workspace you're on
  • what should happen when the user does this on a grid with existing tiles? 🤔

Next iteration: Directed Layouts?

Ok, full disclosure: everything about this iteration might just be a pipe dream but it could be possible, it just has some complexity.

The goal would be something that lets the user setup a layout that has "directed entry points" for any future tiles that get managed by nog.

For example, here's a layout that is a "left-column-and-stack." The idea is that there's a main app "pinned" in the column and any additional apps added to the workspace automatically stack on the right. It's a layout + the behavior dictating how managing on that workspace behaves.

left_and_stack

A little implementation detail: I think in order to add this we'll need a layer above the tile_grid that is like a "layout_manager" that checks what the current layout is and then figures out how to modify the grid to fit the layout (obviously not a simple challenge!)

The other complexity is how the user describes this in the config. Right now I've been playing with this idea where the user just describes the layout in a grid rather than having the user manually write out something similar to the current workspaces.grid syntax. So, for the above layout, it would be something like this

AAAABB
AAAACC
AAAADD
AAAAEE

Additional notes:
- letters could correspond to launching of specific apps
- the proportions directly correlate to the sizes of those tiles when nog is running (i.e., A will take up 2/3rds of the width)
- the layout can be shrunk to something like this too, which would be A is left half and the stack is the right half
  AB
  AC
  AD
  AE

Then nog will parse that with magic and figure out how to construct the grid. That's just the layout though, not the directed behavior. For something with direction the user could write this

AAV

- directions would be <V^> ?

And nog will treat that as "ok, first app goes in the Main 2/3rds left column, any other tile gets added to this 2nd column in the downward direction"

Here are a couple other examples

"center with stacks"
center_stacks

VAAV

There could be a way to specify just direction instructions which will always operate off of the last item added to the grid like this

>V

Could maybe make binary tiling like this?

bsp

>V<^

Spiral?
spiral

Obviously there's a lot there that can be difficult to implement, but I figured I would write this out to see if it's something that would be useful or not.

@ramirezmike ramirezmike added enhancement New feature or request difficulty: hard labels Dec 5, 2020
@TimUntersberger
Copy link
Owner

I am not too sure what the usecases are for saving/loading static layouts. The more I think about it the less useful it seems. Can you think about some valid usecases?

Supporting automatic layouts would be cool, but I don't think that automatic layouts should be part of saving/loading layouts.

I talked about supporting different "organizers" before in the beginning of extracting winapi related stuff. Our manual "Organizer" would be the graph based algorithm.

Do you think it would be possible to have any automatic layouts be completely implemented in nogscript so we can just provide them as plugins and users can develop their own automatic layouts?

@ramirezmike
Copy link
Collaborator Author

I am not too sure what the usecases are for saving/loading static layouts. The more I think about it the less useful it seems. Can you think about some valid usecases?

It probably would only be useful for simpler layouts since nog won't really know which app should go where. The user will probably have to manually move apps around to what they really wanted anyway. And I guess at that point, a simple layout may be easier to just manually construct than to have a keybinding to re-organize what's currently managed... and then have to go back and swap tiles around.

Supporting automatic layouts would be cool, but I don't think that automatic layouts should be part of saving/loading layouts.

Yeah, agreed.

I talked about supporting different "organizers" before in the beginning of extracting winapi related stuff. Our manual "Organizer" would be the graph based algorithm.

I might be interpreting this incorrectly, so I wanted to double-check. The "graph-based algorithm" is what we currently have, correct? And you're saying in the future we could have something else like... say I want workspace 3 to be a tabbed-organizer and the tiles there are tabbable fullscreened tiles rather than the manual tiling we currently have?

Do you think it would be possible to have any automatic layouts be completely implemented in nogscript so we can just provide them as plugins and users can develop their own automatic layouts?

YES! I'm glad you pointed that out, that seems like it'd be way easier and would probably work. We could have the nog api expose functions for returning flags on the focused tile's neighboring tiles and then be able to write up automated scripts. And if a user finds they're limited we can always address specific use-cases there and don't have to worry about supporting literally anything. Might be a good way to test out nogscript too.
.
.
.
As far as this issue goes... do we still want some way for the user to save a layout that can be referenced in the config file along with tagged applications in order to launch a set of applications into a configured layout on a workspace?

@ramirezmike ramirezmike added the frozen Might be worked on in the future but not planned label Jan 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty: hard enhancement New feature or request frozen Might be worked on in the future but not planned
Projects
None yet
Development

No branches or pull requests

2 participants