Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cross-Platform GUI Toolkit Trainwreck (2016)

blog.johnnovak.net

Post reply on HN
Print view View original

51–60 of 177 posts

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#51

Post by bunderbunder »

glangdale wrote: post #21
deathtrader666 wrote: post #5

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

I have the same question. There are many things that are problematic about Qt (personally, I loathe anything that feels the need to interject itself in the middle of the build process) but to completely ignore Qt without explanation - and subsequently post detailed experiences with libraries I've never even heard of - led me to believe the author exists in some uninteresting-to-me parallel plane of existence.

There was plenty of explanation for me when I first encountered this article (in the context of trying to solve the same problem):

> what cross-platform libraries are available for Nim!

Things might have changed over the past couple years, but, at least at the time, there weren't any (usable) Nim bindings for either.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#53

Post by zerr »

ashsys wrote: post #43
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.

Are you associated with https://www.ashampoo.com ?

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#54

Post by lmm »

cfv wrote: post #48
lmm wrote: post #20

Earlier quoted context omitted.

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

Why? Is a medieval scribe hand-copying your GUI libraries?

A bible costs maybe $15, which is about 60GB's worth of storage - that seems like a more relevant comparison.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#55

Post by glangdale »

bunderbunder wrote: post #51
glangdale wrote: post #21

Earlier quoted context omitted.

I have the same question. There are many things that are problematic about Qt (personally, I loathe anything that feels the need to interject itself in the middle of the build process) but to completely ignore Qt without explanation - and subsequently post detailed experiences with libraries I've never even heard of - led me to believe the author exists in some uninteresting-to-me parallel plane of existence.

There was plenty of explanation for me when I first encountered this article (in the context of trying to solve the same problem): > what cross-platform libraries are available for Nim! Things might have changed over the past couple years, but, at least at the time, there weren't any (usable) Nim bindings for either.

Fair enough, but I think that the onus of proof is on the weird-language-user here. That is, a discussion of how cross-platform GUI toolkits are a 'trainwreck' takes on a different vibe if you're insisting on using Nim or Left-Handed Pure Phenomenological Haskell or the like.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#56

Post by ashsys »

zerr wrote: post #53
ashsys wrote: post #43

Earlier quoted context omitted.

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

Are you associated with https://www.ashampoo.com ?

Yes we are a subsidiary of https://www.ashampoo.com

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#57

Post by tpush »

weberc2 wrote: post #10
panemic wrote: post #6

Earlier quoted context omitted.

By personal experience, wxWindows is "OK", but it's not a panacea. There are a ton of little quirks that will burn you when doing cross-platform development simply because native controls do not behave in the same way. HiDpi is a major pain with wxWindows (but then again, the way HiDpi is managed is a pain irrespective of the toolkit). But if you do some forms and basic UI controls, wxWindows does the job egregiously…

Why does electron have broken text rendering? Surely the Chrome browser’s tendering does a good job? Or do you mean something like “it doesn’t match system defaults”?

Visual Studio Code on macOS right now has broken font rendering, since it uses Skia via Electron instead of macOS' native font rendering.

It's fixed in upstream Electron but until a fixed version is integrated into VSCode I have to live with (months of) broken font rendering.

It even makes me want to use Xcode somewhat. For all its flaws, its font rendering is just the system (working) one, and scrolling in Xcode is actually smooth 60fps instead of the laggy mess that is VSCode.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#58

Post by xfer »

lmm wrote: post #41
alxlaz wrote: post #28

Earlier quoted context omitted.

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 hum…

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.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#59

Post by ComputerGuru »

panemic wrote: post #6
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 :)

By personal experience, wxWindows is "OK", but it's not a panacea. There are a ton of little quirks that will burn you when doing cross-platform development simply because native controls do not behave in the same way. HiDpi is a major pain with wxWindows (but then again, the way HiDpi is managed is a pain irrespective of the toolkit). But if you do some forms and basic UI controls, wxWindows does the job egregiously…

I have filed numerous bug reports about Chrome's broken text rendering and hinting and had them closed as won't fix because they're too difficult to fix (note: not too difficult to reproduce, just too difficult to fix). I can't believe how low priority the correct displaying of the most important content in the window is to web browser developers.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#60

Post by cfv »

lmm wrote: post #54
cfv wrote: post #48

Earlier quoted context omitted.

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.

Why? Is a medieval scribe hand-copying your GUI libraries? A bible costs maybe $15, which is about 60GB's worth of storage - that seems like a more relevant comparison.

You miss the point.

And you are missing it because you're OK with jamming your code right inside 400 times more foreign code in order to display a cute window with two panes in it.

Do please make a civil effort to understand there's people who are not ok with it. People like OP, who feels devoting 47 bibles of code to displaying a taskbar widget is not OK.

Or like me, who actually likes to know exactly what is my code doing.

Post reply on HN