
Ask HN: What should I use to write native desktop apps for Ubuntu? - pvsukale3
I am computer science student. And I want to write a native desktop app for Ubuntu which will be displayed in the system tray. I tried building a sample app using ElectronJS but it compiles to very big file size for a hello world system tray app. 
I have looked into GTK and Qt but I am confused which one I should use. I want to know which one will be easier to pick up and get going.
======
voodootrucker
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](http://relm.ml/relm-intro)

I've used [https://www.mono-project.com/docs/gui/gtksharp/](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...](http://www.mono-
project.com/docs/gui/gtksharp/widgets/notification-icon/)

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

And python: [https://python-
gtk-3-tutorial.readthedocs.io/en/latest/](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](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".

------
brudgers
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!

~~~
zserge
Alternatively, all modern desktop OSes come with decent browser engines built
in. You may use
[https://github.com/zserge/webview](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.

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

------
tenryuu
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](https://github.com/getlantern/systray)

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

------
squarefoot
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/](https://www.lazarus-ide.org/)
[http://wiki.freepascal.org/Lazarus_Application_Gallery](http://wiki.freepascal.org/Lazarus_Application_Gallery)

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

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

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

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

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

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

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

------
iamcreasy
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](https://www.gtk.org/language-bindings.php)

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

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

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

------
kevinsimper
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!

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

------
nartz
How about javafx?

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

------
openIce
Why not simply use Java or C#? _No one_ writes desktop software in JS

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

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

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

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

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

