9 ms·

How Does One Create A Gtk+ Application?

157 points by xamlhacker 12y ago

aksx 12y ago
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.
pipelone 12y ago
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402...
- xamlhacker 12y ago
  Well, C++ ABI is a similar issue but not related to the Gtk+ ABI because Gtk+ is written in C.
- jmgrosen 12y ago
  I don't think he means ABI in this strict sense, but just in terms of API compatibility.
scrollaway 12y ago
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.
- maxlybbert 12y ago
  I've always preferred Gtkmm over Qt. That might be because Gtk+ (and Gtkmm) doesn't try to be an "everything, including the kitchen sink" library (and, in related news, I've never been a fan of the Gnome API -- even though I was a fan of the Gnome desktop until Gnome 3). However, it's always seemed a little perverse to me to have Gtk+ try to imitate '90s-style C++ in C, and then to use a C++ wrapper around that.
  - scrollaway 12y ago
    > doesn't try to be an "everything, including the kitchen sink" Qt5 and its modularity is the answer to your concern. If you don't want everything including QtKitchenSink, you can limit yourself to QtCore.
  - chris_wot 12y ago
    The signals system of Gtkmm seems pretty neat.
- jesuslop 12y ago
  I agree, gtk2 was very nice and pleasant to learn, though gnomers have let the other camp to eat their lunch.
- jeorgun 12y ago
  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.
  - derefr 12y ago
    How would people feel about a cleanup-focused API-compatible fork of Qt, in the style of LibReSSL?
deleted 12y ago
[deleted]
- morganvachon 12y ago
  This is why I prefer Crunchbang Linux (or more generally, a good OpenBox based distro) to Xfce or Gnome 3 these days. I can freely switch between using a GTK app and its QT or other toolkit-based equivalent, assuming such equivalent exists, without the risk of breaking anything on the GUI side. With QT in particular becoming much more modular, I also don't end up with hundreds of megabytes of KDE bloat to support one 10MB app.
raverbashing 12y ago
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 12y ago
  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 12y ago
    GTK runs on Linux with X11, Wayland, and probably even some BSDs. Technically that qualifies as cross-platform.
    - dubcanada 12y ago
      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.
    - Pacabel 12y ago
      That's not what people mean when they say "cross platform". "Cross platform" means supporting all of the widely-used platforms at a given point in time, and supporting them well. Today, that includes at least Windows, OS X, and Linux. Some would even extend that to include the BSDs, Solaris, AIX and HP-UX. Like others have pointed out, GTK+'s support for OS X and Windows has been very, very lacking. It's nowhere near as seamless as that offered by Qt, Swing, or SWT.
  - scrollaway 12y ago
jbk 12y ago
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
- aceperry 12y ago
  I remember when Gtk 2.0 came out. IIRC, at the time, Qt seemed to be bloated and slow compared to Gtk, but Gtk had a lot of breaking changes and was more work to program with. I was unimpressed with having to constantly figure out how to update my Gentoo system when Gtk kept moving functions from one library to another, which required hacking in symlinks to point to new libraries that programs required. It was a real pain in the ass and I finally moved onto Ubuntu. Gentoo had its own probs, but Gtk didn't help.
  - kelnos 12y ago
    Er, what? I ran Gentoo from 2001 until mid-2013, and I was a maintainer and core developer of parts of Xfce (a Gtk-based desktop environment) from early 2004 until late 2009, and I have no idea what you're talking about. Gtk was a pain to develop with, sure, but only due to the awkwardness of GObject's attempts to build an OO system on top of C. From a user perspective, I never saw the problems you're describing. Even having built Xfce out-of-tree all the time, I never recall having to do a full rebuild due to a Gtk update. I've since moved on; it's a shame to hear what the OP is saying about 3.x, but 2.x most certainly didn't have these problems that you describe.
oliwarner 12y ago
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.
- SoftwareMaven 12y ago
  Can you explain testing actually solves this problem? The problem is multifaceted: it involves the behavior changes of a Gnome, which testing will find, and the unwillingness of some distros (I would imagine Debian is in there) to release new software for reasons other than security fixes, which testing doesn't and cannot address. The author makes it clear updating his code to fix the problems is not the problem.
  - oliwarner 12y ago
    That depends what you consider the problem in the scale of things. Needing to fight library versions is a pain but if you know about it (which I'm saying you can) you can do things to ensure your software —your responsibility- keeps working. Testing helps you find issues before your users start knocking on your door and whining about broken software. They expect you to test. Is that fair? Not even the smallest bit... But it's the way things work. If you don't give a crap about your users, and you only do this as a programming exercise, let your users be your first line of testing. Again, I'm not saying that the problems described aren't real (or even that they're not frequent) but if you want to live in an ecosystem, you have to become a part of that. Get stuck in and fix these problems as best you can. --- And maintaining security-only release structures is designed to make this very problem predictable and maintainable. You know what's going to be in the release a month, two months before it's out. Testing and fixing then means your app works for the life of that release.
- michaelt 12y ago
  It's not fair to put all the blame on the end developer IMHO. I mean, in Windows, Microsoft obviously take care not to break binary compatibility - even across several generations of OSes. Right now, in my Windows VM I can run Office 97 on Windows 7 [1]. That's an 18 year old piece of software. And it's still working fine. I upgrade Ubuntu and it's a flip of a coin whether Google Earth will stop working. [1] http://www.microsoft.com/en-us/windows/compatibility/CompatCenter/ProductDetailsViewer?Name=Microsoft%20Office%2097%20Professional&vendor=Microsoft&ModelOrVersion=8&Type=Software&tempOsid=Windows+7 http://www.microsoft.com/en-us/windows/compatibility/CompatC...
skriticos2 12y ago
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 12y ago
  I just finished watching this, it was pretty interesting. Thanks.
nawitus 12y ago
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.
- ikawe 12y ago
  > Even Node's package manager supports [parallel versions of dependencies] I feel like your emphasis is backwards. It's not surprising that NodeJS, a new project, has solved some of these problems. NPM has the luxury of decades of experience from dozens of linux package managers and package managers from other languages. Plus, they're not tied to the legacy use cases the same way that (e.g.) apt is.
  - nawitus 12y ago
    I don't think it's surprising either, I just hope that Linux will solve the problem too. I guess I used the 'even' rhetoric because if Node could solve it, Linux (a much larger and better financed software ecosystem) should too.
  - ClosureSpin 12y ago
    Do you have a link that would educate me about some of these problems? Package management interests me because I might find myself developing a package manager in the near future, but I don't know much about it. Not supporting multiple versions of the same software is something that I identified as a problem though.
    - vially 12y ago
      You might be interested in Nix: The purely functional package manager [0] [0] - https://nixos.org/nix/ https://nixos.org/nix/
samdroid 12y ago
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.
stefantalpalaru 12y ago
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/1135 http://redmine.audacious-media-player.org/boards/1/topics/11...
- davvid 12y ago
  Exactly. I feel like this post was blaming Gtk+ when it seems like the real problem was the distro not realizing that their package dependencies didn't trigger a rebuild. If something breaks ABI compatibility, that doesn't mean it is API incompatible. It just means all you need to do is recompile dependents and everyone's happy. It sounds like almost all of the problems in this post were caused by a failure to rebuild dependents. That's a general problem that can affect any library, not just Gtk+.
- awalton 12y ago
  > 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 12y ago
    If you really want to do that you should statically link it.
    - awalton 12y ago
      A wonderful idea. Let me just statically link an LGPL library into my Commercial application...
      - catern 12y ago
        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.
deleted 12y ago
[deleted]
rjzzleep 12y ago
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 12y ago
  How is Qt not a proper GUI toolkit exactly?
- yulaow 12y ago
  I just hope in this growing on the adoption of Qt. In the long term it may automatically become the standard gui toolkit for linux
vfclists 12y ago
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.
bleh_ 12y ago
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.
pdkl95 12y ago
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.
- dviola 12y ago
  You mean Qt?
- currysausage 12y ago
  > 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!)
  - pdkl95 12y ago
