Oh, are we having this discussion again?
If anybody's interested in the previous discussion, which (imho) was pretty darned good: https://news.ycombinator.com/item?id=13952007
Cross-Platform GUI Toolkit Trainwreck (2016)
71–80 of 177 posts
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#72What 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.
For making something absolutely HUGE like Blender or a DAW (which he uses as examples) I can't see why size makes a difference at all. It doesn't matter whether blender takes half a gig or five, or whether it starts in one second or five .
On the other hand if you make a VST plugin or a chat application THEN startup time of 0.1s instead of 1s makes a huge difference.
So I think size/startup time really is important, but I fail to see why he chooses these huge applications as examples (because for them it doesn't matter). I suppose he chose them as they were "state of the art" in terms of complexity etc - but perhaps he should look for smaller aps (such as JUCE plugins) to see the state of the art in terms of size/load time.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#73I 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…
> 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.
Yep, he did that, as stated here from TFA:
> The solution was to redraw only when needed: as a quick hack I introduced a global boolean doRedraw and set it to true only when an input event was received or the internal application state had been changed (e.g. the framebuffer had been updated). Then the drawing would only happen when doRedraw was set to true. Surely this could be done in a nicer way, but the general concept would be the same.
His issue was this...
> The second issue with text rendering was a harder nut to crack.
> I really don’t want to do a Donald E. Knuth here and spend too much time on a problem that has already been solved on the OS graphics library level in a perfectly satisfactory manner. I just want to call drawText() and be done with it!
How does Nuklear handle text rendering, layouts, fonts, etc?
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#74Earlier quoted context omitted.
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.
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)…
Quoting an article's (no doubt extensive) list of bindings for whatever library isn't a great way to start off a conversation about usable bindings in a given language. Bindings often exist, but they are not often any good.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#75Earlier 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.
FWIW, I've made a very-early-alpha thing for making cross-platform apps with Nim: https://github.com/iffy/wiish
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#76What 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.
How is 120MB in any way, shape or form "measly"? It is exactly this kind of thinking that delivered unto us the absolute monstrosities we see in the wild.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#77Earlier 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 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 what saved us.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#78To 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.
It is still a lot of work if you need advanced things then the basic widgets. Thinks where usually you need to extend existing widgets like you want an advanced datagrid/table with sortable/dragable columns, with custom item renders for some columns (like a chart widget for the Trends column). In this advanced cases you will need to create custom widgets for each platform, hope that all platform have the advanced dat…
Exactly. There's GUIs and there's GUIs.
When I've looked at libraries, I always consider how you'd implement the Visual Studio interface with them.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#79Earlier quoted context omitted.
Most of these are limited to the point of uselesness.
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)
#80One warning: if you try to implement your own gui widgets in opengl, unless you're really careful you're not going to support accessibility tools such as screenreaders or Japanese/Chinese text input at all.