16 ms·

Cross-Platform GUI Toolkit Trainwreck (2016)

167 points by aparashk 7y ago

FraKtus 7y ago
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.
- ScottFree 7y ago
  > 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?
  - FraKtus 7y ago
    He speaks about the 60 FPS when he tried NanoVG... I think he did not realize he could do that trick with IMGUI. For text rendering with Nuklear, you make a font atlas from a true type font, rasterizing the font is built in Nuklear with stb_truetype. That gives you a lot of freedom. You can load as many fonts as you need. There is also support to load a binary resource such as the TTF file from a base85 string; it's very handy. For layout it's immediate mode, so you describe it with code such as nk_layout_row_dynamic(ctx, (float) row_height, 3); // a row of 3 buttons if (nk_button_label(ctx, "Previous")) ... if (nk_button_label(ctx, "Next")) ... Here is small app I made with Nuklear: https://www.youtube.com/watch?v=MycIYcutlMA https://www.youtube.com/watch?v=MycIYcutlMA
vortico 7y ago
If you need native look and feel: https://github.com/andlabs/libui 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.
Wyndtroy2012 7y ago
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 :)
- panemic 7y ago
  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. Looks the way it should be on all platforms. It's funny an article from 2016 mentions issues about text rendering, because certainly we've been regressing in this area. I can spot QML and Electron apps by the broken text rendering alone. FF60+ with quantum has incorrect subpixel hinting and does not correctly hint at all sometimes. Many of the mentioned apps int the article are "broken" in my eyes: I don't have perfect vision, and I do expect apps to follow the system text scaling (and they don't). For a "broken by design" example, see Darktable, which is awesome, and should do this by default, but the authors hard-coded a theme where literally every widget is styled for looks and not for function. Nobody speaks about how the widgets should feel and interact, but that's exactly what feels off about "GTK" on windows or macos. QML, Electron and partly GTK3 brings that feeling to all platforms. My biggest letdown is QML, as many QT developers see it as the future so it has a larger adoption than it should have. It breaks just about any rule in the book: poor behavior on any platform, noticeably slower, style not consistent with the platform, broken scrolling, broken text editing, broken text rendering...
  - edraferi 7y ago
    > But if you do some forms and basic UI controls, wxWindows does the job egregiously. Looks the way it should be on all platforms. Word choice? "Egregiously" means "Conspicuously bad or offensive." [0] The context suggests you intended to say "adequate for the purpose," for which "competently" is the correct term.[1] [0] https://www.thefreedictionary.com/egregiously https://www.thefreedictionary.com/egregiously [1] https://www.thefreedictionary.com/competently https://www.thefreedictionary.com/competently
saagarjha 7y ago
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.
- ashsys 7y ago
  Shameless plug: https://github.com/AshampooSystems/boden https://github.com/AshampooSystems/boden We are working on providing exactly that thin native wrapper in modern C++ without much bloat.
  - zerr 7y ago
    Are you associated with https://www.ashampoo.com https://www.ashampoo.com ?
    - ashsys 7y ago
      Yes we are a subsidiary of https://www.ashampoo.com https://www.ashampoo.com
  - holy_city 7y ago
    Do you guys plan on supporting desktop apps or are you sticking with mobile?
    - ashsys 7y ago
      For the first release we are sticking with Mobile, but Desktop is "next on the list". ( And there is rudimentary macOS support right now )
  - slezyr 7y ago
    I can make a GUI in Qt and it will work on android, but I developed a simple time and there was a huge problem. When device goes to sleep it don't runs any code in background and I couldn't play or do anything on timeout. Does your framework solves any problem?
