Beta
×

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!

Qt Opens Source Code Repositories

timothy posted more than 5 years ago | from the good-news-on-a-few-fronts dept.

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

Sorry! There are no comments related to the filter you selected.

QT Looks Like Shit (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27922671)

and smells like it too.

Re:QT Looks Like Shit (4, Funny)

NoStarchPlox (1552983) | more than 5 years ago | (#27922687)

Yes, QuickTime is definitely shitty but what does that have to do with Qt?

Re:QT Looks Like Shit (4, Funny)

Frnknstn (663642) | more than 5 years ago | (#27924079)

I wasn't aware that software could smell at all. Unless...

>>> import odour

Oh Python, I love you...

Re:QT Looks Like Shit (3, Interesting)

CarpetShark (865376) | more than 5 years ago | (#27924309)

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:QT Looks Like Shit (3, Informative)

salimma (115327) | more than 5 years ago | (#27924397)

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:QT Looks Like Shit (1)

CarpetShark (865376) | more than 5 years ago | (#27924499)

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:QT Looks Like Shit (0, Flamebait)

FictionPimp (712802) | more than 5 years ago | (#27924745)

Now all that is needed is a decent version of KDE for ubuntu.

Re:QT Looks Like Shit (1)

poetmatt (793785) | more than 5 years ago | (#27924997)

I swear, I've never heard of kubuntu [kubuntu.org] before.

Should be a followup, actually (0, Flamebait)

BadAnalogyGuy (945258) | more than 5 years ago | (#27922739)

Sales of Linux netbooks collapsed. Google is providing a standardized UI on top of Linux. Symbian is dead. Basically, there is very little need for a specialized UI toolkit like Qt now that there are both fewer platforms for it to run and more mature competitors on the remaining platforms.

Sayonara, Qt. Hope you beat Gnome on the desktop!

Re:Should be a followup, actually (4, Insightful)

skeezixcodejedi (1344929) | more than 5 years ago | (#27922801)

Ignoring the enormous benefits of a single codebase for Windows, Linux/BSD and Mac OSX of course. (Yes, people still make applications for desktops and notebooks .. not just netbooks, PDAs/smartphones)

Re:Should be a followup, actually (0, Troll)

beelsebob (529313) | more than 5 years ago | (#27922843)

The enormous benefits of having a UI that no one wants to use on any of the platforms, because it doesn't behave, let alone look like they expect it to?

Re:Should be a followup, actually (0)

Anonymous Coward | more than 5 years ago | (#27922879)

Ignoring that Qt supports native widgets and UI patterns on whatever OS it's used on.

Re:Should be a followup, actually (5, Informative)

NoStarchPlox (1552983) | more than 5 years ago | (#27922921)

You must be a bit behind the times as Qt no longer emulates a native look-and-feel but uses the native widgets of the platform.

Re:Should be a followup, actually (1)

AnyoneEB (574727) | more than 5 years ago | (#27923327)

Cool. How do I get Amarok and k3b to use GTK widgets on my computer?

Re:Should be a followup, actually (3, Informative)

NoStarchPlox (1552983) | more than 5 years ago | (#27923459)

Since when was GTK+ a native graphics api? Oh wait, it's not. Qt uses Xlib on an X Windows System which is the native graphics API.

Re:Should be a followup, actually (5, Informative)

garvon (32299) | more than 5 years ago | (#27923809)

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:Should be a followup, actually (1)

Jurily (900488) | more than 5 years ago | (#27924025)

GTK is a toolkit on the same semantic level Qt is. It's not a platform.

Re:Should be a followup, actually (2, Informative)

robmv (855035) | more than 5 years ago | (#27923931)

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:Should be a followup, actually (0)

Anonymous Coward | more than 5 years ago | (#27923937)

Qt no longer emulates a native look-and-feel but uses the native widgets of the platform.

That's simply wrong. Qt doesn't use native widgets on any platform. It just uses the theming engine of each platform.

Re:Should be a followup, actually (2, Informative)

pherthyl (445706) | more than 5 years ago | (#27923145)

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 (4, Informative)

daem0n1x (748565) | more than 5 years ago | (#27923305)

My company develops cross-platform applications for Windows, MAC and LInux in C++. Qt is one hell of a cross-platform UI toolkit.

Re:Should be a followup, actually (1)

elashish14 (1302231) | more than 5 years ago | (#27923897)

Excuse me? I can run programs on my desk? This qt things sounds amazing!

QT is used on cell phones as well (2, Interesting)

DomNF15 (1529309) | more than 5 years ago | (#27922961)

I worked on the software for a Motorola unit that used Qt UI framework. What is interesting is that Moto moved away from Qt when one of their major competitors (Nokia) bought Trolltech (the company that makes Qt). Two years later they open source it, I don't quite get it...

Re:QT is used on cell phones as well (3, Informative)

NoStarchPlox (1552983) | more than 5 years ago | (#27923047)

Qt was open source long before Nokia bought Trolltech. The issue was that the original license they used didn't allow you to redistribute modifications and then the subsequent Q Public license, which was a free software license, wasn't compatible with the GPL. Then in 2000 Trolltech released it under the GPL. So I'm not sure where you got that Nokia open sourced Qt, since it had been open source for close to a decade before Nokia came along.

Re:QT is used on cell phones as well (5, Informative)

larry bagina (561269) | more than 5 years ago | (#27923161)

Qt was Open Source in that it was GPL, however trolltech was dual licensing it. Being GPL, it was toxic to anything but GPL programs, which meant closed source (or even non-GPL open source) would need to pay for Qt.

Nokia relicensed Qt as LGPL which makes it usable by non-GPL programs.

Re:QT is used on cell phones as well (1)

NoStarchPlox (1552983) | more than 5 years ago | (#27923201)

Yes, I know Nokia tri-licensed it with the LGPL as an option. The point was that the GP was making it sound like it was closed source before Nokia came along which isn't true since anyone could freely look at the source for a decade before that.

Re:QT is used on cell phones as well (2, Interesting)

salimma (115327) | more than 5 years ago | (#27924483)

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 compatible) that you cannot use, either because its a minor license that Qt's lawyers have not seen, or because it's too new. It took a while for Qt to be GPL3 compatible, for example.

Re:Should be a followup, actually (5, Informative)

Anonymous Coward | more than 5 years ago | (#27922993)

Re:Should be a followup, actually (3, Insightful)

rackserverdeals (1503561) | more than 5 years ago | (#27923275)

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:Should be a followup, actually (1)

Fujisawa Sensei (207127) | more than 5 years ago | (#27923469)

Unix is dying because Linux is growing and Unix is not.

Perhaps you should let Steve Jobs and Apple know about this.

Re:Should be a followup, actually (1)

Hognoxious (631665) | more than 5 years ago | (#27924011)

It's dead as in the "doesn't originate in the USA" sense.

Re:Should be a followup, actually (0)

Anonymous Coward | more than 5 years ago | (#27923001)

I've clearly been living under a rock for the last five years - can you expand on the UI which Google is providing for Linux?

Re:Should be a followup, actually (1)

Tdawgless (1000974) | more than 5 years ago | (#27923425)

Android.

Re:Should be a followup, actually (1)

Hognoxious (631665) | more than 5 years ago | (#27924201)

Android is an operating system, not a GUI.

Re:Should be a followup, actually (1)

entgod (998805) | more than 5 years ago | (#27923005)

You forget who owns Qt. Symbian is not really dying yet (come on, the biggest mobile phone manufacturer uses it in all its smartphones), if it were, it would mean that Qt were becoming more relevant as, you know, the day symbian dies is the day that nokia switches to linux (not the android kind).

Re:Should be a followup, actually (0)

Anonymous Coward | more than 5 years ago | (#27923721)

You forget who owns Qt. Symbian is not really dying yet (come on, the biggest mobile phone manufacturer uses it in all its smartphones), if it were, it would mean that Qt were becoming more relevant as, you know, the day symbian dies is the day that nokia switches to linux (not the android kind).

Maemo?

Re:Should be a followup, actually (5, Insightful)

vrai (521708) | more than 5 years ago | (#27923009)

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 (1)

CarpetShark (865376) | more than 5 years ago | (#27924427)

we can have a global installation of five (for example) really big computers and we can access them using dumb internet terminals.

This doesn't work. They tried it with Vista.

Re:Should be a followup, actually (5, Informative)

Anonymous Coward | more than 5 years ago | (#27923111)

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:Should be a followup, actually (1)

Tetsujin (103070) | more than 5 years ago | (#27924249)

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, everyone's wording of "____ recommends Microsoft Windows for everyday computing" seems rather consistent) It's more or less killed the incentive to make Linux netbooks, as the majority of users (whether or not you or I would feel the same) would rather have Windows on the machine.

Personally, I have Debian on my 901 and it's bliss. Not so much as a Windows logo on the keyboard, and the software works the way I expect.

Re:Should be a followup, actually (1)

Dan Ost (415913) | more than 5 years ago | (#27924749)

How did you get used to the tiny keyboard?

Re:Should be a followup, actually (1)

Tetsujin (103070) | more than 5 years ago | (#27924993)

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:Should be a followup, actually (0)

Anonymous Coward | more than 5 years ago | (#27925051)

Name another platform that can do that

AWT? Swing? SWT?

(burned)

Re:Should be a followup, actually (4, Informative)

NormalVisual (565491) | more than 5 years ago | (#27923183)

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.

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 (3, Informative)

Jurily (900488) | more than 5 years ago | (#27923713)

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:Should be a followup, actually (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27924627)

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.

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

I would have preferred cheaper licensing rather than going LGPL. Something reasonable like the other major developer toolkits. $300 or so for all platforms. Their current pricing is just obnoxious. Especially for freelance developers like myself, paying nearly $3700 plus, what, $2000 or so per year for a single developer on a single platform is absolutely absurd. At that price I could buy a developer subscription with multiple licenses to practically every single product Microsoft and Apple make combined (including operating systems, databases, developer tools, the whole works). Who do they think they are? I mean shit, they're just providing a GUI API and some cross-platform helper API's.

Re:Should be a followup, actually (1)

Anonymous Coward | more than 5 years ago | (#27923205)

Qt is not just a toolkit that replaces MFC, it's a whole set of libraries that can do much more (eg. containers, signals & slots, auto ptrs, sql relational mapping to objects, networkprotocols, and so on and on)

IMHO Qt is what Java promised to be, a truly platform independent development system. I love it, especially since they fully open-sourced it (before only on Unix platforms). And now with qtcreator, even the Visual Studio guys don't have an excuse anymore not to use it.

So, please don't say Qt is just a toolkit, it's much much more.

Parent is Troll, mod down (1)

mangu (126918) | more than 5 years ago | (#27923351)

Google is providing a standardized UI on top of Linux

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] ?

Symbian is dead.

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?

there is very little need for a specialized UI toolkit like Qt now that there are both fewer platforms for it to run

Huh? There are more platforms than ever for Qt to run. Do you mean Microsoft [trolltech.com] isn't delivering operating systems anymore?

Re:Should be a followup, actually (0)

Anonymous Coward | more than 5 years ago | (#27923421)

You are flaming alright but you should have chosen better reasons than that. Lets see - Linux netbooks - irrelevant, what has Linux sales on netbooks got to do with Qt? It's a cross platform UI toolkit. Google Android - It's a nascent Cellphone/PDA platform not the panacea for all UI development - Qt is much closer to being a panacea. Symbian is dead - Last I checked Symbian had the most market share - and I use it daily on my E71, believe me it is far more stable and responsive than any other mobile OS out there - have not rebooted the phone since months. Beating Gnome on the desktop - irrelevant for the same reason as the netbook point above, and if you ask me KDE4 is looking far more pretty and usable than Gnome right now. Besides Qt4 is a compelling choice if you are building an application that is supposed to be cross platform. You could port the application to Symbian and WinCE in no time as an added bonus.

Re:Should be a followup, actually (1)

Fujisawa Sensei (207127) | more than 5 years ago | (#27923577)

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?

Die to unify (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#27922789)

The only complain developers had with QT/KDE was that it was not LGPL. It was one of the main reasons behind creation of horrible GNOME/GTK. Now lets hope that god awful GTK dies and opens-source developers embrace QT resulting in unification of open-source GUI.

Amen..

Re:Die to unify (2, Insightful)

noundi (1044080) | more than 5 years ago | (#27923045)

That horrible GNOME/GTK of yours drove Trolltech into relicensing Qt to GPL. Thus Qt, and even Linux, wouldn't even be close to where it is today without GNOME. Say what you want about Ubuntu, but it's a fact that FOSS (and in particular Linux) awareness has grown immensely due to its contributions, and I doubt Kubuntu is to thank for this. It's a question of flavor, and I like to have options. Both projects thrive from eachother and the constant "battles" drive devs to find out new creative ways in order to be "unique" and innovative. Sure there's an advantage to cooperation, but without competition there's no pressure.

Re:Die to unify (4, Insightful)

Saffaya (702234) | more than 5 years ago | (#27923619)

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:Die to unify (1)

pjt33 (739471) | more than 5 years ago | (#27923787)

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:Die to unify (4, Informative)

MemoryDragon (544441) | more than 5 years ago | (#27924711)

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:Die to unify (1)

jabjoe (1042100) | more than 5 years ago | (#27924785)

Exactly!

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 distro doesn't get it at all.

Re:Die to unify (4, Insightful)

Brandybuck (704397) | more than 5 years ago | (#27924933)

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:Die to unify (0)

Anonymous Coward | more than 5 years ago | (#27923051)

Motif vs OpenLook: Sun capitulated to let Motif win.

Qt vs GTK: Who is going to capitulate to let the other win?

I'm reasonably certain that open-source-survival-of-the-fittest won't be that easy.

Re:Die to unify (3, Funny)

Anonymous Coward | more than 5 years ago | (#27923195)

Motif vs OpenLook: Sun capitulated to let Motif win.

Don't know why, but the phrase "Motif vs OpenLook," make me think of two retards wrestling in a vat of pudding.

Re:Die to unify (1)

ultrabot (200914) | more than 5 years ago | (#27923845)

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:Die to unify (0)

Anonymous Coward | more than 5 years ago | (#27924265)

Motif vs OpenLook: Sun capitulated to let Motif win.

The world of free software works differently. The only thing that matters is how many people use the toolkit to make applications.

And speaking as a programmer who is currently using GTKMM, it really doesn't matter to me how accepted it is. I have considered everything from QT and WX to JUCE, FOX and oddball opengl based toolkits. And I picked the one I liked the best. Baddabing baddabom.

And really, these days there is no reason to try and standardize.

Re:Die to unify (1)

mzs (595629) | more than 5 years ago | (#27924323)

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 to do more now that may not be a part of GTK+ itself though but freely available. Also again Qt is a huge thing that then defines how the rest of your program has to be written to interface with it (containers, pointers, signals, and slots for example). Also it is resource intensive because it does so much.

Re:Die to unify (1)

salimma (115327) | more than 5 years ago | (#27924547)

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

Re:Die to unify (2, Interesting)

CarpetShark (865376) | more than 5 years ago | (#27924387)

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.

I'm at a loss for words. (0, Troll)

AftanGustur (7715) | more than 5 years ago | (#27922847)

What can I say ? Qt has been developed since 1991

This is like ... well .. 18 years to late ..

Re:I'm at a loss for words. (5, Funny)

dwater (72834) | more than 5 years ago | (#27922939)

> I'm at a loss for words.

The word you're looking for is 'too'.

Re:I'm at a loss for words. (4, Insightful)

entgod (998805) | more than 5 years ago | (#27923021)

Too late for what? Too late for it to become adopted? Have you heard of the K desktop environment?

Re:I'm at a loss for words. (1)

maxume (22995) | more than 5 years ago | (#27923163)

Is that from Men in Black?

Re:I'm at a loss for words. (0)

Anonymous Coward | more than 5 years ago | (#27923909)

Too late for what?

Somewhere in the distance I hear the bells ring
Darkness settles on the town as the children start to sing
The lady 'cross the street she shuts out the night
There's a cast of thousands waiting as she turns out the light

London boys are staring as the girls go hand in hand
With a pocket full of innocence, their entrance is grand
And the Queen of the dream stands before them all
She stretches out her hand as the curtains start to fall

Standing by the trapdoor aware of me and you
Are the actor and the clown their waiting for their cue
And there's a lady over there she's acting pretty cool
But when it comes to playing life she's always playin' the fool

Qt GTK (5, Interesting)

Anonymous Coward | more than 5 years ago | (#27922855)

I hope Gnome switches to Qt one day, its so much nicer than GTK.

not a troll (4, Insightful)

CarpetShark (865376) | more than 5 years ago | (#27924713)

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:not a troll (1)

vurian (645456) | more than 5 years ago | (#27924889)

Rosegarden is quite a famous example, especially since one of the rosegarden authors used to be a gtkmm maintainer. His articles on the subject can still be found and are still well worth reading.

The first things to do (4, Insightful)

master_p (608214) | more than 5 years ago | (#27923237)

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 (5, Insightful)

Clith (5063) | more than 5 years ago | (#27923303)

Qt's collection classes are API compatible with STL. So I would argue that it plays nicely already. I prefer Qt containers to STL containers because Qt's classes have been optimized. STL has some issues with performance.

Re:The first things to do (3, Insightful)

Futil3 (931900) | more than 5 years ago | (#27923801)

Better than STL? [google.se]

An STL implementation has a few things going in its favor:

STL implementations use best-of-breed algorithms.
The designers of STL implementations are, more than likely, domain experts.
Those domain experts were entirely focused on the mission of providing a flexible, powerful, and efficient library. This was their primary task.

But then again. (only) You know your own usage scenario, data types and platform. That knowledge can probably offer some profound short cuts and optimizations.

Re:The first things to do (1)

CortoMaltese (828267) | more than 5 years ago | (#27924621)

I haven't really followed up on the recent developments of Qt or STL, but I was under the impression that Qt containers implement copy-on-write while STL ones don't. Correct me if I'm wrong.

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:The first things to do (0)

Anonymous Coward | more than 5 years ago | (#27925005)

COW interacts horribly with threading and a few corner cases of the API (pointer invalidation, two references to the container, etc).

The standard C++ string is designed to allow COW implementations, and they invariably cause trouble.

The only really useful place for COW is to avoid a copy when returning an object from a function, and most compilers already elide that copy via NRVO.

Re:The first things to do (0)

Anonymous Coward | more than 5 years ago | (#27923805)

I prefer Qt containers to STL containers because Qt's classes have been optimized.

And you think that STL containers are not optimized?

STL has some issues with performance.

What exactly?

Re:The first things to do (1)

mzs (595629) | more than 5 years ago | (#27924217)

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 (3, Informative)

zander (2684) | more than 5 years ago | (#27924553)

the shared_ptr equivalent in Qt is QSharedPointer (surprise!) not QPointer which is something quite different. I do suggest not using shared_ptr as the Qt version has better cross-platform support and is easier to use and like most Qt things has better readability.

Re:The first things to do (0)

Anonymous Coward | more than 5 years ago | (#27924417)

Having optimized containers is one thing, but using them as base type instead of the STL throughout the API is another entirely.

Would be nice if you didn't have to (at best) typecast or (at worst) convert all your standard data types to use _anything_ in QT.

IMHO, it's a case of "Not Invented Here" syndrome made worst by the "ignore standard implementations and tightly couple all of our stuff" philosophy.

Re:The first things to do (2, Interesting)

Brandybuck (704397) | more than 5 years ago | (#27924775)

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:The first things to do (1)

ultrabot (200914) | more than 5 years ago | (#27923803)

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 (0)

Anonymous Coward | more than 5 years ago | (#27923887)

Do boost signals use string like QT or is it template driven like libsigc++?

I like libsigc++ a lot. It is what makes gtkmm endurable. The lack of documentation and general quirkyness keeps you on your toes though, but the libsigc part rocks.

Re:The first things to do (5, Insightful)

pyrico (1034804) | more than 5 years ago | (#27924117)

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:The first things to do (0)

Anonymous Coward | more than 5 years ago | (#27924243)

Yeah because Boost is such a great thing. Often to use just a little Boost API you have to pull in massive amounts of other code. You might as well just install Java because it would be smaller than installing all the Boost shit (note, I'm no fan of Java).

I'll stick with the simple STL and my own cross platform API's. My own thread libraries and such are orders of magnitude smaller and simpler than the bloated, complex Boost crap.

Re:The first things to do (2, Interesting)

PerlDudeXL (456021) | more than 5 years ago | (#27924405)

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:The first things to do (1)

oever (233119) | more than 5 years ago | (#27924871)

boost::thread has a different design concept than QThread. I would appreciate if Qt
would introduce a Functor-style API for Threads.

Like QtConcurrent [qtsoftware.com] ?

Re:The first things to do (2, Insightful)

harry1701 (1553093) | more than 5 years ago | (#27924533)

The use of boost will greatly limit the amount of supported platforms and compilers. Replacing Qt collections with STL will kill the embedded branch, where code expansion counts. It'll also not be nice for the deskop - imagine loading a Visual Studio plugin while another plugin is loaded that uses another STL implementation -> boom, symbol clashes.

Re:The first things to do (1)

Brandybuck (704397) | more than 5 years ago | (#27924663)

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 a functor is. They just aren't used much out in the non-academic world. I'm not saying this to belittle Boost, I think it's a great tool set. But one must recognize reality for what it is.

But don't worry about it! Nothing in Qt denies you the ability to use the STL or boost::signals or boost::threads. There are a few caveats of you try to mix thread types, but nothing fundamentally stops you from using them.

MATLAB on OS X won't suck now? (2, Interesting)

myNameIsNotImportant (592769) | more than 5 years ago | (#27923295)

Maybe now that QT is LGPL, Mathworks will finally transition MATLAB on OS X out of X11 and make it behave like a proper OS X app. ...One can dream....

Re:MATLAB on OS X won't suck now? (0)

Anonymous Coward | more than 5 years ago | (#27923563)

If they'd wanted to use a cross platform GUI toolkit with a liberal license they could have used wxWidgets. So I guess nothing will change.

Re:MATLAB on OS X won't suck now? (5, Insightful)

sys.stdout.write (1551563) | more than 5 years ago | (#27924515)

As somebody who has just spent the morning trying to work out inconsistencies in wxWidgets between Windows and Linux, let me just say: shush. It's not that wxWidgets is bad, but Qt's we-are-going-to-implement-everything-ourselves-so-it-acts-the-same-on-all-platforms approach has merit.

Re:MATLAB on OS X won't suck now? (1)

guruevi (827432) | more than 5 years ago | (#27923839)

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 good but is not a real competitor because it isn't fully compatible (which would mean they would need to break stuff in order to emulate the backwards-compatibility of MATLAB) and it doesn't have all the necessary toolboxes scientists like to use.

Re:MATLAB on OS X won't suck now? (0)

Anonymous Coward | more than 5 years ago | (#27924565)

You are paying for support and features when you buy mathworks licenses. You could do virtually literally everything you end up doing in matlab in ANY programming language. There are programs like R, Octave, and Python that could implement the same solution as you could in matlab at zero software license cost.

With Mathworks, you get their product and then get unlimited technical support where they will spend whatever time is required to make you a better programmer and show you exactly how to get your specific problem done in an extremely rapid fashion.

Mathworks is certainly not an evil company compared to the options out there. People don't value time, for whatever reason. If you are doing something as a hobby (i.e. time value = 0), get your hands on the student version or use R/Octave/Python. If you're doing serious engineering, pay for Matlab and get the support as well.

Re:MATLAB on OS X won't suck now? (1)

JimProuty (1298167) | more than 5 years ago | (#27924793)

Perhaps use the lower-cost, well-supported Igor Pro, instead? http://www.wavemetrics.com/ [wavemetrics.com] Disclaimer: I work there :-)

Re:MATLAB on OS X won't suck now? (1)

chthonicdaemon (670385) | more than 5 years ago | (#27924493)

I reckon most of the Matlab frontend is Java. As near as I can tell, only the plotting part uses X at all on OS X. That said, the insane license manager they use for Unix-like platforms (as opposed to a very simple activation code in Windows) has led me to scipy. I have not looked back much, except for the interactive graphs they added to the newer releases.

TGI Git (4, Interesting)

iluvcapra (782887) | more than 5 years ago | (#27923951)

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 (4, Interesting)

ultrabot (200914) | more than 5 years ago | (#27924523)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?