Hacker News Reader

Comment by wizzledonker | Hacker News Reader

As someone who works with QML daily, I had the same question. The work is already done. Why write a common UI backend in swift when you can have the whole thing common using QML/Qt.

It’s the best way to write native Multiplatform apps at the moment. It just is.

View on HN

I’m not entirely convinced that multiplatform UI is a good idea for anything other than the simplest of applications. It always ends up looking out of place on at least one platform and sometimes all of them.

It just takes an effort to make Qt apps look and behave native. This has been one of the goals with my new note-taking app, and I think it looks pretty native (at least on macOS): https://www.get-plume.com/

Looks gorgeous. Is it QML or pure Qt?

Thanks! It’s both. The model side and logic is written in C++ while the view is written in QML. That way I get the best of both worlds, the performance of C++ with the ease of use, flexibility, animations, etc of QML. It’s worth noting that most Qt Quick components and much of QML code is compiled to C++, so even code on that side is performant.

Amazing. This is very inspiring, thanks.

Hey, I don't use your app because it's too limited for my "PKMS" needs (I use trilium notes instead), but I appreciate that you make being "native and fast" a distinguishing feature (vs all the other electron based alternatives boiling the oceans).

Thanks for the feedback, although the app isn’t released yet so you should at least give it a shot once it’s out.

I do try to strike a balance between flexibility and ease of use. I think Notion is too complicated (yet very flexible/powerful). With Plume, the focus is to be able to organize your thoughts in a powerful way, effortlessly. Sign up to the waitlist and try it once it’s out. Much more is coming soon.

> I think Notion is too complicated

I wrote about the problem space extensively on this site before, tl;dr, to me the issue lies in the fact that most of the contenders aim to manage data/knowledge/notes as "types" (for categorization, templating and derivation/re-purposing), but, to my knowledge, only trilium is enabling that with a "sound" design. Notion is exposing a lot of incidental complexity due to its "unsoundness".

Just read this comment of yours[1]. Plume is aimed to be much simpler than Trilium, I want a non-tech-savvy 40-year-old mom that doesn't know what Kanban is to be able to happily use it as someone that is tech-savvy that knows all about Kanbans. Something that just works for many people, like Apple Notes but with a more advanced editor and features.

[1] https://news.ycombinator.com/item?id=39034749

You seem to have your objectives (and non-objectives) clearly stated, which gives Plume a fair fighting chance :)

Good luck with your project!

Thanks!

@ezst I've come across a couple of your comments noting the benefits and shortfalls of the current crop of PKMS. Lots of head nodding going on over here on the "sure you can define your tags/categories/types, but after page/note creation you're on your own for management" theme. That had me jumping with enthusiam towards Trilium, only to see it's gone into maybe-discontinued mode (https://github.com/zadam/trilium/issues/4620). What are your thoughts on it's viability for someone who is not a current user but thinks they might want to be?

(if there's a better place to have this conversation than (ab)using this thread feel free to point the way. Assuming you wish to indulge me at all that is. ;-)

Which kind of supports my thesis. It’s not so much the underlying tech stack that matters, but the attention to platform conventions. I would expect text input on a Mac, for example, to support ctrl-a and ctrl-e shortcuts for beginning and end of the line (Microsoft is a gross offender on this front thanks to their wanting to accommodate Windows users on a Mac who will be used to using ctrl instead of cmd for keyboard shortcuts).

> I’m not entirely convinced that multiplatform UI is a good idea for anything other than the simplest of applications.

Well, I disagree with that. Again, it just takes a lot more effort, but I believe this is achievable (to a large extent).

For me, QML, while expressive, had a lot of rough edges.

If most of your logic is inside the C++ backend, its JS engine is just useless overhead. If you do something like lite data wrangling in QML, or worse, try to adapt existing JS libraries for it, it quickly becomes a nightmare of standard JS weirdness, non-compliance with normal JS, and just outright ridiculous and difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error.

And besides that, QML tooling is virtually non-existent. Major code editors don't even ship basic syntax highlighting for it out-of-the-box, the linter doesn't catch anything useful forcing you back into manual testing, and recently added language-server is at best a little useless and at worst impossible to get working correctly because your components live inside the build container and cannot be installed on the host without risk to system stability (Ubuntu Touch Clickable and Lomiri.Components).

If something like that was possible for Qt, I'd probably switch in a heartbeat. If our modern programing languages are finally expressive enough to write sane reactive UI and statically verify parts of your logic, why keep relying on the unverifiable and slow DSL?

> If most of your logic is inside the C++ backend, its JS engine is just useless overhead.

Well, if most of your logic in C++, what's the problem then? For my app[1] most of the logic in C++ but there's still a good amount of logic in JS (out of laziness or ease). BTW, much of QML code is compiled to C++ these days[2]

> difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error.

This is very true, it's quite difficult to diagnose issues in QML, and it doesn't seem to me like Qt ships debugger tools for errors as available for C++ when a program crashes.

I relate to your issues with syntax highlighting (although the linter is good imo). Also auto-complete is pretty bad in Qt Creator for QML.

I wonder how feasible it is to integrate Typescript into QML rather than JS.

But I think that while all these issues should be addressed, developing with C++ and QML is the most joyful combination I've experienced so far for GUI development (I also developed in React and React Native).

[1] https://www.get-plume.com/

[2] https://www.qt.io/blog/the-new-qtquick-compiler-technology

It just is is a relative term, for example - I already know SwiftUI.

Reply on news.ycombinator.com