deathtrader666 7y ago
Wonder how the author didn't come across Qt or wxWidgets in his research?
- ekingr 7y ago
  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.
  - jcelerier 7y ago
    > 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
    - amelius 7y ago
      Except your users, they end up with your MBs.
      - marvinalone 7y ago
        I ship a Qt app. The installer is 135MB. 90MB of that is a demo video that comes with it. Nobody has ever complained.
      - jcelerier 7y ago
        yes, those poor users who end up with 70 megabytes to download, for something that comes with a large part of Qt, LLVM, libclang, multiple programming language implementation, support for plenty of network protocols... And I haven't even optimized what's inside the release package. ( https://github.com/OSSIA/score/releases https://github.com/OSSIA/score/releases)
  - joezydeco 7y ago
    Making a Qt app smaller would mean statically compiling the app and stripping the libraries but, hey, there’s an angry blog post that needs to get written.
oblio 7y ago
For the Java bit, I imagine that with modern Java versions with modules the app would be a lot smaller. The new Java versions are modular so you can include just what you use and I think it can even create a native package for installation. It should bring NodeNox 3 down from that 220MB package.
lmm 7y ago
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.
- krageon 7y ago
  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.
- badsectoracula 7y ago
  This sort of "who cares" thinking gives us lazy bloatware like Electron.
  - lmm 7y ago
    AKA useful software that actually does something users want, rather than some kind of ascetic practice exercise. Yes, yes it does.
    - gmueckl 7y ago
      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.
      - Justsignedup 7y ago
        That's kinda the fault of the developer. Electron itself isn't very large and I've seen very well crafted electron apps. The fact that slack uses 1-2gb memory is definitely on slack.
      - 7y ago
_pmf_ 7y ago
Oh, are we having this discussion again?
- ScottFree 7y ago
  If anybody's interested in the previous discussion, which (imho) was pretty darned good: https://news.ycombinator.com/item?id=13952007 https://news.ycombinator.com/item?id=13952007
awalton 7y ago
"GTK2 is too big" "Just use Java or Electron" I'm sorry, I just can't reconcile the logic here.
Timothycquinn 7y ago
These days, Xamarin looks interesting. Can target windows, Linux, Mac, Android and IOS. I have not used it yet but if I get a project that needs full Cross platform distribution, I would probably use xamarin with a F# code base where possible.
resoluteteeth 7y ago
One 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.
- AnIdiotOnTheNet 7y ago
  If people cared about those things they wouldn't be making crappy webapps with custom look n feel and no accessibility.
almostarockstar 7y ago
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.
- monksy 7y ago
  Why do I need a browser just to show components on a screen? It's overkill to do that.
  - almostarockstar 7y ago
    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.
    - rkeene2 7y ago
      Well, I'm happy to use Tcl/Tk -- although using it on a mobile device doesn't result in a usable touch-based interface. Really, that's the crux of the problem is that there are different paradigms that are not just a little bit different but fundamentally different. This is especially annoying on my Chromebook running Android apps -- they very often expect you to be using a touch-based system without a keyboard. The way this works with a docked Chromebook and a mouse is the mouse is treated as a VERY precise finger touch. Additionally, on Android and other touch-based systems you're usually not using a Window Manager so, for example, using an Android mail client on my Chromebook, I can't start the reply in a new window so that I can read the message in one window while simultaneously replying... and I especially can't have a bunch of unfinished replies while reading other emails to gather information for the reply. Creating a meta-layer that can represent the fundamentally different modes from the same data is VERY difficult. HTML and CSS do a terrible job as well unless you model your HTML in a very specific way, which cannot accommodate all GUI semantics.
hguhghuff 7y ago
Anyone got experience with this? https://webkit.org/wpe/ https://webkit.org/wpe/ Here it is in use on raspberry pi https://medium.com/@decrocksam/building-wpe-webkit-for-raspberry-pi-3-cdbd7b5cb362 https://medium.com/@decrocksam/building-wpe-webkit-for-raspb... A long video on it: https://m.youtube.com/watch?v=klfE6m1oCkg https://m.youtube.com/watch?v=klfE6m1oCkg A short video on it: https://m.youtube.com/watch?v=wVSwkj9McCU https://m.youtube.com/watch?v=wVSwkj9McCU It says: "WPE is the reference WebKit port for embedded and low-consumption computer devices. It has been designed from the ground-up with performance, small footprint, accelerated content rendering, and simplicity of deployment in mind, bringing the excellence of the WebKit engine to countless platforms and target devices." I'd be interested to know how to use it.
phtrivier 7y ago
So many sub-debates hidden in this "cross-platform native GUI": 1) I want to write a GUI code once 2) I want to ship something that works on Windows / Linux / MacOS 2.1) I want to ship something that looks the same on Windows / Linux / MacOS 3) I want to ship a binary that works on Windows, a binary that works on Linux, a binary that works 3.1) I want to ship a small and efficient binary 4) I want to ship something that looks like a Windows app on Windows, a Linux app on Linux, a MacOS app on MacOS, etc... (By definition, "I want to ship something that looks the same everywhere and looks like an app of my host" is meaningless, right ?) The "holy grail" seems to be: 5) "I want to write a GUI code once that generates small efficient binaries that looks exactly like an app of the host OS, and if possible looks the same everywhere, and let me go back to writing my business logic rather than agonize over drawing a button." It's seems from the debate that nothing obvious fulfills 4 and 5. Then it comes to which requirement you're ready to drop. If you're ready to drop requirement 2) , I suspect you're doing MacOS specific, go for it ;) If you're ready to drop requirement 1) , I suspect your managers / salespersons disagree. I suspect your manager / salespersons do not care about requirement 3.1), but it's debatable. Use Qt/Electron, and ship something. I suspect your manager / salespersons do not care about requirement 4), and I suspect they're esthetics, which can not be defended. I gave up waiting for someone to make 5, and don't have the resources / skill / time to do it myself. And maybe we should stop caring and watch the sky instead. I hope someone is able to get to 1 + 2.1 + 3.1 someday. I'll use that.
- afturner 7y ago
  This is a particularly good summary, thanks for that. At the end of the day, the only way for 5 to happen, is for a development project to architect the requirements and complexities way before even starting to code.
