Earlier quoted context omitted.
All that multiplied by the number of customers. If you don't value your customers, then they are all "irrelevant". > Our programming culture's priorities are so far skewed from whats' actually important. Indeed, that's why there are so many electron based bloatware being developed.
All development effort is multiplied by number of customers though. Like, if you put that time and effort into developing a new useful feature, the value of that is multiplied by number of customers too.
Cross-Platform GUI Toolkit Trainwreck (2016)
81–90 of 177 posts
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#82Earlier quoted context omitted.
I ship nontrivial PyQt apps. PyQt can basically do anything Qt can do. Multiple inheritance of QWidgets can be dicey, but desired results can usually be achieved by defining mixins that don't subclass QWidget. It works brilliantly, far from "the point of uselessness". For me, cross platform GUIs are a solved problem, and I really can't wrap my head around all the noise to the contrary, or the claims that electron is…
Yeah that is why I said C++ and python...
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#83Earlier quoted context omitted.
This sort of "who cares" thinking gives us lazy bloatware like Electron.
AKA useful software that actually does something users want, rather than some kind of ascetic practice exercise. Yes, yes it does.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#84Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window.
We shouldn't need Electron at all! It's like we all have this fantastic rail transport network but insist on riding in our own trains.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#85Earlier quoted context omitted.
120 MB would be enough for me to choose an alternative to your application.
Why? There are computers older than I am for which that's an insignificant amount.
As an example (which i like to point out, but also sad to note that it is only a minority, showing the state of modern desktop software) i bought Total Commander exactly because of how small, lightweight and responsive it is (the entire installation is 14MB, the application itself uses at this moment 3.5MB of RAM - although often goes up to 8MB, depending on what i'm doing and how many tabs i have open - which btw is around 5 times more than the Windows 10 calculator!) while providing a ton of functionality (...certainly more than a calculator :-P). And it isn't like it was written in direct oh-so-hard-to-use pure Win32 API either, the 32bit version is written in Delphi which has a very rich framework and the 64bit version is written in Lazarus (which is pretty much an open source Delphi) and beyond those it uses several additional libraries. It just didn't make choices that were wasteful from the start.
So here is a case of someone making money (from me, but also others since its lightness and power are pretty much what everyone cites about it) explicitly because they cared about their program's resource usage.
I just really really wish more desktop software would do the same. Sadly it only goes in the opposite direction.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#86Earlier quoted context omitted.
Huh? https://wiki.qt.io/Language_Bindings 5.1 Qt for Python (PyQt) 5.2 Qt for Ring (RingQt) 5.3 Qt for Rust (Rust-Qt) 5.4 Qt Quick for Rust (qml-rust) 5.5 Qt Quick for Rust (qmlrs) 5.6 Qt for Crystal (qt5.cr) 5.7 Qt for Go (qt) 5.8 Qt for C#/Mono/.Net (QtSharp) 5.9 Qt for C#/Mono/.Net (Qml.Net) 5.10 Qt for D (QtE5) 5.11 Qt for Haskell (qtHaskell) 5.12 Qtah 5.13 Qt for Julia (QML.jl) 5.14 Qt Quick for Haskell (HsQML)…
Most of these are limited to the point of uselesness.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#87We already have browsers installed that are designed to render arbitrary cross-platform GUIs based on HTML/CSS. Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window. We shouldn't need Electron at all! It's like we all have this fantastic rail transport network but insist o…
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#88We already have browsers installed that are designed to render arbitrary cross-platform GUIs based on HTML/CSS. Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window. We shouldn't need Electron at all! It's like we all have this fantastic rail transport network but insist o…
Why do I need a browser just to show components on a screen? It's overkill to do that.
Plus, it's not overkill when you get the browser for free.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#89To date, the best solution to this problem that I have seen is to write all your core code in a shared library using something like C++, and then hooking it up to a thin layer of completely native, platform-specific code for the UI. It’s fast, lightweight, looks good, and requires minimal extra code if you do it right.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#90Earlier quoted context omitted.
He jokingly mentions Qt in the caption of the final picture. I guess since he excludes GTK2 at the beginning for size concerns, wxWidgets and Qt would fall into the same category.
> He jokingly mentions Qt in the caption of the final picture. well, he can keep joking and I can keep shipping Qt apps and everyone's happy