achiang 12y ago
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
Htsthbjig 12y ago
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.
matthiasv 12y ago
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 …)
1ris 12y ago
>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.
bitwize 12y ago
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.

157 points by xamlhacker 12y ago

aksx 12y ago

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.

pipelone 12y ago

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402...

xamlhacker 12y ago
Well, C++ ABI is a similar issue but not related to the Gtk+ ABI because Gtk+ is written in C.
jmgrosen 12y ago
I don't think he means ABI in this strict sense, but just in terms of API compatibility.

scrollaway 12y ago

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.

maxlybbert 12y ago
I've always preferred Gtkmm over Qt. That might be because Gtk+ (and Gtkmm) doesn't try to be an "everything, including the kitchen sink" library (and, in related news, I've never been a fan of the Gnome API -- even though I was a fan of the Gnome desktop until Gnome 3). However, it's always seemed a little perverse to me to have Gtk+ try to imitate '90s-style C++ in C, and then to use a C++ wrapper around that.
- scrollaway 12y ago
  > doesn't try to be an "everything, including the kitchen sink" Qt5 and its modularity is the answer to your concern. If you don't want everything including QtKitchenSink, you can limit yourself to QtCore.
- chris_wot 12y ago
  The signals system of Gtkmm seems pretty neat.
jesuslop 12y ago
I agree, gtk2 was very nice and pleasant to learn, though gnomers have let the other camp to eat their lunch.
jeorgun 12y ago
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.
- derefr 12y ago
  How would people feel about a cleanup-focused API-compatible fork of Qt, in the style of LibReSSL?

deleted 12y ago

[deleted]

morganvachon 12y ago
This is why I prefer Crunchbang Linux (or more generally, a good OpenBox based distro) to Xfce or Gnome 3 these days. I can freely switch between using a GTK app and its QT or other toolkit-based equivalent, assuming such equivalent exists, without the risk of breaking anything on the GUI side. With QT in particular becoming much more modular, I also don't end up with hundreds of megabytes of KDE bloat to support one 10MB app.

raverbashing 12y ago

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 12y ago
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 12y ago
  GTK runs on Linux with X11, Wayland, and probably even some BSDs. Technically that qualifies as cross-platform.
  - dubcanada 12y ago
    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.
  - Pacabel 12y ago
    That's not what people mean when they say "cross platform". "Cross platform" means supporting all of the widely-used platforms at a given point in time, and supporting them well. Today, that includes at least Windows, OS X, and Linux. Some would even extend that to include the BSDs, Solaris, AIX and HP-UX. Like others have pointed out, GTK+'s support for OS X and Windows has been very, very lacking. It's nowhere near as seamless as that offered by Qt, Swing, or SWT.
- scrollaway 12y ago

jbk 12y ago

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

aceperry 12y ago
I remember when Gtk 2.0 came out. IIRC, at the time, Qt seemed to be bloated and slow compared to Gtk, but Gtk had a lot of breaking changes and was more work to program with. I was unimpressed with having to constantly figure out how to update my Gentoo system when Gtk kept moving functions from one library to another, which required hacking in symlinks to point to new libraries that programs required. It was a real pain in the ass and I finally moved onto Ubuntu. Gentoo had its own probs, but Gtk didn't help.
- kelnos 12y ago
  Er, what? I ran Gentoo from 2001 until mid-2013, and I was a maintainer and core developer of parts of Xfce (a Gtk-based desktop environment) from early 2004 until late 2009, and I have no idea what you're talking about. Gtk was a pain to develop with, sure, but only due to the awkwardness of GObject's attempts to build an OO system on top of C. From a user perspective, I never saw the problems you're describing. Even having built Xfce out-of-tree all the time, I never recall having to do a full rebuild due to a Gtk update. I've since moved on; it's a shame to hear what the OP is saying about 3.x, but 2.x most certainly didn't have these problems that you describe.

oliwarner 12y ago

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.

SoftwareMaven 12y ago
Can you explain testing actually solves this problem? The problem is multifaceted: it involves the behavior changes of a Gnome, which testing will find, and the unwillingness of some distros (I would imagine Debian is in there) to release new software for reasons other than security fixes, which testing doesn't and cannot address. The author makes it clear updating his code to fix the problems is not the problem.
- oliwarner 12y ago
  That depends what you consider the problem in the scale of things. Needing to fight library versions is a pain but if you know about it (which I'm saying you can) you can do things to ensure your software —your responsibility- keeps working. Testing helps you find issues before your users start knocking on your door and whining about broken software. They expect you to test. Is that fair? Not even the smallest bit... But it's the way things work. If you don't give a crap about your users, and you only do this as a programming exercise, let your users be your first line of testing. Again, I'm not saying that the problems described aren't real (or even that they're not frequent) but if you want to live in an ecosystem, you have to become a part of that. Get stuck in and fix these problems as best you can. --- And maintaining security-only release structures is designed to make this very problem predictable and maintainable. You know what's going to be in the release a month, two months before it's out. Testing and fixing then means your app works for the life of that release.
michaelt 12y ago
It's not fair to put all the blame on the end developer IMHO. I mean, in Windows, Microsoft obviously take care not to break binary compatibility - even across several generations of OSes. Right now, in my Windows VM I can run Office 97 on Windows 7 [1]. That's an 18 year old piece of software. And it's still working fine. I upgrade Ubuntu and it's a flip of a coin whether Google Earth will stop working. [1] http://www.microsoft.com/en-us/windows/compatibility/CompatCenter/ProductDetailsViewer?Name=Microsoft%20Office%2097%20Professional&vendor=Microsoft&ModelOrVersion=8&Type=Software&tempOsid=Windows+7 http://www.microsoft.com/en-us/windows/compatibility/CompatC...

skriticos2 12y ago

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 12y ago
I just finished watching this, it was pretty interesting. Thanks.

nawitus 12y ago

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.

ikawe 12y ago
> Even Node's package manager supports [parallel versions of dependencies] I feel like your emphasis is backwards. It's not surprising that NodeJS, a new project, has solved some of these problems. NPM has the luxury of decades of experience from dozens of linux package managers and package managers from other languages. Plus, they're not tied to the legacy use cases the same way that (e.g.) apt is.
- nawitus 12y ago
  I don't think it's surprising either, I just hope that Linux will solve the problem too. I guess I used the 'even' rhetoric because if Node could solve it, Linux (a much larger and better financed software ecosystem) should too.
- ClosureSpin 12y ago
  Do you have a link that would educate me about some of these problems? Package management interests me because I might find myself developing a package manager in the near future, but I don't know much about it. Not supporting multiple versions of the same software is something that I identified as a problem though.
  - vially 12y ago
    You might be interested in Nix: The purely functional package manager [0] [0] - https://nixos.org/nix/ https://nixos.org/nix/

samdroid 12y ago

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.

stefantalpalaru 12y ago

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/1135 http://redmine.audacious-media-player.org/boards/1/topics/11...

davvid 12y ago
Exactly. I feel like this post was blaming Gtk+ when it seems like the real problem was the distro not realizing that their package dependencies didn't trigger a rebuild. If something breaks ABI compatibility, that doesn't mean it is API incompatible. It just means all you need to do is recompile dependents and everyone's happy. It sounds like almost all of the problems in this post were caused by a failure to rebuild dependents. That's a general problem that can affect any library, not just Gtk+.
awalton 12y ago
> 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 12y ago
  If you really want to do that you should statically link it.
  - awalton 12y ago
    A wonderful idea. Let me just statically link an LGPL library into my Commercial application...
    - catern 12y ago
      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.

deleted 12y ago

[deleted]

rjzzleep 12y ago

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 12y ago
How is Qt not a proper GUI toolkit exactly?
yulaow 12y ago
I just hope in this growing on the adoption of Qt. In the long term it may automatically become the standard gui toolkit for linux

vfclists 12y ago

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.

bleh_ 12y ago

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.

pdkl95 12y ago

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.

dviola 12y ago
You mean Qt?
currysausage 12y ago
> 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!)
- pdkl95 12y ago

achiang 12y ago

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

Htsthbjig 12y ago

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.

matthiasv 12y ago

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

1ris 12y ago

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

bitwize 12y ago

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.