- amedvednikov 7y ago
  I'm working on something that might do #4 and #5: https://vlang.io/#ui https://vlang.io/#ui An example of a small GUI app: https://github.com/vlang/v/tree/master/examples/users_gui https://github.com/vlang/v/tree/master/examples/users_gui The app is about 100 KB on all platforms with zero dependencies and uses native toolkits (WinAPI, Cocoa).
TJSomething 7y ago
To add a little data on my experience last time I tried this, using UPX [0], you can get GTK+ 3 down to 9 MB. Most of the size of Qt comes from ICU, which can be feature selected to decrease its size [1]. With that and UPX, Qt can get down to 16 MB. And those can both be compressed another 30% with ZIP files for shipping. While those aren't great numbers, I personally think it's tolerable for most usages. [0] https://upx.github.io/ https://upx.github.io/ [1] https://ssl.icu-project.org/datacustom/index.html https://ssl.icu-project.org/datacustom/index.html
_bxg1 7y ago
Mostly good article, but I don't appreciate the gratuitous dunking on web devs towards the bottom: "so developers can use hipster technologies like HTML, CSS and JavaScript" "the vast armies of newskool web developers who grew up on JavaScript and the DOM" ...especially when the author doesn't really appear to know what he's talking about in that space: "And when things don’t quite work as expected, you can’t do much about it—short of maybe just switching to a different framework as a last attempt." "and long-term maintenance will be a nightmare." "web development technologies—which technically don’t provide any advantages over more traditional approaches" There are legitimate criticisms of Electron as a choice for desktop apps, but that doesn't invalidate an entire domain's worth of developers.
- _bxg1 7y ago
  In reality, JavaScript in 2019 on V8 - thanks to innovations like JIT compiling - is in almost the same ballpark as Java itself when it comes to performance. JavaScript itself is not what slows down JavaScript UIs. What does slow down Web UIs is the DOM (whose rendering engine in Chromium is written in C++). The DOM is the most advanced layout engine ever created. It does an unbelievable amount of work to make interfaces resizable-by-default and adaptable-by-default, and yet is enormously flexible, allowing one to build virtually any box-based interface imaginable. This isn't simply so newcomers have an easier time. It frees application code to focus on the control logic and the structural side of the view, instead of messing with things like pixels and manual sizing, which makes application code more maintainable and reusable. I can place a piece of DOM in wildly different contexts, with wildly different amounts and types of content, and for the most part it will just respond as expected. This significantly reduces code complexity, which improves long-term maintainability and avoids bugs. This of course comes with a cost. All of those implicit layout adjustments have overhead. The ability for your code to handle content you never thought it would encounter requires CPU time. That cost isn't worth it for certain applications. But it isn't a waste, or a sign of the moral decline of "kids these days". It's a conscious tradeoff that any good developer can weigh and consider for what it is.
