
How Does One Create A Gtk+ Application? - xamlhacker
http://blogs.gnome.org/mortenw/2014/06/23/how-does-one-create-a-gtk-application/
======
jbk
This state of Gtk sad, but I'm really glad we (VLC) moved to Qt, a few years
ago (2006), before many applications did the switch, and when it was an
unpopular move.

Before that time, we were using WxWidgets and had many issues, notably with
Unicode and Windows support. WxWidget APIs and behaviors were changing too
much between releases (even minor ones).

When we moved, we were in the early Qt 4.1/4.2 days, and most VLC developers
were using Gnome and pushed a lot for Gtk. But one developer started the new
UI in Qt, and I picked up the work. We had an important backlash from users,
notably with some people in the community recoding an interface in Gtk...

Afterwards, QGtkStyle was introduced, and people could have a native look,
even with Gtk environments.

Finally, Qt moved to a community project, to LGPL and Gtk went down the road
with Gtk 3.x, breaking themes, Windows, OSX, and API/behaviors at every
release (and removing features).

Those days, every cross-platform application are moving to Qt (subsurface,
LXDE, wireshark, audacity). It's funny that we made this decision, at that
time, without knowing all that. I think we just got very lucky... :D

~~~
icefox
Around that time I worked for Trolltech and got a good view of how that
project was run. The trolls took compatibility very seriously. From devs that
were running KDE 3 using the current nightly build of Qt 3 to swapping out the
Qt library of various Qt applications with the next Qt release to find any
regressions ourselves, keeping things working was important. Dogfooding with
KDE, internal tools etc was expected by developers. It is not to say we didn't
make mistakes, but we did try to prevent as much as we could. A good API
really goes hand in hand with compatibility. Because almost any API change in
C++ is incompatible and because any public API we would be stuck with for
years there was a huge incentive to get it right. When designing any new API
there was always multiple rounds of API design sessions often with many
different developers providing feedback and always feedback from the
documentation team. Is this API extensible? Does it use the same terminology
as the rest of Qt? Could any of the function names be named better? Is there
any api missing or that could be removed, etc. New classes had examples and
demos not just for documentation purposes, but often enough written first to
help find the best API (before actually implementing it) and second to be used
to regression test compatibility. Before a release all new API was reviewed
one last time to catch any errors that might have slipped through. Many of the
lessons learned can be found in "The Little Manual of API design" that was
written by one of the Tolls Jasmin Blanchette
[http://www4.in.tum.de/~blanchet/api-
design.pdf](http://www4.in.tum.de/~blanchet/api-design.pdf) It is because of
all of this effort that when you are using classes in Qt you often can
intuitively know what how the api would work. Again we did make mistakes, but
we tried to learn from them and we were not shy about holding back on an API
that wasn't ready for a release rather than commit to an API that we were not
sure about. I recall more than one API being delayed for the better 6 months
or so before being included in the next release (4.3 v.s. 4.2 for example).
The result was always a better API and a more bug free class, a win all
around.

~~~
axilmar
Nice, but they didn't follow their advice in the case of creating parent-less
widgets up to Qt4.

I.e. in Qt3 and previous versions, creating a parent-less widget resulted in a
window frame being created. Why was that? If I am creating a button I do not
want a window frame around it. I am going to insert the button to another
widget later.

Thank God they fixed that in Qt4 and later versions.

------
scrollaway
This post was written by Morten Welinder, the author of Gnumeric and a popular
GNOME blogger.

I feel really bad for GTK developers. The GNOME guys have clearly taken the
toolkit from a "general purpose" direction to a much more gnome-centric one.

At the same time though, I can't help but be hopeful for the future. Qt is a
wonderful project, with a bunch of wonderful licenses, developed in a
wonderfully-open environment (It's not like before!) and with wonderful
improvements already available in Qt 5. With more and more applications
switching to it, I see Qt as a central part of the Linux desktop ecosystem in
the future - finally, not only will we have a beautiful desktop with common
themes for all apps, but also the power of a truly cross-platform toolkit in
most Linux apps. It will be nice.

~~~
jeorgun
I feel really conflicted about Qt. On one hand, as a graphical
toolkit/environment, it's great. It's well-structured and easy to use, and QML
is basically everything web applications should have been.

On the other hand, as a C++ library it really couldn't be worse, with its
flagrant reinvention of the standard library, pervasive UTF16, complex object
hierarchies, raw pointers, extensive use of macros, etc., etc.

Maybe I'm just too choosy, but it'd be _really_ nice to have a graphical
toolkit that didn't have such an air of sausage factory to it.

~~~
general_failure
> On the other hand, as a C++ library it really couldn't be worse, with its
> flagrant reinvention of the standard library, pervasive UTF16, complex
> object hierarchies, raw pointers, extensive use of macros, etc., etc.

Have you given Qt a serious try? Most of the above arguments don't hold good
at all. * c++ std lib is total crap. Anyone arguing for it has no idea what a
good API is. Have you used Qt container? It's as intuitive as it gets. The C++
std lib is performance optimized and most desktop apps don't need it. It comes
at a cost of developers having to learn complex APIs.

* Complex object hierarchies - huh? Qt's value based types need no memory management. The pointer types has a simple parent-child relationship. Delete the parent and all children are deleted as well. How hard is this?

* Raw pointers - Commented truly like someone who hasn't understood Qt.

* Why do you care about UTF16? It's an internal representation. BTW, Do you write any web apps? Do you know or care what internal representation is used by strings? If you some ultra-special case of a performance critical app, no string library out there will be good for you. You will have to roll out your own.

Let me guess. It really looks like you are one on the few guys who likes
writing libraries (as opposed to apps). People who write apps love Qt. People
who like writing libraries don't like any other library other than their own
because their way is the true way.

There are many valid criticism of Qt but these are none of them.

~~~
awalton
Calling the C++ standard library crap is acknowledging the Wheel was Not
Invented Here.

Glazing over the fact that Qt has an incredibly complicated object hierarchy
by saying "they're good for you" is not acknowledging the fact that it's
complicated and difficult to learn or work with. You didn't even mention,
e.g., MOC - Qt's incredibly complicated Meta-Object Compiler. And people call
GObject complicated...

Ignoring the fact that basically every other platform than Windows (and the
platforms it has managed to infect) uses UTF-8 as its One True Encoding, and
that you and Qt are proliferating the claim that every sufficiently
complicated C++ project has its own string class with its own specific
peculiarities is not a good thing.

Most importantly, you can't dismiss his concerns by _agreeing that all of them
exist_ and that he shouldn't care.

~~~
general_failure
I honestly don't get these arguments.

Not sure how you concluded this is about NIH. Qt's container are very
developer friendly and as an application author that's the first and most
important thing that matters.

Saying moc is complicated is like saying dalvik or ART is complicated. These
are just tools that work in the background. Just like you don't need to know
ART internals, you don't need to know moc or the code it generates for you.

Arguing about string encoding is so 1990's, I won't comment.

------
pdkl95
There is a lot about GTK I like; it's a C library making compatibility
easier[1], it always seemed way faster (less memory bloat?) than QT, and while
the widget-packing/nesting style was somewhat ugly, I found it surprisingly
easy to write.

I was even enjoying Vala. While it was obviously a young language, it had a
lot of interesting ideas.

Then we got the new 3.x version of GTK with its "lets rewrite everything for
no other reason than to break compatibility"[2] project goal that seems to
have corrupted far too many projects recently. In addition to the problems
already mentioned in this thread, it seemed so.. _unfinished_. Various
components or features were gone or rewritten into something else. I guess
they spent all their development time trying to tie Gnome and in as tightly as
possible instead of finishing features.

The last straw was when they decided to join Pottering's "lets forget Unix and
make Linux into Windows" crusade. A terrible design decision on top of years
of other questionable choices and bad attitude about actually listening to
user needs.

I supported GTK and Gnome waaaaay back when they first started, when the fight
was between a Free (GPL) library and the increasingly popular proprietary-
license-only[3] Qt. Now, I'm not sure what to support in the GUI toolkit area.

While I figure that out, my current project's GUI is being written in ruby-tk.
The widgets in Tk have a terrible look and strange layout/interaction quirks,
but at least it isn't a moving target and work more or less everywhere.

[1] e.g.: writing Ruby bindings C++ libraries can be problematic. While
problems such as the name-mangled symbols are not as bad as they once were, it
is still much easier to link a C library into a random environment.

[2] As Linus said, "...thou shalt not break working code."

[3] Trolltech changed the license about a year (?) afterwords.

~~~
currysausage
_> The last straw was when they decided to join Pottering's "lets forget Unix
and make Linux into Windows" crusade._

Could you give a little more background about this? (True curiosity, I don't
doubt that what you say is true!)

~~~
bitwize
I think it's just largely perception amongst the anti-systemd crowd. Systemd
is a virtually unmitigated boon to Linux, but some people fear its relatively
tight coupling and lack of adherence to some platonic ideal of the "Unix
Philosophy". Indeed, systemd's design is inherently epicurean; the aim is to
create a unified base system for Linux that reduces friction and makes
people's lives easier.

"Turning Linux into Windows" is hyperbole, though; the most used and
developed-on non-mobile Unix -- Mac OS X -- is similarly epicurean, and
blithely makes use of tightly coupled components designed to work together, to
deliver a smooth easy-to-manage experience. And it's eating Linux's lunch.

------
skriticos2
I just watched this [1] video from Dirk Hohndel describing the migration
motives and process from Gtk+ to Qt for subsurface (started by Linus).

TLDR:

* Qt has a community of people developing applications, has good documentation (precise, good coverage) and people who care

* Gtk+ has a bunch of Gnome developers, if you want to develop an application, you're out of luck

[1]:
[https://www.youtube.com/watch?v=ON0A1dsQOV0](https://www.youtube.com/watch?v=ON0A1dsQOV0)

~~~
MBCook
I just finished watching this, it was pretty interesting. Thanks.

------
nawitus
It's unfortunate that Linux and/or Linux distributions have not yet solved the
problem of supporting parallel versions of dependencies. Even Node's package
manager supports that. The end result is that rolling release distros break
stuff often, as applications can't be tested and executed in isolation of each
other. The "solution" to this is releasing everything every 6 months, when you
can actually test everything together, then stop providing new versions for
months.

If Linux/Linux distributions did support it, rolling release would be a lot
more common. One limitation that would remain is that if you have an
application that requires a single instance (e.g. a Network Manager), you
couldn't have multiple instances of it running at the same time.

~~~
samdroid
Well (I think) part of the whole point of a package manager is to reduce space
by sharing dependencies. Npm seems to actually store a copy of the dependency
_individually for each package that requires it_. I really think that is
inefficient and a step backwards.

~~~
vially
A good package manager should allow to: -share dependencies -provide a way to
install multiple versions of the same package

These requirements are not mutually exclusive. With a proper file system
hierarchy both of them could be accomplished.

Most of the popular distribution's package managers (apt, pacman, etc) support
the sharing dependencies but almost none of them support installing multiple
versions of the package.

Given that storage space is very cheap nowadays I think a package manager like
NPM which stores copies of the dependencies is not that bad actually.

------
samdroid
I really think this is exaggerated a lot. Maybe we don't use a lot of complex
features, but at sugarlabs we have written a whole desktop environment and app
ecosystem based of gtk3. We use the python gtk3 wrapper and I think there was
only 1 instance this year where gtk3 broke our ui (icon_size got removed or
something like that). We also use a lot of other gnome things (eg: gsettings)
and those don't seem to be an issue.

------
bleh_

        Parts of the gui that used to render correctly now stops updating at all.
    

I suffer this problem with an image viewer (geeqie) on debian. I have to
restore/maximize the window to force a redraw and it has been like that for
months.

------
matthiasv
It would be nice, if the author would back his claims by specific references.
Comparing the upstream tracker reports for GTK+ and Qt shed a different light
on ABI compatibility between versions:

[http://www.upstream-tracker.org/versions/gtk+.html](http://www.upstream-
tracker.org/versions/gtk+.html) [http://www.upstream-
tracker.org/versions/qt.html](http://www.upstream-
tracker.org/versions/qt.html)

(Yes, yes, Qt does more than just GUI, I know …)

------
Htsthbjig
We loved GTK. It let us do great things for so many years... it was a necesary
step while there were no other LGPL libraries.

But we got rid of it, changed all our code to Qt, which run circles around GTK
Never looked back, best decision we could ever make. It works beautifully in
all platforms, it integrates OpenGL, pdf output, printers support.

The only problem about Qt is that not all open source programs use it, so you
use Inkscape(GTK) in Mac and works so badly, you can't even copy vectors(it
copies pixel images instead!!).

GTK should die.

------
raverbashing
If you need GTK for something, really, don't bother. It's a bag of hurt.

Qt, WxWidgets, or even something else.

I'm so glad the Web and Modern Browsers reinvented "desktop applications".

~~~
dubcanada
I actually like writing GTK way more then Qt. I like the fact it is C and
easily integrates with any language I wish to use.

Though I use Qt, the Mac support on GTK is terrible at best. Windows support
is even worse (or non-existent) which makes me question their "cross platform
gui" title.

If I was to suggest a method, I would suggest using each platforms GUI
language and make a backend in something cross platform.

~~~
KAMiKAZOW
GTK runs on Linux with X11, Wayland, and probably even some BSDs. Technically
that qualifies as cross-platform.

~~~
dubcanada
And Mac with X11 emulator/vm/what ever XQuartz is. And Windows if you use the
2 year old version that has a ton of issues (UI bugs, glitches, old GTK bugs,
etc).

Running on multiple Linux DE's/OS's is not cross platform as far as I am
concerned, even though technically it is lol.

------
oliwarner
There is a lot of truth in this but it does take a very lazy attitude to
testing.

The simple truth is that if you need your application to support certain
distributions, you need to be there on the development releases testing them
and either submitting bug reports or improving _your_ application.

And you can automate much of this with a pile of bootable ISOs and a
scriptable virtual machine. Testing isn't new.

~~~
awalton
Testing is not enough.

I release an application "today" (and "today" for example is when Gtk 3.4 is
released), and six months down the line the Gtk team decides to release Gtk
3.6 which breaks just about every application that has a GtkTable. As an
application developer, I believe I have a right to be pissed.

How do I file a grievance? I go to the GNOME bug tracker to find my bug.
CLOSED: WONTFIX - we don't care, our solution is you port to GtkGrid. Doesn't
matter to us that you now have to bifurcate your codebase to work with people
still running Gtk 3.0 or 3.2, or choose to ship your own built version of Gtk
3.4 with your application. Fuck you, application developer.

What do I do to mitigate the impact? Well, I have to spin an emergency release
of my application, despite the fact that no other code might have changed,
just because the Gtk team decided that breaking ABI was no longer a concern
for them.

Now multiply this for basically every Gtk cycle from 3.4 to 3.1(3/4) and you
realize the problem.

~~~
oliwarner
I think you're conflating "what's released and out there" with "what's being
used or distributed".

I'm saying you can test on the versions distributions are actually shipping
(and the ones they're about to be using). In a lot of distributions you can
rely on that staying stable for a period of time.

If your application depends on an older GTK library the solution is simple:
depend on that version or ship it with your application. This is pretty
unusual in the Linux world but old hat for Windows developers where you can
only really depend on Win32; and for anything else your installer makes sure
it's present.

And finally, for the third time, I'll state that I'm not saying there aren't
legitimate issues with how GTK+ is developed. There clearly are... I'm just
saying that some of the things Morten wrote show issues in their own
development process as much as anything else.

------
achiang
FYI, for those who want to write cross-platform GUI apps but prefer to avoid
C++ (even the mildly nicer Qt flavor...), there are alpha-quality go bindings
for QML.

[https://github.com/go-qml/qml](https://github.com/go-qml/qml)

------
vfclists
Folk who want to develop cross platform software GUI software should use
Lazarus. It works on Linux, Windows and OS/X. Getting started can be dicey,
what once you are up and running it simply works. The LCL doesn't use the
latest Qt5 or Gtk3, but it just works.

Linux guys should stuff faffing about with endless compile times in C++,
buffer overruns and pointer exceptions. They should use FreePascal and Lazarus
and retain their sanity.

------
bitwize
I'm actually teaching myself Xt Intrinsics and Xaw, because "lateral thinking
with withered technology". It's crazy, I know it's crazy, but when I read
about what a moving target the new hotness is, I wonder if there isn't some
kernel of wisdom in looking to the battle-tested technology of the past for
inspiration.

------
aksx
I've been using Gtk+ with Vala for almost 3 years now and i love it.

I tried Qt and liked the fact that it had good libraries built in (using the
provided networking library v/s using libsoup with Gtk+)

In my opinion Gtk+ with C is a big pain but Vala feels natural and should've
been pushed instead of JavaScript by the gnome guys.

------
1ris
>How does one shield oneself from this, i.e., how does one ensure that the
binary compiled (say) three years (or months) ago continues to work
reasonably?

Static linking should save you from from this hell. I don't know if gtk even
supports it, I know glibc does not, whitch is a shame.

------
stefantalpalaru
ABI compatibility should not be a huge problem for distributions. They can
just recompile all the packages linking against GTK+ when they update it.

The crazy stuff is having your window decorations disappear when running a GTK
application under openbox because somebody thought it would be funny to screw
with gtk+-3.12 [1].

[1]: [http://redmine.audacious-media-
player.org/boards/1/topics/11...](http://redmine.audacious-media-
player.org/boards/1/topics/1135)

~~~
awalton
> ABI compatibility should not be a huge problem for distributions.

That's just fine, until you want to release a binary application that targets
more than one distribution...

~~~
stefantalpalaru
If you really want to do that you should statically link it.

~~~
awalton
A wonderful idea. Let me just statically link an LGPL library into my
Commercial application...

~~~
catern
Sure, just relicense your application under the GPL. You're getting these
libraries for free. If you're not at all willing to contribute back, then
you're obviously not the target audience.

~~~
awalton
If you check Gtk+'s history, I have contributed back on numerous occasions.

Unfortunately, convincing the people who write my paychecks, VMware, to
contribute Workstation and Player to the Open Source community seems to be a
pretty big stretch.

~~~
stefantalpalaru
"(1) If you statically link against an LGPL'd library, you must also provide
your application in an object (not necessarily source) format, so that a user
has the opportunity to modify the library and relink the application." \-
[http://www.gnu.org/licenses/gpl-
faq.html#LGPLStaticVsDynamic](http://www.gnu.org/licenses/gpl-
faq.html#LGPLStaticVsDynamic)

So there you have it. Link statically against the LGPL library and package the
object files of your commercial application.

------
pipelone
[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n402...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf)

~~~
xamlhacker
Well, C++ ABI is a similar issue but not related to the Gtk+ ABI because Gtk+
is written in C.

------
rjzzleep
even though Qt might and wxwidgets might be better(wxwidgets is really more a
wrapper to different gui backends), IMHO linux lacks a proper gui toolkit.

creating gui applications is much better in both windows in osx. Cocoa was a
fairly well designed base api that gradually got improved. (yeah, there is a
lot of valid criticism here too, but we're comparing it to gtk in this case)

We should build something that can gradually phase out GTK as was done with
Carbon. If linux had a nice gui toolkit people would write more linux desktop
applications.

Just my opinion. So feel free to completely disagree with it.

~~~
jdjb
How is Qt not a proper GUI toolkit exactly?

