Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

The Qt 4 Resource Center 45

Posted by CmdrTaco from the develop-all-over-the-place dept.
e8johan writes "The Qt 4 Resource Center features articles regarding the next generation of Qt. Being the basis for the next generation of KDE and being available under GPL for all major platforms Qt 4 will make it even easier to develop powerful cross-platform applications."
This discussion has been archived. No new comments can be posted.

The Qt 4 Resource Center More

The Qt 4 Resource Center

Comments Filter:

  • Price (Score:3, Interesting)

    by Cthefuture ( 665326 ) on Wednesday June 15, 2005 @09:51AM (#12823379)
    OK Trolltech, how about lowering your prices instead of increasing them every few months?!

    Most shops and individuals can't afford that stuff for commercial development. Every other development platform is hella cheaper than Qt (MSDN, Apple, etc.).

    Trolltech needs to take a clue from some failed projects that made it too hard for the system to be adopted by the masses because they were listening to the marketing department.

    • Let the free market work. (Score:5, Insightful)

      by CyricZ ( 887944 ) on Wednesday June 15, 2005 @10:02AM (#12823513)
      Let the free market work its magic. If their prices are truly too high, then the demand for Qt will drop, and they will be forced to lower their prices. Since that is not happening, then there must be shops which can afford to pay their licencing fee. And considering that they're most likely financially stable, there must be enough people willing to pay at that price.

      Now, if YOU can't afford it, then try some of the other open source alternatives. There is always wxWindows, FOX, FLTK, GTK+, the multiple GTK+ C++ wrappers, and so on.
      • I tried wxWidgets (formerly wxWindows) and found that while it did work for some things, there are some very serious bugs. For example, make a tree widget with too many items and it starts displaying improperly. By that I mean connecting lines drawn randomly all over the widget.

        I know about fixing the code since it's free, but frankly, the code is a mess.

        Qt's prices aren't too high at all, so I think we're seeing the free market magic that you're referring to. The price is going up, because Qt is actually
        • I agree with the wxWidgets thing. Honestly, I can't see how a toolkit can be that old and "mature" and still contain so many bugs. It's one of the buggiest toolkits I have ever used... this dispite the fact it is like 12 years old! After looking at the code you can tell why though. The foundation is poorly written, the programmer(s) did not know what they were doing and they never went back and fixed it (what have they been working on the last 12 years anyway?!).

          As for Qt, we'll see. I think the only

          • Re:Let the free market work. (Score:1, Insightful)

            by Anonymous Coward
            Most software companies don't want GPL code and the buy-in price is way higher than Windows or OS X.

            But you're not comparing like for like there.

            The buy-in price for Windows (presumably we're talking about a site license for Visual Studio Enterprise here) may well be cheaper than Qt. But it only gets you Windows development.

            The buy-in price for OS X (= the price of the Macs to do your development on, presumably, since XCode is free) may well be cheaper than Qt. But it only gets you OS X development.

            Q
    • They seem to think that they're being fair..
      http://www.trolltech.com/company/model.html [trolltech.com]

      With the exception of java most libraries don't seem to be as complete a cross platform solution. There are other solutions, they're just trying to make a quality cross platform solution, there are alternatives, but you have to collect the parts and put them together yourself, and test etc...

      There is GTK which is cross platform for windowing and widgets. (GNOME is built on this)

      If you don't like it don't buy it, but

    • Re:Price (Score:2, Insightful)

      by spencerogden ( 49254 )
      Ingnoring the fact that MSDN (meaning .NET and MFC I guess) and Apple (meaning Cocoa and Carbon) are not cross platform, you forget that they are distributed by companies that are using them to sell their primary products. Of course they want to make it easy for developers to make applications for their platforms, that's what sells OS's/Computer's.

      As someone else mentioned, your only other real choice for non-opensource cross-platform developement is Java and wxWindows.

      Time will tell if the price is too h
    • > Most shops and individuals can't afford that stuff for commercial development.

      Commercial? You must mean closed-sourced/proprietary.

      • Nothing wrong with being closed source. The open source model doesn't fit every business situation. To be honest, I think that the open-source concept has turned being a programmer into being a "superstar".. What I mean is that there are lots of good applications that people could make a living at if they maintained closed source. Those same applications would not bring in enough service revenue to allow the developer a decent living. The few products that DO bring in this much money are the "superstars

    • Re:Price (Score:2, Insightful)

      by TampaDeveloper ( 834876 )
      "The results of the 2005 Qt Customer Survey are in! 96% of Qt customers said that they would recommend Qt to others."

      Maybe its that expensive because its really that good!

      Anyhow, there are lots of low cost development tools for developing the standard internal corporate software. People that buy Qt are making commercial apps. If $3000 is going to break you, then perhaps you need to reconsider your business strategy.

    • The prices are not that out of line for professional software.
      QT Enterprise is $ 2880 for a single seat.
      Borland JBuilder is 3500 a seat.
      Visual Studio Enterprise Architect Edition is $2400
      You do not want to see how much money you would spend on Solidworks or a full seat of AutoDesk's stuff.
      Yes QT is priced out of the range of hobbyists but not for most shops.
      • Don't forget how much you have to pony up for any of Rational's stuff!
    • OK, Qt is a multiplatform toolkit, right? That means you can pretty much just port to a supported platform by recompiling.

      So if the cost of porting the application and then maintaining separate source trees is greater than the cost of the Qt licence, buying Qt makes sense. Given that the cost of Qt is less than a month's salary per developer, it doesn't seem so bad to me.
  • It mentions that Mac OS X and Linux/X11 are GPL and Windows will become GPL in v4. What about the other versions of UNIX?

  • Qt4 and extra compile phase? (Score:4, Interesting)

    by Paradox ( 13555 ) on Wednesday June 15, 2005 @10:17AM (#12823665) Homepage Journal
    Despite being a Qt3.3 developer, I've had almost no chance to check out any of the buzz on Qt4. What I want to know is, are they going to find a more elegant and in-language way to handle signals and slots, preferably one that does not require the use of an extra compile phase?

    I'm all for meta-language programming. I love it. But not at the expense of an extra compile phase which complicates my makefiles and can introduce errors that were introduced when the generated code was inserted. I'm happy that Qt4 will finish opening up as a GPL'd library (that removes one of my biggest complaints about Qt), but are my technical concerns also going to be invalidated?

    To me, this extra phase and the awkwardness of signals and slots syntax is a real weakness when compared to frameworks like Cocoa that don't need to resort to it. Now, I understand dynamic dispatch is hard in C++, but if the Boost people can get HOF-aware template-based lambdas, I'm certain that TrollTech could do better.
    • > are they going to find a more elegant and in-language way to handle signals and slots

      No, using macros and moc *is* the elegant way.

      > preferably one that does not require the use of an extra compile phase

      moc is a preprocessor, no compiler.

      • moc is a preprocessor, no compiler.

        Source processing is part of the compiler run. Preprocessing a phase of compilation. Therefore, moc another compile phase. Do not confuse this with compile phase within the cc executable itself, that's something different and lower level.

        No, using macros and moc *is* the elegant way.

        No. I'm sorry, it is not. C++ is a powerful language, and while it may not be my favorite, I cannot deny that people have done amazing things with it. Check out some of the more i

        • > it certainly would make life easier for the developers

          I don't see how. Handling moc in the Makefiles is easy and telling that moc generates broken code is FUD, it for sure is one of the most bug-free parts of Qt. And btw, moc doesn't only add signal/slots to Qt.

          • I don't see how. Handling moc in the Makefiles is easy and telling that moc generates broken code is FUD, it for sure is one of the most bug-free parts of Qt.

            Oh! No no! moc doesn't generate broken code. I was obviously unclear (that sentance above was supposed to be edited, but I hit Ok accidentally) and I apologize. The problem is it generates a lot of code, and it does so in nearly every Qt file. If you have an error in your code, the generated code can really confuse matters. Also, if you end up w

            • Qt is very heavily invested in the "enhanced C++" provided by the usage of MOC (for example, the new foreach keyword they add in Qt4), so I don't think it's going away any time soon. You can certainly replicate the functionality that Qt provides via the MOC using sufficently sophisticated macros & templates but Trolltech has decided to embrace the enhanced syntatic sugar at the expense of technical correctness or standards compliance (people argue that Qt code is 'standard' C++ code, but they're being p
    • I tend to agree, but the issue here is: Will the elegant solution work on a million random compilers, like those made by SUN, or Intel's C++ compiler, or HPUX's compiler, and so on.

      Sure, some of the clever and typesafe and modern signal-slot implementations work on GCC 3 and up, and on whatever MS has these days. But that's not the entire world of c++ compilers.
      • I know backwards compatability is a good thing, but at some point we need to get off the bus and say, "Standard is standard. If you break on this code, it's your problem."

        It's not like we haven't had years to update these sorts of things. With TR1 incorporating some Boost features into the standard, and TR1 being the future of C++ in many eyes, it's time to stop coddling.

        Since Qt is primarily a Linux, MacOSX and Windows phenomenon, I seriously doubt that TrollTech would lose sales from such a move.
        • Actually, I agree with you 100% -- I was just saying why I believe Qt still relies on the MOC.

          Now, one thing I can't help but wonder -- since I haven't done any Qt programming in 2 years ( moved to Cocoa/OSX, never looked back ) -- is wether the moc is doing things that simply aren't available in a standards based manner. For example, I recall writing a test app that enumerated the signals and slots on an anonymous QObject. I don't think you can do that at *all* with plain old ( even modern ) C++.

          But, I c

    • Re:Qt4 and extra compile phase? (Score:1, Interesting)

      by Anonymous Coward

      are they going to find a more elegant and in-language way to handle signals and slots

      Doubtful, and definitely not for 4.0. C++ just isn't equipped to deal with this model of programming, you end up with massive amounts of inheritance or similar messes. "More elegant" and "in-language way" are at odds with each other for C++ GUI development. Trolltech can't get around that short of taking their modifications to C++ to ISO and getting them approved as proper C++.

      I'm happy that Qt4 will finish openin

      • If you've got a better suggestion, let's hear it.

        I am not a template meta-programming guru. I do not have better suggestions from within C++ off the top of my head. Give me awhile to think about it. :)

        But, I am baffled why TrollTech stopped at signals and slots instead of allowing real smalltalk style dynamic message sends. If you're going to introduce code generation to a framework, you need to get as much bang with the least amount of intrusion as possible.

        They could have removed these awkward

    • Use python, then you don't have to worry about it.

      The fact that you can suggests to me that trolltech wouldn't require moc when using c++ unless they had to.

      • Well, I haven't tried PyQt in about 6 months. Even if I liked it, our customer demands C++.

        But, when I tried it, PyQt had some flaws. It was awkward when you wanted to make new widgets, in particular. And, maybe this is fixed, but I had a heck of a time reusing some components that my coworkers wrote.

        Python is a great language with a lot of potential, but I couldn't help but feel that Qt isn't very Python-ish, and it showed in the experience. I'll check into it again.

        The fact that you can suggests to

  • This would be pretty great. I run pretty much only open-source software for almost everything I do (except media playback), yet I've found Windows XP to be the most stable platform on which to do so on my PC.

Slashdot Top Deals

My sister opened a computer store in Hawaii. She sells C shells down by the seashore.

Close