vram22 7y ago
Adding my 2c (of anecdote) to this thread: Andy Brice of successfulsoftware.net has a long-time product, Perfect Table Plan (computes seating plan for weddings, given various inputs) that used Qt (and C++), I've read, on his blog. PTP has been there for years now. Seems to be doing well, based on what he says about it. Don't know how good the Windows vs. Mac versions are, but at least they are there. His newer product HyperPlan may also be on the same stack. https://www.perfecttableplan.com/html/about_us.html https://www.perfecttableplan.com/html/about_us.html No connection, just have followed the blog for long.
dysoco 7y ago
I know the author focused on Nim, but I wonder how Lazarus (or Delphi I guess) would fare. Sadly it's FreePascal, but it really does look like the less bullshit platform to make cross-platform desktop applications.
- lbruder 7y ago
  Delphi was, and Lazarus is, amazingly well designed. Lazarus comes pretty close to a Swiss army GUI tool, and once you get to know it a little better, Object Pascal is actually a very nice language that rivals C++ (!) in power. It's still my secret weapon at work. If only the docs were better. Still keeping around a VM with Delphi 7 from 1999 just because documentation was sooo good then.
NikGeeonx 7y ago
I like the idea of having one c-sourcecode compiling on Linux, macOS and Windows. Hence, I have developed a platform independet GUI called Geeonx https://www.geeonx.org https://www.geeonx.org . Versions for Linux and MacOS X are ready for download. The version for Windows will follow soon - I will speed up development if someone claps in his hands.
paulcarroty 7y ago
https://proton-native.js.org/ https://proton-native.js.org/
ryanmarsh 7y ago
This is exactly why I say Electron is going to “win” in the cross platform GUI toolkit space. I do not think this is good thing. Cross platform GUI dev has been a train wreck as far back as I can remember. Contrast that with the immense amount of human years invested in making the browser a cross platform GUI runtime. I’m sorry folks, 198MB menu bar apps is what we’re going to have unless a cross platform GUI effort equivalent to that of Chromium comes about.
patrickg_zill 7y ago
I am looking into doing some small projects for those I work with... Am seriously considering going to either text only (as in you have to ssh to a Linux server and run the app) or using Zenity and shell scripts for the front end.
analognoise 7y ago
FreePascal/Lazarus : cross platform native GUIs out of the box. Super small executables. No bloat. For the love of God, check it out.
netrap 7y ago
Weird article. Why write an entire cross-platform GUI toolkit when he could port IUP to OS X? :)
ianharrigan 7y ago
Hi all, one option might be HaxeUI (full disclosure, im the author!) :) Its essentially a UI abstraction that delegates certain things "backends" site: http://haxeui.org/ http://haxeui.org/ github: https://github.com/haxeui/haxeui-core https://github.com/haxeui/haxeui-core discourse: https://community.haxeui.org/ https://community.haxeui.org/ It uses the Haxe language (haxe.org), here is a very small/simple/dumb sample of it "in action": https://www.youtube.com/watch?v=cijUTbMKMHI https://www.youtube.com/watch?v=cijUTbMKMHI It can use native components (wxWidgets, android, html5) but you can fairly easily extend it to use other "backends" (like Qt for example - i havent written that backend yet, but its something ill almost certainly do)... It can also handle drawing the components in a variety of methods (so called "composite backends"). Im currently aiming to get it out of alpha asap, and most work goes into "new-component-method" branches (these will become master shortly). Documentation is pretty slim at the moment, but something im actively working on, two examples that i just wrote up today in fact are: https://github.com/haxeui/haxeui-guides/blob/master/custom-components.md https://github.com/haxeui/haxeui-guides/blob/master/custom-c... and https://github.com/haxeui/haxeui-guides/blob/master/modules.md https://github.com/haxeui/haxeui-guides/blob/master/modules.... Let me know if you have any questions! Ian Harrigan Heres some other links / screens that may be useful: https://twitter.com/IanHarrigan1982/status/1111348116433850368 https://twitter.com/IanHarrigan1982/status/11113481164338503... https://twitter.com/IanHarrigan1982/status/1090535390598041600 https://twitter.com/IanHarrigan1982/status/10905353905980416...

