Add some notes to ref docs and a minor changes elsewhere

This commit is contained in:
2025-10-01 17:14:33 -05:00
parent a788324026
commit 26028eb228
5 changed files with 63 additions and 30 deletions

View File

@@ -0,0 +1,55 @@
# notes regarding my workflow and intended use of workspaces
## workspaces layout
idea from the ThePrimeagen: designated workspace/label/desktop per app/purpose
### current layout/plan
| workspace number | wm default layout/mode |
|--------------------------------------------------------------|------------------------|
| 1. notes/drawing/thinking (notes app, drawing pad, etc) | stack (fullscreen) |
| 2. music makeing - misc | stack (fullscreen) |
| 3. music making - daw | floating |
| 4. music/audio listening | stack (fullscreen) |
| 5. general misc (catch-all) | stack (fullscreen) |
| 6. comms (email, chats, etc) | stack (fullscreen) |
| 7. dev - misc | stack (fullscreen) |
| 8. terminal (primary; one-offs & tui apps can be anywhere) | stack (fullscreen) |
| 9. web browser | stack (fullscreen) |
### ideas/guidelines:
- use this consistently accross all machines
- if something not applicable for a given machine, just don't have apps or screens
present, but maintain absolute position/numbering of each screen
- structure the above so that programs which i'm likely to use with one hand off of the
keyboard (i.e. to use a trackpad, mouse, stylus, etc) are on the screens that allow
for one hand (i.e. the one still on the keyboard) to navigate those screens
- for me, using peripherals with right hand, so put programs likely to be used with
peripherals where my left hand can switch to them single-handedly (screens 1 to 5)
## workflow/use notes
- related to the layout above, my approach is to run almost every window in fullscreen
- note: on macOS, this is not mac's notion of fullscreen, which basically moves
windows to new workspaces/desktops when going to fullscreen mode; instead, when i
say 'fullscreen', the idea is taking up all of the normal screen (excluding the
menu bar at the top of the screen)
- key bindings are set for moving window focus up/down (vim style: mod + k/j)
- the mental model here is that every fullscreen window is in a stack, so i can move
focus up and down the stack
- for any app which can have tabs, pair the above mental model of a stack with a mental
model of a circular-linked list being in any position in that stack
- so, keybindings are also set for previous/next tab (vim style: mod + h/l)
- all this said, it is better to keep things simple when possible and avoid having too
many windows and/or tabs open at one time; however, with the designated purpose for
each workspace and the mental models above, it rarely takes me long to find what i need
- examples:
- if i want a particular browser window, i jump to workspace 9, then move focus
up or down until i get to the window i want; if the window is right but i need
a different tab, i then just move "right or left" through my tabs
- if i want a particular music-playing app/tui, i jumpt to workspace 4 and move
focus up or down as needed to find it
- exception case: if i want a particular terminal workspace, i jump to workspace
8, but then i'm in tmux land and navigate via the methods i've set up for tmux