Is there a story for interop with other languages? I understand the UI probably has to be defined in JS, but what about transparently making request to a local server written in another language (bonus point if it can somehow be made less observable than that, i.e. not consuming a localhost port).
The NodeJS NAPI support binary modules written in any language that can build dynamic libraries against the C FFI. There's still a little overhead marshaling between Javascript and the guest language but it's small compared to the overhead of HTTP or WASM.
It’s looking good! One really common usecase Id suggest emphasizing (it looks supported) is the systray UI. I’ve had a lot of cases where my program is mostly just a background nodejs service and the simple task of adding a dock UI required electron. A great thing to have solved!
"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."
Also, Chromium's Blink renderer has a lot of LGPLv2 source files that date back to the KDE KHTML days[1] and as you can see by the numerous proprietary applications that use Electron and Chromium Embedded Framework, that this doesn't hinder companies from using LGPL libraries as long as they abide by the license.
However, one thing to note: the OSS version of Qt uses the LGPLv3 license, which has additional restrictions (like the "Anti-Tivoization" clause) which make it incompatible with the iOS AppStore thus forcing you to use the commercial version of Qt in those situations. Not sure about the Mac and Windows 10 app stores, I am curious if anyone knows/has experience with LGPLv3 and those stores?
> which make it incompatible with the iOS AppStore thus forcing you to use the commercial version of Qt in those situations.
Not necessarily. If you're able to distribute versions of your app to iOS users so that they can link it against their own Qt libraries, you'd be in compliance with the LGPL.
I've seen companies that distribute via the App Store, but also provide object files with instructions to link them against user supplied Qt libraries and to get them on iPhones/iPads.
I might go a little offtopic here. Any plans to integrate https://github.com/c-smile/quickjspp. That way you can target mobile platforms too. QT supports mobiles well
As for desktop only this is great. Great work. Many people are commenting on NodeGUI only. They have forgotten to mention how Svelte also contribytes to saving memory footprint and cpu cycles over other frameworks with a much easier way to write apps. Add a small learning curve to that.
There are other projects like this - But what would really set it apart would be mobile (iOS and Android) support. Can we do anything to support that happening?
Qt does have an implementation that targets mobile. I don’t know how the licensing works, but in theory there should be a way to rely on Qt for mobile to extend support to iOS and Android. Way out of my own expertise, though!
Qt for Android and Qt for iOS can be used under the LGPL[1]. The issue for iOS, though, is that Apple's App Store violates the terms of the LGPL. To comply with the LGPL, you must make available to iOS users versions of your app that can be linked against user-provided Qt libraries.
If you use the Qt commercial license for either, then you don't need to worry about your app conforming to the LGPL.
I'm really happy to have found this at I'm in the early stages of building an app. My plan is to release a web only version first and then desktop clients later depending on demand.
So, my question is, how much work is there to convert a web app built with Svelte to a Svelte NodeGUI app? Will most things just work, or should I expect to have to rebuild a lot of functionality?
Second, my app will make use of WebGL (or possibly WebGPU in the future) and have done wasm components. Do these work with NodeGUI?
I'm really happy to have found this at I'm in the early stages of building an app. My plan is to release a web only version first and then desktop clients later depending on demand.
So, my question is, how much work is there to convert a web app built with Svelte to a Svelte NodeGUI app? Will most things just work, or should I expect to have to rebuild a lot of functionality?
1. Is there any way to load a UI file made with designer-qt5, perhaps with example code?
2. Thank you for backing up your claims about a native implementation by actually providing one, unlike your competitors Tauri and Wx who constantly lie about the topic.
No plans, but what kind of integration would you have in mind?
I actually happen to be struggling to get React Native in the NativeScript runtime right now – running it in the Node.js runtime would be if anything even more challenging. But there are other ways to make the two work together.
I’ve always been wondering what nativescript really was about, and how it compared to react native and other platforms (and also, why do i barely read about it on HN or elsewhere, as it seems to offer a cross-platform dev environment).
The project’s webpage has way too many tech listed to be of any help, and the video mentions a framework, an IDE, a debugging environment...
Do you have a good link where i could get a better understanding of the tech, and how it’s used in real world project ?
The parent project, NodeGUI, has some Windows screenshots and examples – I’m not familiar enough with Fluent or WinUI, but basically the UI runtime is Qt5, so integrating it into genuine Windows apps is out of scope (but may well be possible with the right expertise). I assume it would involve some kind of Qt-hosting view. I’m unsure whether Qt5 can host Windows UI components.
WinUI 3 improves the ability to embed fluent UI “xaml islands” in Win32 apps (like Qt processes) but it’s extremely convoluted and requires a lot of boilerplate (that I believe Qt could theoretically abstract over being at a high-enough level).
> I’m unsure whether Qt5 can host Windows UI components.
yep, basically you have to do :
auto window = QWindow::fromWinId(reinterpret_cast<WId>(/* HWND, NSView, X11 buffer, Wayland surface... /*));
auto widget = QWidget::createWindowContainer(window);
and then you can use the widget like any other Qt widget, put it in a layout, etc... (of course caveats may apply when you start doing transparency or other fun things).
