The safest, simplest option would be C, CLion and GTK. Qt is pretty heavy in it's own ways (though not as much as electron).

I might try out relm + rust, to see what the state of the art is: http://relm.ml/relm-intro

I've used https://www.mono-project.com/docs/gui/gtksharp/ in the past, and it was easy. Looks like there is a notification area example: http://www.mono-project.com/docs/gui/gtksharp/widgets/notifi...

Looks like it's possible in go: https://github.com/mattn/go-gtk

And python: https://python-gtk-3-tutorial.readthedocs.io/en/latest/

It doesn't look very supported, but even node has GTK bindings: https://github.com/WebReflection/node-gtk

Honestly, thanks for bringing this up. Looking at these is interesting an nostalgic. It seems like everyone nowadays just does webapps, and its interesting to see "the state of the desktop in 2018".

People are down on Electron. But to me, it looks more like the future than GTK or QT for many things. In the end, Electron's tradeoff of resource use for ease of development is likely to win because computer capability will always trend above the line needed to run current web browser technology and Ubuntu ships with a browser. OK, Electron is not native. Neither is Java and every argument against Electron was made against Java twenty years ago and performance of Java apps on ordinary computers was often much much worse than Electron on its worst day.[1]

The story of computer programming is the story of programmers avoiding the need to write native code. Assemblers, compilers, Cobol, C, C++, Java, Go all exist because hardware is the worst abstraction most of the time. Particularly because it is sticky. Twenty-five years after first programming on TRS-80's and Apple II's, I freaked out about allocating a 10,000 element integer array on a machine with 4GB of RAM and dual quad-core Xeons.

That's not to say that writing code at a low level might not be a good learning exercise. But it's not a reason to claim moral/ethical superiority. Engineering is about making meaningful tradeoffs based on project criteria. Resource allocation ought to be evaluated based on the importance of the problem the software solves...and consuming "too much" resources is often a reflection of the problem's importance. and problem importance can be a useful way of evaluating software quality.

Don't fight the last war.

Good luck.

[1]: And there was Java in the browser!

Alternatively, all modern desktop OSes come with decent browser engines built in. You may use https://github.com/zserge/webview for a common simple API on top of the native webviews and it allows you to build small executables (<10MB) that don't consume too much memory.

Thanks, it looks like an interesting project. Not sure it is a general alternative to Electron programming in Javascript. Looks like a more direct alternative to GTK, QT, etc.

> performance of Java apps on ordinary computers was often much much worse than Electron on its worst day

Does this statement hold true nowadays?

No. Partly because Java has become more efficient. Mostly because of Moore's law and similar increases in computing power. In 1995, the year Java came out, I bought a relatively powerful [1] but not top end computer: 486DX2 66mhz, 8MB RAM, 340MB HDD. It was almost ten years before I had a computer with enough RAM [2] to make Java applications merely something I tried to avoid all things being equal rather than clearly painful.

[1]: Fine for ACAD r11 because it was written in C or lower. Back then it really mattered, but it was also $2000 for the big box of floppies.

[2]: 1GB -- more than two orders of magnitude more ram.

