Live data from Hacker News

Cross-Platform GUI Toolkit Trainwreck (2016)

blog.johnnovak.net

81–90 of 177 posts

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#81
post #63
post #58

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.

xfer means to multiply the cost of the wasted resources by the number of customers, since it is they who will have to waste those resources, not you. On the other hand the resources spent to implement the new useful feature will only be used by you, not your customers, so you do not get to multiply that.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#82
post #79

Earlier 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...

Apologies, didn't see that

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#83
post #15

Earlier 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.

I don't consider text editors that take 10,000 times the necessary resources to run without lag to be useful.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#84
We 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 on riding in our own trains.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#85
post #34

Earlier 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.

Because it is a waste of resources and an extremely good indicator (as shown by the replies to these posts) that the low standards the developers of these applications have towards their code.

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)

#86
post #67

Earlier 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.

I use the D bindings to qt regularly when I'm not using dlangui for GUI.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#87

We 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.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#88
post #87

We 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.

I agree, but we're not really talking about simple components on a screen. If that was the case, everybody would be happy to use tcl/tk, or swing or whatever.

Plus, it's not overkill when you get the browser for free.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#89

To 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.

I think this is the best option but for most it's still a lot of work. I spend far more time on the UI code of my applications than I do on the model or domain specific parts.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#90
post #12

Earlier 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

Except your users, they end up with your MBs.
Post reply on HN