I will try the Alt+Tab alternative to scratchpads.
However the spatial memory concern I talked about isn't exactly of losing windows and trying to find them.
The script you mentioned seems useful to jump faster between windows you are not sure where they are. But what I tried to express is that when I'm in a workspace in i3, I have "perfect vision" of whats inside the workspace, niri I sometimes I have "tiny lapses" of having myself asking "where's the terminal, is it on the left or right of my browser?" this is not "losing the window" is just tiny frictions of having to think where a window is.
I don't know if that was a first impression that could just be solved with better attention and organization(I confess that my first try with niri was not on my work PC, but my media one that is attached to television, so I was not using niri exactly on the same mood I use i3wm).
Soon I might give niri another test drive, thanks again!
For people that went from i3wm to Niri, I would love to be convinced.
Being a i3wm(now sway) user, I tried Niri but found the following points a little bit uncanny:
- (Cropping) Sometimes when I scroll by shifting focus, a little bit like 10% of the window I pushed to the left keeps appearing. I tried to configure Niri in such a way that never a tiny fraction of a window be cropped but couldn't manage. Not sure I missed some config though.
- (Scratchpads) No scratchpads. There's workaround that I saw using extension scripts, but felt cumbersome to use(not the script itself, I just wished it was native feature on Niri). I use scratchpads a lot for "global" apps like email, discord, obsidian so I can open them on any workspace I am at, then make them disappear completely after.
- (Spatial Memory) By being used to i3wm I am comfortable pushing different applications so they can fit on a single screen. In i3wm i have "perfect vision" of a workspace. Niri style keeps me "forgetting" what's to the left and right. I know I can zoom out, but feels like friction upon my short term memory.
I would love to receive any suggestion so I overcome these points that I stumbled upon. Soon I might be trying Niri again on a more work environment(my first try was on a PC connected to TV, so more media focused usage).
Yes! I am aware of that functionality, and I've tried it, but this just substitutes the Godot code editor with an external one while keeping the rest of the Godot editor.
In short terms, Godot development workflow has three pieces at least: editor interface(nodes, viewport, etc) + code editor(can be external through LSP) + game/app running.
What I'm trying to say is that app development doesn't strictly need the editor interface at all. For instance, when I'm developing an app with web technology I usually just have a text editor on the left, with my language of choice server side rendering html, and the browser on the right with the "app running".
It would be lovely to spawn the Godot editor and drag around interface components experimenting with them(like the inspector tool on browsers), but usually I just want the peace of mind of having the code and the app running.
So what I'm envisioning is that it would be possible to call Godot in my language of choice just like I would call a normal framework(PyGame in python, Love2D in Lua). With the difference of the powerhouse of functionalities that Godot carries, and the possibility of launching the full editor if desired.
I wonder the same thing, but with an emphasis on app mobile development.
Godot from project setup to running on my Android is way more effortless/lightweight experience than doing the way of AndroidStudio and/or Flutter stuff.
What I dream of is making a Lua binding for essential godot GUI control nodes using GDExtension and using this LibGodot to own the engine loop, so I can do all the app code in Lua.
So, I may have drifted away from your question, but the point is that I love Godot for gaming, and I can handle GDScript plus the engine editor, but for writing a complete application I would want to develop in my language/editor/ecosystem of choice.
In that sense, LibGodot(plus GDExtension) may help indirectly developing GUI applications by letting people own Godot in their ecossystem of choice.
I will try the Alt+Tab alternative to scratchpads.
However the spatial memory concern I talked about isn't exactly of losing windows and trying to find them.
The script you mentioned seems useful to jump faster between windows you are not sure where they are. But what I tried to express is that when I'm in a workspace in i3, I have "perfect vision" of whats inside the workspace, niri I sometimes I have "tiny lapses" of having myself asking "where's the terminal, is it on the left or right of my browser?" this is not "losing the window" is just tiny frictions of having to think where a window is.
I don't know if that was a first impression that could just be solved with better attention and organization(I confess that my first try with niri was not on my work PC, but my media one that is attached to television, so I was not using niri exactly on the same mood I use i3wm).
Soon I might give niri another test drive, thanks again!