Qt Opens Source Code Repositories 230
sobral writes "Following the announcement of the LGPL license model, since yesterday the Qt source code repositories are open to the public together with their roadmap. The contribution model is online and will enable developers from the community to submit patches through a single click process, avoiding the previous hassle of sending in signed paperwork. The code is hosted at qt.gitorious.org and an instant benefit of this launch is that Qt Software has been working together with Gitorious maintainers for the last four months to improve Gitorious and all these new features are already submitted upstream."
Qt GTK (Score:5, Interesting)
I hope Gnome switches to Qt one day, its so much nicer than GTK.
not a troll (Score:5, Insightful)
What reactionaries are modding this "troll"? It's a perfectly valid comment, for anyone who has actually sat down and compared the libraries. Also, it's a perfectly reasonable issue to consider, now that both desktops' core libraries share common licenses and have essentially become interchangeable. Yes, that interchange would involve hard work, which may lead reactionaries to reject it, but what progress doesn't involve hard work? It would at least be nice to see a study of some GNOME app re-implemented in Qt, and what the pros/cons are. I know for a fact that at least a few apps have have been ported from GNOME to Qt (Qt3, though, I think), and probably some have been ported the other way too. Even just those historical cases with Qt3, the case study would be interesting.
Re: (Score:2)
It's not going to happen. Qt makes sense if you develop in C++. Gnome is going to move gradually to Python and C# development; C++ is just not on its roadmap.
The first things to do (Score:5, Insightful)
1) replace Qt memory management with TR1::shared_ptr (or boost).
2) replace Qt collections with STL collections.
3) replace Qt threads with boost::threads.
4) replace Qt signals and slots with boost::signals.
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
Re:The first things to do (Score:5, Insightful)
Re: (Score:3, Insightful)
But then again. (only) You know your own usage scenario, data types and platform. That knowledge can probably offer some profound short cuts and o
Re: (Score:2)
I don't think it's an exactly clever idea to be unnecessarily copying containers in the first place, but no matter what it makes Qt to STL migration hard if the Qt applications are filled with assumptions on copy-on-write.
Re: (Score:2)
shared_ptr and QPointer don't play together so nicely though. Also QPointer tends be slower than shared_ptr when I only need what shared_ptr does. To get them to work together I end-up copying things between the two or just end-up not using shared_ptr at all.
Re:pointer (Score:4, Informative)
Re: (Score:3, Informative)
To be fair QSharedPointer showed-up in 4.5, hence the reason I had never heard of it until now. OPointer was forced upon me due to everything being a QObject, but then there was the other non-Qt half of the code that used boost, it was not pretty.
Re: (Score:3, Interesting)
Almost, but not quite. STL containers tend to be optimized for speed, while Qt containers are optimized for size. There is an old Qt Quarterly that discussed the implementation of Qt's containers what was quite interesting. Go online and search for it.
Re: (Score:2)
1) replace Qt memory management with TR1::shared_ptr (or boost).
2) replace Qt collections with STL collections.
3) replace Qt threads with boost::threads.
4) replace Qt signals and slots with boost::signals.
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
So it doesn't play nice with them right now?
You'll be waiting for Qt5 for that kind of stuff.
I think this will be about the time C++0x [att.com] gets mainstream. Breaking Qt source compatibility before that is just not worth it.
Re:The first things to do (Score:5, Insightful)
1) replace Qt memory management with TR1::shared_ptr (or boost).
For the core purpose of Qt (GUIs), Qt's various memory models work very well. Every widget is a QObject and by default they fall into parent child releationships that include life-cycle management of your objects. Why would you want to mess up that clean model?
2) replace Qt collections with STL collections.
Another unnecessary generalization. I actually much prefer Qt's collections because A) they are implicitly shared (you can pass them around without getting deep copies) and B) they have one clean and very efficient implementation across platforms, so I don't have to worry about the memory and performance characteristics of a MSVC std::map vs a GCC std::map. Also they are much cleaner to work with and don't require hideous iterators every step of the way.
3) replace Qt threads with boost::threads.
Again, Qt threads will perform as good as native threads on each platform, something you can not guarantee with pthreads (with weaker windows support). Also, QThread and friends (QMutex, QSemaphore, QWaitCondition, QThreadStorage) are very C++ oriented and stylistically much cleaner than pthreads and even go beyond it in scope.
4) replace Qt signals and slots with boost::signals.
This is probably the most valid argument, and there is some legacy reasons why Qt had to throw a meta object compiler on top of C++ to get this to work 18 years ago. But in the mean time, that moc layer has paid off in gold. Now you the ability to get free introspection on classes of your choosing which is vital in making C++ suck less in well designed programs (i.e. can do automatic class instance serialization etc).
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
In other words, Qt is a great one-stop-shop for cross platform development and I wouldn't change a single thing you listed. In fact, if you write your C++ code in stylelistic keeping with the Qt libraries, you avoid most of C++'s warts and can even enjoy the language.
Re: (Score:2)
1) parent-child relationships are not enough in many cases where objects are shared across multiple domains.
2) nowadays STL is as efficient as it gets across all major compilers - plus you'll get big speed ups with the upcoming changes in C++0x.
3) I did not say anything about pthreads. I said 'replace Qt threads with boost threads'.
4) Introspection has nothing to do with signals and slots. Qt signals and slots are very limited in what they can do.
Re: (Score:3, Interesting)
boost::thread has a different design concept than QThread. I would appreciate if Qt
would introduce a Functor-style API for Threads.
boost::signals doesn't work across threads (this is docuemented in the boost API).
Throwing both Qt and boost APIs together would create an ugly mess.
Re: (Score:2)
Boost::signals doesn't need to work across threads because it can be made to work across threads with very little code. All that you need is a single template class which wraps the signal into a QEvent.
No ugly mess if whatever common functionality they have is removed from Qt.
Re: (Score:2, Insightful)
Re: (Score:2)
Qt works on Windows, Mac, Linux/X11, embedded Linux, Windows CE (according to Trollech).
Boost works on almost any modern operating system, including UNIX and Windows variants (phrase copied and pasted from boost site).
So I think boost works in more platforms than Qt.
Re: (Score:2)
Qt is Object Oriented through and through, with only a hint of GP. There's no need to use functors. Threads are defined by subclassing QThread, not passing in a functor. Signal/slots are implemented as GoF Publish/Subscribe, not functors wrapping a member function pointer.
The fact of the matter is that most C++ developers just don't know function objects. I've been doing an informal survey for the past two years, asking clients about functors. My informal results seem to be that only one in twenty know what
Re: (Score:2)
1) functors and lambdas simplify code greatly.
2) it's time for C++ devs to know about functors.
3) I can't bind functors with Qt signals.
Re: (Score:2)
Note however that when I showed C++ coders what function objects are, they liked it every time. It is somewhat strange at the beginning, but once you grasp it fully, you never want to put function objects, bind, lambda etc. away.
Re: (Score:2)
And replace the wchar_t Qt strings with stl::string!
Re: (Score:2, Interesting)
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
In still other words, make it emit mountains of non-shared, hard to update code into every client application and dependent library, thus turning it into awful crap for purposes of mobile platforms, or just any platforms where shared libraries are anything but a joke.
As a side-effect, force it to use C++ exceptions, which are a sick joke to anybody who knows how real exceptions work in managed environments, and introduce any number of invisible, rarely exercised paths through the application code, which cau
Re: (Score:2)
Without boost, you don't get stuff like bind, lambda, phoenix, enable_if, any, graph, GIL, xpressive, spirit, fusion, ....
I've heard the "massive amounts of code" gibberish several times. You *don't* have to import boost into your own project. Keep it an external dependency. Since a substantial portion is header-only, all that is necessary is another include path.
Oh yes, you may try to write all this code on your own, but unlike your homemade stuff, this has already been tested and is mature, thanks to the
MATLAB on OS X won't suck now? (Score:2, Interesting)
Re: (Score:2)
MATLAB won't transition to anything. It's the only player in the market and is about as bad as Microsoft as far as licensing goes. Since they switched to activation for their licensing I have been looking for competitors. I've even had to crack some of their systems in order for it to keep working (some with an official crack, others with a not-so-legal crack). The Mathworks knows they have all educational institutions and a lot of engineering labs by the balls and can twist them however they want.
Octave is
Re: (Score:2)
Re:MATLAB on OS X won't suck now? (Score:5, Insightful)
Re: (Score:3, Interesting)
Somebody mod this insightful.
There are also incompatibilities with MacOS X. It really is a lot in regards to feel to how Java was circa '98 where you have different versions of wxWidgets and on different platforms really affecting how you have to write the code so that it works right on everything. Also long ago, when they were still wxWindows, they dropped the support of wxX11 and had you use wxGTK on unix-alikes. The wxX11 code stayed so close to working, only little tweaks are needed every now and then,
TGI Git (Score:5, Interesting)
I have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github [github.com]. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable. With the way Git works, and particularly with the implementations the hosting companies provide, it's very easy to fork a project, make the changes you want, and always have the power to commit to a remote repository that not only keeps track of all your commits but ALSO how all your commits relate back to the original forked project...
Instead of downloading someone's tarball and (maybe) emailing them a diff (or just posting your own duplicate of their source with your little changes), it's like you're making a shadow copy of a projects source, where you have all the control but no information is duplicated or lost.
Re:TGI Git (Score:5, Interesting)
have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github [github.com]. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable.
However, if you've worked with mercurial before, the experience is comparable - but not really favorably for Git.
It seems Git is this shiny thing every trend chaser is picking it up right now, but it has the overall feel of not really being ready yet. I'm glad it's having some serious competition right now, so it won't be the "obvious" choice like svn was for the previous generation. It's a mixed blessing - I'd really want us to have one obvious DVCS choice, but on the other hand I don't want it to be git as it is right now. And Git doesn't seem to be getting better fast enough, since the current users are familiar with its quirks and don't really mind that much.
Mercurial hosting? (Score:2)
Is there any kind of Mercurial hosting for open source projects you can recommend?
Re:Mercurial hosting? (Score:5, Informative)
Is there any kind of Mercurial hosting for open source projects you can recommend?
http://bitbucket.org/
And soon, google code [blogspot.com]
Re: (Score:3, Informative)
Where does Hg succeed over Git? My understanding is that a lot of people really don't like the way git merges..
- It gets by with far smaller amount of commands, that are generally understandable and do "what you would expect" (whereas with git, to get "what you would expect" you need to do some serious study).
- It reports failures in a terminology that a normal person can be expected to understand.
- It's implemented in Python and little C for speed, not a hodgepodge of every language known to man.
- Probably deriving from previous point, it has a first-class windows implementation
- It gives revisions in local repo a
Qt: a dream platform! (Score:3, Interesting)
What can I say... Qt is becoming a dream platform thanks to Nokia's insight!
- a powerful language/library (C++)
- real cross-platform
- support for embedded and mobile applications (a great alternative for the difficult Symbian C++ language)
- open source and nice licence (LGPL)
- exemplar own IDE but also Eclipse/VS integration
- additional languages supported
What else could one ask?!
Re:QT Looks Like Shit (Score:4, Funny)
Re:QT Looks Like Shit (Score:5, Funny)
I wasn't aware that software could smell at all. Unless...
Oh Python, I love you...
Re:QT Looks Like Shit (Score:4, Interesting)
It does have a certain shitness to the look, for some reason, at least in KDE. I noticed a while back that a bug was fixed in KDE 4 that rendered stuff with too many borders -- so when a widget was inside another widget, or adjoining another widget, they would both render a border. Kind of hoped that would solve the vague cluttered/weird/awkward feel, but it's hard to tell, since KDE 4 went with the horrible Oxygen theme which could make any widget library look like crap. I suspect Qt itself can still look very nice though. I don't mind the look of Google Earth, for instance, and QtDesigner is quite nice in places at least, though simplistic, even WITH it's horrible KDE4-like colors etc.
That said, Qt is way more than than a widget look/theme. It's a very nice OO library for cross-platform GUI (and non-GUI) applications, with modern threading and event-driven programming support, etc. It's one of the few libraries that make me even consider using C++ these days, as opposed to nicer, more rapid languages like python++. I also think that, if GNOME had used a library of similar quality** and similar OO features, then the GNOME desktop, and Free Software in general, would probably be a lot more advanced at this stage.
++ Yes, I know PyQt is available
** Yes, I know that GNOME was a reponse to Qt's early licenses, and that Harmony didn't pan out
Re: (Score:3, Informative)
Qt 4.5 has an excellent GTK style that makes Qt and KDE applications look just like GTK/GNOME applications, down to button ordering.
Also, Qt Creator, their new C++ IDE, is a good illustration of what a Qt application can look like. Delicious.
Re: (Score:2)
I didn't know the GNOME-compatible look/feel had improved much with Qt4.5, thanks.
On QtCreator... yeah, that's what I meant when I said QtDesigner. Just tried it last night, and it was quite... interesting. I really can't say nice, because it showed more potential than actual beauty, but it did make me stop and think a little :)
Re: (Score:2)
I swear, I've never heard of kubuntu [kubuntu.org] before.
Re: (Score:3, Insightful)
Kubuntu is not a decent version of KDE. Or KDE really sucks.
If they put half the time into kubuntu that they put into ubuntu it could become a great operating system.
Re:Should be a followup, actually (Score:4, Insightful)
Re: (Score:2)
Re:Should be a followup, actually (Score:5, Informative)
Re: (Score:2)
Re: (Score:3, Informative)
Re:Should be a followup, actually (Score:5, Informative)
qt 4.5 does have a gtk theme that uses gtk to draw the widgets. It allows me to continue using qt applications and have them match my desktop now that i no longer find kde usable as a desktop. The applications are still 1st rate.
Re: (Score:2)
GTK is a toolkit on the same semantic level Qt is. It's not a platform.
Re: (Score:2)
Re: (Score:2, Informative)
QT emulates the platform widgets, but uses the platform API (if it exists) to draw them, all event processing and widget behavior is done by QT, much like Java Swing do. previous QT version emulated the widget look too, but that was before even Windows APIs provided themes APIs (Windows XP)
Re: (Score:3, Informative)
You should tell my customers that. I've never received a single complaint about look&feel on my Qt4 software in 4 years.
Re:Should be a followup, actually (Score:5, Informative)
QT is used on cell phones as well (Score:2, Interesting)
Re: (Score:2, Informative)
Re:QT is used on cell phones as well (Score:5, Informative)
Nokia relicensed Qt as LGPL which makes it usable by non-GPL programs.
Re: (Score:2, Interesting)
Qt had a license exemptions for the major open-source licenses, which makes the licensing situation really confusing. Since one of the exempted license was BSD, arguably their "holey" GPL license is effectively just the LGPL license, since you can write a wrapper around the parts of Qt that you want, BSD-license it, and write a proprietary app that uses it.
On the other hand, unless you jump through these hoops, there will be perfectly fine open-source licenses that are LGPL-compatible (but not GPL compatibl
Re:Should be a followup, actually (Score:5, Informative)
Symbian is dead? Having 47% of smartphone sales worldwide in Q4 2008 means you're dead? [gartner.com] Really?
Re:Should be a followup, actually (Score:4, Insightful)
You have to understand the "ABC is dying/dead" mentality.
It doesn't matter how much market share you have, only that your market share is decreasing and some smaller technology which they favor has an increasing market share.
IE is dying because Firefox use is increasing in the market and IE is declining.
Unix is dying because Linux is growing and Unix is not.
It doesn't matter that at the rate of decline it would take 20 or more years for whatever it is to die. Or that the decline may be arrested. Saying something is dying is usually misinformed or more likely spreading FUD to hasten the decline.
Old technology with 80% market share drops down to 79% marketshare and new cool technology jumps up from 2% to 3% market share and old technology is declared dying. Here's a perfect example [cnet.com].
Re: (Score:2)
Unix is dying because Linux is growing and Unix is not.
Perhaps you should let Steve Jobs and Apple know about this.
Re: (Score:2)
Re: (Score:2)
Remember Palm.
Re: (Score:2)
Re:Should be a followup, actually (Score:5, Insightful)
Yes - because web frontends are the silver bullet that solves all of our client-side needs. In fact, why bother having general purpose computers out side of data centres? Instead we can have a global installation of five (for example) really big computers and we can access them using dumb internet terminals. Luckily the infinite bandwidth and uninterrupted global connectivity on offer, combined with the well enforced WWW standards means that even the most complex of GUIs can be provided via the browser. Why do we even bother with proper operating systems when everything man could need from a computer can be provided via a TCP/IP stack and XULRunner?
Oh wait, because even the best web based GUIs are primitive and unresponsive compared to a well designed, well implemented local interface. With Qt it's possible to create a native GUI that runs on all major desktop platform (and even Solaris) with less effort than it takes to get even a moderately complex web interface running correctly on IE, Firefox, Safari, Chrome and Opera.
Web interfaces are excellent for simple tasks like email and feed reading; they are terrible when deployed in more complex arenas. Even when you take in to account proprietary, binary only workarounds like Flash and Silverlight.
Doesn't work (Score:2)
This doesn't work. They tried it with Vista.
Re:Should be a followup, actually (Score:5, Insightful)
The problem is deployment and support. As much as Javascript is a pain, non-standard HTML support in IE is a pain, and a million other headaches come with a website, in many ways it's far less headache than supporting a
There's certainly a wide range of applications that will always remain fat client only. But the terminal-server model makes a lot of sense from the support perspective for many applications.
Re: (Score:2, Insightful)
Websites cannot be definitely superior and unusable in certain situations. As it is they are not definitely superior as anything that can be done on a website can be done using a local client. However not everything that a local client can do is possible on a website (unless you start using embedd
Re:Should be a followup, actually (Score:5, Informative)
Yeah sure...
>> Sales of Linux netbooks collapsed.
Proof? Sure lots of netbooks are Windows, but that doesn't mean sales of Linux models aren't increasing with the market segment.
>> Google is providing a standardized UI on top of Linux.
Incredibly immature project, and isn't even close to a competitor to Qt on anything but embedded.
>> Symbian is dead.
Well, there are millions of devices out there still with Symbian, but I agree it probably has little future.
>> Basically, there is very little need for a specialized UI toolkit like Qt
Qt is not a specialized UI toolkit. It is a general class library for C++ that happens to include UI classes.
>> now that there are both fewer platforms for it to run
Qt runs on more platforms now than ever before. I don't know what you're talking about. Symbian, WinCE, Windows 98 to 7, Linux (normal and embedded), and Mac (with Cocoa even). Name another platform that can do that.
>> and more mature competitors on the remaining platforms.
Like what? Each platform has their own thing, but unless you feel like implementing your interface 5 times, that's not really an option.
Re: (Score:2)
Yeah sure...
>> Sales of Linux netbooks collapsed.
Proof? Sure lots of netbooks are Windows, but that doesn't mean sales of Linux models aren't increasing with the market segment.
Can't offer proof or even statistics - but I think the Linux netbook thing is basically over. For a while, going with Linux instead of Windows made a significant difference in the price of the machine - and Linux could do the "netbook" job (i.e. run a web browser, etc.) just fine.
But since people wanted Windows on these machines (particularly as their storage specs improved), Microsoft made licensing Windows for these low-end machines more reasonable... With some conditions, I think. (Among other things,
Re: (Score:2)
How did you get used to the tiny keyboard?
Re: (Score:2)
How did you get used to the tiny keyboard?
The size of the keyboard is fine for me (I have long, spindly fingers) - the only problem I have currently is some minor issues with keystroke reliability - occasionally keystrokes don't register and occasionally I get some kind of multiple input from switch bounce or something...
Still, got no regrets about buying this particular netbook.
Re: (Score:3, Insightful)
None of those run on as many platforms as Qt does. And all of them look out of place on all the platforms they run on (except for SWT, which looks ok on Windows and Gnome, but runs badly on Linux).
Re:Should be a followup, actually (Score:5, Informative)
The only thing holding me back from totally adopting Qt was the outrageous licensing cost, not anything lacking in the toolkit itself. With it having gone to LGPL now, that is no longer an issue.
Re:Should be a followup, actually (Score:4, Informative)
Qt offers quite a bit more than just an abstracted UI model. Being able to have a totally common codebase across a number of platforms for a given application (including lower-level network code, threading, non-UI graphics manipulation, file I/O, printing, etc.) is a great help.
Not to mention an XML parser, localisation and Unicode support by default, a great scripting engine, MD5 and SHA1, and awesome documentation, while the whole API is built to encourage best practices.
About the only thing I'm missing is archive handling with QDir. Including bzip for a fully functional NMDC client is so last year :)
Re: (Score:2)
Same here. Only problem is that one of the major libraries "QtUiTools" is still only available as a static library which means if you use it then your app becomes GPL infected. It's hard not to use it if you use anything that creates GUI resources (eg. Qt Creator).
Is QtUiTools part of the Qt source distribution? If so, can you recompile it as a .DLL and get around the GPL encumbrance?
Re: (Score:3, Informative)
I've never used QtUiTools and I use Designer all the time.
I don't see any reason to create the UI at runtime. I just do the single inheritance model and everything gets converted to C++ at compile time.
Parent is Troll, mod down (Score:2)
Then let the better UI win. Will it be one that's Java-only, or one that can be used in its native C++ environment or with Python [python.org], Ruby [darshancomputing.com], or even Java [javaworld.com]?
Even if it were true, and with about half of the smartphones in the world running Symbian I don't think it is, what has that to do with Qt?
Huh? There are more platforms than eve
Re: (Score:2)
Google is providing a standardized UI on top of Linux.
Remember how CDE was supposed to be the standardized UI on top of X?
Remember how successful it was?
Re: (Score:2)
Re:I'm at a loss for words. (Score:5, Funny)
> I'm at a loss for words.
The word you're looking for is 'too'.
Re:I'm at a loss for words. (Score:5, Insightful)
Re: (Score:3, Informative)
And KDE isn't exactly the only software project relying on Qt. Here is a semi-official list of software projects using Qt [qtsoftware.com]. I do believe that software projects like Mathematica is a nice example of how widespread Qt is and how seriously it is being used.
Re: (Score:2, Insightful)
Re:Die to unify (Score:5, Insightful)
Just to clarify :
Nokia acquired TrollTech.
Nokia then decided to license QT under the LGPL, it wasn't a decision made by TrollTech while they were still independent
Re: (Score:2)
GP is talking about GPL. You're talking about LGPL. I'm not sure whether you think you're correcting GP or expanding on it. Could someone clarify in a way which leaves the situation clear?
Re: (Score:2)
Probably because QT was Trolltech's bread and butter, and thus wanted commercial apps to pay for a license, while QT is just a means to an end for Nokia, its end being to increase its smartphone market share and to dominate the portable device space.
Re:Die to unify (Score:5, Informative)
Actually Qt was relicensed into GPL because of KDE, not because of Gnome. KDE used Qt and came under heavy fire due to using Qt, TrollTech relicensed then Qt due to this criticis, and later on hired some of the KDE developers!
The relicensing to LGPL now happened after the Nokia buyout, and was also preplanned because Trolltech always said, if it was bought or went bankrupt it would relicense it into LGPL!
Re: (Score:2)
Free software's diversity is it's strength. Each part can be replaced with a competing component. It's all glued together with open standards. This makes things more modular and enforces the Unix philosophy "Write programs that do one thing and do it well." It's an ecosystem, competition fueling evolution. Forking into more competing versions when people disagree.
Some crazy people even replace the Linux kernel with a BSD/Solaris even Hurd!
Anyone one thinks there should only be one Linux distr
Re:Die to unify (Score:5, Insightful)
Interested rewrite of history. But it's not true. GNOME didn't drive Trolltech to open source Qt, KDE did. GNOME wasn't (and still is not) using Qt, so why should have Trolltech cared about their whines? It was KDE developers advocating for real open source that did it.
Re: (Score:2)
That horrible GNOME/GTK of yours drove Trolltech into relicensing Qt to GPL
No, what drove Trolltech into relicensing Qt under the GPL was that KDE had built on Qt assuming that it was open source and then discovered that the Qt license was incompatible with KDE. If Trolltech hadn't relicensed Qt, KDE would have been dead, and that would have been very, very bad for Qt.
Both projects thrive from eachother and the constant "battles" drive devs to find out new creative ways
Qt and KDE were a major incentive for
Re: (Score:2)
GTK+ is not horrible. The reasons people most often cite for it being horrible are in two categories:
The code is so convoluted.
That is because it is C and not C++ so it cannot take advantage of features of the language. There are times C (say you want to use it in a C program and do not want to do a bunch of glue code with C linkage) is nice and also it depends on less with a smaller overhead.
It does not do all the fancy stuff like SQL that Qt does:
Check again, things have changed, people have written code
Re: (Score:2)
Ideally, GTK+ will be rewritten in Vala. That way, we get C compatibility together with being able to write code in a modern, high-level, C#-like language (with type inference, memory management and anonymous functions, to name a few features).
Yeah, then we'd have a desktop based entirely on language/precompiler that exists solely for the developers of that desktop.
Why not start shipping Gnome as a Smalltalk system image while we are at it?
Re: (Score:3, Interesting)
Agreed. GNOME is great and all, but I feel it could have gone (and could go) a lot further with a better underlying (and fully OO from the start) library. All the stats I've seen suggest that Qt is much faster than GTK+ (and Cairo) too. The only thing is... I'd hate to lose the GNOME look/feel (especially not in favor of the god-awful KDE4 look and feel), and more importantly, I'd hate to lose Pango. Pango is probably the best thing that ever happened in GNOME.
Re: (Score:2)
resulting in unification of open-source GUI
Yeah, right. Take away choice! We hate choice! Right? ^^
Only when the last fork is unified, will you notice, that the main trunk it crap. ^^
(True for states, companies, rule sets, etc. too)
Re: (Score:2)
"is"! I meant "is". ;)
Damn! Ruined my *one* chance to be quoted. Ever.
Re: (Score:3, Funny)
Don't know why, but the phrase "Motif vs OpenLook," make me think of two retards wrestling in a vat of pudding.
Re: (Score:2)
Qt vs GTK: Who is going to capitulate to let the other win?
One thing is certain - it sure as hell won't be Qt.
It survived under QPL and GPL - it's basically unstoppable under LGPL (and relavite "financial independence" under the Nokia umbrella).
Re: (Score:2)
Last I checked QT 4.5 Visual Studio compiler still required a license and lots of money. Only the MinGW + QT was free. I guess it's ok if you use sharedevelop and tell it to use the MinGW compiler toolchain, but for someone wanting the VS integration it is not too good. Has this changed?
http://www.qtsoftware.com/downloads/visual-studio-add-in
Re: (Score:2)
that's the add-in. I didn't know that existed before. Anyway, the commercial version says it has full visual studio integration. What does that mean? What is the difference. If there is no difference then why would anyone pay the a commercial license?
I don't know what's the status with visual studio toolchain proper at the moment (I don't do windows development); but I think the important thing is the VS compiler + debugger support in qt creator. Full Visual Studio integration (VS IDE) was important before qt creator, since all we had on windows side was the buggy eclipse plugin.
Just try Qt Creator.
Re: (Score:2)
There are unofficial qmakespecs for visual studio. The missing official VS support has got something to do with licensing incompatibilities between LGPL/GPL IIRC (but I'm unsure).