Cross-Platform GUI Toolkit Trainwreck (2016) • Hacker News Board

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#41

Post by lmm » Thu, Apr 25, 2019, 1:25 PM UTC

alxlaz wrote: post #28

lmm wrote: post #11

What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.

It's not ridiculous. We write off executable size as something that's irrelevant in an age where you can get a 4 TB drive for (what most of the HN audience would consider) peanuts, but it's not just disk space budget that's affected. Larger executables also mean: - Longer start-up times (ridiculous things in 2019: a) SSD prices, b) the fact that it takes longer for an Electron todo app to load off a high-speed SSD th…

Sure. However long it takes to read 120mb off a disk (most likely less, if the application is only using some of the GTK dlls). 120mb of RAM. 120mb more to read when restoring from suspend. 120mb extra data use over your home internet connection. (I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you). It's still all irrelevant. Put a monetary or human-time value on it and compare to the cost of the application, or the development time, or a single crashing bug. Our programming culture's priorities are so far skewed from whats' actually important.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#42

Post by FraKtus » Thu, Apr 25, 2019, 1:25 PM UTC

Wyndtroy2012 wrote: post #2

Given the other applications you chose to look at, I'm surprised you didn't also look at Audacity. It uses wxWidgets, which is a nice C++ cross-platform GUI framework. It wraps native controls on each platform it supports, and also has a "Generic" variant where it draws its own. It's not very heavy as these things go, and has a nice python binding called wxPython. I'd check it out before rolling my own :)

Since many years I made a few application using wxWidgets, and the macOS part can have issues. While it's ok regarding the size of the app (in term of MB) you still drag and extensive library.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#43

Post by ashsys » Thu, Apr 25, 2019, 1:27 PM UTC

saagarjha wrote: post #3

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.

Shameless plug: https://github.com/AshampooSystems/boden We are working on providing exactly that thin native wrapper in modern C++ without much bloat.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#44

Post by [deleted] » Thu, Apr 25, 2019, 1:29 PM UTC

saagarjha wrote: post #3

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.

[deleted]

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#45

Post by FraKtus » Thu, Apr 25, 2019, 1:35 PM UTC

I think he got it wrong when he quickly ruled out IMGUI, as you can use it to create a small app with next to no dependencies. He complains that you need to redraw your GUI at 60 FPS, but this is wrong, you should be able to draw with it only when needed. I am a big fan of Nuklear. I can write a tiny C app that compiles on macOS, Windows, iOS, and Android with it. The look and feel of Nuklear can be something you don't like, however.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#46

Post by rapsey » Thu, Apr 25, 2019, 1:39 PM UTC

ausjke wrote: post #29

deathtrader666 wrote: post #5

Wonder how the author didn't come across Qt or wxWidgets in his research?

exactly, unless he really has something super special, QT should fix all his jokes. I don't use QT, but I think QT rarely has competition as far as cross-platform desktop GUI is concerned. the only true "cross-platform" alternative is electron, which is a bit bloated and slow, but vscode is built on it, along with many others and worked fine. I personally prefer electron these days.

Qt and wxwidgets pretty much force you into using C++ and maybe python.

If you have to deal with all that baggage, then you might as well go build the UI layer native.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#47

Post by FraKtus » Thu, Apr 25, 2019, 1:42 PM UTC

josteink wrote: post #40

FraKtus wrote: post #37

Earlier quoted context omitted.

He does not like Qt because a simple window with a few buttons and sliders will end a big (in term of MB) application. He did not realize that one but another reason not to like Qt is that fact that they recreate the native look on each platform it's highly inefficient on macOS.

> another reason not to like Qt is that fact that they recreate the native look on each platform it's highly inefficient on macOS. Given how everyone jumps on Electron these days, I don’t think thats a particular concern for anyone who just wants something to “simply be” cross-platform.

He complains that this creates enormous (in term of MB) application. My users sometimes have to rely on a lousy network connection to download. It can be because they are far away (China) or on a job. My users are in the event business and often have to rely on the WIFI of the hotel or the conference center.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#48

Post by cfv » Thu, Apr 25, 2019, 1:47 PM UTC

lmm wrote: post #20

[deleted] wrote: post #17

Earlier quoted context omitted.

[deleted]

> If personal storage units were given away for free, you might argue that it doesn't make sense to organize your stuff, or remove stuff you don't need anymore, and you would be wrong. The least important reason to consider is to conserve disk and bandwidth; the most important is to reduce risk by reducing surface area. Small, sleek and efficient is mostly about reducing cognitive load, even if it had it's roots in m…

The King James bible is about 4mb of UTF-8 text.

If your business code is 300k, or about 1/13 of that, then slapping a whopping 30 bibles of bullshit you will definitely not use for a 2 pane thing with a couple buttons and some renderer output on one side is not an insignificant investment.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#49

Post by vortico » Thu, Apr 25, 2019, 1:49 PM UTC

If you need native look and feel: https://github.com/andlabs/libui

If you need HTML5 canvas-style drawing: I propose building an (abstract) SVG document and render with Skia. When part of the SVG document changes, that part will be redrawn by Skia, just like an interactive SVG in your browser. Disclaimer: I haven't tested this idea.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#50

Post by astrobe_ » Thu, Apr 25, 2019, 1:51 PM UTC

blattimwind wrote: post #32

gmueckl wrote: post #19

Earlier quoted context omitted.

Well, not really. I hate on Electron not because of its size on disk, but its runtime memory footprint. Things like Skype in the background using 500MB, an Autodesk update notifier sitting silently in the tray using 350MB etc. all add up to a few GB of main memory you suddenly don't have. And these numbers are real, by the way.

It's kinda weird how little you have to do with 32 GB (!) of RAM until Windows starts to complain about not having enough free memory and you-better-close-some-applications-right-now! I remember when a 1 GB memory upgrade was something, and back then I could even play a game on 512 MB of memory and occassionally alt-tab to a web browser for cheats... nowadays a web browser on 512 MB RAM is virtually impossible. (Edit…

> nowadays a web browser on 512 MB RAM is virtually impossible.

Right now my Palemoon browser uses less than 240Mb. It is possible, just don't do stupid things (like keeping 4385972Z38947 tabs open instead of using bookmarks) or cut out a little the eye-candy and the the "geek status symbol" stuff.