Readit News1. Does FlashSpace require disabling SIP?
2. Aerospace documents the limitations of macOS spaces [1]. How does FlashSpace deal with these limitations?
3. Do you have any plans to support file-based configuration? I like syncing my dotfiles between multiple computers.
[1]: https://nikitabobko.github.io/AeroSpace/guide#emulation-of-v...
Semver is great for libraries. Caddy is a project which has so many dimensions of "surface area" that it's hard to boil down the implications of changes into a single decimal-separated number. Presumably this is why a lot of larger projects use year-month versioning or just bump the major version every release. I'm actually considering doing the latter, except ... Go modules are very opinionated about major version bumps because it was designed with libraries, not commands (main funcs) in mind... and bumping the major version each release would be also be a major inconvenience to dozens of plugin authors.
Caddy has a Go API, a configuration surface (two built-in: JSON and Caddyfile); a config API; HTTP, TLS, TCP, and UDP behavior; a command-line interface; etc... the list goes on and on in ways that can break a deployment. Which of those does the one and only semver version apply to? Go has opinionated tooling around semver for the Go package stuff, so we kind of have to cater to that, but end users don't really care about that. We could split the project into multiple smaller sub-projects, each with their own versions, but then it gets confusing and tedious to build and maintain. It's also inconvenient for people to contribute to that. And we'd have to ship Caddy with several versions, one for each "surface area dimension."
We've settled on mediocrity with our current version scheming which I admit is not my favorite, but I haven't really found anything better yet. Year-month versions are nice except that it implies either a regular release cadence (which we don't have) or that a larger span between two releases is more significant than more frequent releases (maybe true, but maybe not); it doesn't really tell you anything about the build... just approximately when it was made, but not even exactly when it was made (a month is a big window!) - I guess if you do multiple releases per month you just tack another number on the end? Maybe it should just be a timestamp. Or we could invent an N-dimension decimal number or some sort of string that has to be split and parsed...
Anyway. We do try to be gentle with breaking changes. Most of these have been documented as deprecated for years as well as printing warnings in logs. But we try to minimize the number of these, for sure.
Deleted Comment
> [...]
> 5. copy the next day's calendar items to the bottom of the text file
Interesting. For a file with 51,690 lines at the time this post was created, I'm curious why the file is not ordered with the most recent day at the top of the file.
[0] https://lit.dev/
[1]: https://en.wikipedia.org/wiki/Asynchronous_communication#Ele...
2. Aerospace has significant performance issues with workspaces. The problem has persisted for over a year, and there are no plans to fix it. That's why I started building FlashSpace - to make it blazingly fast. Which limitation is especially interesting to you? FlashSpace addresses the animation lag, the number of workspaces is unlimited, and you can move apps between workspaces with hot keys.
3. FlashSpace already supports JSON config files which are stored by default in ~/.config/flashspace, so you can easily sync them.
I really like how FlashSpace plays well with macOS native tabs. One follow-up question I had is how you manage your windows? FlashSpace not managing windows on one hand is really nice for floating windows (e.g., mpv), but in your examples you have all the windows already set up with some gaps around each. Is all that set-up done by dragging windows around with your mouse? I use an accordion layout heavily, and I don't see how I can make it work with FlashSpace.