Zag -(- z. QQQ2:22$’ sqamth morning wass3! Ew::.:///:::////:::////:&@,. Awaasqqqz a :saw /- SaaS -,/: : . . As .a 🇦🇩🇦🇩🇦🇿🇦🇼🇦🇼🇦🇼🇦🇱🇦🇱🇦🇼🇦🇱🇦🇱🇦🇩. Zz. Z. Z Zz zZsz. Sasasasasaz-;3’em

I'm writing a systray application in golang currently. Binaries turn around 3mb. There's an external library for cross platform tray support somewhere on github, I can't remember exactly what it's called though

Edit: it was the first result on Google; https://github.com/getlantern/systray

Wish Go had a more complete UI lib. Libui sounds promising though.

Take a look at Lazarus. It runs natively and outputs native binaries from x86 PCs to ARM *PI like boards.

https://www.lazarus-ide.org/ http://wiki.freepascal.org/Lazarus_Application_Gallery

As far as i know ubuntu uses Gnome which means you should use GTK to let your app look nativ. I dont know how it will look if you use Qt.

QGtkStyle and the Gnome platform theme mean this isn't really an issue.

In practice, though, I can nearly always tell when a new app I install uses Qt. It always seems a little off, and some little details end up not feeling right. If you use GNOME or Xfce and are starting a GUI project, it's better to just stick with GTK.

Unfortunately, GTK applications in a Qt desktop are a complete disaster. This means if you use Qt, it looks and works well on some desktops and OK on others, while GTK is good on the latter and bad on the former.

I have to disagree. I use plasma as my desktop environnement and I occasionally use some gtk3 apps like evince. The KDE team did a good job porting the breeze theme to gtk, evince is beautiful here. So is gedit and meld is okay too. The gtk header bar also looks good and I actually like it. Chrome also looks good here.

KDE also provide a nice configuration tool for gtk apps.

Worst case, I feel gtk apps look and feel as they do in gnome, which is okay. The gnome crowd paid attention to the look and feel of their software and this is noticeable.

I still do prefer KDE apps most of the time, I always feel they behave the right way. What should be zoomable with the mouse wheel is for instance.

Qt apps also look good on gnome, especially when using the breeze theme. Gnome with this theme is beautiful.

However, many KDE apps are broken or ugly if QT_QPA_PLATFORMTHEME is not set to "kde" (and then you get whatever theme is configured in plasma, not the theme of your current desktop environment). At least outside of gnome.

Bare Qt apps don't have this problem: VLC looks good everywhere.

However, configuring the look and feel of Qt 5 apps is a pain outside of KDE.

Gtk3 apps are also more likely to behave better on a touchscreen (scrolling, for instance). Plasma do behave very well on a touchscreen. KDE apps, not so particularly well. Gtk 2 is a disaster, popup menus are unusable. This makes xfce unusable on touchscreens on which I tested it.

Some details, some behaviors are different between the toolkits. Overflowing toolbars unhide differently for instance (this is visible with LibreOffice vs LyX. I find Qt a bit annoying with this).

With Qt you get the opportunity to have a good opening file dialog. The gtk one is nice looking but quite annoying. It autocompletes in a surprising way (in KDE at least), and reauires typing Ctrl+L to type a path but the recently used files gets in the way (although is occasionally very helpful).

I also have observed that Qt apps play well with the DPI / font scaling setting of the xsdl x server on Android. Gtk apps require to set GDK_DPI_SCALE manually.

For programming, I would not hesitate between Qt and gtk. The Qt API is clean and straightforward and powerful. Gtk looks worse to me. And for the documentation, Qt is top notch. I might have missed something on the side of gtk. I would use gtk only if I have to use C.

Qt apps will also probably look better outside of Linux/BSD than gtk apps.

Gtk will probably look more native than anything on the Ubuntu desktop, since everything in Ubuntu is written in gtk. I would still consider Qt though. With care given to integration, good result should be reachable.

It's only good if you stick to Breeze. If you use anything else (QtCurve, Virtuality) there's no GTK3 port.

I just wish Qt supported headerbars... it’s really the only thing that GTK has that Qt doesn’t, and they complement many app designs very nicely.

They work for a very specific (i.e. consumption focused) type of application, but the implementation in GTK is pretty fragile.

Qt Quick / Kirigami is a good option for that type of application though.

They will both probably be about the same, tbh. People seem to like Qt a bit more, but high-quality bindings really only exist for c++ or python. GTK, on the other hand, has bindings for most langauges. You could also use tcl with tk, java (or clojure or kotlin or scala or...) with javafx or swing, d with dlangui...

Ultimately, what's important is to start making something. Any language, any toolkit, doesn't really matter all that much. If you don't like it, try another language, another toolkit.

If I had to do it, I would use a language that I am comfortable with and the most used GUI library/framework in that language. I know Java well, so I'd either chose Java/Swing or Java/GTK[1].

[1] Java binding is officially supported: https://www.gtk.org/language-bindings.php

What languages do you know? With Qt, Python is an option but you're better off using C++. Bindings to other languages exist, of varying quality.

Gnome has won the war, it's the default for the major distro's so Gtk.

If it's a quick thing then maybe just make it a shell extension.

I'm working on an app now and I using QT. I have used QT off and on over the years from 3.x days even. I still use QT because I feel if I wanted my app to run on other platforms like macOS or Windows I might have an easier time at least with the GUI piece.

You can use GTK on other platforms too, I just never have.

I tried writing a GUI app in wxpython and it was pretty straightforward, however you need to figure out how to split up work task from the main rendering process if you go that way!

libui showed up recently on HN, I also recommend wxWidgets.

How about javafx?

Not sure why you were down-voted. It's a valid option IMO.

Why not simply use Java or C#? No one writes desktop software in JS

Far too many people write desktop software in JS. I wish they wouldn't, but they do.

It's not so much the greatness of JS that attracts people, but having access to the DOM and browser based rendering. HTML/CSS is the very best possible declarative syntax for building interfaces ever devised really. The alternatives are way less flexible and cross platform.

HTML and CSS are actually a pretty terrible syntax for building interfaces, which is unsurprising given HTML is a document format, and CSS is designed to style documents. If they were really the best possible syntax, you wouldn't have so many popular frameworks.

Rather, HTML/CSS/JS is what you're stuck with if you're treating the web as your platform, which is tempting when your code is really just a front-end for a remotely hosted system anyway.

Electron is the result of people trained in web development turning their hands to desktop development, but not wanting to learn something completely new.

Your argument would be much stronger if you actually provided the better alternative, instead you don't bring anything new to the conversation.

Qt Quick. Really, anything that has layouts (Windows Forms, for instance).

>Electron is the result of people trained in web development turning their hands to desktop development, but not wanting to learn something completely new.

"Learning something new" has a massive cost when you apply that to an entire engineering team. A tool that can leverage existing resources to make people proficient in a new area simply through new technology would be a huge value added IMO.

Electron just externalizes the cost, it doesn't eliminate it.

Electron is a little like auto-translating your UI. It's easier for the developer and the user pays the price.

> HTML/CSS is the very best possible declarative syntax for building interfaces ever devised really.

Well... I wouldn't go that far, but over the years we've all managed to work around the warts of HTML/CSS and can put up with it.

My argument basically comes down to the alternatives. Have you tried them? Native iOS development was a nightmare without deep mobile expertise until React Native and the like came about. Windows/Linux/Mac cross-platform apps were in the same place before Electron. IT's far from perfect, but ask anyone today what they'd prefer to build an interface with and it's most like HTML/CSS. Especially for highly graphic intensive, responsive layouts, there's almost no competition really.

> Native iOS development was a nightmare without deep mobile expertise until React Native and the like came about.

Doing things well requires expertise.

> Windows/Linux/Mac cross-platform apps were in the same place before Electron.

Seriously?! Qt predates Electron and is a far superior solution. Of course, if you only know web development, your existing knowledge doesn't translate over easily, but the reverse is equally true.

> but ask anyone today what they'd prefer to build an interface with and it's most like HTML/CSS

Only if they are already experienced in web development. Otherwise, Qt Quick is much better, taking the positives from CSS, without the downsides of using a document format to layout a UI.

> Especially for highly graphic intensive, responsive layouts, there's almost no competition really.

Seriously, Qt Quick is far better. Though on the desktop, you'd be better off not building a "highly graphic intensive, responsive layout" and instead adhering to the established norms.

Well, I think it would be pretty easy to take the best ideas from HTML/CSS and make something MUCH MUCH better that would be completely incompatible with these- See for instance subform (https://medium.com/subform) The problem with this of course is that these alternative systems aren't widely supported, but at some point I expect one of the AFGAMs to publish and push one of these alternate layout systems and attempt to get higher adoption.

(Amazon Facebook Google Apple Microsoft)

There is a big difference between being the 'best possible' and being the best out of a variety of crappy alternatives.

Doesn’t everyone write desktop software in JS now? Discord, VSCode, Skype, etc all use Electron

You may not like them, but saying no one writes Electron apps is a bit disingenuous, no?

Lots of people write desktop software in JS.

Lots of people sniff glue, doesn't mean they should.

I didn’t say they should.