167 points by aparashk 7y ago

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.

ScottFree 7y ago
> 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?
- FraKtus 7y ago
  He speaks about the 60 FPS when he tried NanoVG... I think he did not realize he could do that trick with IMGUI. For text rendering with Nuklear, you make a font atlas from a true type font, rasterizing the font is built in Nuklear with stb_truetype. That gives you a lot of freedom. You can load as many fonts as you need. There is also support to load a binary resource such as the TTF file from a base85 string; it's very handy. For layout it's immediate mode, so you describe it with code such as nk_layout_row_dynamic(ctx, (float) row_height, 3); // a row of 3 buttons if (nk_button_label(ctx, "Previous")) ... if (nk_button_label(ctx, "Next")) ... Here is small app I made with Nuklear: https://www.youtube.com/watch?v=MycIYcutlMA https://www.youtube.com/watch?v=MycIYcutlMA

vortico 7y ago

If you need native look and feel: https://github.com/andlabs/libui 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.

Wyndtroy2012 7y ago

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 :)

panemic 7y ago
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. Looks the way it should be on all platforms. It's funny an article from 2016 mentions issues about text rendering, because certainly we've been regressing in this area. I can spot QML and Electron apps by the broken text rendering alone. FF60+ with quantum has incorrect subpixel hinting and does not correctly hint at all sometimes. Many of the mentioned apps int the article are "broken" in my eyes: I don't have perfect vision, and I do expect apps to follow the system text scaling (and they don't). For a "broken by design" example, see Darktable, which is awesome, and should do this by default, but the authors hard-coded a theme where literally every widget is styled for looks and not for function. Nobody speaks about how the widgets should feel and interact, but that's exactly what feels off about "GTK" on windows or macos. QML, Electron and partly GTK3 brings that feeling to all platforms. My biggest letdown is QML, as many QT developers see it as the future so it has a larger adoption than it should have. It breaks just about any rule in the book: poor behavior on any platform, noticeably slower, style not consistent with the platform, broken scrolling, broken text editing, broken text rendering...
- edraferi 7y ago
  > But if you do some forms and basic UI controls, wxWindows does the job egregiously. Looks the way it should be on all platforms. Word choice? "Egregiously" means "Conspicuously bad or offensive." [0] The context suggests you intended to say "adequate for the purpose," for which "competently" is the correct term.[1] [0] https://www.thefreedictionary.com/egregiously https://www.thefreedictionary.com/egregiously [1] https://www.thefreedictionary.com/competently https://www.thefreedictionary.com/competently

saagarjha 7y ago

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.

ashsys 7y ago
Shameless plug: https://github.com/AshampooSystems/boden https://github.com/AshampooSystems/boden We are working on providing exactly that thin native wrapper in modern C++ without much bloat.
- zerr 7y ago
  Are you associated with https://www.ashampoo.com https://www.ashampoo.com ?
  - ashsys 7y ago
    Yes we are a subsidiary of https://www.ashampoo.com https://www.ashampoo.com
- holy_city 7y ago
  Do you guys plan on supporting desktop apps or are you sticking with mobile?
  - ashsys 7y ago
    For the first release we are sticking with Mobile, but Desktop is "next on the list". ( And there is rudimentary macOS support right now )
- slezyr 7y ago
  I can make a GUI in Qt and it will work on android, but I developed a simple time and there was a huge problem. When device goes to sleep it don't runs any code in background and I couldn't play or do anything on timeout. Does your framework solves any problem?

deathtrader666 7y ago

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

