3 ms·
That's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm. I would honestly pay
by Klonoar 9y ago
That's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm. I would honestly pay money to see how much effort it took to get it to this.
There's also the point I forgot to mention in my original post, which is that... if your entire app starts as a webapp, there's no sense in maintaining an entire separate Qt codebase when you could just wrap it. Standalone products like this (embedded, etc) might have an easier time justifying it, but I really don't think it hits the ease of use metric (not even touching on the fact that you then need to handle product changes across multiple codebases/teams - money doesn't absolve your, your team or your company of the inherent difficulty here).
Also, hell, the simple act of refactoring native level UI code is often more of a PITA than the HTML/CSS/JS counterpart. Native APIs need to make themselves more accessible and sexy if they want to have a chance here.
Alsoooo to just end this rant of mine, I'll point out that the OP's project shouldn't charge money for this. It's not that they're not allowed to or anything like that, but you're in no way making PyQT a viable Electron alternative if you require licensing. There's little money in building UI frameworks for this reason; the web kind of requires you to compete on free to use. There are people (regardless of your take on the matter) that don't use Qt for licensing reasons and that is a hard blocker.
- jcelerier 9y ago> That's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm. It's the norm for Qt apps since 2011 - 2012 when qml was introduced (of course, older apps use the older tech - and honestly, sometimes it makes more sense : at least all the colors, fonts, etc... will respect your desktop theme unlike "modern" toolkits). Here's how some QML code looks: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qml https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... ; as you can see, it's far from bloated (mostly due to the language being based on reactive semantics). For instance a consequent part of KDE has been rewritten in QML and more is underway with Kirigami : https://dot.kde.org/2017/01/12/kde-releases-kirigami-ui-20 https://dot.kde.org/2017/01/12/kde-releases-kirigami-ui-20
- Klonoar 9y agoI've used QML before, but I appreciate you linking a sample for anyone who's curious. Re: the matter at hand, it's cool if you don't consider that bloated. If I was using a C++ Qt codebase as the comparison point, I might think that too. However, if we're comparing it to a typical web codebase, that's an order of magnitude more dense. This also just doesn't matter in 2018, because QML could have the best documentation in the world and you'll still have trouble figuring out any issues as it doesn't have anywhere near the level of literature and/or (discoverable, not buried in some dead Linux project) open source code that the web platform does. Qt has a sexy problem, and every time it's brought up people try to claim it doesn't matter, but it does. (There's also a slew of apps (e.g, I could go pick a cryptocurrency wallet app at random...) that have been built long after 2012 and still have issues with rendering.) I'm not interested in debating KDE, since... that project stopped being relevant to me around KDE4. Nothing but wasted potential. Re: respecting a Desktop theme... I used to love ricing out my desktop too. ;P The thing is that it's an archaic viewpoint - one that you're welcome to have, but it'll increasingly be pushed down. Product design is always going to trump desktop UI customization capabilities, because one of those has money behind it and the other doesn't. I also don't know anybody who customizes their desktop chrome anymore because (in addition to companies like Apple making it next to impossible) most people use their machines through a web browser at this point. Also, let me be clear: I would love for native UI frameworks to be better. I don't particularly enjoy digging around in web codebases, but pretending that anything is else is as close to approachable as them makes it very difficult for any native UI toolkit to improve. People seem to think it's on the Web to catch up to the performance of native, but it's really the reverse - native needs to play the game how the web does or it's going to go extinct.
- jcelerier 9y ago> However, if we're comparing it to a typical web codebase, that's an order of magnitude more dense Well, I disagree. All the examples I could find, for instance in Vue.js, React, etc... had quite a bit more LOC necessary to achieve the same behaviour, when counting JS + CSS + HTML. Even with lambdas, associating a behaviour to an object is still not as nice as just doing `height: width/2` and knowning that the constraint will keep being enforced. > I'm not interested in debating KDE, since... that project stopped being relevant to me around KDE4. Nothing but wasted potential. These certainly were troubled times, but KDE5 is honestly really nice. See the latest release https://www.kde.org/announcements/plasma-5.12.0.php https://www.kde.org/announcements/plasma-5.12.0.php > The thing is that it's an archaic viewpoint - one that you're welcome to have, but it'll increasingly be pushed down. Will it ? in the contrary I find that the ricing community is more active than ever :p Ricing was a thing with e16 and blackbox when there were less than 100k linux users two decades ago. Now there are more than a hundred million... it's not going to disappear. Besides, it's sometimes a necessity. Think for instance of all the vision-problem-related enhancements that a coherent desktop theme can provide. > I also don't know anybody who customizes their desktop chrome anymore www.reddit.com/r/unixporn
- infinite8s 9y agoHere's another example of a UI built in PyQt: https://pbs.twimg.com/media/Cyji3jRWIAA2LRY.jpg:large https://pbs.twimg.com/media/Cyji3jRWIAA2LRY.jpg:large