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).
I've avoided needing them because of 2 niri features:
- You can quickly tap alt+tab to focus the last previously focused window (assignable to a custom bind if you want)
- niri's CLI is very easy to work with so you can build a general purpose "launch or focus" shell script in a few lines of code
If you have something like Discord or any app you want to only be opened once, you can "launch or focus" it and now it's running somewhere. Somewhere as in, you can control which workspace it's on at your discretion.
Then if you launch it again from anywhere, you'll jump right to it instead of launching a 2nd instance and you can tap alt+tab to go back to exactly where you were before.
A nice effect is after it's been launched once it never interferes with your existing windows since nothing is getting opened again.
I'm after the end result of "let me access this program quickly no matter where I am", it doesn't need to literally follow me around every workspace to do that.
The launch or focus model can be applied to GUI apps and also TUIs.
=== SPATIAL MEMORY ===
niri's overview gives you a holistic view of everything. Status bars can also show you which workspaces are in use (and even open apps if you want that).
In addition to that, certain launchers like Walker have shortcuts to let you switch windows. This means you're only ever 1 global hotkey away from seeing a list of every window that's open and being able to fuzzy find switch to it in a second. I use this all the time. If you're not using Walker you can build this in a few lines of code since niri's CLI gives you a list of open windows.
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!
niri's alt+tab also has a filter where if you hold alt and then press "w", it will only show you things on your active workspace. There's a little label that pops up showing this. You can also press "o" to filter it for only 1 monitor (output) too.
The above might help with those lapses.
In my case I haven't experienced this because I'm usually after the end game destination which is focusing the app so fuzzy finding it is the quickest path to that. If it's 8 windows to the right or 3 to the left is all the same to me.
With that said, I do sometimes have sessions where I have 3-4 things open side by side and I quickly cycle between them by going left and right. In those cases I don't have memory lapses because there's only a few windows open and I'm doing something specific. When this task is done I usually close those windows or no longer need to remember their relative position to windows in view.
I bet you could create a cool looking horizontal mini map to show a strip of things open on a workspace, this way you don't need to open up other things (overview, alt-tab, window finder, etc.) to see where things are.
i3 shows title bars (shrinking or expanding them) kind of like how tabs are displayed in a web browser. If you do nested layouts with i3, though, you wont be able to see all the title bars, but otherwise usually you can see all the title bars (though truncated to fit). That's a pretty common workflow, and it gives you "perfect vision" of all the windows in that workspace. Vs niri which by default scrolls the whole window (title bar included) off the screen, so you can't see all the windows in the workspace at a glance.
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.
> but for writing a complete application I would want to develop in my language/editor/ecosystem of choice
For well over a year now, you can use an external editor (VSCodium or whatever) and set it in Godot settings (so that clicking a script icon in the scene tree opens that file, and clicking a signal handler in the properties pane jumps to that line), and the LSP for GDScript (which is hosted by your running Godot instance, and which your editor's LSP client connects to) has been excellent back when I last dabbled in it.
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.
A fork of Godot optimized for native apps would be a good idea. Especially if it learned the lessons of the web stack and used basic text-based formats for describing layout and theming (like HTML and CSS). Maybe something like QT. Something simple, flexible and portable that's as easy to use as Electron but doesn't require lugging around a 60mb Chromium instance for every application.
Some work would need to be done improving text rendering, layout and to add more GUI elements. Probably a lot of stuff removed from the backend that isn't necessary (apps won't need physics or lighting, probably.)
I made a basic theme loader for a project ages ago based on the config file format because dealing with theming and fonts was a pain at the time. Nothing novel, it was just a dictionary that had node paths as keys and set values. It is possible, I don't know why Godot makes some things more complicated than they need to be.
This is how GTK came about. Literally "GIMP Toolkit". They took the widgets that the GIMP creators had created, and turned it into a general-purpose toolkit for other apps to use, due to issues with Qt.
The comments about web stack stuff is probably off. Godot is already a pretty featureful UI framework + form designer that makes anything the "frontend" world has ever produced seem like they only had a fraction (1-to-10%) as much time and resources to build, compared to what Godot was already shipping in 1.0, (even though the reverse is true).
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).
reply