ekingr 7y ago
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.
- jcelerier 7y ago
  > 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
  - amelius 7y ago
    Except your users, they end up with your MBs.
    - marvinalone 7y ago
      I ship a Qt app. The installer is 135MB. 90MB of that is a demo video that comes with it. Nobody has ever complained.
    - jcelerier 7y ago
      yes, those poor users who end up with 70 megabytes to download, for something that comes with a large part of Qt, LLVM, libclang, multiple programming language implementation, support for plenty of network protocols... And I haven't even optimized what's inside the release package. ( https://github.com/OSSIA/score/releases https://github.com/OSSIA/score/releases)
- joezydeco 7y ago
  Making a Qt app smaller would mean statically compiling the app and stripping the libraries but, hey, there’s an angry blog post that needs to get written.

oblio 7y ago

For the Java bit, I imagine that with modern Java versions with modules the app would be a lot smaller. The new Java versions are modular so you can include just what you use and I think it can even create a native package for installation. It should bring NodeNox 3 down from that 220MB package.

lmm 7y ago

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.

krageon 7y ago
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.
badsectoracula 7y ago
This sort of "who cares" thinking gives us lazy bloatware like Electron.
- lmm 7y ago
  AKA useful software that actually does something users want, rather than some kind of ascetic practice exercise. Yes, yes it does.
  - gmueckl 7y ago
    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.
    - Justsignedup 7y ago
      That's kinda the fault of the developer. Electron itself isn't very large and I've seen very well crafted electron apps. The fact that slack uses 1-2gb memory is definitely on slack.
    - 7y ago

_pmf_ 7y ago

Oh, are we having this discussion again?

ScottFree 7y ago
If anybody's interested in the previous discussion, which (imho) was pretty darned good: https://news.ycombinator.com/item?id=13952007 https://news.ycombinator.com/item?id=13952007

awalton 7y ago

"GTK2 is too big" "Just use Java or Electron" I'm sorry, I just can't reconcile the logic here.

Timothycquinn 7y ago

These days, Xamarin looks interesting. Can target windows, Linux, Mac, Android and IOS. I have not used it yet but if I get a project that needs full Cross platform distribution, I would probably use xamarin with a F# code base where possible.

resoluteteeth 7y ago

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

AnIdiotOnTheNet 7y ago
If people cared about those things they wouldn't be making crappy webapps with custom look n feel and no accessibility.

almostarockstar 7y ago

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.

monksy 7y ago
Why do I need a browser just to show components on a screen? It's overkill to do that.
- almostarockstar 7y ago
  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.
  - rkeene2 7y ago
    Well, I'm happy to use Tcl/Tk -- although using it on a mobile device doesn't result in a usable touch-based interface. Really, that's the crux of the problem is that there are different paradigms that are not just a little bit different but fundamentally different. This is especially annoying on my Chromebook running Android apps -- they very often expect you to be using a touch-based system without a keyboard. The way this works with a docked Chromebook and a mouse is the mouse is treated as a VERY precise finger touch. Additionally, on Android and other touch-based systems you're usually not using a Window Manager so, for example, using an Android mail client on my Chromebook, I can't start the reply in a new window so that I can read the message in one window while simultaneously replying... and I especially can't have a bunch of unfinished replies while reading other emails to gather information for the reply. Creating a meta-layer that can represent the fundamentally different modes from the same data is VERY difficult. HTML and CSS do a terrible job as well unless you model your HTML in a very specific way, which cannot accommodate all GUI semantics.

hguhghuff 7y ago

Anyone got experience with this? https://webkit.org/wpe/ https://webkit.org/wpe/ Here it is in use on raspberry pi https://medium.com/@decrocksam/building-wpe-webkit-for-raspberry-pi-3-cdbd7b5cb362 https://medium.com/@decrocksam/building-wpe-webkit-for-raspb... A long video on it: https://m.youtube.com/watch?v=klfE6m1oCkg https://m.youtube.com/watch?v=klfE6m1oCkg A short video on it: https://m.youtube.com/watch?v=wVSwkj9McCU https://m.youtube.com/watch?v=wVSwkj9McCU It says: "WPE is the reference WebKit port for embedded and low-consumption computer devices. It has been designed from the ground-up with performance, small footprint, accelerated content rendering, and simplicity of deployment in mind, bringing the excellence of the WebKit engine to countless platforms and target devices." I'd be interested to know how to use it.

phtrivier 7y ago

So many sub-debates hidden in this "cross-platform native GUI": 1) I want to write a GUI code once 2) I want to ship something that works on Windows / Linux / MacOS 2.1) I want to ship something that looks the same on Windows / Linux / MacOS 3) I want to ship a binary that works on Windows, a binary that works on Linux, a binary that works 3.1) I want to ship a small and efficient binary 4) I want to ship something that looks like a Windows app on Windows, a Linux app on Linux, a MacOS app on MacOS, etc... (By definition, "I want to ship something that looks the same everywhere and looks like an app of my host" is meaningless, right ?) The "holy grail" seems to be: 5) "I want to write a GUI code once that generates small efficient binaries that looks exactly like an app of the host OS, and if possible looks the same everywhere, and let me go back to writing my business logic rather than agonize over drawing a button." It's seems from the debate that nothing obvious fulfills 4 and 5. Then it comes to which requirement you're ready to drop. If you're ready to drop requirement 2) , I suspect you're doing MacOS specific, go for it ;) If you're ready to drop requirement 1) , I suspect your managers / salespersons disagree. I suspect your manager / salespersons do not care about requirement 3.1), but it's debatable. Use Qt/Electron, and ship something. I suspect your manager / salespersons do not care about requirement 4), and I suspect they're esthetics, which can not be defended. I gave up waiting for someone to make 5, and don't have the resources / skill / time to do it myself. And maybe we should stop caring and watch the sky instead. I hope someone is able to get to 1 + 2.1 + 3.1 someday. I'll use that.

