×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

45 comments

Price (2, Interesting)

Cthefuture (665326) | more than 8 years ago | (#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. (4, Insightful)

CyricZ (887944) | more than 8 years ago | (#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.

Re:Let the free market work. (2, Interesting)

Profane MuthaFucka (574406) | more than 8 years ago | (#12823627)

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 a well-written, well-debugged, powerful, and well-organized toolkit.

Re:Let the free market work. (1)

Cthefuture (665326) | more than 8 years ago | (#12825158)

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 reason it survives is because of a couple corporate cash cows plus KDE. That will only last so long though. If KDE ever became extremely popular, creating commercial applications would be a huge drag because of the price for Qt. Most software companies don't want GPL code and the buy-in price is way higher than Windows or OS X. In fact, that is probably holding KDE back more than anything else.

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

Anonymous Coward | more than 8 years ago | (#12826086)

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.

Qt may be more expensive. But it gets your application onto all three platforms with no extra effort.

Consider a hypothetical developer wanting to write a commercial application that runs in KDE. In this hypothetical future, Linux + KDE has taken off beyond our belief and now commands a 25% marketshare; Apple have trebled theirs, too, and now have 15% of the market; and Windows controls the remaining 58% of the market (apart from the 2% "other" that the Gnome fans will insist I put in here).

Your hypothetical developer has three choices:
  1. Use a free toolkit on Linux. Let's say they choose GTK+ - that makes them a second-class citizen immediately in KDE, a third-class citizen in Windows (seriously, GTK+ on Windows is a pig to use), and it rules them out of the Mac market altogether because there is no up-to-date GTK+ for OS X.
  2. Go the platform-specific route. They get to pay once for Windows tools, once for Mac tools, and presumably use something free on Linux. They now have to write their user interface three times. That takes time, and time is money.
  3. License Qt. One single payment, one single codebase, and immediately they can deploy their application as a first-class citizen for 98% of the potential market, at no further cost whatsoever.
Too expensive? Methinks Trolltech could charge twice as much and it would still be a bargain.

Re:Let the free market work. (0)

Anonymous Coward | more than 8 years ago | (#12833553)

Some corrections:

Even the single platform license is way more expensive than the alternatives.

Qt is a pig on all platforms. It's good, but still a pig.

Licensing Qt is not one single payment. If you ever hope to get bugfixes you're looking at yearly renewals (which are also insanely expensive compared to the alternatives).

Two as much? LOL... you must work for Trolltech. Sorry but the cross-platform market is too small for their current pricing. Many more companies would be using Qt if it were just a bit more reasonably priced. Then us users benefit by having more applications on our desired platform.

free for open source (2, Funny)

acomj (20611) | more than 8 years ago | (#12823521)

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 I love the irony of software developers whinning about software prices (or pirating for that matter).

Re:Price (2, Insightful)

spencerogden (49254) | more than 8 years ago | (#12823608)

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 high, but most developers who have used QT will tell you that its pretty head and shoulders above any other cross-platform library.

Re:Price (0)

Anonymous Coward | more than 8 years ago | (#12824186)

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.

Meh, a $1000 MSDN subscription is not just development tools. It's most of the products that Microsoft makes (including all the operating systems). People wonder why Microsoft is so widespread? Look no farther than the fact that they make it easy for developers.

Re:Price (1)

CableModemSniper (556285) | more than 8 years ago | (#12824527)

.NET [mono-project.com]
Cocoa [gnustep.org]

Re:Price (1)

arkanes (521690) | more than 8 years ago | (#12824932)

The GUI parts of .NET are not supported by Mono, and GNUStep is a pale shadow of Apples Cocoa in terms of scope and functionality. Both are certainly usable but are not drop-in replacements that can magically make .NET or Cocoa code cross-platform.

Re:Price (1)

twener (603089) | more than 8 years ago | (#12824339)

> Most shops and individuals can't afford that stuff for commercial development.

Commercial? You must mean closed-sourced/proprietary.

Re:Price (1)

TampaDeveloper (834876) | more than 8 years ago | (#12824449)

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"... There are very few superstars. Certainly there are too few of them for me to personally consider giving away my source code.

Re:Price (2, Insightful)

TampaDeveloper (834876) | more than 8 years ago | (#12824380)

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

Re:Price (1)

LWATCDR (28044) | more than 8 years ago | (#12825685)

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.

Re:Price (0)

Anonymous Coward | more than 8 years ago | (#12825832)

Visual Studio Enterprise Architect Edition is $warez.

Re:Price (0)

Anonymous Coward | more than 8 years ago | (#12825876)

MSDN is $1000 for all the operating systems and development tools Micrsoft makes. The entrise version is around twice that price. That's a hell of a lot more software than what Qt gives you (and it costs more even!).

Re:Price (1)

LWATCDR (28044) | more than 8 years ago | (#12825972)

Yes but you only get tools for Windows Development. QT is multi-platform. Hell Microsoft gives some versions of VS away I wonder why....
If QT is not worth it to you then don't buy it. Or do OSS development with it. It is free if you GPL your code. You only have to pay to charge.

Re:Price (0)

Anonymous Coward | more than 8 years ago | (#12831051)

even though it's only windows, the cross-platform market isn't big enough to justify the price for qt when you compare prices. people will just stick with windows-only since it's the main market and way cheaper.

Re:Price (1)

BenjyD (316700) | more than 8 years ago | (#12830652)

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.

GPL for other UNIX's? I.e. Solaris, HP-UX, *BSD (1)

Bryan-10021 (223345) | more than 8 years ago | (#12823390)

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?

Re:GPL for other UNIX's? I.e. Solaris, HP-UX, *BSD (1)

twener (603089) | more than 8 years ago | (#12823657)

There is no "Linux/X11" edition but only an "X11" edition which also runs on Solaris, HP-UX, IRIX, AIX and many other Unix variants.

Re:GPL for other UNIX's? I.e. Solaris, HP-UX, *BSD (1)

Bryan-10021 (223345) | more than 8 years ago | (#12823985)

``[..] and under a GPL license for Mac OS X and Linux/X11 for the Open Source community. Qt/Windows will be available under the GPL license at Qt 4 launch.``

Thanks. I misunderstood what they meant by Linux/X11.

Qt4 and extra compile phase? (3, Interesting)

Paradox (13555) | more than 8 years ago | (#12823665)

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.

Re:Qt4 and extra compile phase? (1)

twener (603089) | more than 8 years ago | (#12823695)

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

Re:Qt4 and extra compile phase? (2, Insightful)

Paradox (13555) | more than 8 years ago | (#12823861)

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 intense Boost libraries for an example of what can be done without a preprocessor.

While that approach may be a bit more complex for the library maintainers, it certainly would make life easier for the developers, at least in my opinion.

Re:Qt4 and extra compile phase? (1)

twener (603089) | more than 8 years ago | (#12823969)

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

Re:Qt4 and extra compile phase? (1)

Paradox (13555) | more than 8 years ago | (#12824215)

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 with a heap corrupution, a lot of times it segfaults in the generated code. This is not the generated code's fault, it's my error, but it does create debugging problems. It's a weakeness of all code generation systems.

But setting it up? A pain. Now, if you don't unit test your code, you can get away with qmake, no problem. But if you want to have a nice make test/check target, you're SOL, and have to go to either rolling your own or using a Qt-aware build tool, such as automake with Qt macros added in. Or, of course, you can use a controlling makefile. But this solution isn't entirely cross platform and can be confusing to people new on a project.

I find the lack of a flexiblity in their make tool particularly annoying. I've read every bit of documentation Qt3.3 has on the subject, I've asked other developers and put forth questions on mailing lists. No one seems to even think about qmake and unit tests. If they removed the need to moc source files, they'd open up the build process to more tools and make it easier to integrate into an existing project.

Re:Qt4 and extra compile phase? (1)

arkanes (521690) | more than 8 years ago | (#12824901)

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 pedantic. Qt requires MOC to be run, plain & simple, and is therefore a meta-language on top of C++, not C++ itself). Personally, I don't like the solution (I'm a former Qt user who switched to wxWidgets), but there's plenty of people who don't mind.

Re:Qt4 and extra compile phase? (1)

Paradox (13555) | more than 8 years ago | (#12824958)

This is what I wanted to know, thank you.

I agree with you, I wish they would find a better way. Or, they could at least be honest and admit they're crafting a new C++ compatible language.

Re:Qt4 and extra compile phase? (1)

TomorrowPlusX (571956) | more than 8 years ago | (#12824857)

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.

GCC2.95 and up should be okay (1)

Paradox (13555) | more than 8 years ago | (#12825003)

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.

Re:GCC2.95 and up should be okay (1)

TomorrowPlusX (571956) | more than 8 years ago | (#12826366)

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 could be wrong, I haven't kept up to date with Boost, since most of my work is AI and game programming, where I don't have the luxury to use most of the really hairy modern stuff.

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

Anonymous Coward | more than 8 years ago | (#12825018)

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 opening up as a GPL'd library (that removes one of my biggest complaints about Qt)

Qt has been GPLed for years for X11. If you really care about it being available under the GPL for other platforms, then it has been perfectly possible to port it for all this time.

if the Boost people can get HOF-aware template-based lambdas, I'm certain that TrollTech could do better.

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

Re:Qt4 and extra compile phase? (1)

Paradox (13555) | more than 8 years ago | (#12825161)

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 signals and slots, and instead introduced an Objective-C style delegation paradigm. Since they're parsing the header, why not say, "All virtual functions are now dynamically dispatchable with some simple syntax?" This pattern has been proven to work exceptionally well in staticly-typed environments. They could have even improved upon that model by allowing for multiple delegates.

I appreciate Qt as a cross-platform environment. But when I compare it to specific environments like Apple's Cocoa (or GNUStep, which is similar), or even Swing, I find that it's lacking. I understand there is a language handicap here, but that doesn't change my opinion.

Re:Qt4 and extra compile phase? (0)

Anonymous Coward | more than 8 years ago | (#12826163)

There are approaches that do this "in-language". libsigc++ is one, boost.signals is another, and I think that GNU Common C++ has another one. There is some motivation to get this into the language coming from the boost folks, but I don't think a formal proposal exists yet.

Re:Qt4 and extra compile phase? (1)

m50d (797211) | more than 8 years ago | (#12826786)

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.

I wish (1)

Paradox (13555) | more than 8 years ago | (#12833088)

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 me that trolltech wouldn't require moc when using c++ unless they had to.


Unless they used SWIG and MOC to do the binding. :) You don't need Moc. You could just write in all the Qt signals-slots code by hand. But who would want to? That'd totally remove the benefits of Qt.

Does this mean KDE will run natively on Windows? (1)

samrolken (246301) | more than 8 years ago | (#12824261)

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.

Re:Does this mean KDE will run natively on Windows (1)

twener (603089) | more than 8 years ago | (#12824316)

Only parts of KDE will be made running natively on Windows (like Kontact), some already do (KOrganizer, Kexi, ...).

Re:Does this mean KDE will run natively on Windows (1)

MrDomino (799876) | more than 8 years ago | (#12824984)

Probably not without a lot of tweaking and extra work. Windows' desktop environment is fundamentally different from X, so I don't think that a full port of KDE is a reasonable expectation. There are, however, some nice Windows clones of *nix shells (e.g., http://www.bb4win.org/ [bb4win.org]), and there is of course always Litestep [beyondconvention.net].

Re:Does this mean KDE will run natively on Windows (1)

mvdw (613057) | more than 8 years ago | (#12828417)

I just want kate and kdevelop available on windows. That way I can have the same dev environment at home and at work.

BTW, what closed-source media playback software do you use? I use mplayer (under linux, admittedly), and I find it much better than anything I have found under windows (without looking too hard).

Re:Does this mean KDE will run natively on Windows (1)

samrolken (246301) | more than 8 years ago | (#12828842)

Eh, it kind of varies. Mostly Winamp 5, though I've flirted with iTunes a bit, but mostly given it up due to the bloat. And sometimes Windows Media Player does things, and I don't mind.

Then of course there is the Windows Media Center, for when I'm using my remote and my Destination monitor... but I'd like to switch it all to MythTV on that and just get a mac mini for my personal desktop use.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...