Rnote – A note-taking application for drawing tablets, written in Rust and GTK4
github.com
github.com
Kudos to him, may other be inspired :)
(Submitted title was "Rnote – A simple note taking application written in Rust and GTK4")
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?
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.
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.
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.
Personally I'm pretty happy with Apple Notes, though Bear is a close runner up.
I'm not sure why they don't go the Syncthing route of offering peer-to-peer note syncing.
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.
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.
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.
> 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…
[1]: https://www.reddit.com/r/rust/search/?q=Rnote&restrict_sr=1&...
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.
At least I know its rust, and won't be surprised by needing to compile it
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++.
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..
There are some examples of OO rust in the documentation here for instance: https://gtk-rs.org/gtk-rs-core/stable/latest/docs/glib/subcl...
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
struct Model {
chickens_can_fly: bool
}
enum Command {
ToggleChickensCanFly
}
fn view(model: &Model) -> impl Widget {
CheckBox {
checked: model.chickens_can_fly,
on_change: || Command::ToggleChickensCanFly
}
}
fn update(model: &mut Model, command: Command) {
match command {
Command::ToggleChickensCanFly =>
model.chickens_can_fly = !model.chickens_can_fly
}
}Procedural programming hype was in 70s/80s, but that doesn't mean we got rid of procedures afterwards :)
I'm truly sorry
I just did my own PR about it anyway so no worries.
[0] https://pursuit.unimelb.edu.au/articles/it-s-time-to-retire-...
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.
Glade is very mature, people use it extensively for serious software:
https://blog.horizon-eda.org/misc/2021/01/29/glade.html
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)
Edit: Ok, it's the first link in your link, which is a rebuttal to this exact blog post.
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...
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...
Out of curiosity why is this?
"You can reopen it. But it is not a bug. ... And it is not a regression either."
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.
Is it using libadwaita?
It seem so: https://github.com/flxzt/rnote/blob/main/Cargo.toml#L39
But it's not using any official published crate FWICT, but downloads a source tar ball directly from the GNOME servers: https://github.com/flxzt/rnote/blob/ba02e999ffebb52a9f3b2b3f...
A bit weird, but maybe there's just no ergonomic and/or stable crate for it yet.
You probably wanted to comment on https://news.ycombinator.com/item?id=30023169