afturner 7y ago
This is a particularly good summary, thanks for that. At the end of the day, the only way for 5 to happen, is for a development project to architect the requirements and complexities way before even starting to code.
amedvednikov 7y ago
I'm working on something that might do #4 and #5: https://vlang.io/#ui https://vlang.io/#ui An example of a small GUI app: https://github.com/vlang/v/tree/master/examples/users_gui https://github.com/vlang/v/tree/master/examples/users_gui The app is about 100 KB on all platforms with zero dependencies and uses native toolkits (WinAPI, Cocoa).

TJSomething 7y ago

To add a little data on my experience last time I tried this, using UPX [0], you can get GTK+ 3 down to 9 MB. Most of the size of Qt comes from ICU, which can be feature selected to decrease its size [1]. With that and UPX, Qt can get down to 16 MB. And those can both be compressed another 30% with ZIP files for shipping. While those aren't great numbers, I personally think it's tolerable for most usages. [0] https://upx.github.io/ https://upx.github.io/ [1] https://ssl.icu-project.org/datacustom/index.html https://ssl.icu-project.org/datacustom/index.html

_bxg1 7y ago

Mostly good article, but I don't appreciate the gratuitous dunking on web devs towards the bottom: "so developers can use hipster technologies like HTML, CSS and JavaScript" "the vast armies of newskool web developers who grew up on JavaScript and the DOM" ...especially when the author doesn't really appear to know what he's talking about in that space: "And when things don’t quite work as expected, you can’t do much about it—short of maybe just switching to a different framework as a last attempt." "and long-term maintenance will be a nightmare." "web development technologies—which technically don’t provide any advantages over more traditional approaches" There are legitimate criticisms of Electron as a choice for desktop apps, but that doesn't invalidate an entire domain's worth of developers.

_bxg1 7y ago
In reality, JavaScript in 2019 on V8 - thanks to innovations like JIT compiling - is in almost the same ballpark as Java itself when it comes to performance. JavaScript itself is not what slows down JavaScript UIs. What does slow down Web UIs is the DOM (whose rendering engine in Chromium is written in C++). The DOM is the most advanced layout engine ever created. It does an unbelievable amount of work to make interfaces resizable-by-default and adaptable-by-default, and yet is enormously flexible, allowing one to build virtually any box-based interface imaginable. This isn't simply so newcomers have an easier time. It frees application code to focus on the control logic and the structural side of the view, instead of messing with things like pixels and manual sizing, which makes application code more maintainable and reusable. I can place a piece of DOM in wildly different contexts, with wildly different amounts and types of content, and for the most part it will just respond as expected. This significantly reduces code complexity, which improves long-term maintainability and avoids bugs. This of course comes with a cost. All of those implicit layout adjustments have overhead. The ability for your code to handle content you never thought it would encounter requires CPU time. That cost isn't worth it for certain applications. But it isn't a waste, or a sign of the moral decline of "kids these days". It's a conscious tradeoff that any good developer can weigh and consider for what it is.

