Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
GUI Graphics Intel Programming

Intel Dev: GTK's Biggest Problem, and What Qt Does Better 282

Posted by timothy from the choosing-sides dept.
Freshly Exhumed writes "Phoronix has an article about how Dirk Hohndel of Intel's Open-Source Technology Center has stirred the hornet's nest with a talk at Australia's Linux.Conf.Au (MP4 file) about what he views as the biggest problem with the GTK: he finds dealing with upstream GTK/GNOME developers to be tough, with frequent abuse and flame-wars, with accusations from the developers that "you're doing it wrong." Conversely, he found the Qt development community to be quite the opposite: willing to engage and help, with plenty of application developer documentation and fewer communication problems than with their GTK counterparts."
This discussion has been archived. No new comments can be posted.

Intel Dev: GTK's Biggest Problem, and What Qt Does Better More

Intel Dev: GTK's Biggest Problem, and What Qt Does Better

Comments Filter:

  • GTK is trash (Score:3, Insightful)

    by JDG1980 ( 2438906 ) on Thursday January 16, 2014 @09:38AM (#45975671)

    I don't understand why anyone would use GTK. It's not noticeably easier to use than other toolkits. It doesn't have a "native" look and feel on any system (if you run GIMP on Windows, you'll notice how all the dialogs are much different than what you're used to seeing in other applications). It's cross-platform, but so are Qt, WxWidgets, and probably a bunch of other GUI toolkits that don't come to mind at the moment. So what's the appeal?

    • Re:GTK is trash (Score:5, Funny)

      by Anonymous Coward on Thursday January 16, 2014 @09:40AM (#45975689)

      pissing you off, mainly.

    • Re:GTK is trash (Score:4, Informative)

      by Anonymous Coward on Thursday January 16, 2014 @09:45AM (#45975727)

      Many years ago it was the only FSF-approved cross platform toolkit, so it gained a fair amount of momentum because of that. Qt has since moved to a more favorable license but a lot of people have yet to migrate.

    • Qt and wxwidgets aren't particularly good at blending in with native apps either. Qt5 have dropped any use of native widgets beside for backwards compatibility afaik. All gui toolkits suck in different ways. Qt doesn't appeal to pure C programmers because it's C++, personally I don't particularly like it as C++ programmer because it doesn't use the language to its full potential and employs hacks like MOC. But it's the only more-or-less complete cross-platform C++ GUI toolkit atm.

      • Re: (Score:2)

        by satuon ( 1822492 )

        Qt4 didn't use native widgets either, so Qt5 didn't 'drop' them.

      • Re: (Score:3)

        by tibit ( 1762298 )

        You're someone who doesn't value your own productivity if you resort to calling code generators hacks. It's not a hack, it's something that lets the machine do the work a machine can do, instead of forcing a human intervention in generating introspection data. Calling moc a hack is like calling a lexer or parser generator a hack. Now I'm not commenting on the quality of the moc code itself, just on the general approach of leveraging computers in all aspects of software development, not merely to run the res

        • It is a hack because it does nothing useful that you could not do with later versions of ANSI C++. For whatever reason Trolltech decided they couldn't trust ANSI C++ compilers to be present on the system.

          • Sorry, but that is just not true: moc does add meta data on objects (their methods, properties, etc.) that is _not_ available in ANSI C++. Not even with C++11.

            • Re: (Score:2)

              by tibit ( 1762298 )

              Yep. The best the C++ standards folk has come up so far is a bunch of proposals that try to get some of moc's functionality into C++. Normal people, who have some perspective, would call moc visionary and ahead of the time (if Common LISP is ignored, of course). Clueless people, well, remain clueless. It makes me a bit happy that I could, if I were looking for work, sell myself to the employers with full knowledge that a large bunch of behind-the-times folk are proclaiming that staying less productive is so

              • MOC sucks period. You can implement all of those paradigms in C++ without the use of a pre-compiler. I mean GTK+ does it in C so you surely can do it in C++. And it doesn't take forever to compile code with it.

                As for ANSI Common LISP I haven't programmed it in yonks and the reasons are usually the same. Generally shitty compilers which produce slow native code, bad GCs, fragmented support for ANSI Common LISP features, poor interfacing with C system libraries, etc.

            • C++ has RTTI typeid and dynamic_cast. People usually deride MOC not only because it makes compilation loads slower but because Qt's signal and slots mechanism sucks. I personally think it is WORSE than the GTK+ signal mechanism. GTK+ doesn't need a pre-compiler either.

              • Boost manages to do signals in C++ without a precompiler as well.

                • Yeap. But Boost does not allow to inspect which signals/slots and properties are available on any given object.
                  That is the information moc generates. Signals and slots in Qt just use that information, just as a host of other things including the language bindings, some runtime debugging tools and lots of other things.

              • Exactly. Plus C++11 has given us new tools to do sig/slots way more efficiently now.

          • Re: (Score:2)

            by tibit ( 1762298 )

            You really should keep your mouth shut if you neither understand what C++ can and cannot do, and what moc actually does.

      • Comment removed based on user account deletion

    • Re: (Score:2)

      by jythie ( 914043 )
      On the other hand, it is GTK is LGPL rather then GPL, which means many projects favor it for pragmatic or philosophical reasons. WxWidgets, while the license is pretty permissive, has some pretty sketchy bindings (ok, I am mostly thinking wxPython, which makes my life miserable). So GTK can be a 'best worst option'.

      • Qt on the other hand is available in LGPL, GPL or proprietary licensed form. You are free to pick whatever works best for your project. I really fail to see how GTK can be better than that on the licensing front.

    • Re: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

    • Re: (Score:2)

      by caseih ( 160668 )

      The appeal of GTK is that from a programmatic pov (and I haven't yet watched the talk so I could be wrong, but this is my experience) and API than Qt, and much much better than wx. Furthermore GTK has much better bindings in various languages than Qt, mainly because it's C-based. PyGTK (now replaced with Pyobject) is very pythonic, whereas PyQt is really just C++ transliterated to Python.

      GTK's biggest problems come from trying to develop new GTK objects in C. A ton of boiler plate code. But nowadays you

  • Woot! (Score:5, Funny)

    by Anonymous Coward on Thursday January 16, 2014 @09:40AM (#45975685)

    There hasn't been a good GTK / Qt flamewar around here for ages!

    Now that Qt is free, shouldn't we be migrating away from GTK?

  • GTK+ is a C library (Score:5, Informative)

    by i ate my neighbour ( 1756816 ) on Thursday January 16, 2014 @09:53AM (#45975793)

    The only reason to use it now is if for some reason you want to avoid C++ and develop in pure C.

    • Re:GTK+ is a C library (Score:5, Insightful)

      by Brandybuck ( 704397 ) on Thursday January 16, 2014 @11:34AM (#45976855) Homepage Journal

      When it comes to the UI, objects are natural. Every C toolkit goes through hoops to provide you with objects of some kind. Motif, GTK, etc. So why not just use an object oriented language to begin with?

      You don't have to use the dark corners of the language. Qt sticks to just the Object Oriented parts of C++, with just a tiny bit of templates. Not a functor in sight (unless you wander toward the totally optional Qt::Concurrent framework). Internally it uses all of the language, but as an API it provides just the object oriented subset.

  • "Intel Dev" in Headline is misleading (Score:5, Interesting)

    by t_hunger ( 449259 ) on Thursday January 16, 2014 @10:06AM (#45975915)

    Dirk stated in his presentation that this is his own, private opinion he is presenting here and not that of his employer Intel.

    So the headline is technically correct, but that Dirk works for Intel is not relevant in this context at all.

    • Re:"Intel Dev" in Headline is misleading (Score:4, Insightful)

      by smash ( 1351 ) on Thursday January 16, 2014 @12:12PM (#45977313) Homepage Journal
      Well, it does give some background that he is actually deemed to be employable by intel, rather than some hack pumping out shit in his bedroom.

      • Re:"Intel Dev" in Headline is misleading (Score:4, Insightful)

        by t_hunger ( 449259 ) on Thursday January 16, 2014 @03:03PM (#45979009)

        First I am almost 100% sure that there will be some idiots employed by Intel somewhere. Every big company has some of those around. So "works for company X or Y" is not a qualification in my book.

        Second Dirk is making it very clear that he is speaking as a private person about a hobbyist project of his, not as an employee of some company. So there is no reason to bring the company into the discussion. People will misread the headline to mean that this is something that Intel is doing. Just check this thread: One misguided individual is asking: "How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason? Are you now going to flame Intel because their developers are saying the same thing?".a couple of comments down. It is not Intel speaking, it is not even "their developers". It is just one single guy speaking about something that is not related in any way to what Intel does. These misunderstandings were needlessly created by the headline.

        Seriously: This is slashdot. How many people here on slashdot bother reading more than the headline? :-)

  • Qt, on the other hand, is its own universe. It's written in a weird dialect of C++98 (though I'm sure it works just fine in C++11 these days), it has its own object model, networking stack, container library, threading library, graphics primitive library (i.e. not Cairo). This object model also leaks into its language bindings if you don't want to write your software in C++.

    It's the same problem that Java and C# also suffer from: they're not cross-platform, nothing is. What they actually are is their own pl

    • Re:GTK+ is standalone (Score:5, Insightful)

      by t_hunger ( 449259 ) on Thursday January 16, 2014 @10:49AM (#45976341)

      I would argue exactly the other way around: Qt is stand-alone and GTK is not. If you want to write any app you need more than the UI. You actually want the application to *do* something but render a couple of widgets.

      With GTK you end up hunting down a host of glib/gnome based libraries, all with slightly different peculiarities and all of them coming with little useful documentation. How is that stand-alone? With Qt you get everything in one convenient package (and are still free to leave out the parts you do not need in your binary packages).

      Qt is a C++ library: Any C++ compiler can compile it on a wide range of platforms. How would that be possible if Qt was written in a weird dialect?

      Of course the object model leaks into the language bindings. How could it not be? The same is true for "object-oriented" libraries written in C.

      Yes, even with Qt you can not get perfect cross-platform applications. You will need to some platform-specific code in any non-trivial application. That is perfectly possible in Qt... and it still gets you at least 90% of the way! That was the other reason for switching that Dirk gave in his presentation: That GTK does *not* run properly on windows nor on Mac. He claimed that some core GTK people are actually opposing the toolkit working on those platforms and that independent teams are trying to maintain the cross-platform parts as good as they can against a hostile core team.

      Subsurface was cross-platform with GTK and it looked like shit on *all* platforms incl. Linux. The Qt port looks way better -- they could finally get the UI they wanted but could not manage to implement in GTK -- and works equally well on all three target platforms. Check the demo right in the middle of the video: Dirk shows of the new UI and contrasts it with the old one in pretty gory details. So, yes, Qt is not perfect, but it is pretty good nontheless:-)

    • Re:GTK+ is standalone (Score:5, Informative)

      by Gravis Zero ( 934156 ) on Thursday January 16, 2014 @10:57AM (#45976435)

      it has its own object model, networking stack, container library, threading library, graphics primitive library (i.e. not Cairo).

      the toolkit is split into modules that can be used completely independently of each other. If you only want the GUI stuff, you can use just the GUI module.

      This object model also leaks into its language bindings if you don't want to write your software in C++.

      binding are completely third party software to Qt. you might as well complain about gtkmm while you're at it.

      It's the same problem that Java and C# also suffer from: they're not cross-platform, nothing is. What they actually are is their own platform built alongside a perfectly good already-existing one, and you can see the seams. There's more to each platform's UI than what bitmap you skin buttons and checkboxes with.

      obviously you have not used Qt in the last five years.

      where is the "-1 Ignorant" mod?

    • Re:GTK+ is standalone (Score:4, Informative)

      by tibit ( 1762298 ) on Thursday January 16, 2014 @11:00AM (#45976463)

      There is no way other than having a meta-platform that can abstract things away from the physical platform it runs on. A platform is not merely the UI. If you really want to write cross-platform code that has native-API-using GUIs, you'll still find yourself having to use a platform abstraction for all the non-GUI stuff like events, threads, containers, strings/internationalization, etc. Even if this abstraction is provided by the standard C++ library, it's still an abstraction, and you can still choose who provides it - compiler vendors are just one in a crowd here.

      There is a very good reason that Qt has its own object model etc. It's because all those things, done natively, are full of inconsistencies, bugs you have to work around, and other shortcomings that have you, the brave cross-platform coder, having to re-do things again and again.

      No, using Qt core and networking for non-GUI platform abstraction is no different from using Boost. Just that with Qt you have the option of using the gui stuff, and platform-specific extras, and qt quick, and a whole bunch of other goodies that you get nowhere else.

      There is nothing wrong, of course, with doing the core of your application using Qt's core and networking modules, and doing the UI natively. Often, though, you'll find that the native way will not give you as many advantages as you thought you had.

      Never mind that even some "native" ways of doing things do it exactly the way Qt does it. For example, WPF on .net is not using native legacy winapi windows controls, since they render everything using GPU acceleration and conceptually are much closer to Qt Quick 2 controls. So even your own "stay native" argument flies in the face of what the "native" platform vendors are themselves doing!!

    • Re:GTK+ is standalone (Score:4, Informative)

      by BravoZuluM ( 232200 ) on Thursday January 16, 2014 @11:01AM (#45976485)

      How is this insightful? GTK guys modding this up? FUD. Qt is not written in some weird dialect. Where'd you pull that factoid from? I compile QT all over the place, Windows, Mac, LInux and embedded Linux using the VS C++ compile or gcc. On each of those platforms, it works VERY well. It's cross platform; more so than any other framework/language I've worked with. Qt apps look like Windows apps on Windows, Mac apps on Mac, Linux apps on Linux (if there really is such a thing)

    • Re:GTK+ is standalone (Score:5, Insightful)

      by Brandybuck ( 704397 ) on Thursday January 16, 2014 @11:50AM (#45977035) Homepage Journal

      "weird dialect of C++98" - WTF? What is this dialect you speak of? Do you need to pass --weird to G++ to get it to compile? Of course not! It's using the same C++ every other C++ app in the world is using. Both C++98 and C++11 are supported. It doesn't REQUIRE you to use C++11, but that is a benefit not a drawback.

      "it has its own object model" - Of course it does, that's because C++ does not have one of its own. QObject is there to provide for the introspection that C++ lacks. Once you have that introspection you can start communicating with other objects. I fail to understand why this is a disadvantage in your eyes.

      "networking stack" - Of course. Why should it not? It is an cross-platform application framework.

      "container library" - When Qt began the STL was fragmented, not standardized, and poorly supported. Yet containers are useful. Qt kept them around because they turned out to be better than the STL containers. They're a balance between raw performance and the "bloat" of pure templatized containers. Externally they end up being 100% compatible with the STL.

      "threading library" - It was only extremely recent that C++ got its own threading, and it's just very low level threading. Qt threading provides a nice usable wrapper around threads (which are native C++ threads underneath if built with C++11), and the ability to easily communicate between threads with signals/slots.

      "graphics primitive library" - Why not? Seriously, why not? Isnt't that the whole point of a GUI toolkit? Underneath it draws widgets using the native controls, if available, or uses its own if not. That's why the widgets look like native controls on Windows and Mac, because they ARE native controls! On X11 it will draw its own. It doesn't use Cairo, why should it use Cairo, who made Cairo king that we all have to bow down before it?

  • Not all that surprising (Score:5, Interesting)

    by Octorian ( 14086 ) on Thursday January 16, 2014 @10:07AM (#45975927) Homepage

    Gtk+/GNOME (in popular form) basically exists because of a flamewar, so is it any surprise that the community is still like that?

    It always struck me as a bunch of stuck up C developers who outright refused to use C++, on principle alone. So instead, they implemented everything C++ does on top of C, using macros and coding conventions. They later managed to spin their crusade as "actually" being about the licensing issues with Qt at the time. While those licensing arguments may have been valid, to me they always felt like little more than a cover for a C vs C++ fight. However, it made their side of the story a lot easier to sell.

    • No. People just used GTK+ because GIMP used it as a toolkit. Eventually someone pushed GNOME around but that was later.

  • And why are we listening? (Score:3, Funny)

    by evilviper ( 135110 ) on Thursday January 16, 2014 @10:09AM (#45975943) Journal

    That's awfully big talk, from the company that unleashed EFI upon an innocent and unsuspecting public.

  • Open Source Culture (Score:3)

    by EmperorOfCanada ( 1332175 ) on Thursday January 16, 2014 @10:09AM (#45975955)
    I never really thought about it but different OS project have vastly different cultures. I have long had a happy relationship with Qt; I was worried a bit after their Nokia purchase, and then really worried after MS bought Nokia; but all seems to still be good. For instance the Python culture is embroiled in a civil war with 2.x vs 3.x. And quite clearly some OS projects are very responsive to customers (For example the warning that git screamed after typing "git add ." disappeared. Other projects like Boost are definitely populated by academics, and so on.

    I generally have stayed away from GTK and part of that reason might be that I sensed an unfriendliness there.

    • Re: (Score:2)

      by HiThere ( 15173 )

      Saying "the Python culture is embroiled in a civil war with 2.x vs 3.x" is grossly misstating the position. Both Python2 and Python3 are currently supported, and, as much as feasible, fixes to Python3 are backported to Python2. A lot of people still use and develop in Python2, but it's no longer recommended for new projects. (It will be EOLed in a year or so. I believe 2.8 is intended to be the last version, but it could be 2.7, as I haven't kept current.) That said, 2.7 is stable and well supported on

    • Re: (Score:3)

      by jbolden ( 176878 )

      When MS bought Nokia, Nokia had already sold Qt to Digia.

  • Native Widgets (Score:5, Informative)

    by robmv ( 855035 ) on Thursday January 16, 2014 @10:23AM (#45976109)

    Can we stop spreading false information about QT?

    the native widgets for OS X / Linux / Windows

    QT doesn't have native widgets for any platform, QT draw the widgets with their own code, it only skins them with the platform APIs if they are available, Quoting myself [slashdot.org]:

    Native controls means more than to have the same look, if that is the way to measure "nativeness", then Java Swing UIs (Windows/GTK L&F) are native because they call platform theme APIs.

    When a toolkit draw controls by itself, the applications normally lose a lot of UI functionality, for example, if Android/iPhone controls add proper default assistive technology metadata to their controls, the toolkit (QT in this example) need to do the same for each control they draw, because the OS don't see buttons as buttons, It see them as a custom control. If the platform control change behaviour in a new OS release, the QT control will not see it, for example when Windows added default context menus to the text fields, self drawed controls don't expose that behaviour until applications are updated with a new version

    • Re:Native Widgets (Score:4, Informative)

      by satuon ( 1822492 ) on Thursday January 16, 2014 @10:48AM (#45976329)

      In reality, I've never noticed practical differences between Qt and a native application on Windows, or on Gnome Linux. On Android currently it doesn't look native at all, but that's because it's not implemented yet, they plan on doing it later.

    • Re:Native Widgets (Score:4, Informative)

      by tibit ( 1762298 ) on Thursday January 16, 2014 @11:04AM (#45976513)

      You do know that Qt has had accessibility support for quite a while now, in both Qt 4 and Qt 5? You do realize that WPF itself is not using the native winapi controls, and is peddled as the "new native way" of doing controls on Windows? You do realize that Qt does way more beyond mere native-looking-skinning of controls? It does actually re-implement platform-specific behaviors on a lot of controls, often in ways that are much simpler to code for than whatever native legacy boondoogle of an API someone at MS or Apple has conceived?

      There is something to be said for having uniform principles for the design of an application framework, and Qt is reasonably good in that department. My experience is that the non-nativeness of Qt-provided controls is something that is hard to notice if it can be noticed at all, if the application developer has done their homework.

      • Re: (Score:2)

        by tibit ( 1762298 )

        Basically, Qt is doing controls on Windows the same way Microsoft is doing controls on Windows these days. So stop with the FUD.

      • Re: (Score:2)

        by robmv ( 855035 )

        Accessibility was an example, I was referring about updates to the OS Widgets not being inherited by QT because QT does not have native widgets. It doesn't matter if Microsoft is doing the same with WPF, QT doesn't have native widgets, plain and simple. is that good or bad? is your call.

  • That's Depressing (Score:4, Insightful)

    by zakkudo ( 2638939 ) on Thursday January 16, 2014 @11:09AM (#45976573)
    I feel like all the time I donated helping with gtk questions on the gtk irc channels was useless now. )-:

  • It was like this a deacde ago, too. (Score:5, Interesting)

    by Lendrick ( 314723 ) on Thursday January 16, 2014 @12:48PM (#45977669) Homepage Journal

    My experience with asking for help with GTK was having random people rudely tell me that I should go read the documentation (which, incidentally, I *did* read, and it was woefully incomplete). Qt actually has good documentation, but in the rare instances when I need help, people are always happy to assist. I wouldn't touch GTK again with a ten foot pole.

Slashdot Top Deals

If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson

Close