Same here since my new phone.
I wanted a very simple interface and have no need for widgets and don't like a grid of toy icons. I just saw the pro version has folders but I don't have a lot of programs installed so the flat list is managable.
The launcher itself is also very clean and minimal, with a text-only UI. You can pin up to 8 apps to the home screen and the rest are accessible through search. You trigger search with a swipe, and when only a single matching app remains for your query, it automatically opens it, making it pretty efficient.
E.g., if you don't have Firefox pinned, you can swipe and type "fir" (or any other unique substring) and it will open just like that. It's great for muscle memory.
My only complaint with it is that the developer sometimes sends messages (e.g., happy new year) and there doesn't seem to be any way to disable it. I don't see why a minimal launcher should have internet access at all.
[dev here] The Internet access is required only for the daily wallpapers and nothing else. The messages pop up based on date. Many users seem to like it but if I hear any more complaints, I'll consider removing them.
Thanks for the clarification (and your work on Olauncher)! I knew I should have checked the source code before posting my comment. I don't think they need to be removed, but I would appreciate an option to disable them.
Not who you replied to, but I would personally prefer them to be opt in. The most recent message was sweet, but it also felt a little intrusive or ad-like. Love the launcher!
Just wanted to mention Stow[1] here, which I use to symlink my dotfiles on a new machine on a per app basis for many years now. My set up script just installs basic compiler toolchain and runs a bunch of stow commands based on Linux/Mac OS. I also adhere to XDG base spec[2] so I can keep my ~/ clean.
Also, the latest version (>= 2.3.0, released June '19) has a new flag specific to managing dotfiles. When passing `--dotfiles`, stow replaces `dot-` at the beginning of filenames with `.` in the symlinks. The online help does not mention it, but the release notes and man pages do.
Yeah, I don't understand why people like reinventing the wheel, Stow works, Make works, both are available everywhere, you don't need 30 layers of JS to manage dotfiles, I'm not against progress, but at least make something better than what's already around.
I really like stow. It handles almost everything for me.
One thing, I didn't split things by apps per se. I split them based on task. In some machines, I do Python work, so I created a 'python' package. In some I do PHP, so I created a 'php' one. I have a 'base' one where it has my .bashrc, .profile, .bash_profile, fish configs and other things.
Everything in the .bashrc. .profile, etc is loaded around conditionals. So, while the files are long, the section only activates if the other package is available. I thought about splitting it onto files, but most editors have a way of collapsing sections, so I decided to keep it on one so it's easy to edit in one place.
It would be beneficial to couple transactional data (Postgres) with OLAP data (CH). There are a few other things coming in PG which might mitigate the need for CH too (pluggable storage, zheap), so we're not going to rush this part.
Would've loved it if it wasn't a JUCE wrapper. Nevertheless, some great work here. The same approach can be applied to any non-JUCE stuff too, which would be kickass! :)
Why do you say that? I've built the core of the engine entirely from scratch, entirely indepenent of juce. The CLI tool does use juce for opening the audio device, but that's about it.
When choosing to apply parallelism, it should never be about the length of the collection but only the computational intensity of the function that's being applied. There's a considerable overhead in spawning processes and collecting the result from them
