Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

GTK-- vs. QT 325

Posted by Cliff from the technical-comparisons dept.
spirality asks: "The company I work for is getting ready to decide on a GUI Toolkit for our Computational Modeling Toolkit (CoMeT, www.cometsolutions.com). We would like C++ compatibility and ports to various Unices and Win32 platforms. Not supprisingly we've come up with two choices, GTK-- and QT. I've attempted to compare the two by doing alot of web surfing and searching, but I've come up with things that are consistently one or more years old. So, the question I pose is what are the (dis)advatages of GTK-- and QT, and why would I choose one of these toolkits over the other? Overall functionality, momentum for future growth, ease of use, licensing, and pretty much anything else is relevant to our decision." With QT now at version 3.0 and GTK now in the 1.2.x revisions, maybe it's time to give the two libraries some fair comparison and discuss the new features, advantages, and disadvantages of each?
This discussion has been archived. No new comments can be posted.

GTK-- vs. QT More

GTK-- vs. QT

Comments Filter:

  • QT seems to rule (Score:2, Interesting)

    by PRobinson ( 471021 )
    I've recently got my Sharp SL-5000D which comes with a cute embedded version of QT. I'm starting to play with it some more, and I have to say I'm impressed. I've not done much GUI dev. under 'nix before, but I've followed many threads in the past elsewhere that suggests GTK is a hodge-podge and is getting out of control, with no coherent design.

    I'm not experienced, but as a lay-man, I'd have to say go for QT.

  • Qt if you need Win32 (Score:5, Informative)

    by Ami Ganguli ( 921 ) on Friday November 23, 2001 @08:33AM (#2603401) Homepage

    I actually prefer GTK+ and I think it's a better bet long-term, but I don't think the cross-platform aspect of the library gets much developer attention.

    Being cross-platform is a major selling point for commerical Qt users, however, so if you need your apps to work on Windows then it's clearly the way to go.

    • What about gimp? (Score:2, Interesting)

      by bani ( 467531 )
      Didn't they port gimp to win32?

      gimp is THE flagship gtk application, bar none.

      • Re:What about gimp? (Score:5, Informative)

        by Ami Ganguli ( 921 ) on Friday November 23, 2001 @08:58AM (#2603454) Homepage

        It exists, but I don't think it's maintained as well. The primary developers don't really care about Win32, so maintaining it is left to a few masochists :-).

        • Re:What about gimp? (Score:2, Informative)

          by egghat ( 73643 )
          yeah and that's a big shame.

          GTK porting was mainly done by one single person.

          I think, there are a few other GTK based apps, which Windows Users would like. But without a stable GTK on Windows?

          Bye egghat.
          • I regularly use the GIMP on Windows, and at least for me, it's at least as stable as any of my other Windows programs. Remember one thing: if it crashes running under *nix, people will get mad. Things aren't supposed to crash under *nix. If it crashes under Windows, people will more than likely say "humbug", restart their computer, and go on with things.

    • Re:Qt if you need Win32 (Score:4, Insightful)

      by Orycterope ( 67067 ) <joel.rainville@g ... minus herbivore> on Friday November 23, 2001 @09:12AM (#2603488) Homepage
      Being cross-platform is a major selling point for commerical Qt users, however, so if you need your apps to work on Windows then it's clearly the way to go.

      Absolutely.

      One important thing to note about Qt is the fact that it ain't a wrapper around existing GUI APIs. It emulates the different GUIs out there, so it does the drawing itself, avoiding going through some additional API layers. That translates into a fast and responsive GUI.

      I tried it on both Windows and Linux using the platform's native GUI and GUIs from other platforms, i.e. the Motif or CDE style on Windows, the Windows style on Linux. It is very convincing and very fast.

      When performance matters, I definitely go with Qt.

      Watch out for that "non-commercial" license on Windows though. It might not be appropriate for what you are doing. Your company will probably have to acquire a Qt license for Windows.

      • Re:Qt if you need Win32 (Score:5, Informative)

        by hattig ( 47930 ) on Friday November 23, 2001 @09:26AM (#2603518) Journal
        Knowing companies like I do, they will go with the most expensive solution - because expense usually means support. In this case QT is clearly the way to go, as everyone is pointing out (okay, wxWindows is another good choice, but I have no experience with this system).

        QT has an easier to program API, is quick to program in, has great documentation, has support, has a huge wealth of existing code examples, and is supported on Windows. GTK is not supported on Windows, and is a one-man port job. Fine for free software like the gimp, but not for a commercial application. Don't save a couple of grand on the GUI toolkit and get yourself a lot more costs in support that you have to provide because of problems.

        GTK2 might solve a lot of the problems in the current GTK of course, but I am not qualified to comment about that. And do you really want to program using a just finalised API?

        QT just does things right. 'nuff said.

      • Relying on a library that does UI emulation is a double-edged sword though. Since the emulation effectively replaces the native UI code, your app will lose all leverage from upgrades to the OS services. For example, an app that natively calls the Windows menu manager will automatically get the new windows XP look and feel for its menus. However, an app that uses a library that emulates the native OS will still have the old look and feel until the emulation library is upgraded. Since look-and-feel issues are the biggest gripes you will get from users when developing a cross platform library, this is not a decision that should be taken lightly.

        I've worked on two 1 million+ line sourcebases that were cross platform. One used a commercial porting library that was closed source but we had the source license for it. This was a losing proposition. If there was a bug, we could fix it in the library. However, that was a poor long-term solution because we were just patching the library rather than building a long-term cross platform infrastructure for our product.

        The second sourcebase I worked on used a home-grown UI abstraction. This one is a lot better because we have the ability to add or remove emulation as we wish. If we have an OS that doesn't support the services we need, we emulatate it. If the OS does support the services we need, we go directly to the OS and gain native look and feel with much less effort.

        For this reason, I recommend libraries that
        a) Provide a platform-neutral interface
        b) Implement the functionality by eventually calling the OS calls required to implement the functionality
        c) Is provided in source form so that you basically "own" the library. That way, any changes you make to the library improve your own long term situation.

        The only library I've seen that fits that requirement recently is wxWindows but I haven't used it for a real application so I can't comment on its suitability.

        Good luck
        • However, your point is rather moot because TrollTech quickly updates Qt whenever there are new Windows versions. For example, with win2k, they updated Qt before win2k was out to have the new fading animations, etc..

  • wxWindows (slightly OT) (Score:5, Informative)

    by Balinares ( 316703 ) on Friday November 23, 2001 @08:34AM (#2603403)
    You may also want to take a look at the wxWindows toolkit [wxwindows.org]. It's a wrapper over what's available on a given platform (the native API in Win32, GTK in the Unix world, and there's a Mac port in progress, I believe). Good stuff, definitely, especially if what you want is C++ and portability. Note that your apps will look totally windowsy on win32, so your users will not be confused by their look.

    • Mozilla (slightly OT too) (Score:5, Informative)

      by mvw ( 2916 ) on Friday November 23, 2001 @08:52AM (#2603442) Journal
      Another alternative is using Mozilla as IDE. This might sound a bit crazy right now, but I believe this idea will get more followers, if Mozilla gets more and more stable.

      An example is the Komodo IDE [activestate.com] by ActiveState, which uses XUL.

      XUL [xulplanet.com] is the next generation browser application platform. Simply speaking, the Mozilla [mozilla.org] team chose an approach very similiar to JAVA [sun.com] to come closer to a platform independent graphical user interface:

      • implement a set of base compenents on the most popular platforms (Win32, Mac, UNIX, ..), that render your JAVA specific widgets in terms of the native GUI.
      • implement your applications in your JAVA language
      • compile application
      • distribute JAVA binaries

      XUL goes one step farther, as there is no compilation step.

      The XUL application implementation language is a XML language that together with cascading style sheets and JavaScript glue will yield an application one starts in the browser by opening the .xul document.

      A possible advantage of XUL might become the relative ease of application development, change and distribution.

      Possible problems will be similiar to the ones known from JAVA. The qualitiy of XUL applications will stand and fall with the quality of the XUL implementation for a specific platform, which right now means the quality of its Mozilla or Netscape implementation.

      Of course, compared to JAVA, which has underwent several larger development cycles and now features mighty libraries, XUL is a bleeding edge technology at its beginnings.

      However it is still possible to make direct use of the various Mozilla widgets as well from C++.

      • I've played with Komodo, and I have to say that I'm impressed. XUL+Moizilla can certainly be turned to one's advantage. I imagine that the crucial point is where you put the dividing line between your app and the UI. I would think that you'd want to build only the highest level UI pieces in XUL, and then the rest of your app in a low level language.
    • > Note that your apps will look totally windowsy on win32, so your users will not be confused by their look.

      Which Qt does as well. I find wxWindows too MFC-y too use tho, although it is quite a viable alternative to Qt, especially for open software on Windows.

      However, If you want a high quality professional toolkit, stick with Qt. gtk--? no way, it's not in any good shape.
      • Have you used FLTK or FOX as well? Any recommendations on the best out of those? I'm writing myself a front end to control the parallel port for some electronics stuff I'm doing, and I'm getting pissed off with being stuck in DOS. :-) A free toolkit to write a decent GUI interface would be ideal for me, especially if it was cross-platform.

        Since I can't afford the megabucks for a QT Windows license, I guess I'm stuck with GTK, wxWindows, FLTK or FOX. So which one to go for?

        Also, do any of these make it easy to do user-customisation of menus, toolbars etc, similar to current MS Office apps? Or docking windows?

        Grab.
        • It depends on if you want to release it.

          You can always use Qt non commercial on Windows for free without spending the megabucks.

          I've used FLTK, but it's a bit too light for my tasts.

          So, I think either wxWindows or Qt is your best bet.

          Qt does docking windows. Both Qt and wxWindows have good toolbar classes.

    • Re:wxWindows (slightly OT) (Score:5, Informative)

      by Sludge ( 1234 ) <[gro.dessot] [ta] [todhsals]> on Friday November 23, 2001 @03:58PM (#2604310) Homepage
      I second this, and find it not offtopic at all. wxWindows doesn't get anywhere near as much press as the other toolkits, but it's got fully fleshed out documentation available in a number of formats, active developers, four mailing lists of which I can attest the developer one getting 15-20 messages a day and ships with tons of code samples.

      The license it's under is acceptable (to me), and there are working large apps such as Audacity [sourceforge.net] out there.

      When I discovered all of this, I decided to look into the technology side of things. To throw more goodness at you, let me say reiterate that the toolkit looks native to your environment which is a big win. On top of that, it lets you do things which aren't lowest common denominator and exist in only one or more environments, such as toolbar icons in Windows.

      I also like the class hierarchy. I had never done GUI programming before but everything came across rather clearly when I started reading the documentation.

      Additional to all the "low level" GUI junk, it also contains some routines for networks and a portable wxString class which is a lot like stl::string with more methods added. I found myself using this almost immediately and I haven't looked back.

      It's worth learning this stuff just to get away from MFC without taking the speed hit of learning Java/Swing and having to learn a whole new language and culture. There is even some boasting about how 'the Java honeymoon is over' on the page, stating that wxWindows is actually a more portable toolkit. :) ymmv.

      There are both Python and Perl bindings for it. I haven't looked into either really, but at least the Python ones seem to be of high quality as a number of people on the mailing list are Python programmers.

      Check it out [wxwindows.org] before coming to a conclusion of what toolkit to use. It's worked for me.

    • Good stuff, definitely, especially if what you want is C++ and portability.

      QT is excellent on both counts.

    • Re:wxWindows (slightly OT) (Score:5, Informative)

      by mill ( 1634 ) on Friday November 23, 2001 @07:01PM (#2604989)
      If it hasn't been mentioned yet

      Al Stevens took a look at both Qt and Gtk-- in the September and October issues of Dr Dobbs Journal.

      What he didn't like with Qt:

      • No namespaces
      • Language extensions to implement slots
      • An ill-organized and unnecessary RTTI mechanism
      • Custom rather than standard containers
      • Questionable C++ coding conventions

      The last (I think. I only have October) refers to that Qt takes ownership of objects instantiated on the heap i.e. new without a corresponding delete. Which means you have to do all instantiating on the heap because there is no portable way for Qt to know if it is on the stack, external, or static memory.

      He thinks Gtk-- remedy all these problems and he actually found the tutorial funny albeit a work in progress.

      /mill

  • ...but a little slow on Solaris 8. Maybe it is just me, but my build of Mozilla really jerkey on a workstation (UltraSPARK III, 2G RAM). On the other hand The Gimp runs like a dream on my Windows box, and Mozilla is zappy on Linux.

    --
    Dooferlad

  • licensing (Score:5, Informative)

    by Cardinal Biggles ( 6685 ) on Friday November 23, 2001 @08:41AM (#2603418)
    Overall functionality, momentum for future growth, ease of use, licensing, and pretty much anything else is relevant to our decision.

    To pick up your point on licensing, Qt is either GPL or pay. So if your application will also be GPL, it's free, if your application will not be GPL you will have to pay up for Qt. GTK is LGPL AFAIK (enough acronyms for you? ;-) so that will not stand in the way of making your app non-free.

    BTW, if you know C++ and want to get to know a bit about Qt, they have a pretty good tutorial online here [trolltech.com]. Just walking through the examples made me realize just how cool it is, and how much you can do in just a few lines of code.

    • Re:licensing (Score:3, Informative)

      by Snowfox ( 34467 )
      Overall functionality, momentum for future growth, ease of use, licensing, and pretty much anything else is relevant to our decision.
      To pick up your point on licensing, Qt is either GPL or pay. So if your application will also be GPL, it's free, if your application will not be GPL you will have to pay up for Qt. GTK is LGPL AFAIK (enough acronyms for you? ;-) so that will not stand in the way of making your app non-free.

      Just remember that you only need to give your source to any entity you give the binary to. Being GPL/LGPL doesn't mean you can't use it for business use; the license is entirely transparent for apps which will only be used internally.

  • Licencing (Score:3, Insightful)

    by CH-BuG ( 55283 ) on Friday November 23, 2001 @08:43AM (#2603423) Homepage
    If you intend to develop a closed-source product, the licence of both library will probably need to be evaluated too. If you go for
    an open licence, then it's of minor importance.
    (Qt requires licencing fees if you want to keep
    your sources closed).

    • Re:Licencing (Score:2, Informative)

      by zmooc ( 33175 )
      As far as I know/understand, QT is GPL and GTK is LGPL so you can't make a closed-source application based on QT unless you buy a license from Trolltech.
    • I think Qt comes out ahead on the free/licensing issue; if you want to use it for free software, then Qt is GPL'd, but if you want to use it for commercial software you need to buy a licence - but most importantly that also brings you commercial support. In either case you have the source so that you can fix bugs or figure things out for yourself, but if you're working on a commercial project and under deadline pressure it's nice to have that commercial support available.
      • I think Qt comes out ahead on the free/licensing issue; if you want to use it for free software, then Qt is GPL'd, but if you want to use it for commercial software you need to buy a licence


        Actually, this is one point where Qt comes out way behind. Gtk++ is LGPL, which frees you to build commercial apps using it with no cost. Qt has a very infectious license where if you at any time use a free version of Qt on your project, then you can never release your project commercially.



        And Trolltech dismisses shareware completely. They consider it to not be a viable approach, and so Qt can't be used for it.

        • > Qt has a very infectious license where if you at any time use a free version of Qt on your project, then you can never release your project commercially.

          Huh, what FUD. Qt has nothing of the sort.

          > And Trolltech dismisses shareware completely. They consider it to not be a viable approach, and so Qt can't be used for it.

          No they don't. If you have a commercial license, you can sell as much properitary, close source shareware as you want. If you use free Qt, you can sell as much of open sourced shareware as you want.

  • Qt has better documentation (Score:5, Interesting)

    by tgreiner ( 107912 ) on Friday November 23, 2001 @08:44AM (#2603427) Homepage
    I have only scratched the surface of both GTK-- and QT, but I found QT to have a *very good* documentation. It has a complete class hierarchy documentation and comes with a load of example programs.

    Another observation is that GTK-- is much more low-level than QT. If you want to extend it's components you might have to delve into the depths of the gdk library (which, in my view is only a thin wrapper around the X11-libs). QT on the other hand has a very good abstraction of windowing system details. Being mostly a Java programmer, I found the QT model very easy to use.

    Of course, YMMV.
    • > QT on the other hand has a very good abstraction of windowing system details.

      Yup, this is because Qt is not a gui-toolkit but rather an application framework. It provides classes that work equally on all platforms that Qt supports, saving the user from writing a bunch of #ifdefs for particular platforms. It works really well :)

  • GTK+ C++ wrappers (Score:5, Informative)

    by HalfFlat ( 121672 ) on Friday November 23, 2001 @08:44AM (#2603429)

    I worked on a rushed project earlier this year, and used the gtk-- C++ wrapper for GTK, as well as the gnome-- wrapper (then still very much under development) for the Gnome libraries, specifically the canvas.

    Personally, I found it frustrating to use. As these wrappers are still being worked on, the documentation is sketchy. The object-owning semantics are confusing (at least to me) - I was forever leaking memory or prematurely destroying objects. Trying to destroy something from within a menu callback I recall was particularly noisome. The gnome-- canvas wrappers were a moving target, though they may have since stabilised, and didn't fully expose the canvas API. Writing one's own canvas items is done in C, and then wrapped.

    Perhaps with more persistance I might have figured out how to set up keyboard acceleration, but it is at anyrate a real battle to find documentation that explains what is going on with it. AFAIK, there is no straightforward way of making a multiple file selection in GTK+ 1.2. In gnome canvas (not GTK+, but a close cousin) there is promised functionality that is simply not implemented - I'm thinking here of smoothed lines, for which the code reads:

    /* FIXME */

    I haven't used QT yet. It certainly looks pretty, and a quick glance at the example code and docs provided seems to indicate that it's not too complicated, and well documented. I'd certainly shy away from GTK+ if a C++ interface is required.

    The new version of GTK under development should address many of the shortcomings of the current toolkit, and includes goodies such as Pango. It is not yet in a stable state, however, with the API still undergoing final tweaking I believe.

  • A third alternative... :) (Score:3, Informative)

    by jonathan_ingram ( 30440 ) on Friday November 23, 2001 @08:45AM (#2603431) Homepage
    I'm a great fan of Qt, but I don't believe it's always the best toolkit to use for cross platform compatibility (although it is the best toolkit available for UNIX-based systems), plus there are complications about the licenses differing versions are available under. GTK-- and its competitors (Inti?) only have a very small user and documentation base, so they are probably not a good choice for a large commercial project.

    If you want cross platform compatibilty with C++, then check out wxWindows [wxwindows.org]. It has ports to Windows, MacOS (9 & X), UNIX + Motif, UNIX + GTK. It also has a very well developed Python binding [wxpython.org] -- so well developed that quite a few people want it adopted as the official Python GUI instead of TKinter.

    • > good choice for a large commercial project.

      Nah, Qt itself is probably the best choice for a commercial project. I'd use wxWindows for free software that targets many platforms tho, and Qt for X11-only free software.

      > wxPython

      Yeah, wxPython's really nice.

  • Before the flame wars start... (Score:5, Insightful)

    by CaptainAlbert ( 162776 ) on Friday November 23, 2001 @08:47AM (#2603436) Homepage
    My suggestion - try them out.

    Come up with a few small use cases and let your developers loose on everything you can get your hands on. Both Qt and GTK+ are freely available enough for that to be a useful exercise.

    You might find that, while Qt has nicer abstractions, and provides a familiar set of classes which are (IMO) far superior to MFC... perhaps GTK has a slight edge for lower level work (which it sounds like you might get involved in). Also, see which interface builder tools your team feels most comfortable with.

    The problem with this question is that the replies are likely to degenerate quickly into a C vs. C++ rant-a-thon. Yes, GTK is entirely written in C. But it *is* object oriented. It seems strange to everyone at first, but just because a language doesn't support particular features, doesn't mean that you can't use a particular programming style. OO methodology is just as relevant to C programmers as to C++ or Java programmers.

    If your programmers are good, they'll write good code whatever the toolkit. Just make sure everyone thinks that they got a say in the decision. ;-)
    • The problem with this question is that the replies are likely to degenerate quickly into a C vs. C++ rant-a-thon. Yes, GTK is entirely written in C. But it *is* object oriented. It seems strange to everyone at first, but just because a language doesn't support particular features, doesn't mean that you can't use a particular programming style. OO methodology is just as relevant to C programmers as to C++ or Java programmers.
      Of course. The OO features of C++ can be largely implemented in C, using structs and function pointers. Both ObjC and C++ are just C with some extra syntactic sugar...not that that is a bad thing. =)

  • Portability to Win32 (Score:4, Redundant)

    by kintel ( 28098 ) on Friday November 23, 2001 @08:51AM (#2603441)
    AFAIK, the Win32 port of GTK+ is more or less a one-man show, making GTK pretty unstable and lagging behind on Windows.
    In addition, Qt now has a Mac OS X port.

    Add this to the excellent commercial support from Trolltech.

    Design and language issues not taken into account.

    • Re: OS X port (Score:2, Interesting)

      by smurfi ( 91140 )
      The downside is that QT is slow, which is because they fake all the high-level UI calls with low-level code. That's how you can run a QT program on the Mac, but with Win32 or Motif look-and-feel.

      The HUGE disadvantage is that QT programs will never be as fast as "real" Mac programs, because all the UI stuff (bitmaps for buttons, for instance) will eat up memory space and disk access time. The other programs get the UI for free.

      It's also a practice Apple doesn't like. At all. Remember the Mozilla port?

      There's also the danger that OS X will pick up some new feature, like for instance voice-controlled mouse movement to UI elements or whatever. Every program will magically work with them, except for QT-based programs which will just sit there and look stupid until Troll gets around to update their (closed-source!) Mac port. :-/
      • > The downside is that QT is slow,

        No, in fact, quite the opposite is true. It'd be faster than solutions that simply wrap around native API calls.

        It is like in the Java world between AWT (Java 1.0.x) and Swing (Java 1.2.x). AWT tried to simply wrap around the native toolkits. As a result, it was quite slow. Swing does it like Qt, and provided an API for drawing widgets, much like Qt does with QStyle.

        > eat up memory space and disk access time.

        I think they alleviated this by using QPixmapCache. It should be only a tad bit slower, if not the same speed as regular OSX apps. Either way, an user would not know the difference in speed.

  • Some REAL points (Score:5, Insightful)

    by faber ( 142067 ) on Friday November 23, 2001 @08:53AM (#2603446) Homepage

    Developing for a professional product I would always go with as many professional tools as possible.

    To me QT seems to be the FAR better decision. It has true interoperablity between Win32, MacOS X and X11.

    QT is C++ from the ground up, GTK-- is wrapping GTK++.

    Furthermore with GTK you definitely write more code to accomplish the same.

    QT 3 gives you access to SQL-databases from its widgets.

    QT comes with a very good interface builder.

    QT based programes feel snappier than GTK based ones.

    One drawback might be that you have to preprocess (actually your Makefile has to) your code before its ready for the compiler, but that's not a big deal.

    With Kdevelop you have access to a very good IDE.

    One thing I don't know is how QT works in terms of different GUI threads, but I neither know for GTK.

    So please, go with QT and be happy

    A much harder decision would be: What should I use for my Web-Frontend, mod_perl or PHP... but that's a different story!

    • Re:Some REAL points (Score:2, Insightful)

      by bigtoy ( 170668 )

      What does having Kdevelope have anything to do with Qt? Regardless of whether you use Qt or gtk based systems you can use Kdevelope. Looks like you are grasping a bit here.

      Why do I care that the widgets provide SQL? I may consider that bloatware and more that I want for my development needs.

      I know lots of professionals that go with products that are open source and not termed "professional" because they are not backed by a company. A good number of professionals use tools that they can modify and see the internals. (Both available for Qt and gtk, so no harm no foul.)

      Qt feels "snappier"? Puh-lease. Lets live in the land of the subjective here. You are obviously lost. Look into the role of the WM.

      BTW, I am not endorsing either product. Just playing the "Devil's Advocate". I hate to see biased, pointless, not clearly thought through arguments used to push someones view.

      • Why do I care that the widgets provide SQL? I may consider that bloatware and more that I want for my development needs.

        You may not care. Many application developers in the world need both rapid development and database access. This feature is something they would care for very much. Yours is a poorly thought through argument.

        Qt feels "snappier"? Puh-lease. Lets live in the land of the subjective here.

        He was being subjective, so are you.

        You are obviously lost. Look into the role of the WM.

        If the same functionality under the same WM has a feel of faster feedback with a Qt application than with a GTK-- application, that kind of eliminates the role of the WM, doesn't it?

    • QT is C++ from the ground up, GTK-- is wrapping GTK++. Correct me if I'm wrong, but neither "signal:" not "slot" are C++ constructs. You still have to use the moc utility to translate your code into standard "C++". QT is C++ only to the extent that "Objective C++" can be considered C++.

  • Mozilla? (Score:3, Insightful)

    by dannyspanner ( 135912 ) on Friday November 23, 2001 @09:00AM (#2603458) Homepage
    I'm not trying to sound stupid or off-topic here, but have you considered Mozilla [mozilla.org]? Beyond ther browser, they've developed a really interesting cross-platform C++ (and JavaScript) development platform. For a start there's a cross platform implementation of COM [mozilla.org] and you can develop your UI's in an XML dialect called XUL [mozilla.org].
    • When running Mozilla on my old P233, I could literally see the space for a menu blocked out, then the lines of text for menu options drawn to the screen one after the other. The only other time I've experienced anything with a user interface this slow is when I'm running X applications on servers in the States from our offices in the UK. Mozilla is simply unacceptably slow.

      Grab.

  • New GTK+ (Score:4, Informative)

    by JanneM ( 7445 ) on Friday November 23, 2001 @09:12AM (#2603484) Homepage
    Don't forget that an all-new GTK+ version is just coming out, a cleaner design, vastly improved i18n support, and all. I suggest you look at GTK2 (and it's C++ wrappers) as well, as this is what's going to be used, rather than the current version.

    /Janne

    • Re:New GTK+ (Score:2, Insightful)

      by elflord ( 9269 )
      Don't forget that an all-new GTK+ version is just coming out, a cleaner design,

      If they're redesigning the toolkit with every major release, that's a bad sign. Qt has not changed substantially since 1.x, the main difference is that functionality has been added to a rock solid infrastructure.

      BTW, when is the GTK documentation going to be available ? IMO if there isn't any documentation, it doesn't even deserve to be called "1.0".

  • Well.. (Score:2, Insightful)

    by DGolden ( 17848 )
    Geez. Talk about flamebait topic. Personally (and personal opinion only, here), I'd say, Qt is better designed, clearer, and easier from a programming standpoint - but it's actually not clean C++, what with its dodgy signals/slots stuff, that gtk-- manages to do within the bounds of the language.

    If you're writing commercial, proprietary software, then you have to pay to use Qt - but Trolltech provide a thoroughly professionally supported toolkit to you for your money.

    The Qt class library is actually more akin to the standard set of Java classes than just a widget set - there's decent cross-platform support for sockets, xml, threads, unicode, etc. It really makes C++ programming very easy.

    OF course, there's other cross-platform C++ tollkits like FLTK [fltk.org]... The gui toolkit page [geocities.com] lists many more.

  • If internationalisation matters... (Score:3, Insightful)

    by tempfile ( 528337 ) on Friday November 23, 2001 @09:19AM (#2603497)
    ...go for Qt. Gtk, IMO, has the huge disadvantage that the current 1.2 revision doesn't support Unicode, whereas Qt fully relies on it and even provides GUI-independent helper classes for all kinds of Unicode conversion that you can use anywhere in the program. This would also help for the mathematical symbols that you probably want to display. It looks like Gtk2 will use Unicode and Pango, thus potentially blowing away the competition, but as long as there's no stable version of Gtk2, I'd go for Qt.
    • > It looks like Gtk2 will use Unicode and Pango, thus potentially blowing away the competition, but as long as there's no stable version of Gtk2.

      However, Gtk2's win32 port will likely remain a very unsupported port. While qt's win32 port is as important if not more important (because of commercial licenses), than their X11 port.
      • Well, sure there is a difference between "designed for" and "ported to" (tho for some "designed for" means "press release for").

        GTK 1.x was always portable -- designed so -- because the GDK was an abstraction layer that allowed porting to nearly anything someone had a desire to port onto (win32, framebuffer, whatever). I've used GTK under Python, and while it's slower than native Windows UI, it's more than acceptable for GIMP.

        This fellow really needs to prototype some stuff using *each* of the closest candidates. If his schedule does not include time for prototypes, the software will be ready for a code rewrite MUCH sooner than they expect. I do Software QA, and I've seen the effects of rushing a project without proper homework up front. You *always* throw away some code, like it or not...

        >However, Gtk2's win32 port will likely remain a very unsupported port.

        Opinion presented as fact. There are *many* projects using GTK on Windows... just like there are many Qt projects on Windows. They're just ot very prominent (aside from GIMP).

        .. And from what I read on the mailing lists, GTK 2.0 will be "officially supported on Windows (whatever that means), and the rendering rewrite has eliminated that "slow redraw" problem of GTK 1.x.

        Cheers..

  • I switched from Gtk-- to Qt (Score:3, Insightful)

    by Per Abrahamsen ( 1397 ) on Friday November 23, 2001 @09:22AM (#2603507) Homepage
    From a conceptual point of view, I like Gtk-- better. It actually uses the modern C++ language, including the C++ type system. This way you avoid the need for a preprocessor, and get static typechecking instead of "dynamic typechecking" (i.e. "the user does the checking"), which is the entire point of using C++ in the first place. It also use the standard C++ library instead of duplicating it poorly, so you don't have to deal with multiple string types and the like. Since the application is a GUI frontend to a library written in standard C++, using the standard C++ library classes, this matter a lot. Qt is written for an ancient subset of C++, something closer to "C with Classes" than the C++ standard.

    However, Qt is simple to use, well documented, and have stable API's. In practice, these make it much easier to use than Gtk--.

    As an extra plus, Qt is GPL and therefore more gnulitically correct than Gtk--, which is only LGPL.

    • As an extra plus, Qt is GPL and therefore more gnulitically correct than Gtk--, which is only LGPL.

      The LGPL was written specifically to get around the 'viral' aspects of the GPL. Meaning that while Gtk-- gives you the option to GPL your product, QT does not. With QT you MUST use the GPL... unless you pay Troll Tech an arbitrary, although currently quite reasonable sum.

  • The big difference is that gtk-- is based on the C++ standard library, and so allows you do use familiar and efficient constructs like std::vector, std::string and so on.

    QT has reimplemented all those things as a rather dodgy set of proprietry classes, which lock you into, for example using QString rather than std::string throughout your application, or doing a lot of extraneous conversions every time you need to talk to the GUI.

    In its favour, QT does have much better documentation than gtk--, but all the same, I prefer the standards based gtk--.

  • Easy! (Score:4, Funny)

    by zensonic ( 82242 ) on Friday November 23, 2001 @09:50AM (#2603589) Homepage
    Qt is 3.0

    Gtk is 1.2.x

    Sure it's friday, but come on, thats easy 3.0>1.2, so the choice must be Qt!

    Same reasoning shows that Windows 2000 are MUCH better than Windows 98 which in turn is slightly (by 3 point) better than Windows 95, which again are MUCH better than windows 3.11.

    Sigh. Does you youngsters not learn anything today?

  • Some points from using Qt. (Score:5, Informative)

    by hpj ( 26910 ) on Friday November 23, 2001 @10:19AM (#2603660) Homepage
    I have been using Qt for some years now starting with Qt 1.0 some years ago. I have also tried to both patch GTK+ programs and in one instance port one of my Qt applications to GTK+ (I was preferring gnome at the time).

    The advantages I can see from using Qt is:

    * Superb design. The OO design of Qt is really thought out. There are virtual function to do all the basic things you can think of and if you think of something really clever there are lowlevel routines to do that too.

    * Superb documentation. A comprehensive, hypertext help and in Qt3 an included help browser. This is really an advantage since GTK+ not really being supported by a commercial entity suffer from lots of "I'll rather code than document" in the libraries.

    * Good migration path to new versions. I have a program consisting of ~100000 lines of code (An Oracle client http://www.globecom.net/tora) which I migrated to Qt3.0 in about 2 hours, some of that time was spent using Qt3 specific features also like docked windows where appropriate.

    * Not only a GUI toolkit. It also includes primitives for handling threading, I/O (files and sockets), UNICODE conversions and also some basic template classes made mostly obsolete now that STL is starting to actually work in GCC.

    * Truly multiple platform. The application above was ported to Windows in about a day, all of the problems related to the fact that Visual C++ understands a different dialect of C++ than most of us are used to and that took some time write around, none of it was Qt specific. The extra thread and I/O classes really helps here as well.

    /Mauritz
    GlobeCom AB

  • Clearly an unfair comparison... (Score:4, Funny)

    by pastie ( 80784 ) on Friday November 23, 2001 @10:22AM (#2603673)
    ...as everyone knows that the software with the highest version number is obviously the best.

    (Score:-1, Sarcastic)

  • If you want better cross platform support.. (Score:3, Insightful)

    by MongooseCN ( 139203 ) on Friday November 23, 2001 @10:26AM (#2603678) Homepage
    ..make your application interface independant. The idea is to make your program a basic application that can run without a gui. The gui is then a plugin or something. That way you can take one application and write a gui using gtk, QT, win32, whatever you want and never have to rewrite the application. This is how licq works. The licq application is stand alone and you can download interface plugins for it, QT plugins, gtk plugins even command line plugins. This is great for me since QT doesn't run on the platform I use, so I have to use the commandline plugin.

    Don't lock yourself into one gui and hope that it will cover all the platforms you need, most of them don't. Allow any kind of gui to work with your program, not only is it more cross platform compatible, but other people can create guis for your application without ever have to touch the applications code.
    • This is a good idea, but a plugin interface might be more than you need if the interface is going to be your only plugin.

      A better idea might be to use #defines and #ifdefs and other magical compiler directives, write some wrapper functions if necessary, and then at compile time, decide which toolkit you're compiling for.

      #define TOOLKIT gtktk
      #include

      Or something of the sort.

      --Dan
  • Lately I've been using, of all things, GLOW [sourceforge.net]. GLOW is a cross-platform toolkit built on top of OpenGL and GLUT. The internal architecture is sound, but the widget set is sparse. I've had to fix a few problems in GLOW, but nothing serious. GLOW is on SourceForge.

    GLUT, the widely used cross-platform wrapper for OpenGL, has problems when used in a multi-window application, and those problems affect GLOW programs. I've been documenting the problems and sending them to the current maintainer of GLUT, and they may eventually get fixed. Supported platforms are Win32 and X.

    These alternatives are only useful if you're writing a 3D application. Otherwise, use one of the 2D toolkits.

  • My company went through this... (Score:5, Informative)

    by cjhuitt ( 466651 ) on Friday November 23, 2001 @01:42PM (#2603772)
    About a year ago, the company I work for went through this. (This was before I worked for them.) The company debated the merits of Gtk-- and Qt. The basic conclusions were that Qt would (or at least, should) have the better support and documentation, and lack minor irregularities. However, when it was all computed, the deciding factor was the licensing fees. Since our software would be quasi-commercial (we are a consulting company, but for a fee, we provide companies with portions of our software as well) we would have to pay the licensing fee for Qt. This was a lot more than was thought our ~6 person (at the time) company could afford, so we went with Gtk-- pretty much only for that reason.

    Now that we have been using Gtk--, we have relatively few regrets. The documentation was poor, for a time, but they have semi-recently improved the documentation, and it is quite workable. There are some small things that you would think would be done differently, but overall they are very minor and easy to live with.

    Since we aren't concerned (yet) with porting our software, that wasn't much of an issue. Of course, your situation may be different there.

    Finally, echoing what other people have said here, Gtk-- can be quite low level at times. I would recommend that if you decide upon Gtk--, you do what our company has done. We created our own set of libraries that provide standard looks to things with minimal hassle, derived from the Gtk-- classes. An example of this would be windows. We have our own window class that sets up standard options that Gtk-- allows to vary considerably. (Additionally, it automatically checks for certain keystrokes, like the F1 key, and signals that fact.) Making a button class would be similar, so all of your buttons are approximately the same size, have the same shading, etc. We were late in figuring this out, but it has greatly simplified our code and made our program look much more consistent.

  • Dr. Dobbs articles. (Score:2, Interesting)

    by bigtoy ( 170668 )

    Al Stevens provides a column in Dr Dobbs Journal titled "C Programming". In the Sept-Oct 2001 columns he described issues he ran into testing both the Qt and GTK-- class libraries. I do not have the articles here but Al gave some pretty good C++ aesthetical reasons for staying away from Qt. Specifically he mentions having to re-compile some of the Qt libraries so that he could extent their class to properly convert from a STL String to their Qt string class.

    He had many other reasons for not using Qt. When I get back to work from this long holiday I will post an outline of his specific reasonings.

    Just to clarify. I am not an Al Stevens "fan". The man really seems off his rocker sometimes. However, the articles on Qt and GTK-- were very informative. And yes, I did investigate a few of the items for myself. (Do not trust my word though, get the article, read the article, try it out for yourself!)

  • and some other toolkits too. Each one has its distinct advantages although if I were to make such a decision it would be a no-brainer to go with Qt. Gtk-- lacks documentation, seems to have an inconsistent API which is still in a state of flux (not good when you're trying to write an app with it that has a definite deadline on it).

    Others wrote there are other toolkits as well but IMO they are nowhere near the usability of Qt. The often mentioned wxWindows is a wrapper around native widgets meaning that things like widget alingment issues become a pain in the butt as each platform will have widgets drawn in their native size. Also widget toolkits that wrap native widgets are diffucult to extend (by class derivation) so if you need to create your EnhancedComboBox from their ComboBox it's sometimes difficult to accomplish with wrapping toolkits. Personally I think going with an emulating toolkit is better than using a wrapping toolkit (fewer headaches). If you don't agree think for a minute why Swing in Java is considered an improvement over AWT. Same reasons.

    FLTK is sweet if you don't need advanced widgets and i18n. They finally got their issues with keyboard focus fixed so it begins to look more and more like a real alternative. However, they use char* for text handling all over the place so it's certainly a disadvantage if you need unicode support. However, it is small and it is fast but it's only good enough for simple UIs.

    You can't go wrong with Qt it gives you the power of something like MFC in a more digestible form with cross platform portability to boot! Also the sheer number of widgets available for it is pretty amazing. Oh, and the slot/signal thing isn't half as bad as some people here make it out to be.

    1 vote for QT here.

  • GTK-- is not GTK+ (Score:5, Interesting)

    by marble ( 120353 ) on Friday November 23, 2001 @02:45PM (#2604094)
    A lot of people seem to have missed that the question was asking for opinions on GTK-- (now gtkmm), not GTK+. The difference being that gtkmm is the C++ interface to GTK+, so no C vs C++ dilemma exists here - both are C++.

    Well, nearly. If you're from a standard C++ background (as I am), you will find gtkmm preferable, as they don't reinvent parts of the standard library (eg QList vs std::list), they use namespaces and templates (including giving familiar, STL-style interfaces to container widgets etc), and it's implemented entirely in C++ (whereas Qt is in a C++ like language that must be first preprocessed to produce C++).

    But, as someone before me said; get both, try them, see which you prefer - there are obviously people who disagree with me, as KDE and Qt are popular.
    • "[...] Qt is in a C++ like language that must be first preprocessed to produce C++."

      First of all that is a serious exageration! Second it does not matter even if from a esthetical point if view the preprocessing of the headers is not nice. Why? Because the decision for a specific product/venor leads to vendor lock (see Anti Patterns) in any case.

      You rely on a library. Your code will not compile if that library is not there! In the case of Qt you also rely on a little preprocessor program --- so what? If you use GTK or Win32 or MFC that don't need the preprocessor what is the difference? You cannot take your MFC program and compile it using say GTK.

      The only thing you can do is to try to introduce clear layers that separate you program logic from the GUI to contain and localize the damage in case you have to go from one GUI library to another.

      This is also my answer to the criticism that Qt (which was started in pre STL times if I am not completely wrong) uses non-STL containers. Separation of GUI and core program allow you to use more approprate/modern/protable technologies in the core. It is the architect's/designer's/programmer's choice where to use these non-standard constructs and how deep you will move into vendor lock.

      Especially tricky in the case of Qt is that Troll Tech also offers a Qt specific abstraction layer for low-level constructs like threads/locks/sockets, etc. This means that if you are not carefull your software is locked at the top and at the bottom. If these low level services are used I would recommend to wrap them into a platform isolation layer. In the case you want to change you can replace these services using the native OS constructs or libraries like ACE, etc.

  • GTK--/Qt are not the only choices (Score:3, Informative)

    by VZ ( 143926 ) on Friday November 23, 2001 @03:39PM (#2604252)
    [disclaimer: my real email address is @wxwindows.org]

    > Not supprisingly we've come up with two choices,
    > GTK-- and QT.

    This surely is surprizing to me. I wouldn't consider GTK-- a serious choice for writing Win32 programs - sure, it "works", but have you seen it and/or used any GTK+ programs under Windows? But I would consider FOX, FLTK and wxWindows as serious contenders to Qt.

    I can't speak of the others but let's compare wxWindows and Qt:

    1. wxWin has almost all of the features Qt has
    (it doesn't have some, but then it has some extras)
    2. wxWin is free (as in beer too) for all uses
    3. wxWin has native LNF, even under Windows XP
    (which can be a serious advantage if you
    target this platform).

    But try it for yourself - wxWindows 2.3.2 is scheduled for Dec, 2 and has quite a few interesting new features. And see www.wxwindows.org for more info.

  • GTK+ and Objective C (Score:2, Interesting)

    by Nicopa ( 87617 )
    As it was mentioned before (and many times) GTK+ is coded in C, but is still object oriented. It uses an ad-hoc object system with dynamic typing, single inheritance. It's clean, but it's rather clumsy looking. If it had some kind of pre-processor it would look much nicer... wait! that would be just objective C! Wouldn it be nicer to have implemented gtk in Objective C? Just a random thought..

  • Try FLTK (Score:2, Interesting)

    by Taco Cowboy ( 5327 )


    Try FLTK { www.fltk.org }

    You won't be disappointed with the Fast and Light Tool Kit.

    For download, go to ftp://ftp.fltk.org

Slashdot Top Deals

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Close