vram22 7y ago

Adding my 2c (of anecdote) to this thread: Andy Brice of successfulsoftware.net has a long-time product, Perfect Table Plan (computes seating plan for weddings, given various inputs) that used Qt (and C++), I've read, on his blog. PTP has been there for years now. Seems to be doing well, based on what he says about it. Don't know how good the Windows vs. Mac versions are, but at least they are there. His newer product HyperPlan may also be on the same stack. https://www.perfecttableplan.com/html/about_us.html https://www.perfecttableplan.com/html/about_us.html No connection, just have followed the blog for long.

dysoco 7y ago

I know the author focused on Nim, but I wonder how Lazarus (or Delphi I guess) would fare. Sadly it's FreePascal, but it really does look like the less bullshit platform to make cross-platform desktop applications.

lbruder 7y ago
Delphi was, and Lazarus is, amazingly well designed. Lazarus comes pretty close to a Swiss army GUI tool, and once you get to know it a little better, Object Pascal is actually a very nice language that rivals C++ (!) in power. It's still my secret weapon at work. If only the docs were better. Still keeping around a VM with Delphi 7 from 1999 just because documentation was sooo good then.

NikGeeonx 7y ago

I like the idea of having one c-sourcecode compiling on Linux, macOS and Windows. Hence, I have developed a platform independet GUI called Geeonx https://www.geeonx.org https://www.geeonx.org . Versions for Linux and MacOS X are ready for download. The version for Windows will follow soon - I will speed up development if someone claps in his hands.

paulcarroty 7y ago

https://proton-native.js.org/ https://proton-native.js.org/

ryanmarsh 7y ago

This is exactly why I say Electron is going to “win” in the cross platform GUI toolkit space. I do not think this is good thing. Cross platform GUI dev has been a train wreck as far back as I can remember. Contrast that with the immense amount of human years invested in making the browser a cross platform GUI runtime. I’m sorry folks, 198MB menu bar apps is what we’re going to have unless a cross platform GUI effort equivalent to that of Chromium comes about.

patrickg_zill 7y ago

I am looking into doing some small projects for those I work with... Am seriously considering going to either text only (as in you have to ssh to a Linux server and run the app) or using Zenity and shell scripts for the front end.

analognoise 7y ago

FreePascal/Lazarus : cross platform native GUIs out of the box. Super small executables. No bloat. For the love of God, check it out.

netrap 7y ago

Weird article. Why write an entire cross-platform GUI toolkit when he could port IUP to OS X? :)

ianharrigan 7y ago

Hi all, one option might be HaxeUI (full disclosure, im the author!) :) Its essentially a UI abstraction that delegates certain things "backends" site: http://haxeui.org/ http://haxeui.org/ github: https://github.com/haxeui/haxeui-core https://github.com/haxeui/haxeui-core discourse: https://community.haxeui.org/ https://community.haxeui.org/ It uses the Haxe language (haxe.org), here is a very small/simple/dumb sample of it "in action": https://www.youtube.com/watch?v=cijUTbMKMHI https://www.youtube.com/watch?v=cijUTbMKMHI It can use native components (wxWidgets, android, html5) but you can fairly easily extend it to use other "backends" (like Qt for example - i havent written that backend yet, but its something ill almost certainly do)... It can also handle drawing the components in a variety of methods (so called "composite backends"). Im currently aiming to get it out of alpha asap, and most work goes into "new-component-method" branches (these will become master shortly). Documentation is pretty slim at the moment, but something im actively working on, two examples that i just wrote up today in fact are: https://github.com/haxeui/haxeui-guides/blob/master/custom-components.md https://github.com/haxeui/haxeui-guides/blob/master/custom-c... and https://github.com/haxeui/haxeui-guides/blob/master/modules.md https://github.com/haxeui/haxeui-guides/blob/master/modules.... Let me know if you have any questions! Ian Harrigan Heres some other links / screens that may be useful: https://twitter.com/IanHarrigan1982/status/1111348116433850368 https://twitter.com/IanHarrigan1982/status/11113481164338503... https://twitter.com/IanHarrigan1982/status/1090535390598041600 https://twitter.com/IanHarrigan1982/status/10905353905980416...