Looks like I missed that thread on Tildes. I can relate to that post, cause I was looking around for a cross-platform UI toolkit/library to build a desktop application. I was definitely not going...
Looks like I missed that thread on Tildes.
I can relate to that post, cause I was looking around for a cross-platform UI toolkit/library to build a desktop application.
I was definitely not going to use electron.
After trying various libraries over 2 months I kinda lost interest in the original project I was trying to build itself.
However, I thin flutter-dekstop might come out as a good toolkit for this purpose. I used dart/flutter to built a simple Android app and it was very easy to pick up and overall I was left with a nice feeling of the whole ecosystem.
A notable mention is also webview. I used the Rust bindings for it and it was fairly easy to use. I used clojurescript to build the actual UI and was able to easily interoperate between Rust and JS. I gave up on this cause I do not enjoy fiddling with CSS and JS in general. But I think this might've been what I would've gone ahead with if I did go ahead with my project.
I also wanted to give McCLIM a decent shot, but by the time I got to it, I had run out of interest in wanting to build a desktop application :(
Edit: I think imgui is also a decent option. It has quite a few language bindings. I used the bindings from Rust and CommonLisp and both seemed to work well enough. However trying to mess with OpenGL and stuff for a desktop application was a hassle I wasn't willing to deal with.
The one with the least problems is Electron, regardless of how much people in online programming circles dislike it. It has really basically just one problem: resource consumption. While every...
The one with the least problems is Electron, regardless of how much people in online programming circles dislike it. It has really basically just one problem: resource consumption. While every other framework is riddled with far more annoying issues. Easier to just pass the buck and tell your users to get some more RAM. And I don't blame them for that.
For non-production ready but interesting prospectives, when the desktop implementations of react native are finally mature.
Something like EEL for python, which is Electron but hitches a ride on the user's already installed browser so install sizes aren't large.
flutter, though you need to be comfortable with dart
I recently tried out webview and it seems to be in the same vein as electron, but a lot less resource intensive. I think sciter is another alterative similar to this, however I do not think it is...
I recently tried out webview and it seems to be in the same vein as electron, but a lot less resource intensive.
I think sciter is another alterative similar to this, however I do not think it is FOSS.
I recently built an android app using flutter/dart and it was surprisingly easy. Given that Dart syntax is heavily C-like, it is very familiar for someone comfortable with any language having C-like syntax (like Java, C#, etc). The Flutter ecosystem is also pretty nice to use.
I saw a post on /r/linux, it's interesting to see where the cause for Qt Company's blog post came from. I've always been a little edgy around QT because of its connection to The Qt Company for...
I saw a post on /r/linux, it's interesting to see where the cause for Qt Company's blog post came from.
I've always been a little edgy around QT because of its connection to The Qt Company for reasons like this. I'm curious about what'll happen if KDE winds up straight up forking QT.
Tbh at the moment KDE considers the fork a viable but unattractive threat. The great benefit for us of using Qt is the fact that we don't have to play upkeep with the toolkit, and can focus our...
Tbh at the moment KDE considers the fork a viable but unattractive threat. The great benefit for us of using Qt is the fact that we don't have to play upkeep with the toolkit, and can focus our attention more on other issues - so far we've also had a good cooperation with The Qt Company via Qt Free Foundation etc. They knew full well that we where the core providers of a lot of their code and outside of in-car entertainment systems and similar we are one of the biggest front viewing projects in Qt.
Then the Qt company thought it would get cute, got some new leadership who started kicking off a stink. The first one was with the lack of LTS for the open projects - now this one.
The reason they went from claiming we would have to bend over backwards for them to making the worlds most awkward blogpost in the history of awkward PR blogposts ("we didn't say that, and if we did, we didn't mean it. Anyone who says we did must be lying. Also we love you. Also we bought flowers for no reason") is the fact that we started to get support for free fork by some of their core customers and what started as a "oh god we can't do a fork" became a "oh we could actually totally do a fork of this".
So the Qt Company got instant karma'd essentially.
.... but at the same time - there are benefits not being in control of the toolkit
Oh sorry, yeah I should have been clearer. :) As a designer my insight in to the technical bits are not as solid as the programmers ofc but the internal discussions are (as is common in KDE, we're...
Oh sorry, yeah I should have been clearer. :)
As a designer my insight in to the technical bits are not as solid as the programmers ofc but the internal discussions are (as is common in KDE, we're a pretty anarchic bunch) fairly heated. That said most are pretty clear that Qt Company recent behaviour has to get a reality check.
From their perspective, the management at Qt Company, I can see how they can slip in to this nonsense though. I get the feeling that they see us turn up at Qt Conf, a rather shaggy bunch of freaks lost in a sea of corporate casual wear, and think "why are we catering to those bums again?". The fact that their entire tech department tend to come via us, or hell - IS us - can easily be missed if you have little to no insight in to Open Source development and how the sweaty nerd in the Star Trek t-shirt might be the core fundament in your company,
So when cash flow gets constricted, massive auto-companies etc are using their software and paying for it - having what seems like a clique of freeloaders must be a bit odd to a new management divorced from the technical realities of the project.
The fact that they seem to have assumed that they could just tell a negotiator for KDE and Qt Free at a meeting some demand and that person wouldn't immediately publicly tell the rest of the community this in a public mailing list to be debated - also paints a fairly clear picture of the divide between this new leadership-method and the company's core work and background. They seem honestly shocked that this would "slip out" and what may have been a hidden negotiation tactic turned out in to what is currently a PR disaster for them.
For me personally I am fairly certain that KDE will do well - I have a really high trust in our ability to look innocent and raise a stink if needed and if a fork is coming (chances are low, Qt Company is sort of doing that "... ah errr we're sorry. Not for anything in particular, but still very sorry for nothing like that" so they seem to get back in line) there is a good to fair chance that a massive chunk of Qt Company's clients are going with us and that the support for it would be good. Still not a great thing though since it means way more work.
Haha well good luck is all I say! I can mumble cheerily about usability patterns, visual design and icon creation - but the second you get beyond the "happy-go-lucky champ with a full set of...
Haha well good luck is all I say! I can mumble cheerily about usability patterns, visual design and icon creation - but the second you get beyond the "happy-go-lucky champ with a full set of crayons" stage I am really not your best option. :D
If you wanna deep dive though and have a good project idea that fit in to KDE community that you wanna work on I implore you to go to the KDE IRC channels etc and check on how to be included. We tend to be very much "Oh come on in, yeah just build your doomsday device in that corner next to the kitten launcher"
It's kinda annoying to see that there isn't any serious FOSS cross-platform GUI toolkit that isn't riddled with problems..
Looks like I missed that thread on Tildes.
I can relate to that post, cause I was looking around for a cross-platform UI toolkit/library to build a desktop application.
I was definitely not going to use electron.
After trying various libraries over 2 months I kinda lost interest in the original project I was trying to build itself.
However, I thin flutter-dekstop might come out as a good toolkit for this purpose. I used dart/flutter to built a simple Android app and it was very easy to pick up and overall I was left with a nice feeling of the whole ecosystem.
A notable mention is also webview. I used the Rust bindings for it and it was fairly easy to use. I used clojurescript to build the actual UI and was able to easily interoperate between Rust and JS. I gave up on this cause I do not enjoy fiddling with CSS and JS in general. But I think this might've been what I would've gone ahead with if I did go ahead with my project.
I also wanted to give McCLIM a decent shot, but by the time I got to it, I had run out of interest in wanting to build a desktop application :(
Edit: I think imgui is also a decent option. It has quite a few language bindings. I used the bindings from Rust and CommonLisp and both seemed to work well enough. However trying to mess with OpenGL and stuff for a desktop application was a hassle I wasn't willing to deal with.
I did read it a few days ago, indeed!
The one with the least problems is Electron, regardless of how much people in online programming circles dislike it. It has really basically just one problem: resource consumption. While every other framework is riddled with far more annoying issues. Easier to just pass the buck and tell your users to get some more RAM. And I don't blame them for that.
For non-production ready but interesting prospectives, when the desktop implementations of react native are finally mature.
Something like EEL for python, which is Electron but hitches a ride on the user's already installed browser so install sizes aren't large.
flutter, though you need to be comfortable with dart
I recently tried out webview and it seems to be in the same vein as electron, but a lot less resource intensive.
I think sciter is another alterative similar to this, however I do not think it is FOSS.
I recently built an android app using flutter/dart and it was surprisingly easy. Given that Dart syntax is heavily C-like, it is very familiar for someone comfortable with any language having C-like syntax (like Java, C#, etc). The Flutter ecosystem is also pretty nice to use.
I saw a post on /r/linux, it's interesting to see where the cause for Qt Company's blog post came from.
I've always been a little edgy around QT because of its connection to The Qt Company for reasons like this. I'm curious about what'll happen if KDE winds up straight up forking QT.
Tbh at the moment KDE considers the fork a viable but unattractive threat. The great benefit for us of using Qt is the fact that we don't have to play upkeep with the toolkit, and can focus our attention more on other issues - so far we've also had a good cooperation with The Qt Company via Qt Free Foundation etc. They knew full well that we where the core providers of a lot of their code and outside of in-car entertainment systems and similar we are one of the biggest front viewing projects in Qt.
Then the Qt company thought it would get cute, got some new leadership who started kicking off a stink. The first one was with the lack of LTS for the open projects - now this one.
The reason they went from claiming we would have to bend over backwards for them to making the worlds most awkward blogpost in the history of awkward PR blogposts ("we didn't say that, and if we did, we didn't mean it. Anyone who says we did must be lying. Also we love you. Also we bought flowers for no reason") is the fact that we started to get support for free fork by some of their core customers and what started as a "oh god we can't do a fork" became a "oh we could actually totally do a fork of this".
So the Qt Company got instant karma'd essentially.
.... but at the same time - there are benefits not being in control of the toolkit
Oh sorry, yeah I should have been clearer. :)
As a designer my insight in to the technical bits are not as solid as the programmers ofc but the internal discussions are (as is common in KDE, we're a pretty anarchic bunch) fairly heated. That said most are pretty clear that Qt Company recent behaviour has to get a reality check.
From their perspective, the management at Qt Company, I can see how they can slip in to this nonsense though. I get the feeling that they see us turn up at Qt Conf, a rather shaggy bunch of freaks lost in a sea of corporate casual wear, and think "why are we catering to those bums again?". The fact that their entire tech department tend to come via us, or hell - IS us - can easily be missed if you have little to no insight in to Open Source development and how the sweaty nerd in the Star Trek t-shirt might be the core fundament in your company,
So when cash flow gets constricted, massive auto-companies etc are using their software and paying for it - having what seems like a clique of freeloaders must be a bit odd to a new management divorced from the technical realities of the project.
The fact that they seem to have assumed that they could just tell a negotiator for KDE and Qt Free at a meeting some demand and that person wouldn't immediately publicly tell the rest of the community this in a public mailing list to be debated - also paints a fairly clear picture of the divide between this new leadership-method and the company's core work and background. They seem honestly shocked that this would "slip out" and what may have been a hidden negotiation tactic turned out in to what is currently a PR disaster for them.
For me personally I am fairly certain that KDE will do well - I have a really high trust in our ability to look innocent and raise a stink if needed and if a fork is coming (chances are low, Qt Company is sort of doing that "... ah errr we're sorry. Not for anything in particular, but still very sorry for nothing like that" so they seem to get back in line) there is a good to fair chance that a massive chunk of Qt Company's clients are going with us and that the support for it would be good. Still not a great thing though since it means way more work.
Haha well good luck is all I say! I can mumble cheerily about usability patterns, visual design and icon creation - but the second you get beyond the "happy-go-lucky champ with a full set of crayons" stage I am really not your best option. :D
If you wanna deep dive though and have a good project idea that fit in to KDE community that you wanna work on I implore you to go to the KDE IRC channels etc and check on how to be included. We tend to be very much "Oh come on in, yeah just build your doomsday device in that corner next to the kitten launcher"