Way to bury the lede — "simple note taking app" usually makes people think of the usual text notes. This is a handwritten notes app for drawing tablets, like a more modern xournalpp. Nice!
I was positively surprised as well. This looks more like OneNote than your average mini text editor. As a Linux user with a graphic tablet I love to see progress in that area.
I see lots of note taking/personal knowledge info management apps being announced and criticized on HN, but I think it's great that we are exploring the space.
Eventually, things will probably whittle down to a handful of successful options, a la survival of the fittest.
I wonder if there's an example of a software category that went through something like that?
> Eventually, things will probably whittle down to a handful of successful options, a la survival of the fittest.
Doubt it. Most people aren't trying out a lot of these things.
There's always going to be more people who come up with their own ideas of how to take notes, making new note-taking applications.
They will reinvent each others' ideas again and again, maybe some _ideas_ will somehow persist and become pervasive, but always there will be new note-taking apps with every generation.
> I think it's great that we are exploring the space
I am 100% agreed on this. I have used Evernote for many years and really hate the curse of commercial software that forces them to constantly fiddle and break things that their customers have come to rely on. Nevertheless, despite not loving it, I touch Evernote multiple times per hour almost every hour throughout my work day. I need a mobile app and quick sync between different apps, and that will be hard for an open-source effort or a one-person startup to achieve. I wonder if an open-source app could be built on top of a paid commercial sync service; I would gladly pay for that.
I switched from Evernote to Joplin a year or two ago, and it has been a great experience. Joplin is much more markdown-centric, so it doesn't fully replace all of Evernote's features, but it does have good support for multiple organizational schemes, including notebooks (i.e., folders) and tags, which I appreciate. They have both mobile and desktop apps, and even a CLI. And it's built to sync over any number of cloud services, including Dropbox, Google Drive, or Nextcloud.
Anyway, I recommend checking it out to see if it meets your use case. It's been a while, but I believe it has the ability to import from Evernote, or at least read from whatever export format Evernote provides, something like that.
I'm still looking for an Apple Notes-equivalent that I can comfortably use on Linux. It's been the hardest part about switching away from MacOS. A cross-platform app that launches instantly, syncs notes, has search functionality, and works on mobile is something I think we're missing.
I use for that Write from StylusLab. You have to sync the files yourself but I appreciate the fact that they are just .svg files that I can read later on with any program instead of some propietary format.
It's still not Notes/One Note equivalent (I'm in your same boat) but it's the closer thing I've found to use with my Android and Linux.
It's not sarcasm. I've looked pretty hard for the right app and haven't found one that meets all of those requirements. If it's that saturated, then what would you suggest?
Google Keep, Microsoft OneNote, Notion, Obsidian, Simplenote, Bear, Joplin, Notable, Inkdrop, Supernotes, DevonThink, Craft, Standard Notes, Notability, Roam, Nimbus, Notejoy ... these are just the ones I could think of without even searching.
Personally I'm pretty happy with Apple Notes, though Bear is a close runner up.
All of those either require a paid subscription for syncing/storage, don't support mobile & linux, or are electron-based and take a long time to start up.
I'm not sure why they don't go the Syncthing route of offering peer-to-peer note syncing.
I use Automattic's Simplenote. I pin the web app in a Firefox tab, avoiding the Electron app. The Android and iOS apps are both great tho. Live sync is perfect, you can publish read-only links to notes (like pastebin), and it has basic Markdown support but basically no other frills.
I think that task/project management is also starting to go through that with Clubhouse, Linear, Height, Notion/Coda/Knowledge-bases (trying to solve it). I would not be surprised to hear that there are a couple in "Stealth" as well.
Question: Why is Rust important in this, important enough to be in the name of the app (presumably the "R"), not just the HN submission title (which has its own reasons for including "Rust")? That seems very insider-baseball for the average user.
For the average user indeed, but for the average rust developer hanging around on HN, having examples of how a full-featured GUI app that use GTK4 is something really valuable!
I have no interest in note-taking apps and I'm never gonna use this one, but I'm eager to read the code.
Agreed - I have a personal project that needs a GUI. Still debating which to use but right now GTK4 is likely my top pick due it's binding maturity. Having a codebase to look at, esp. one that has obviously taken great care in it's design, is extremely valuable.
>I have no interest in note-taking apps and I'm never gonna use this one, but I'm eager to read the code.
Probably you should subscribe to some Rust specific reddits or forums ?
Otherwise it means we should see on first page 10 different TODO apps in 5 different languages with 10 different toolkits. There should be something relatively interesting about the app IMO.
Most people in the comment section seems to find something interesting about the app, and a few of us found something interesting about the fact that it's made with Rust.
> Probably you should subscribe to some Rust specific reddits or forums
I'm following /r/rust, but nobody submitted this app on it [1] so I was happy to find it here. Maybe you should tell the OP to go subscribe on reddit and post there instead of HN, why are those people using your forum for things you don't like…
> Maybe you should tell the OP to go subscribe on reddit and post there instead of HN, why are those people using your forum for things you don't like…
The issue is with Rust related spam, similar crap will not get blindly up-voted if Rust won't be in the title. Anyway we have to upvote or flag the articles as per the rules, but seemed weird that you would find cool Rust stuff here and you would miss it, then you either are not subscribed on the good Rust community or the Rust subreddits forums are so hyper filled with garbage that you miss interesting stuff.
I appreciate the mention if only because a bunch of projects look cool by description, but when you dig in you find out they have some silly stack of tech required.
At least I know its rust, and won't be surprised by needing to compile it
Just taken it for a spin, really intuitive and worked beautifully! I love that it has 'rough' shapes built in, I'm already a huge Excalidraw user and fan and having a native alternative is exciting.
I like it. I wonder if this is available for Windows?
The title invites us to talk about the tech stack, so I'll do:
The better tech for an app like this would certainly be Qt with C++. OP mentioned that this is a project for learning Rust which is perfectly fine. However, if the goal was to build the best possible product in the most efficient way, just use Qt and C++. At my job we've build many Qt apps and they don't explode with memory leaks and race conditions (unlike many Rust evangelists keep praying). And also they don't became an unmaintainable mess. Rust is great and all, but if you need a cross-plattform UI that is not Electron just use Qt with C++.
Just as a matter of research giving your background:
Would you like/consider to use C++ but with the web as the UI/presentation layer?
No javascript, no WebAssembly. Just pure C++ talking nativelly with the web layer..
Im working on something where applications can use the web as api, just as ( and even more than) Javascript can, with other spices added to the whole thing.. and im considering to jump to C++ as the second SDK (the first one already implemented being Swift)
Just to understand, what someone like you would think about this, if you dont mind me asking for this..
I like Qt. However, integration into a Gnome+Wayland environment is still buggy. For example, in my new Fedora install, Qt apps using the Wayland backend lack window borders.
Can anyone briefly describe or point to the relevant resource - how GUI toolkits in Rust are done without the proper OO? E.g. how do you model and implement Object > EventHandler > Window > Control > RadioButton hierarchy?
I mean, for gtk in particular, I think they just implemented everything necessary to make rust understand and interact with gobjects "proper OO" hierarchy, which gtk is built on top of. Rust isn't natively OO, but neither is C...
Or you can look at the repository linked in this HN submission as a practical example...
---
Outside of the OO-gtk world, there's been quite a bit of experimentation with non-OO gui systems in rust, but I don't think there's a settled "best design" yet. Many designs look something like the following
- model: rust struct describing your data
- view: function mapping your data to widgets, widgets understanding how to layout, render, and issue commands
- commands: events in view generate simple command structs
- update fn: iterates over commands, updating model
With the framework passing input to widgets, and taking commands from the widget and passing them to the update fn, and then calling view to update widgets. Potentially intelligently to avoid redundant work (e.g. not re-rendering widgets that haven't changed).
The bigger constraint driving this than "not-OO" is "not mutably aliasing data". You probably don't want to try and have your update functions take a mutable reference to your model, because you will end up fighting the borrow checker. (On the other hand, I think egui does manage to pass mutable references to the model to callbacks, so maybe this is just a reflection of the rust gui's I've personally experimented with)
So in a slightly imaginary reasonably representative gui framework, I might have
In my small project ([1], Rust + GTK3) I pass the program state wrapped in Rc<RefCell> to my update functions (closures-as-event-handlers) and so far it's been OK (after all they're executed sequentially from the main thread only). One just needs to remember not to hold the borrow when displaying a message box (as in GTK it enters a new message loop recursively).
Rust has something akin to inheritance for traits. There are no up/down/cross-casts, but these can be done as methods in hierarchies where they are actually needed.
OO is a pattern, not (necessarily) a language feature. As already mentioned, GTK is implemented in C, which has "similar" starting point for OO as Rust.
For the record, I find little wrong with this comment as it was originally posted. People might not be aware of the story behind that image, and that Lena Forsén herself doesn't wish her photo to be used like this any more [0]. I can't for the life of me understand how this can remotely be interpreted as a flame bait.
Oh wow I'm sorry, had no idea it was controversial in that way! Truly not trying to initiate anything... Thought just some people didn't know the story, which is why she is still used.
I just did my own PR about it anyway so no worries.
Gtk4 has a lot of potential to be disruptive if the tooling becomes at least competitive to what other frameworks have (qt, flutter,etc).
For now it's a serious choice (or the only choice) if you develop for linux.There are cases where this is desirable and if you have a product that has multiple 'native' versions and that's good, but most often than not that's not the case.
-Language bindings(this is where gtk is overlooked and has a solid position, being written in a low-level language it already satisfies one segment of developers and through bindings the other half)
And either:
-A decent designer tool (glade and cambalanche exist - they're better than nothing, sadly would say they're not production-ready)
-Or some (possibly community-driven, which can be the case since gtk is open) extensions for couple major IDEs/editors: think emacs,vscode,intellij-based.This is where gtk is way behind flutter/qt and i think they can gain the most since a lot of developers rely (for good or worse) on editor extensions.
And i'm willing to guarantee that gtk will be often be picked as a solid alternative.Again, this is not bashing against gtk4, because it's free and my talk is worth nothing compared to contributors, but these are just my 2 cents.
I agree, but I think the biggest issue is that GTK4 no longer feels like a "native" toolkit. To get it working properly on Linux, you need to sandbox your application and load more assets into memory than the average Electron app. Then you factor in how difficult GNOME makes it to feel native on other systems, how difficult it is to write a GTK4 app properly (as you highlighted with your designer tool point) and how little people care about making it feel right on other platforms... it unfortunately looks like GTK4 insists on shooting itself in the foot every time it turns the corner.
I've personally been happy to stick with GTK3, which doesn't fall victim to the majority of those issues. It's still not ideal, but one thing is apparent: the potential of the GTK toolkit is being actively squandered...
Cambalanche is a fresh start, with gtk4 in mind, of course it's not production ready yet. But I'm really excited about it, the architecture is cool (probably the best use of the broadway backend ever)
Looks neat, but I have no intention of installing Libadwaita onto any of my systems. I hope the people who will enjoy this though, Rust/GTK programs seem to have huge potential in my experience writing them.
Edit: Side note, why does the CSD switch sides from left to right? If I was a user, that would annoy the hell out of me, especially if I was using a drawing tablet...
GNOME middleware has no place on my system. GTK4 breaks font rendering which is already eye-searing enough, but libadwaita is woefully incomplete and barely functions without sandboxed life-support propping it up. It also violates the native LAF of my system, introduces compositing issues on any system that isn't running a GNOME 40/Wayland combo, consumes too many resources and frankly has no reason to exist given the modern state of GTK programming. Since I'm a GTK dev, I choose to abstain by staying on GTK3, which has none of the aforementioned issues.
It's pretty terrible. I've feuded with more GNOME maintainers than one person should ever have to, and it always comes down to the same "well we're right and you're wrong" mentality that makes nobody happy. With blurry text in particular, a surprisingly large number of GNOME team members decided it wasn't an issue since the effect could be halfway mitigated with sandboxing, so none of them ever addressed it.
I can't use GTK4 or libadwaita confidently, as a developer. It's tooling that was designed from the ground-up to limit my capacity as a developer, and as such I refuse to write code with it or install it on my system, for that matter.
Ok, interesting. I am running Sway on Wayland and have one application that depends on libadwaita. Looking it over, I can see what you're talking about. Thank you for sharing!