BTW thanks for Daino! I'm working on assembling a set of tools to easily build and manage a personal knowledge base locally. I was worried I would have to build every piece myself, specially for note taking, so I was really glad to find Daino!
Oh that's awesome to hear! I have been playing with the idea of creating a desktop environment. Don't know if necessarily using i3wm but it's good to have your library if I do (:
With Haiku I like that I can use the computer without having to resort to dark mode like the other operating systems. The other systems are just too bright, while Haiku interface is warm and on-point.
I get that... I didn't like it in BeOS either... It just feels off, the more time spent on more recent alternatives (Windows, Mac, Linux+Cosmic/Gnome/Kde...). Similarly, trying to use OS/2's desktop also feels more and more alien as the years pass.
I mean, I get trying something different and/or sticking to a legacy, but there's also being usable to today's users.
I get the joke, but Haiku could indeed have its year because it's the only one of these OSs that has Firefox running. Do you need anything else? (ok, some hardware support would be nice, I guess)
I agree. Modern Qt is great - you get the performance of C++ and the ease of use (simpler than React!) of creating UIs in QML. I've built my note-taking app with a from scratch block editor[1] (like Notions's) with it. Now working on a mobile version[2]. Also working on a LLM client[3]. And working on a library that will simplify and help others build such apps easily - which is my solution to the original article author's problem.
Yes! I'm not using Qt's built-in components like StackView, but reimplementing them from scratch to better support swipe gestures, etc so they feel native-like.
> Instead, I imagine a future where we have new “high-level” tools, built from lower in the stack.
This is exactly what I'm trying to build. I'm writing a library on top of Qt that would make it easy to write native code as easy as it is writing React code! I would say it's even easier since we are throwing all the constraints of browsers and web apis out of the way.
AFAIK Fil-C does not catch all memory safety bugs, for example some use-after-free are just not bugs but work as intended (you still access the original data/allocation). This means that it's not a sanitizer and code that runs fine on Fil-C may show UB when run normally.
> for example some use-after-free are just not bugs but work as intended (you still access the original data/allocation)
That doesn't sound right? For example, from the Fil-C GC docs [0]:
> If you call `free`, the runtime will flag the object as free and all subsequent accesses to the object will trap. Additionally, FUGC will not scan outgoing references from the object (since they cannot be accessed anymore).
eh, I daily-drive a -fsanitize=address -fsanitize=undefined build of Qt and actual memory bugs are almost never a thing - I think the only time I had some were in tooling executables such as qmllint, but not in the framework itself. Most of the bugs by large are more "behaviour" bugs.
ubsan definitely has some warnings due to a few "technically UB" patterns used as optimizations in Qt as they are known-working on every target platform under the sun, but yeah, no crashes :)
I'm only using this configuration for the software I develop though (+ libc++ debug mode) as it's painfully slow, but it exercises the Qt codebase in depth.
Depends in which sense you want it to "catch" the bugs. As this readme notes/quotes,
> All memory safety errors are caught as Fil-C panics.
If your problem is a memory-based bug causing a crash, I think this would just... catch the memory-based bug and crash. Like, it'd crash more reliably. On the other hand, if you want to find and debug the problem, that might be a good thing.
Sure, if the memory error is an immediately crashing one like a null per deref, but if is (for example) a memory corruption (e.g. an out of bounds write or a write-after-free) then this would be super helpful in exposing where those are happening at the source.
That’s what “catch” means here. As in, catch it in the act. Tools that make bugs crash more reliably and closer to the source of the problem are extremely valuable.
As a FOSS maintainer myself, I recommend you to charge (a small amount of) money for the app. People could always compile and run the app themselves still, so paying for the app is a clear way to support the project. I see that you have donation on your page, but it rarely happens that people donate. Just my 2 cents.
Thanks for the suggestion. I do plan to publish the app on Google Play as well. While much of the audience is FOSS-oriented, there are also users who aren’t familiar with open source or compiling apps themselves, like here: https://github.com/CompassMB/MBCompass/issues/48.
For them, donations are a simple way to support the project, and they’re definitely appreciated.
Thanks! MBCompass will stay fully FOSS and free. Donations are extremely rare (tbh, I've not received a single one), especially from the Foss Android community, but they’re still very helpful for long-term sustainability (given Google's non-sense Play monthly policies) and greatly appreciated, especially for users new to open source.
Not true anymore! \o/ I don't use Android anymore, but I agree a lot with the principles you've shared here, so it's a thank you for sharing that. And I know how difficult it is to get the first donations, and after you get the first, it's much easier to get the later ones. So best of luck, and I hope you'll remain steadfast with your principles when it'll matter! :)
Thank you, that really means a lot. Consistency has been important to me, whether it’s shipping regular releases with real improvements (https://github.com/CompassMB/MBCompass/releases) or writing about Android development and FOSS alongside the project. I really appreciate the encouragement and support.
You might add Bitcoin, Lighting or Monero to your donations page. Would've gladly dropped you a few bucks but I don't use any of the services you're offering.
Thanks for the suggestion, that’s a fair point. I currently rely on a couple of mainstream platforms mainly to keep things simple, but I do see the value in more open and permissionless options like Bitcoin/Lightning or Monero.
I’ll definitely consider adding at least one of them going forward. Really appreciate the willingness to support.
Right, for small scripting, not for the majority of the app. All the backend interaction is in C++.
Like, electron is fine, but it's orders of magnitude slower than it needs to be for the functionality it brings. Which is just not ideal for many desktop applications or, especially, the shell itself.
Ultimately people use electron because they know HTML, CSS, and JS/TS. And, I guess, companies think engineers are too stupid to learn anything else, even though thats not the case. There is a strong argument for electron. But not for Linux userland dev, where many developers already know Qt like the back of their hand.
TypeScript transpile to Javascript - do you really want your operating system's shell written in slow ass Javascript? Modern C++ with hardening rules for the compiler[1] is pretty safe.
reply