[isolatedsystem]

Yes. I'm over the hatred for Electron too. Programmers have few options if they want cross-platform compatibility without Electron. What else are they going to use? QT? Please, give me a break. Some angelic developers like the KeepassXC guys still use QT, but that is a tough road to go down on. For the rest of them, Electron Or Bust I'm afraid.

[bigstrat2003]

I would unironically rather have nothing than an Electron app in most cases. They are that bad. And in this case the app doesn't even add anything of value. Literally any email application will let you do the same thing.

[wiseowise]

> I would unironically rather have nothing than an Electron app in most cases.

So let me understand something: you obviously have a free will to not use something, but you would prefer something TO NOT exist and NOT solve problems for users, because you hate the technology so much?

[dymk]

What is that bad about them?

[tankenmate]

Waste of disk, RAM, and CPU. Tabs in your browser at least try to share those; but no chance of that with Electron.

[dima55]

There are multiple cross-platform gui toolkits. What's wrong with QT?

[fragmede]

Using QT is complex for commerical products.

[rubymamis]

How so? I've used Qt for my commercial note-taking app[1].

[1] https://get-notes.com

[fragmede]

https://opensource.stackexchange.com/a/8806

In order to abide by QT's license, you have to follow the appropriate set of rules, depending on how you use it. You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program. You can use it GPL but you have to release the source to your app. Finally, you can give QT money, and use it closed source. Okay, that wasn't that complex, but those are the rules if you want to use and distribute QT legally.

https://doc.qt.io/qt-6/licensing.html

[rubymamis]

> You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program.

This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.

I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.

[1] https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

[fragmede]

Here is the exact guidance from QT:

> In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

https://www.qt.io/licensing/open-source-lgpl-obligations#lgp...

That last sentence is key. It is a recommendation to dynamically link OR provide application source code. We don't want to be forced to provide application source code, so according to QT.io, dynamically linking is the way to go.

On top of that, there are GPL-only licensed QT modules that aren't suitable for use by closed source applications. Programs using QT on locked down OSes aka iOS and Android are subject to LGPL version 3's anti Tivo-ization clause. I'll revert to my original claim: Using QT is complex for commerical products.

Specific questions about dynamic linking and derivative works re: LGPLv3 have never been tested in a court of law, in any jurisdiction, so all we have to go on are tea leaves and armchair Internet lawyer-ing. The FSF and GNU are certainly entitled to their own opinion about their own license, but they also have a vested interest in casting as wide a net as possible. There are plenty of dissenting opinions out there, by actual lawyers. The important point is that GNU/FSF wouldn't be one deciding what's what in a court of law, a judge is. That judge gets to decide if the specific technical differences between static linking vs dynamic linking are even relevant in the first place. They might decide there isn't one!

Since it hasn't been tested in a court of law, different people are going to have different opinions on what's actually right. QT.io gives a specific recommendation on how to use their library, so I'll defer to what they have to say, but everyone's free to make their own decisions.

[isolatedsystem]

Whoa. This looks very interesting. Does it support maths? Are the images stored locally? Can fonts and typography be changed? How does it differ from your open-source version which looks similar?

[rubymamis]

Thanks!

- Not yet, but adding support for Math blocks is planned.

- Yes, images are stored locally in the ~/user/.config/Awesomeness/attachments folder

- Yes, but only for pre-defined fonts. This is by design - I wanted the app to be opinionatingly simple. But since I got many requests for that, I'm gonna add an option in the settings for that.

- My FOSS version uses a simple plaintext editor (QTextEdit) with some Markdown highlighting. Daino Notes uses a block editor (a la Notion) I wrote from scratch[1] - this allows me to add complex blocks *in the middle of the documents* - so things like Kanban, Images - any custom component that I wish basically - so also math blocks, tables, etc in the future. It's also allows me to do nifty things like cool drag & drop[2] and the editor is even more performant than QTextEdit (especially on large texts).

[1] https://rubymamistvalove.com/block-editor

[2] https://rubymamistvalove.com/blog/drag_and_drop_internal.mp4

[wiseowise]

> Using C++ for frontend (no, QML does not help)

> Licensing costs

> Atrocious DX

> Still non-native UI

No problem at all.

[ozgrakkurt]

Why do they even need an app if they use electron?

Even discord is basically the same thing in the browser

[JodieBenitez]

Tauri or similar webview integrations ? Even though it is based on the OS’s native web renderer, so prone to break.

[throawayonthe]

tauri sucks on linux right now because there isn't a good "system webview" available

hoping servo makes it better

[JodieBenitez]

I've used similar webview solutions before and they can break even on Windows (example: needing edge webview2 but not available on the user install). I get why people are pissed off by Electron but I also get why it's the de facto standard in its field.

[echelon]

Tauri needs to bite the bullet and bundle Chromium.

[justmarc]

Flutter is a pretty good alternative.

[wiseowise]

Even worse performance on Web and Desktop, very good indeed.