Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

TrollTech Releases Qt 3.0 285

Posted by Hemos from the comin'-at-you dept.
Dr. Sp0ng writes: "TrollTech released Qt 3.0 today. Among the new features are platform- and database-independent data-access features, data-aware GUI widgets, a much-updated Qt Designer, and much better internationalization and font handling features. It breaks binary compatibility but keeps almost complete source compatibility with Qt 2.x. The KDE team has already begun work on KDE 3.0, which will use the new toolkit."
This discussion has been archived. No new comments can be posted.

TrollTech Releases Qt 3.0 More

TrollTech Releases Qt 3.0

Comments Filter:
  • While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries. The glibc mess has made binary compatibility between distributions more and more difficult, and important libraries like Qt and the various KDE and GNOME libs regularly break binary compatibility. I realize a lot of this has to do with the C++ ABI; have the GCC people thought of any ways to make binary compatibility easier to maintain in C++ programs without requiring vtable hacks and other ugliness?

    As Linux comes of age, this is an important issue. Major companies want to bring their software to Linux, but often give up when face with the nightmare of having to support the thousands of subtly different library interfaces. Working to maintain binary compatibility for new versions of software would be a good goal for Linux's advancement.

    • Re:Binary compatibility (Score:5, Informative)

      by Dr. Sp0ng ( 24354 ) <mspong@nospaM.gmail.com> on Monday October 15, 2001 @06:26PM (#2433784) Homepage
      While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries.

      This is an issue with C++... since most of KDE's widgets are subclasses of Qt widgets, they are very dependant on the signature of the Qt class. When the class signature changes (for example, when a function is added or removed, or a data member is added), the derived class needs to be recompiled or the linking will be all screwed up. This isn't an issue between minor revisions of the library as the API is stabilized, but with a major jump (2.3.1 -> 3.0), the API or implementation changes and things must be recompiled.

      It's impressive that TrollTech (which is a great company, btw) managed to keep source compatibility so well. I'm a professional developer and we're using Qt for our app (which is currently ~20,000 lines), and exactly *1* line of code needed to be changed when we moved from 2.3.1 to the 3.0 betas.

    • Re:Binary compatibility (Score:2, Informative)

      by davecb ( 6526 )
      As another commentator pointed out, this can be hard if your C++ compiler gets in the way (;-))

      The general problem was solved back before Unix (on Multics, to be precise), and an equivalent problem was solved for databases by the relational algebra folks.

      You need a motivation to do it, though, and that motivation's not there. You need to be worried about stability without preventing innovation. A few years back a quite large part of it was solved for Suns by My Evil Twin, David J. Brown: a two-part version number for every interface in the libraries, checked at link time.

      --dave

    • Re:Binary compatibility (Score:5, Interesting)

      by elflord ( 9269 ) on Monday October 15, 2001 @07:37PM (#2434087) Homepage
      While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries.


      The short answer is yes, there has been. The biggest problem has been with the C++ libraries, and g++ is finally standardising on a stable ABI.
      As for Trolltech, they've always worked hard to maintain binary compatiblity (eg minor releases are binary compatible), indeed there were more
      problems with binary compatiblity caused by libstdc++ issues than with Qt itself. I'm not
      sure that KDE has been as stable, though this
      should improve. (The move to DCOP resulted in growing pains)


      To get some appreciation of how fragile binary compatibliity is, read this [trolltech.com]. Binary compatibility is fundamentally
      difficult to preserve in C++, and I don't think there's any clean way around it. Fundamental
      changes in interface or exposed structure
      (that means anything besides opaque pointers) will break binary compatibility.


      Personally, I think the fundamentals need to be
      nailed down. C++ and C libraries need to preserve
      binary compatiblity. On the other hand, I don't
      think there's a problem with other libraries, so long as they maintain binary compatiblity across minor releases. (users could install multiple versions of the same library)

    • have the GCC people thought of any ways to make binary compatibility easier to maintain in C++ programs without requiring vtable hacks and other ugliness?
      >>>>>>>>>
      Hopefully, C++ binary incompatibility should be passe. There is a standard C++ ABI for Itanium, and GCC 3.0's C++ ABI should be standard for x86. I don't know if other compiler vendors will follow suit (one hopes, but doubts), but the GCC people shouldn't change it.
      • Doesn't the standard ABI only address binary compatibility across libraries compiled by different compilers? I.e., now you may lose binary compatibility between otherwise compatible libraries if they are each compiled with a different compiler.

        But won't you still lose binary compatibility when you change the source sufficiently? For instance, don't most C++ compilers use offsets to refer to the various instance variables, and won't those offsets change as you add or remove variables?

        I suppose for virtual methods calls you could preserve binary compatibility. Does Qt use virtual methods for everything?

        And if everything was virtualized, wouldn't C++ be about as efficient as Objective C (or maybe even GCJ'd Java)? Or is there some fancy translation that C++ will do when linking, for a one-time-only cost (for each application startup, but not every call)?

        I know little about the internals of C++ compiled code and linking, so I really don't know.

        • You're perfectly right about breaking binary compatibility due to source changes. I was talking about binary compatibility between GCC releases (C++ libraries in GCC break every new release). As for virtual methods, they don't totally solve the problem, but don't incur a speed hit either. The virtual method type thing you're referring to is what COM does. You can't easily subclass such an object, and most C++ libraries depend heavily on that capability. Second, virtual C++ calls are no slower than C library calls. In C, all library calls refer to a table of function offsets. The call first jumps to that table, which then jumps to the actual function. (Or it reads the address of the function from the table, it depends on the implementation.) This is done so that you can map libraries into different places in the process address space (say one day at 0x600 then the next at 0x1200) and you only have to change the values in the table rather than all the function calls in the code. With C++ virtual function calls, the process is similar (in Visual C++'s compiler anyway). When the library is dynamically linked to the program, the vtables of each class are written with the addresses of the functions that implement each method. Thus, the call is a single-indirect calls, just like a C library call.
    • I realize a lot of this has to do with the C++ ABI; have the GCC people thought of any ways to make binary compatibility easier to maintain in C++ programs without requiring vtable hacks and other ugliness?

      C++ doesn't have a standard ABI, and can't sensibly have one. For a start, there's nothing in the rulebook that says you must implement virtuality using v-tables. Even if you do, there is more than one possible way to implement multiple or virtual base classes, for example. Imposing a required ABI would force compromises in the efficiency of C++ code, which is against the spirit of the language.

      Basically, you're using the wrong tool for the job if you try to impose an ABI on raw C++ classes. If you want binary compatibility between C++ libraries, you should be advertising a higher-level interface using something like COM or CORBA or whatever other features your platform provides. You can always build something like this on the efficient base C++ provides, but if you compromise that base by trying to impose a defined ABI, you're taking the wrong approach, IMHO.

  • Something to think about (Score:5, Insightful)

    by Reality Master 101 ( 179095 ) <RealityMaster101@gma i l .com> on Monday October 15, 2001 @06:20PM (#2433750) Homepage Journal

    How far would Microsoft have gotten if they "broke binary compatibility" with major releases of Windows? Basically, not far at all. That's not to say that Windows has perfect backward compatibility, but I don't think it's too strong a statement to say that one of the reasons Microsoft has dominated is that they have given people an upgrade path for their old applications.

    Of course, the downside to this philosophy is the incredibly crufty interfaces to a lot of the Windows functionality. But I think it's key to point out that users don't care at all about those things -- they just care that their applications work.

    If the desktop dreamers ever want to see Linux on the desktop, then they need to not destroy everyone's applications if you want to upgrade. Just telling everone to "recompile your applications" is not going to fly well with the typical user.

    • Re:Something to think about (Score:5, Insightful)

      by Skeezix ( 14602 ) <jamin@pubcrawler.org> on Monday October 15, 2001 @06:22PM (#2433762) Homepage
      I am sure that KDE 3 and KDE 2 can be installed in parallel. That's what we're doing with the GNOME 2 release. In other words, you'll still be able to run you're GNOME 1.x applications...you just have to have the GNOME 1.x platform libraries on your system in addition to the GNOME 2.x libraries. Distributors such as Red Hat will take advantage of this, so your apps won't "break".

    • How far would Microsoft have gotten if they "broke binary compatibility" with major releases of Windows? Basically, not far at all. That's not to say that Windows has perfect backward compatibility, but I don't think it's too strong a statement to say that one of the reasons Microsoft has dominated is that they have given people an upgrade path for their old applications.


      Just keep the old major version around, what's the problem with that? I have both Qt 1.x and Qt 2.x installed already and I can happily run programs linked against both.

      Windows has problems with having different versions of a dll installed at once leading to what is often called dll hell, but this is not a problem with Unix.
      • Qt 1.x and Qt 2.x installed already
        >>>>>>>>
        Great, now you'll have Qt 1.x, 2.x, AND 3.x.

        UNIX is about power, elegance, and simplicity. Somewhere along the line, elegance and simplicity got lost in features and bloat.

    • Re:Something to think about (Score:2, Informative)

      by Anonymous Coward
      There are binary compatibilities between certain Microsoft operating systems. When going from Windows 3.x to Windows 95 Microsoft had to keep all the old libraries in addition to the new Win32 libraries. In the case of XP, Microsoft came up with a library of "shims" - wrappers around the program that successfully routed the calls to a similar method.

      Linux distributors use a method similar to the first one - they supply both libraries. However, the binary library for Qt is just 5MB, a tiny amount - libc5 is even less, and in the long run it makes for a better API, a cleaner system, and far faster software development.
    • I call bullshit.

      Here's a simple exercise: go to the nearest Windows machine, preferably one loaded with lots of apps of various vintages, and delete all but the newest VBRUN*.DLL, MFC*.DLL, etc. Then see how many of your apps work.

      When Microsoft releases new widget sets, API's, etc., older applications do not automagically use them. Having, for example, MFC 2 and MFC 3 on your system isn't any different from having Qt 2 and Qt 3 on your system.

      What Microsoft did get right, is the installation procedures: have multiple libraries sitting on the same machine if necessary, but don't bother the user about it -- it's not their problem.
    • How far would Microsoft have gotten if they "broke binary compatibility" with major releases of Windows? Basically, not far at all.

      How far would MS have gotten? Probably up to about 20 megs for a basic install instead of 100. Maybe 64 megs of RAM total instead of 128 recommended for Outlook alone?

      You take on bloat when you keep providing older interfaces and older subsystems.

    • Well, Apple has done it three times: with System 7, Power Macintosh, and now OS X. In the old days this was a pretty major pain in the butt (of course Mac fans took it all, like abused lovers) but these days the sw vendors are being nice and shipping both binaries (OS X and Classic) together. So, while undesirable, isn't the end of the world.

  • Professional user of QT 2.12 (Score:4, Interesting)

    by anfloga ( 139529 ) on Monday October 15, 2001 @06:26PM (#2433781)
    And all I can say is, what a joy to work with this QT toolkit is.

    Before I wrote software which uses QT, I wrote it using Motif. The designer that comes with QT is light-years ahead of any designer I've used for Motif. The "slot/socket" mechanism that it uses allows me to use a more abstract GUI design. And the geometry management is much nicer as well.

    Just thought I'd throw those thoughts in. No, I don't work for Trolltech. Lykke til Trolltech!

    Hope I said that right. It's been years.

  • Qt improvement BETTER than KDE improvements (Score:4, Offtopic)

    by alexhmit01 ( 104757 ) on Monday October 15, 2001 @06:29PM (#2433801)
    KDE is an impressive desktop, it works nicely, and has really grown. I always play with new releases on a Linux box, though my daily desktop in a Win2K laptop. It's fun to watch Linux's desktop grow, but I need too many Win32 only programs. My G4 Cube is fun as well, but I still have the Win32 problems, so the laptop stays.

    However, looking at two "market" outcomes: Win32 vs. Cocoa|Carbon vs. Qt/KDE vs. Gtk, OR Win32 vs. Qt, and you clearly see which API system is more likely to allow competition on the desktop.

    Java held great promise, but MS has succeeded in killing desktop Java. Without WORA, there is no real advantage to Java (the platform), but Qt has an interesting perspective.

    As Qt Designer grows, it can become competitive to Visual Studio. Potentially, Qt becomes the glue that binds everything together.

    If you can build a Qt application for Linux/MacOSX/Win32, or a Win32 app for Win32, there is an advantage to make the former. You still need to QA all the platforms that you support, but Qt lets you produce a product for multiple markets.

    For a small company, Linux/MacOS provide a niche to target, but adding Win32 really makes this compelling. The windows market is MUCH more competitive, so being apple to primarily target niche markets but still selling to the dominate market is tempting.

    Go Trolls go!

    Alex
    • This is great, but.... there is one major problem with your arguement.

      In order for you to make your Qt application cross platform (linux/win32), it's gonna Cost ($$$) you an arm and a leg in license fee's for the Win32 version of Qt, which, by the way is NOT FREE.

      Don't get me wrong, I love Qt, but if it costs me $2k to 3k grand to make my application cross platform, forget it! I cannot afford that. In addition, if a commercial company wants to develop software for linux, they too have to purchase a Qt license ($$$ several grand), unless they want to release their app under GPL, which means they can no longer expect to sell their app and make money.

      So just because Qt is free, as in GPL, it doesn't make it more free than Gtk, which is LGPL. GTK apps face none of the problems that Qt apps incurr. A GTK app can be make open source or closed source, and can be made cross platform or uni-platform... ALL FOR FREE.

      And that, folks, is the biggest difference between the two widget toolsets!

      • In order for you to make your Qt application cross platform (linux/win32), it's gonna Cost ($$$) you an arm and a leg in license fee's for the Win32 version of Qt, which, by the way is NOT FREE.

        Ahh, but it is. Qt/Win32 is now licensed similarly to the X11 version - free for open source stuff, expensive for commercial stuff.

        • No, it's not (Score:2, Informative)

          by GCP ( 122438 )
          I just came from their site. I just read the FAQ. They reiterated the point in several of the answers: "no, you have to buy the pro or enterprise version if you want to sell on Win32", "no the free version is not even available on Win32, only the pro or enterprise version," "no, you *can't* even develop for free on Win32 and then pay for a license when you decide to start selling, the Win32 license requires you to pay us, even for development...."

          They couldn't be much clearer. Or, are you saying that their Website is wrong?

      • but if it costs me $2k to 3k grand to make my application cross platform, forget it! I cannot afford that.

        Well, I don't think trolltech is targeting developers like you, or companies that can't afford a couple thousand in development costs. And as far as I know, there's no "official" win32 GTK version out there, except for this: http://www.gimp.org/~tml/gimp/win32/ [gimp.org], from which I quote the top line: "I do this work in my free time, so don't ask me for release timetables etc. If you want some new feature, you are free to suggest it, but don't hold your breath."

        Is that a statement you want to build your corporate software around?
      • In order for you to make your Qt application cross platform (linux/win32), it's gonna Cost ($$$) you an arm and a leg in license fee's for the Win32 version of Qt, which, by the way is NOT FREE.

        WRONG, WRONG, WRONG. Completely false. See the Qt non-commercial license. I can't believe this crap is marked as "informative".

        • FAQ you. [trolltech.com] In short, any version of Qt released under the non-comm license is free as in beer, but not Free as in speech. There are two notable issues:
          1. No source code. You're stuck with the binaries only.
          2. Incompatible with GPL. It's a non-Free, 3rd party library, which is a no-no in GPL'd projects. From the README [trolltech.com]:
            If you wish to port one of the many GPL'd Qt-based Unix applications to another operating system using the Qt non-commercial edition, you need to get that application's copyright holders to add an exception to its license.
          Favorite quote from the FAQ: "Once Microsoft Windows is completely open source, we will reconsider." So there. Nyah! They still can't tell the difference between taunting Microsoft (which they're not), and taunting Windows developers (which they are).

    • I have to beg to differ. If MS can destroy desktop Java by simply not bundling it with their OS, then desktop Java was dead already.

      In fact, the wide range of systems on which network clients written in Java can operate was and is one of the main reasons why we did Ganymede in Java.. we can and do run our client on Win32, Mac OS (8, 9, and X), OS/2, Linux, FreeBSD, Solaris, HP/UX, AIX, etc., etc., etc.

      In the real world, Java is still the best at client-side WORA if your demands for performance and features can be satisfied with the abilities of the Java VM and class libraries.

    • Who killed Java? Who will kill Qt? (Score:5, Insightful)

      by fm6 ( 162816 ) on Monday October 15, 2001 @09:59PM (#2434458) Homepage Journal
      Java held great promise, but MS has succeeded in killing desktop Java.
      Even if you subscribe to the worst MS conspiracy theories, you can't give MS sole credit for killing desktop Java.

      Sun deserves a lot of credit. If you're going to introduce a Revolutionary New Approach to Programming, you shouldn't do it with inefficient, buggy VMs, or quickie compilers that don't properly exploit garbage collection. Thos mistakes gave Java a reputation for flakiness and inefficiency it still hasn't fully dispelled.

      And if you want everybody to start using Java to develop desktop apps, you don't suddenly shut down your own application development efforts [javaworld.com] before they've had a chance to bring their product to market. But of course IBM, Oracle, and all the other biggies were doing that too. Coinciding with the downfall of the Network Computer [cnet.com].

      And that's what really went wrong with desktop Java. Platform independence was never enough by itself to make Java widely adopted on the desktop. You had to give people a reason to abandon their investment in Windows-based solutions. That reason, was the Java-based NC, which was supposed to lower the Cost of Ownership for big corporate computer buyers. (And, not incidentally, give these same buyers a reason to buy proprietary Sun and IBM hardware instead of commodity PCs.) Unfortunately, nobody bought the NC idea, and the main market for Java desktop apps disappeared.

      Some, but not all, of this history is repeating itself with Qt and KDE. Being technically superior to Windows wasn't enough for Java, and it won't be enough for the Linux desktop.

      • Even if you subscribe to the worst MS conspiracy theories, you can't give MS sole credit for killing desktop Java.

        Desktop Java is dead? That's news to me, since I'm currently working with plenty of big companies who are still developing desktop Java solutions.

        What died was the idea that Java would be the development language of choice for all desktop apps in the future, from diarying systems to desktop publishing. And that's a good thing, IMO.

        • Well, "dead" is relative, at least in software. One does see a fair number of Java desktop apps. But it's pretty marginal. Of course, Java never was going to take over completely, But at one time, it was reasonable to hope that Java would replace native code for some basic desktop apps, such as word processing and spreadsheeting. Early attempts at this, like the Java version of WordPerfect, were underwealming. But some decent desktop apps did eventually appear. Alas these were much too late to arouse any serious interest.

          And I think that's too bad. It would have been really nice to have a universal component architecture. It would have allowed us to get away from big, bloated, brittle apps that irritate techies and frighten non-techies. Maybe Java couldn't have replaced every native app in the world, but if it had replaced just two -- Word and Excel -- the world would be a better place.

      • Being technically superior to Windows wasn't enough for Java, and it won't be enough for the Linux desktop.
        >>>>>
        The Linux desktop hasn't even gotten to the "technically superior" phase yet. I use it everyday, but Windows has a really big edge in the technical superiority department.
        • Depends on what you mean by "superior". If you just count features, Windows will always beat Linux. MS's huge employee base can dream up new features faster than any competing team, Open Source or otherwise.

          But that's part of the problem. On Windows, everything gets totally re-invented ever few months. As a result, nobody can keep up with all the changes, and the system as a whole is painfully complex and unpredictable.

          If you care about the stability and useability of a system, then the "superior" system is usually not the more "advanced" one.

          • I care about speed, Windows wins. I have yet to see a widget set on X that matches the performance of Win32 in terms of redraw speed. Hell, even Qt on Windows is faster than Qt on Linux.

            I care about unification, Windows wins.
            >>>>>>>
            I like GIMP, and I like KDevelop. I don't have infinite RAM and I like my apps to look the same. What do I do?

            I care about predictability, Windows wins.
            >>>>>>>
            The other day, I installed AbiWord, and it didnt' like the fact that I'd removed its crappy Type1 fonts from my path. Why? Why is the app so damn bound to its fonts? I tried to install the mandrake kernel source RPM the other day, to find that it needed GCC 2.96. GCC 3.0.1 (which I have installed, in RPM form no less) works fine for the kernel, why is it so attached to its obsolete RPM? There are just too many factors in Linux that can fuck up. In theory, Linux is quite elegant and powerful, but in practice, its really not. Not as a GUI machine anyway.

            I care about stability, Windows wins:
            Its true. KDE-2 has crashed more often on me than Windows 2000. Of course, you'll tell me to go use Window Maker, then I'll ask where my unified GUI is, and you'll then tell me to use KDE-2.

            I care about audio, Windows wins:
            The Linux audio system is probably the most f*cked up thing ever. aRts on top of OSS/ALSA? WTF? Aren't software mixers archaic relics of the early 1990's? And why is aRts nifty media framework tied to a dumb software mixer? I wnat to use my SBLive! fully! ALSA is quite powerful, and quite speedy. Build a media framework on that instead.

            Of course, Linux has tons of strong points. The kernel whips Windows to all hell. The VM system is (finally, thanks AA) much better, the filesystems are faster, and everything is just smoother. With the preempt and lowlat patches, BeOS finally loses the audio-latency performance crown for a general purpose OS (as long as you don't use aRtsd or esound!) urpmi is nifty (when it works). Konqourer is really a step forward. Auroura boot is just plain cool. I use Linux on a daily basis these days, but I don't enjoy it as much as I should. XFce and GNOME are decently fast, but lacking in features I enjoyed in Windows. I can use XMMS/ALSA and get good sound, but I have to live without the media framework I had in BeOS. It certainly gets the job done, but it has so much more potential its disgusting. Everything is already there. If only someone non-braindead came along to organize it all...

  • database functionality... why? (Score:3)

    by nilstar ( 412094 ) on Monday October 15, 2001 @06:31PM (#2433814) Homepage
    Okay, here goes.... why oh why is QT in need of database support. It is a cross platform GUI (last time I checked?). Aren't things like cross platform database access left to tools like Java?
    • If I had to predict a reason, it is probably because Trolltech's paying customers want integrated database access. If you are building a corporate app to deploy across Win32 AND Linux desktops to access the corporate database, you likely want it to be able to. In fact, you probably want the app to function without calling an external Java system and therefore need a Java programmer/QA person.

      Java is a cross platform toolkit/language/vm, Qt is a cross platform toolkit for C++.

      This lets you build database applications (the VAST majority of application, in fact just about every application is really a database application, think about what computers do...) that will compile for Linux, Win32, Mac OS X, and Qt Embedded platforms...

      Pretty slick...

      Alex

    • Re:database functionality... why? (Score:5, Interesting)

      by jfunk ( 33224 ) <jfunk@roadrunner.nf.net> on Monday October 15, 2001 @07:14PM (#2433993) Homepage
      A bunch of points in no particular order:

      • Qt was never intended to be just a GUI. It was intended from the beginning to be a RAD environment. That means simplifying many programming tasks including, but not limited to: GUI stuff (QWidget on down), string use (QString, etc.), internationalisation (i18n, QtLinguist, etc.), 3D graphics (QGL), and the elimination of evil callbacks (signal/slots are my very favourite feature). You can also create non-GUI apps under Qt, if you want (KDE's 'dcop' command is an example. try an 'ldd' on it)
      • Database functionality is actually quite important for a toolkit such as Qt. Have you tried Kylix? It's biggest selling point is it's DB functionality. It's really simple to quickly create DB apps, even if you can only use MySQL or Interbase. We have it where I work but we use PostgreSQL. I will definitely be trying Qt's new DB functionality
      • Do you *really* want to make a frontend in Qt and a backend in Java? If you're going to use Java, you might as well use Swing or Awt for the GUI bits. Besides, I've seen some terrible experiences with getting different Java programs running under various JREs on Windows. If you can simply compile a binary and an installer, then the user only has to install one thing and can avoid JPain


      OK, not so many points as I thought...
      • Have you tried Kylix? It's biggest selling point is it's DB functionality. It's really simple to quickly create DB apps, even if you can only use MySQL or Interbase.
        Actually, you don't even need MySQL. There's a driver for XML-based flat file databases.
    • Okay, here goes.... why oh why is QT in need of database support. It is a cross platform GUI (last time I checked?)

      No, it was never just a GUI library. It also included a container class library, strings, streams, graphics file manipulation, and more recently, it has an OO socket implementation, and XML support (Sax and DOM) You're on to something with your Java comment though -- think of it as a C++ version of the Java standard library, if you like.

  • almost complete source compatibility (Score:2, Insightful)

    by Anonymous Coward
    <I>keeps almost complete source compatibility with</I>
    That means, according to my practice, almost no bigger QT2 project compiles with QT3 without modifications (yes, the modifications are not very big and depending what classes you're used these may not be very much also).
    What I really liked with QT3 was new designer, it's way ahead of old dialog drawing app, going near to Delphi's funcionality.

  • Finally for the Mac! (Score:2, Interesting)

    by SeanAhern ( 25764 )
    One of the most exciting pieces of news about Qt 3 (for me at least) is that it supports Mac OS X [apple.com]. And I'm not talking in X11 mode running XFree86. They have a true Quartz/Aqua [apple.com] implementation that runs natively, including OpenGL support.

    So finally, all of those apps that use Qt to port to Windows now immediately port to Mac OS X with a recompile. Good show, Trolltech!

    Read more from their press release [trolltech.com].

  • Kapps for Mac OS X? (Score:2, Interesting)

    by Tachys ( 445363 )
    Does this mean that in the future we will see Kapps like Kword and Kmail on Mac OS X?

  • Damm (Score:2, Funny)

    by harvord ( 197507 )
    Damm I thought this was some sort of first post/goatsc.ex tool with a GUI.

  • QT Pricing (Score:5, Insightful)

    by hack0rama ( 253610 ) on Monday October 15, 2001 @07:46PM (#2434114) Homepage Journal
    QT is not free for cross platorm freeware.

    Earlier we did not had a very good choice for cross platform GUI, AWT/SWING did not have the performance of native GUI and WxWindows was not powerfull/rich enough.

    Then came QT and I thought wow ! this is it, for my next cool application, eventhough I will develop it on Linux, I can make it available for Windows as well as Mac users.

    Then I realised its only free on X, you got to pay around 1500$ to get it on other platforms even if you want to write/ditribute a freeware app.

    On Windows you pay 50$ after rebates to get a copy of VisualC++ 6.0. And for 50$ you get a compiler, GUI class library, and IDE and debugger. And just for the QT library its 30 times more than Visual C++, how can any hobby programmer afford it ?

    I hope Trolltech come out with a more sensible pricing for freeware developers on Windows/Mac which should help QT to gain more acceptance in the non Linux programming community as well.

    • Then I realised its only free on X, you got to pay around 1500$ to get it on other platforms even if you want to write/ditribute a freeware app.

      No, dude. It's free for open source software on Win32 as well:

      http://www.trolltech.com/developer/download/qt-win -noncomm.html [trolltech.com]
  • ...or do they work for free (uncompensated)?

    My reading of the Qt license says it can't be both ways; you can't be compensated for the code you develop, unless you buy a license, regardless of your end product license.

    • Re:are all KDE contributors paid licensees? (Score:4, Insightful)

      by Bob Uhl ( 30977 ) on Monday October 15, 2001 @08:44PM (#2434285)
      Read the GPL--which Qt is now offered under. As long as you abide by th (well-known and acceptable to many) terms of the GPL, it doesn't matter what you do.

      If you wish to offer non-GPLed code to the world, then yes, you'll need to purchase a license from TrollTech (a great company, from everything I hear). Personally, I really do hope that things go well for them. They're good guys. Does the KDE project have any plans to donate money in their direction?

      Personally, I'm a gtk+ man, simply because I prefer C development, and like gtk's handling of classes, types and all that. I also prefer GNOME as a desktop environment. But KDE is sweet, to be sure. It just doesn't do quite what I like. Choice is a Good Thing(tm). I look forward to many years of desktop competition. It should be interesting.

      • Ahhh...so as long as they use Linux, not Windows, they can do this. Actually, on X11, you can use a number of "free" licenses for the end product, and be compensated for creating it as well.

        The Linux Qt goes out as a "Free Edition" while the Windows Qt goes out as the "Non Commercial" edition, with different restrictions on each.

        The GPL is not all-knowing is this case. Reading the GPL tells you nothing about the following, which applies to Qt-win:

        "Terms of use"

        "Developing and distributing applications"

        "Private users may use the Qt non-commercial edition in a non-commercial setting to produce non-commercial applications."

        "A non-commercial setting means that you must not use the package in the course of your employment or whilst engaged in activities that will be compensated. A non-commercial application is an application that cannot be sold, leased, rented or otherwise distributed for recompense."

        Snipped from:

        http://www.trolltech.com/developer/download/qt-w in -noncomm.html

        Seems odd to use different licences for different platforms, but I'm sure there is logic in it.

  • yacc ... (Score:2, Informative)

    by _generica ( 27453 )
    from src/moc/README
    ----
    Notice that moc does not compile with GNU bison, use standard AT&T yacc or Berkeley yacc instead.
    ----

    why do these people refuse to use commonly available tools. I've spent a lot of time searching for these, neither of which are under developemnt or even easily availble. Bison is under development. Why don't they use it, or at least let us use it ??? Because of this, I can't compile qt-3.0.0, and I think this is unacceptable.
  • Not wanting to troll, but in October's Dr Dobbs (pages 105-107), Al Stevens points out what he doesn't like about Qt - primarily the way that the framework breaks the "new/delete" idiom. In particular, widgets must be allocated on the heap and then given to the framework to manage and delete. (When I last looked at Qt I though the same sort of thing but thought maybe I was being a little too snobby and showing my age).

    As I said, I don't want to troll, but for those who're using Qt/KDE is this a big concern ? Do you write a handler wrapper class around widgets that hides this mis-match, or do you just live with it ? Does it only happen in one or two spots ? Is short - how do you change your practices to match the toolkit ?

    He also dislikes the metaobject compiler and a few other items, but I'm less concerned about those...

    T
    • Having looked at MSFC (yuck!), GTK and Qt, I find that Qt is the toolkit that makes UI programming the easiest. And frankly, I don't quit get what you mean with your new/delete idiom breakage. It all works the very same way as in standard C++, except for two things:
      1. Include the QOBJECT macro in every class you want to use Qt in
      2. You don't have to bother deleting Qt Objects. It's done by Qt.

      I think it's great. How is this bad?

      Anno.
      • His complaint is with Point 2, it seems strange to have to explicitly call a new, but then not have to worry about deleting either. From a functionality standpoint it's nice, but it does cause problems to those who expect to have to delete for everything they use new to make.
      • Having looked at MSFC (yuck!), GTK and Qt, I find that Qt is the toolkit that makes UI programming the easiest

        I agree MFC is nasty (I almost had to use Glockenspiel CommonView 10+ years ago, and MS just stole the entire team to write MFC version 1 - I'd already written my own C++ wrapper by then).

        except for two things [...] You don't have to bother deleting Qt Objects. It's done by Qt [...] How is this bad?

        When you have a large body of code evolving over a period of time, you often want to check such things as resource leakage. This normally means checking that all allocations match up with deallocations (with a GC-ed resource you do this by checking all your GC code works and by checking people use the GC properly). You check this by matching up alloc and de-allocs of whatever resource it is.

        If you have a single block of code that runs

        alloc resource
        use resource
        free resource

        then you can easily see that this resource is handled properly (ignore true exceptions for now).

        On the other hand

        alloc resource
        if resource allocated
        use resource
        free resource
        end-if

        is also correct, but

        alloc resource
        use resource
        if some-condition
        free resource
        blah-blah-blah
        if some-other-condition
        free resource

        is usually wrong - it breaks the idiom - reviewing this code should set off alarm bells as allocs and frees don't directly match. If the code is genuinely correct (say the 2 conditions are mutually exclusive) then you have to mark it in some way to say "this misuse of the idiom is correct" - often you "mark it" by refactoring the code to use the idiom

        alloc resource
        use resource
        do-the-commonstuff-here
        free resource

        In C++ the standard idiom is "object construction is resource allocation", and this makes exception handling and some of the refactoring easier - you allocate the resource in the constructor and free it in the destructor. Again, for the reader/reviewer it is easy to see where allocs and frees match up and prove the use is correct

        class blah
        {
        blah() { alloc resource }
        ~ blah { free resource }
        reset { free resource; alloc resource }
        }

        Again, this is not language specific, but idioms that make it easy to see when your code is correct. That's why adding a function to the above class

        set(r) { free resource; resource = r; }

        is nasty - you have an unbalanced freeing of a resource so to prove its correct you have to show that everyone who calls set knows how to use it properly. This seems to be the Qt idiom.

        How is this bad ? Add 5 years of development with a rotating team of 10 developers (say turnover of 2 a year) and management, and a medium sized code base of 250,000 lines of code across 25 libraries and a dozen executables.... it's 10pm on the night before a release - do you know where all your allocs and frees are ?? On a small project or a small codebase you can hold it in your head "don't worry about these special cases" but in the larger case it makes for problems, and I put enough bugs in my own code without idioms that encourage me to introduce more. I can think of ways to code around it (a wrapper that allocates the class and gives it to the Qt framework, a bit like auto_ptr) but why doesn't Qt do this for me ?

        Long answer to a short question - sorry....

        T
        • My toolkit fltk does things similar to Qt: when you destroy a "containier" widget it destroys all the inner widgets for you, even though you had to use "new" to create all those child widgets.

          I have to admit this has caused problems, though for most programs the code savings is enormous (because fltk has to keep track of all the child widgets anyways, this avoids the need for the program to do so just to be able to delete them).

          I solved a lot of this with a hack: I made the destructor change part of the object (the "parent widget pointer") to null, and container destructors don't destroy child widgets unless the parent pointer is equal to them, thus avoiding double destructors. This is theoretically bad programming practice but as far as I can tell has never failed. It allows widgets to be local variables, and imbedded (non pointer) members of larger structures, which Qt does not allow, this has proved to be very useful! However it still fails if the programmer calls the destructor after destroying the container.

Slashdot Top Deals

Too much of everything is just enough. -- Bob Wier

Close