21–30 of 87 posts
Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron: https://blog.stevensanderson.com/2019/11/01/exploring-lighte... From Blazor roadmaps a few months ago, I think the idea is that Blazor will become the recommended .NET Core cross-platform UI choice sometime after .NET 5.
I always wonder why Qt5+/Qml/QtQuick have not taken the XP desktop development by storm. QML is JS like, there's an IDE and KDE seems to have built lot of good looking desktop software using Kirigami/QtQuick. It's got to be better than anything Electron for sure. Anyone know if .NET Core Qt bindings are a technical possibility?
Anyway, the point is, people may not want to use Qt without being absolutely certain about how the licensing works and they (like me) probably don't have the time to try to understand the poorly organized information on the Qt site.
This is a great step forward, but it seems like a great deal of overhead and complexity to have a cross-platform GUI. If I were creating a new cross-platform desktop application I would probably reach for Java instead. I know that's not the popular answer, but if a .NET Core cross-platform GUI requires either using Electron or simulating a client-server setup with Node then it's not there yet. To illustrate, here is…
[0] https://gluonhq.com/gluon-substrate-and-graalvm-native-image...
Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron: https://blog.stevensanderson.com/2019/11/01/exploring-lighte... From Blazor roadmaps a few months ago, I think the idea is that Blazor will become the recommended .NET Core cross-platform UI choice sometime after .NET 5.
That is a much better way to go on imo. No Electron and no Node involved. A tiny crossplatform webview + .net core is much preferable for me.
Earlier quoted context omitted.
> I always wonder why Qt5+/Qml/QtQuick have not taken the XP desktop development by storm. If I had to guess, it's because people are misinformed about the pricing and features. I regularly see people who assume that you either have to pay a large per-developer fee, or completely open source your application, even though Qt is licensed under the LGPL, so you're fine as long as you don't statically link it or depend o…
LGPL is problematic for App Store, since the user should be able to relink the app with a newer version [of QT] if they wanted to.
Static/dynamic linking isn't a problem.
Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron: https://blog.stevensanderson.com/2019/11/01/exploring-lighte... From Blazor roadmaps a few months ago, I think the idea is that Blazor will become the recommended .NET Core cross-platform UI choice sometime after .NET 5.
But the big advantage of using Electron is that you know exactly what browser and Node version you are targetting. That takes away a lot of the cross-browser HTML/CSS pain.
Perhaps if you are starting from zero on the CSS front you will see minor quirks browser-to-browser, but if you start with something like bootstrap 4 and leverage the responsive layouts you can see consistent results that your clients will enjoy pretty much immediately.
Thinks using a web server is too much. Then recreates http. ¯\_(ツ)_/¯
Earlier quoted context omitted.
LGPL is problematic for App Store, since the user should be able to relink the app with a newer version [of QT] if they wanted to.
They can relink. The object files for relinking aren't required to go through App Store. Static/dynamic linking isn't a problem.
0: https://apps.apple.com/us/app/qt-5-showcases-by-v-play-apps/...
This is a great step forward, but it seems like a great deal of overhead and complexity to have a cross-platform GUI. If I were creating a new cross-platform desktop application I would probably reach for Java instead. I know that's not the popular answer, but if a .NET Core cross-platform GUI requires either using Electron or simulating a client-server setup with Node then it's not there yet. To illustrate, here is…
Swing is probably the wrong choice if youre going java. I do electron everyday for work and we use stdin/stdout to farm json to a Java process as well. Given the chance I would probably use JavaFX over Electron or Swing. The FX app will be easier to style than swing and Gluon just announced native compilation support via Graal for new FX apps [0]. [0] https://gluonhq.com/gluon-substrate-and-graalvm-native-image...