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!

Free Software Faces a Test With Qt

Unknown Lamer posted more than 3 years ago | from the here-code-pick-me dept.

KDE 177

An anonymous reader writes with an article in TechRadar. From the article: "Thanks to Nokia's jump to Windows Phone 7, from the frying pan into the fire, its Free Software darling, the Qt toolkit, has been left living on vague promises and shell-shocked, hollow enthusiasm. Nokia has pledged some continued investment, bonuses for developers who stick with the platform and even a phone or two that might use it. But the truth is that Qt is deprecated, the project has stalled, and its future is uncertain."

cancel ×

177 comments

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

In completely unrelated news (2, Informative)

Anonymous Coward | more than 3 years ago | (#36301618)

Nokia today [theregister.co.uk] restated their sales and profit projections for this quarter and retracted the full year prediction completely. They report seeing strong competition in emerging markets and pricing pressures around the world. The stock's price fell over 14 percent on the day and plumbed a new full-year low. On the upside there is increasing confidence they'll be able to ship at least one WP7 product before the end of the year.

Re:In completely unrelated news (4, Insightful)

Compaqt (1758360) | more than 3 years ago | (#36301758)

In a statement Stephen Elop, Nokia's CEO, said the company must "accelerate the pace of our transition"

Hilarious. Translated: March faster to oblivion.

What fool would buy a Nokia smartphone after all the jerking around of customers and developers? The sad thing is Nokia had the best actual phone technology in the business (i.e., actually making calls with good voice quality).

Re:In completely unrelated news (0, Flamebait)

Anonymous Coward | more than 3 years ago | (#36302140)

Sorry, I did not know that modern mobiles could be used to make phone calls. Five years ago maybe, but nowadays only hopelessly retarded people care about the quality of voice calls. Some would even consider dropping that capability if it made the device cheaper.

Re:In completely unrelated news (0)

Anonymous Coward | more than 3 years ago | (#36302264)

Yep. When I realized that the phone was the least-used 'application' on my iPhone, it was pretty clear what was about to happen.

Shame nobody at Nokia was awake and paying attention.

Re:In completely unrelated news (0)

Anonymous Coward | more than 3 years ago | (#36302368)

heavy weight market colossus simply cannot evolve fast enough to cope with change. They just barely managed now to ditch symbian, but they did too little, to late.

they have good hardware and the nokia N8 is(was) quite impressive, but the market is no longer caring about hardware - this is the ibm pc situation repeating all over.

customer will be loyal to the brand only in the early expansion, where they're close to the ware and make informed choices about the product. As soon as the market enlarges, marketing gains weight and the actual merit of the device goes on a little writing on a small side of the box, leaving the rest to marketing and placement.

this permits the business to evolve. and evolution is actually a good term: pretty rarely a company can manage to survive the change in the market landscape. Usually minor companies producing niche products get lucky and jump on a trend right at his beginning, like htc with android. other try to follow, like motorola, and suceed. others simply cannot change and die off, leaving the market to the most adapt.

DOES ANY ONE HERE REMEMBER? (1)

Jeremiah Cornelius (137) | more than 3 years ago | (#36302422)

This was the sort of license/ownership issue forseen by Miguel and the crew back 'round '97.

That's when the GNOME project was initiated, as a hedge against Qt forking up - despite the stated good intentions of TrollTech.

Re:DOES ANY ONE HERE REMEMBER? (2)

walshy007 (906710) | more than 3 years ago | (#36303570)

They made gtk back when QT had crappy licensing conditions, since QT 1.4 (around 1998) then these conditions have been remedied and qt is distributed by gpl (or commercial if you feel like paying).

Is it possible less developers will use it? sure, but that isn't a problem with licensing, qt is gpl and lgpl licensed (with commercial available if you pay). I fail to see the issue as this was resolved well over a decade ago.

Re:In completely unrelated news (0)

Anonymous Coward | more than 3 years ago | (#36302026)

From yahoo (yikes - ugly-ass link, so I hope it works):

http://finance.yahoo.com/news/Nokia-warns-of-weaker-sales-rb-3982930229.html;_ylt=AjBy4kv9Oq_ZQekq56iUED67YWsA;_ylu=X3oDMTE1YjE2aGtyBHBvcwM1BHNlYwN0b3BTdG9yaWVzBHNsawNub2tpYXdhcm5zb2Y-?x=0&sec=topStories&pos=2&asset=&ccode=

In large part they blame competition from smartphones running iOS and Android. I like Nokia, and it's unfortunately for them, but they appear to really have bungled the transition from featurephones to smartphones. The world's cell phone market is slipping away from them as people increasingly move to smartphones.

Re:In completely unrelated news (1)

Anonymous Coward | more than 3 years ago | (#36302164)

If only there was a magical way to shorten URLs. Would be a great business idea, probably.

Re:In completely unrelated news (0)

Anonymous Coward | more than 3 years ago | (#36302274)

There is, but there are really, really good reasons not to use such "services".

Re:In completely unrelated news (0)

Anonymous Coward | more than 3 years ago | (#36302364)

Goatse! LemonParty! BlueWaffle!

For your own sanity: please do not ever google those terms.

Re:In completely unrelated news (3, Funny)

catalina (213767) | more than 3 years ago | (#36302490)

On the upside there is increasing confidence they'll be able to ship at least one WP7 product
A WP7 product is an upside?

er... (2)

brennanw (5761) | more than 3 years ago | (#36301628)

... hasn't QT been LGPL'd? I don't see the problem.

Re:er... (3, Informative)

jonbryce (703250) | more than 3 years ago | (#36301666)

The problem is that development is funded by the people who pay for non-free licences. If that income dries up, the KDE project would have to put their own development team together with volunteers or donation/grant funded developers.

That's not a huge problem... (2)

brennanw (5761) | more than 3 years ago | (#36301750)

KDE is already involved in the changes it wants for QT that are KDE-specific, aren't they? It's not like that would stop development cold. Hell, it might even make it easier for them to get the changes they want put in. Whether that adversely effects the rest of the developers who use QT for other things... well, I can't speak to that.

Re:That's not a huge problem... (0, Insightful)

Anonymous Coward | more than 3 years ago | (#36302880)

Most of the developers I know that use Qt don't like KDE. They use Qt for C++ development that must be cross platformed. If KDE starts to dominate the library then I see the writing on the wall...

Re:That's not a huge problem... (1)

Anonymous Coward | more than 3 years ago | (#36303602)

No what the parent means is that the number of developers on the QT project will be reduced. From what I hear by a good margin. Most of the QT developers are Nokia people, there will still be the community developers but the for pay ones contributed the most code.

No doubt this will slow the project down quite a bit.

Re:er... (0)

Anonymous Coward | more than 3 years ago | (#36301884)

Seeing as it's the #1 desktop for open source OSes, that's not exactly a problem. Stop the FUD, eh?

Re:er... (1)

CSMoran (1577071) | more than 3 years ago | (#36302488)

During the year of the desktop in particular... I mean, sheesh...

Re:er... (1)

jbolden (176878) | more than 3 years ago | (#36302670)

They do that with the rest of QT, what's so hard about supporting a widget kit at this point?

Re:er... (1)

infolation (840436) | more than 3 years ago | (#36303728)

Two commerical reasons why it isn't going to dry up anytime soon:

Autodesk Maya
The Foundry's Nuke

Re:er... (5, Informative)

MrHanky (141717) | more than 3 years ago | (#36301678)

It has. Also, anyone bothering to check facts, such as the public git repository, can see that it's still actively developed.

Re:er... (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#36301824)

Being actively developed does not necessarily mean "developed by people with a clue, and some kind of coherent vision." In FOSS, sometimes too much emphasis is given to what is possible in principle, versus what is actually occurring.

Re:er... (3, Insightful)

Anonymous Coward | more than 3 years ago | (#36301740)

... hasn't QT been LGPL'd? I don't see the problem.

Some feel that Qt's superiority stems from its corporate sponsorship, and that being "demoted" to a sponsorless open-source project like GTK will result in a loss in quality. Others (like me) think that a lot of the quality is in the product design itself and that while development may slow down post-Nokia, it will still provide a superior open source toolkit for the forseeable future.

Re:er... (4, Insightful)

mirix (1649853) | more than 3 years ago | (#36302640)

It was GPL/commercial dual licence for ages, and more recently LGPL'd.

Development is continuing, this is a complete FUD non-story. Qt isn't going to disappear even if Nokia did.

No (2, Informative)

Anonymous Coward | more than 3 years ago | (#36301654)

It hasn't.

First comment on referenced article (5, Informative)

Anonymous Coward | more than 3 years ago | (#36301658)

From the first comment on the linked article:

You obviously have no idea what you're talking about, and have not been following the Qt project's development lately.

Development is steaming ahead, releases are coming out, and they are hard working on Qt 5. They are also putting Qt into open governance, so even "outside" people may take "ownership" of certain parts of the project, and be more involved in the development of the project.

Qt is, in other words, no way near its end of life. (Also, KDE wouldn't *need* to fork, if Qt did come to its End of Life. Obviously you haven't heard of the KDE Free Qt Foundation, which was set up very early on between KDE and then Trolltech (and updated when Nokia bought Trolltech). Should Nokia discontinue the development of the Qt Free Edition under the LGPL 2.1 and the GPL 3 licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreement stays valid in case of a buy-out, a merger or bankruptcy.)

So please, stop spreading FUD.

This is a lot more accurate than the article or the Slashdot post. Seriously, folks, Qt existed a long time before Nokia. KDE never needed Nokia's support, and Nokia didn't use KDE. Keep calm and carry on.

Re:First comment on referenced article (-1)

Anonymous Coward | more than 3 years ago | (#36301844)

You mean the hopelessly unreliable KDE... the one one that since 4.0 has barely been able to run for 10m without crashing? Yeah... it's a shining beacon of quality.

Face it. QT without it's corporate sponsors removes one professional thing from the KDE stack.

You're fucked.

Re:First comment on referenced article (2)

eldepeche (854916) | more than 3 years ago | (#36301922)

blah blah windows 98 blah blue screen blah

Re:First comment on referenced article (2)

knotprawn (1935752) | more than 3 years ago | (#36301940)

I've been running KDE on arch for the past one month without a single crash. Been using KDE for years now. 4.0 was buggy, but the latest releases are extremely stable. I understand that mine may be an isolated case, but your comment may have an equally unreliable basis. Simply wanted to point that out.

Re:First comment on referenced article (2)

knotprawn (1935752) | more than 3 years ago | (#36301988)

in the previous comment, I mean that I haven't experienced a crash, or the need to reboot in a month. KDE may not be the most bug-free DE out there, but in terms of reliability, I've experienced nothing but improvement over the past few years.

Re:First comment on referenced article (2)

ThePhilips (752041) | more than 3 years ago | (#36302054)

I tracked KDE 4 versions, starting with 4.0 and up to 4.3, via VirtualBox'ed Aptosid (at the time called Sidux) installation, and never had seen such problems. There were early problems upgrading KDE3 to KDE4, and in KDE 4.0/4.1/4.2 many vital pieces were missing - but otherwise, I have never seen the "crash every 10m" behavior you mention.

Re:First comment on referenced article (1)

pantherace (165052) | more than 3 years ago | (#36303716)

Indeed, even when I was running direct cvs and later svn versions, that rarely happened, and usually it was fixed if I rebuilt it a few hours later.

Re:First comment on referenced article (3, Interesting)

Anonymous Coward | more than 3 years ago | (#36302064)

I can only agree. Just take a look at all the (FOSS/non-FOSS) projects that currently use Qt (from wikipedia [wikimedia.org] ):

Qt is most notably used in Autodesk Maya, Dassault DraftSight, Google Earth, KDE, Adobe Photoshop Album, the European Space Agency, OPIE, Siemens, Volvo, Walt Disney Animation Studios, Skype, VLC media player, Samsung, Philips, Panasonic, VirtualBox and Mathematica.

Maybe it will be developed by other people, but it's probably safe to say that it won't die so soon.

PS: Skype uses Qt? Could be interesting to see what Microsoft will do about that...

Re:First comment on referenced article (0)

Anonymous Coward | more than 3 years ago | (#36302834)

Other examples, for information: Opera uses Qt on Linux. It is also used on Linux for the control center of ATI graphics cards and for the one of HP printers. In these three cases, this is the only GUI toolkit used.

Re:First comment on referenced article (2)

Christopher Fritz (1550669) | more than 3 years ago | (#36303884)

Opera's actually removed its Qt dependency [opera.com] since 10.50:

Like Opera for Mac, the Unix version will have some big changes under the platform hood: it will no longer be necessary to have Qt installed.

It means [Qt] is totally removed and no longer required at all. Hence UNIX [Opera] required a bigger rewrite than the other platforms.

Re:First comment on referenced article (2)

Kjella (173770) | more than 3 years ago | (#36302406)

But things aren't going to go back to the way things were. Qt is LGPL'd, they'd have an extremely hard time going back to a dual GPL/commercial license which is what funded Qt before Nokia bought them. Is "the community" going to pick that up with just as many full time developers to replace them? And with my experience with Qt (excellent) vs KDE (very mixed), do you want KDE teams taking over? And isn't their developer resources spread pretty thin as it is?

Face it, Nokia is going tight with Microsoft. I don't see how they could possibly want hold on to Qt as a sideshow to that, it's going to get sold out somehow or die a slow death starved of resources and priority. That they're keeping all the wheels turning right now is to try to make an exit on their $153 million investment, if they flat out halted everything the value would quickly drop to near zero. I just can't see it in their long term strategy, one way or another they'll go different ways.

Re:First comment on referenced article (1)

jbolden (176878) | more than 3 years ago | (#36302776)

I guess it depends a great deal if your priority is other QT apps or KDE + KDE applications. I'm the latter. I love having a standard C++ widget kit that's really really good. But I think KDE is more important by a long measure. I think having QT become a component of KDE fully would be to open source's general advantage; while willing to acknowledge there are plusses and minuses.

Troll? (3, Informative)

Anonymous Coward | more than 3 years ago | (#36301684)

Sometimes I get the feeling that all you need to do in order get on Slashdots front page is to post an inflammatory article about open source.with no real basis.

Re:Troll? (1)

GameboyRMH (1153867) | more than 3 years ago | (#36303528)

It doesn't even need to be about open source, remember the "is science a matter of faith?" article?

Maybe the Slashdot editors are trying to get rid of the trolls by giving Slashdot a reputation as a target with no challenge.

...so? (2)

betterunixthanunix (980855) | more than 3 years ago | (#36301692)

We have some options here:
  1. Fork Qt, let the community maintain it.
  2. Ditch Qt, use any of the dozen other free/libre toolkits out there.

Re:...so? (5, Insightful)

MrHanky (141717) | more than 3 years ago | (#36301716)

3) Stop believing in crap opinion pieces by random know-nothings on the web.

Re:...so? (1)

zixxt (1547061) | more than 3 years ago | (#36302110)

3) Stop believing in crap opinion pieces by random know-nothings on the web.

Right on and so true.......

Re:...so? (1)

Tanktalus (794810) | more than 3 years ago | (#36302528)

What, and stop reading slahsdot?

Re:...so? (4, Insightful)

MrHanky (141717) | more than 3 years ago | (#36302610)

I said stop believing, not stop reading. If you stopped reading Slashdot, then how would you know whom to flame?

Re:...so? (1)

shutdown -p now (807394) | more than 3 years ago | (#36302374)

Ditch Qt, use any of the dozen other free/libre toolkits out there.

The problem with this option is that Qt is vastly superior to any other FOSS toolkit. In fact, I dare say that it's better than most UI toolkits, regardless of the license.

Re:...so? (0)

Spicerun (551375) | more than 3 years ago | (#36303666)

That's your opinion, not mine. Let me know when Qt finally starts conforming to the C++ standard instead of hiding where they don't want to conform to the C++ standard... via macros nobody else in the real C++ world uses. Let the rebuttals from upset Qt fans begin......

Re:...so? (1)

shutdown -p now (807394) | more than 3 years ago | (#36303694)

Qt finally starts conforming to the C++ standard instead of hiding where they don't want to conform to the C++ standard...

Can you give some examples?

Re:...so? (1)

Spicerun (551375) | more than 3 years ago | (#36303960)

This is my only reply to this topic: Anything the MOC (QT metacompiler) understands is a good example of something that doesn't conform to the C++ standard in my view. My point is not that you don't have to use the MOC, but that because it exists, a lot of developers do use it, causing them to not be following C++ standards (ie - not even recognizing that they are not using correct C++ syntax). I have seen myself a few Qt programmers that simply couldn't understand why their moc-based program would not build on embedded hardware that only had a C++ compiler....one of those was an MSVC++ compiler too. It is another subject entirely on how much MSVC++ follows the C++ standard.

Re:...so? (1)

shutdown -p now (807394) | more than 3 years ago | (#36303992)

This is my only reply to this topic: Anything the MOC (QT metacompiler) understands is a good example of something that doesn't conform to the C++ standard in my view

The only pertinent question at hand is whether the output of MOC conforms to the C++ standard. As far as tools go, it's not fundamentally different from any other code generator, such as e.g. re2c, or lex/yacc, or proxy/stub generators for various RPC stacks such as CORBA or ICE.

Another one of those cases... (5, Insightful)

hardaker (32597) | more than 3 years ago | (#36301720)

... where a reputable news source would have checked its sources for accuracy first. stagnated and stalled? Hmm... Just two weeks ago we had very different news [slashdot.org] .

In reality, even if Qt stopped dead in the water with no development from anyone, it'd still be one of the best documented GUI libraries out there. I've never been a fanboy of any particular software suite, but the more and more I've dove into Qt in the last year the more I'm truly impressed with the design and documentation of the toolkit. Somehow I don't think it's going away.

The future of everything is uncertain; thats life (1)

jeffmeden (135043) | more than 3 years ago | (#36301724)

They can spin Trolltech back out, if as a product it is worth the money. Or, all the fans/supporters can pick up the GPLed portions of QT and keep the ball rolling (if there is indeed a groundswell of community support). It's not like Nokia is holding the only copy of the QT source code, and is dangling it over a bottomless pit...

This happens to projects and products all the time. The article, for it's good intentions, makes it sound like no software ever died on the vine before. Yeah, right.

Re:The future of everything is uncertain; thats li (4, Informative)

ensignyu (417022) | more than 3 years ago | (#36301872)

Qt is actually LGPL now. Furthermore, if Nokia decides to stop developing Qt, the KDE Free Qt Foundation [kde.org] can vote to release Qt under a BSD license.

Wow, how can you be so far off the mark? (4, Informative)

t_hunger (449259) | more than 3 years ago | (#36301822)

Since the windows 7 announcement the following things happend in Qt land: The Qt SDK had mayor update, Qt Creator had a new release, Qt had some minor updates, the open governance program is in full swing, Qt 5 was announced with open planning, there is a Contributor Summit coming up to discuss all these changes with non-Nokia developers...

Yeap, Qt has all the hallmarks of a dead project!

Re:Wow, how can you be so far off the mark? (0)

Anonymous Coward | more than 3 years ago | (#36301904)

A zombie would fit both your and their descriptions. Dead and alive at the same time.

Re:Wow, how can you be so far off the mark? (0)

Anonymous Coward | more than 3 years ago | (#36302010)

Can a zombie code? if so, I can't see the problem....

Brains!!!!

Re:Wow, how can you be so far off the mark? (5, Informative)

suy (1908306) | more than 3 years ago | (#36302758)

Exactly, just a quick look at the dev blog [nokia.com] shows the following updates with respect to new features (some stable releases, some tech preview):

  • QML Scene Graph in master branch
  • Qt Webkit minor releas
  • Qt 4.8 tech preview
  • Updates on Qt Creator, and its integration on the SDK
  • Updates on the open governance
  • Qt Quick 3D
  • Qt Mobility 1.2
  • First plans for Qt 5

This is only during May. If anything, I see Qt more alive than ever.

There is also the misconception that only the Qt developers do interesting research and add features. That's very wrong. Lots of KDE ideas were implemented in Qt at one point or another. Also note that companies like Digia or ICS (and several others) are now way more involved in Qt than ever, and will be more once the open governance transition finishes.

Report of Qt's death... (1)

VortexCortex (1117377) | more than 3 years ago | (#36301874)

Report of Qt's death is greatly exaggerated.

Quicktime is dying? (5, Funny)

Anonymous Coward | more than 3 years ago | (#36301960)

ITS ABOUT DAMN TIME!

Man, Nokia is dying fast (0)

Anonymous Coward | more than 3 years ago | (#36301962)

They're losing market share hand over fist and their share price has fallen to almost half what it was when they announced their switch from Meego.

You Can Just Use It As It Is (2)

oldCoder (172195) | more than 3 years ago | (#36301974)

Regardless of what the Qt developers do, the toolkit is very good and available. You can just use it to build your software and let the rest of the world jump in a lake. The worst that can happen is that Qt development will be slow and steady.

An alternative to reliance on a single toolkit (5, Interesting)

byuu (1455609) | more than 3 years ago | (#36301992)

I hate to come across as advertising, but for those worried about the possibility of any specific API going away ...

I've found that most small to mid-sized GUI applications only really need the basics: windows, menus, buttons, check/radio boxes, list/tree views, sliders, scollbars, combo boxes, and something to render graphics (Direct3D/OpenGL/raw pixels) onto. It won't get you Photoshop or Quark Xpress, but that's enough for most CLI frontends, emulators, text/hex editors, office tools, etc.

I put all my eggs in the Qt basket and got burned by a lot of platform-specific bugs. So I took all the core features and wrote a unified wrapper around all of the major toolkit APIs: pure Win32, GTK+ and Qt. In this way, there are no 4-10MB run-time library dependencies, the code is much simpler, and I feel my applications are more portable: the wrapper is so small one could port it to eg Haiku, Cocoa, etc in roughly one weekend. I can also target any platform (Win32, Win64, Linux, OS X), and any toolkit available on each, with the exact same codebase. Eg both Gnome and KDE users gets 100% native apps.

Doesn't have a snazzy public name, but internally I call it phoenix, and it's available here [byuu.org] , if anyone is interested. There are, of course, obvious downsides: if you want a complex GUI, you would have to add the higher-order, platform-specific (floating docks, grid views, tab bars, sheets) controls yourself. And it also targets C++0x, which is great for lambda callbacks, but bad for portability at the moment.

Re:An alternative to reliance on a single toolkit (1)

byuu (1455609) | more than 3 years ago | (#36302216)

That said, I also feel the article is fear-mongering. Even if Nokia folds, and even if KDE doesn't utilize its agreement, the code is now LGPL'ed anyway. Such an important project will undoubtedly at least be maintained, if not extended upon, by others.

Re:An alternative to reliance on a single toolkit (3, Insightful)

shutdown -p now (807394) | more than 3 years ago | (#36302390)

So I took all the core features and wrote a unified wrapper around all of the major toolkit APIs: pure Win32, GTK+ and Qt.

It sounds like you reinvented wxWidgets?

Re:An alternative to reliance on a single toolkit (1)

byuu (1455609) | more than 3 years ago | (#36302502)

More of a wxWidgets Lite, but yes, same idea, just a different scale. wxMSW is 93MB of code, phoenix/Windows is 58KB of code.

You lose a lot of the great features (like HTML rendering) in return for the ability of one person to port the entire toolkit in two days. According to this page [filelab.com] , wxmsw28.dll is 10MB in size. phoenix compiles to 20KB. Again, not important if your app spans two DVDs. Kind of important if you have a 5GB/mo hosting bandwidth limit and your app is otherwise only 300KB or so in size.

Re:An alternative to reliance on a single toolkit (2)

shutdown -p now (807394) | more than 3 years ago | (#36302536)

But you don't have to dynamically link to wxWidgets - use static linking and full-program link-time optimization, so that any unused code gets discarded. I bet you could get at the same 300Kb figure in the end, so long as you use a similarly restricted feature set.

I see your point about being easy to port, but how often is this, realistically, a requirement for most typical projects? Win/X11/Mac is usually good enough.

Re:An alternative to reliance on a single toolkit (2)

byuu (1455609) | more than 3 years ago | (#36302718)

But you don't have to dynamically link to wxWidgets - use static linking and full-program link-time optimization, so that any unused code gets discarded. I bet you could get at the same 300Kb figure in the end, so long as you use a similarly restricted feature set.

It can get that small? My attempts at statically linking Qt with a six-line-long --no-bla configure line, -Os build flag and upx --ultra-best could only get my executables down to an added 4MB or so. I will admit, that's very respectable indeed.

To be honest, I kind of fell in love with the Qt API. Mine is basically Qt sans a few inconsistencies, with references instead of pointers, with less std:: reimplementations (but still a few), and with C++0x enhancements. I haven't used wx because it seemed rather MFC-ish, but if sizes get that small it sounds like a great choice for more complex apps.

but how often is this, realistically, a requirement for most typical projects?

Kind of depends. Eventually someone would port over anything, even to new targets like OS XI. Qt is on Haiku, GTK+ is on OS X, etc. Go too far in the future and the entire UI paradigm we use could be thrown out.

You could end up with an embedded project based on QNX or something where the Qt run-time size becomes a bigger issue. Or maybe you just want to be 100% in control and able to modify the toolkit directly yourself. The library is ISC licensed.

Who knows, I'm definitely not saying phoenix is for everyone. But I do feel it's as small, as easy to learn, and as portable as you can possibly get while still being useful.

Re:An alternative to reliance on a single toolkit (1)

shutdown -p now (807394) | more than 3 years ago | (#36302838)

It can get that small? My attempts at statically linking Qt with a six-line-long --no-bla configure line, -Os build flag and upx --ultra-best could only get my executables down to an added 4MB or so. I will admit, that's very respectable indeed.

Qt is a very different case because it handles all widgets itself - it uses the OS APIs to get theming information so that it can make them look native, but actual rendering and behavior is fully implemented by the framework. wxWidgets, like your framework, is a true wrapper around native widgets, and a relatively thin one at that.

That said, I didn't actually try, so I wouldn't quite stand by 300kb figure... just that it doesn't sound unlikely. I wrote commercial apps (in-house line-of-business) in wx a long time ago, back in 2000 or so, and I recall that the size of compiled binary was definitely in hundreds of kilobytes ballpark. I haven't tracked its development for several years now - now that you've piqued my curiosity, I might actually take another look, and check the size of binaries while I'm at it.

I haven't used wx because it seemed rather MFC-ish

Yes, there is that. It really is much more "traditionalist" compared to Qt, and drags a lot of its design from the dark ages of C++, when templates were finicky and optimizers very naive. The only bright side to it that I can think of is that it's relatively straightforward to port MFC applications to wx, thus making them cross-platform.

Re:An alternative to reliance on a single toolkit (1)

byuu (1455609) | more than 3 years ago | (#36303008)

Qt is a very different case because it handles all widgets itself - it uses the OS APIs to get theming information so that it can make them look native, but actual rendering and behavior is fully implemented by the framework.

Yeah, I tell people this and they keep insisting Qt is 100% native. I'm kind of an OCD perfectionist, and find it falls into the 'uncanny valley' of UI design. Alignments and positioning of QGtkStyle and the Windows versions are just ... off. Very easy to tell when you compile the same app with phoenix/GTK and phoenix/Qt and compare side by side.

I haven't tracked its development for several years now - now that you've piqued my curiosity, I might actually take another look, and check the size of binaries while I'm at it.

I don't mean to impose, but if you do this, could let me know your results? I'm at setsunakun0 from hotmail. No worries if you're busy, I should really do it myself. I'd like my pros vs cons page to be unbiased and could use the info.

Re:An alternative to reliance on a single toolkit (1)

shutdown -p now (807394) | more than 3 years ago | (#36303838)

I don't mean to impose, but if you do this, could let me know your results?

Well, I must admit that I'm rather disappointed by the figures that I see. This all was done using VS2010 SP1, and wxWidgets 2.9.1 (the most recent available), building release versions which link statically against wx, but dynamically against C++ runtime. I compiled a bunch of samples that came with wx itself.

I started with a basic console application (samples\console) that parses command line parameters and prints out some help text. This doesn't use any of the "meat" of the library - only string processing and some basic I/O (wxPrintf, wxFgets). The resulting executable was over 500kb! Okay, so 100kb (let's be generous) of that are iostreams, though God knows why it uses them - but where did the rest come from?

GUI apps are even worse. There's a simple MDI document/view demo (samples\docview), where you can open text or image files, and it renders them. It still uses a fairly small variety of widgets, yet it compiled down to 3Mb. Then there's a demo that showcases all widgets (some of which are not native) - that one is almost 4Mb!

I then set off to look at compiler flags. First of all, I enabled LTCG, which lets optimizer do some nifty tricks. That didn't really help all that much, getting the size down by ~100kb across the board. Then I've noticed that all code is compiled with "optimize for speed" (/O2), so I figured it might be seriously blowing up inline function expansion. So I changed it to "minimize size" (/O1) - that brought the console sample down to 380Kb, and docview to 2.2Mb. Still rather unimpressive.

I'm now wondering if I'm really just misremembering how things were back in 2000, or if that much bloat got in. Either way, it's a huge WTF to me, because back in the day Delphi VCL apps easily compiled down to 300-500Kb - and I'm not talking about a simple demo here, but full-size app - and VCL was much more extensive than wxWidgets is even today. And Delphi apps also had the core runtime library (startup code, basic functions such as strings & math etc) statically linked in as well!

Re:An alternative to reliance on a single toolkit (1)

The Snowman (116231) | more than 3 years ago | (#36303152)

One of the reasons I don't use wxWidgets is that, in 2011, it supports neither 64 bit nor Unicode. Does your toolkit? I didn't see this mentioned on the web page.

Re:An alternative to reliance on a single toolkit (2)

byuu (1455609) | more than 3 years ago | (#36303418)

Yes, it does both. All GUI strings are in UTF-8 on all platforms (*not* UTF-16/UCS-2 on Windows), and it also has block-buffered file (FILE*) / filemap (mmap/MapViewOfFile) / directory (opendir/FindFirstFile) / dynamic-link library access (dlsym/GetProcAddress) wrappers that take UTF-8 as well. There's also a handy callback to grab a UTF-8 argv[] list on Windows (I do not hijack main.) And lastly, I provide some RAII UTF-8 UTF-16 transformations for when you absolutely need that on Windows.

Windows 64-bit was the other major reason I wanted to move off of Qt. You can pull it off in Qt, but it takes some source hackery and is unofficial, last I checked anyway (4.6.x)

If you're interesting in audio-visual stuff, I have a library called ruby (I'm great with this naming thing, huh?) that wraps DirectDraw+Direct3D+OpenGL(wgl+glx)+GDI+SDL+X-Video, XAudio2+DirectSound+PulseAudio+PulseSimple+ALSA+OSS+OpenAL+libao, DirectInput+RawInput+XInput+SDL+Xlib cross-platform as well. Like SDL but with pixel shaders, hardware scaling, multi-mouse, etc.

Re:An alternative to reliance on a single toolkit (1)

Anonymous Coward | more than 3 years ago | (#36303626)

What are you talking about? We ship wxWidgets applications in both 32-bit and 64-bit builds, and in Unicode. And have for years now.

Re:An alternative to reliance on a single toolkit (0)

Anonymous Coward | more than 3 years ago | (#36303424)

Named Phoenix? Ouch.

(Kidding)

Re:An alternative to reliance on a single toolkit (0)

Anonymous Coward | more than 3 years ago | (#36303544)

So instead of using one of the well established, well tested, and full featured cross platform toolkits out there (Qt or WxWidgets being just two), you wrote your own extremely limited one that you will add hugely to your testing burden in perpetuity, be a disincentive for new developers, and accumulate cruft as feature after feature get hacked onto it.

Good work!

Re:An alternative to reliance on a single toolkit (0)

Anonymous Coward | more than 3 years ago | (#36303642)

So instead of reading my pros and cons page, or even reading the pros and cons listed in my post, you pointed out the downsides I've already listed and ignored all the benefits. Good work! :D

The other option (1, Interesting)

greg1104 (461138) | more than 3 years ago | (#36301994)

As opposed to GTK+, where the project is healthy, the toolkit project is changing rapidly, and GNOME's future is uncertain because there's a giant user backlash over the changes.

Re:The other option (1)

Anonymous Coward | more than 3 years ago | (#36302310)

users will always bitch about any and all changes.

Re:The other option (2)

jedidiah (1196) | more than 3 years ago | (#36303128)

No. Some changes cause more backlash than others.

Re:The other option (1)

tyrione (134248) | more than 3 years ago | (#36303300)

No. Some changes cause more backlash than others.

The entire KDE 4 switch was one giant cluster of pain. It's nearing 4.7 and it's still not as rock solid as the last 3.x branch.

Meanwhile..... (4, Informative)

diegocg (1680514) | more than 3 years ago | (#36302034)

...QT continues developing announcing cool features, like the QML scene graph [nokia.com] (post from today)

"the truth is that Qt is deprecated" (4, Insightful)

volkerdi (9854) | more than 3 years ago | (#36302068)

The only truth here is that the article was written by a completely ignorant asshat.

Reform Trolltech? (0)

Anonymous Coward | more than 3 years ago | (#36302078)

Reform Trolltech?

Nokia PR and Qt development are different (0)

Anonymous Coward | more than 3 years ago | (#36302126)

Some comments here claim Qt is not dying because Nokia made some announcement and the Qt blog is hyperactive.

But look at the facts:
-the IRC channel they used: #qt-labs, has almost no activity since February
-the brand new Qt Developer Network has been deserted by the trolls
-the blog posts on Qt labs are just about future project, never anything concrete for the current library
-the plans for Qt 5 announced recently are ridiculous, no troll was involved in those
-the development on qt.gitorious.org stalled since February

If there is not quickly a fork of Qt, we will discover in 2 years that Qt is outdated and there is no longer any professional GUI library for Linux.

Time for a GTK wrapper (1)

gr8_phk (621180) | more than 3 years ago | (#36302170)

If QT gets a wrapper so it can handle GTK apps, then its future would be more certain than ever. With the crap that is Gnome 3, I'd happily switch to KDE so long as all my apps work there. Of course you can install GTK along with KDE so they'll work, but not needing the whole of GTK would be nice. Or I suppose I can just find KDE apps, but what about GIMP and Inkscape on KDE?

Re:Time for a GTK wrapper (0)

Anonymous Coward | more than 3 years ago | (#36302220)

I use GIMP on Kubuntu without issue and always have since switching to KDE. I tried to make an app with GTK and then tried with Qt and switched to KDE the next day. There is NO REASON for anyone to put up with trying to learn GTK, though I'm sure it works fine if you already know it and don't need documentation or examples.

Re:Time for a GTK wrapper (1)

TD-Linux (1295697) | more than 3 years ago | (#36302556)

GTK as a library is big, but not horribly big. If you aren't too tight on disk space or RAM, using a theme available for both (i.e. Oxygen) works well enough for me.

Re:Time for a GTK wrapper (1)

jbolden (176878) | more than 3 years ago | (#36302840)

A wrapper is going to be not much different that GTK. Everything is open source its not worth the effort to re-implement GTK and keep it current, it ain't gonna happen.

Dear Submitter, (1)

BitHive (578094) | more than 3 years ago | (#36302326)

When you overuse commas, it has the effect, of making your writing, read as though it were being read, by William Shatner.

Re:Dear Submitter, (2)

GigaplexNZ (1233886) | more than 3 years ago | (#36302568)

That's a feature, not a bug.

My view of what's happening (1)

Anonymous Coward | more than 3 years ago | (#36302358)

Qt is THE best Cross Platform software development solution. It is mature and is going to new heights once again in Qt 5 to make it easier to develop software and deploy anywhere, Android devices included.

Nokia however may be currently a target of an attack on it's image to spread FUD on it's investors, see today market opening for nokia and this FUD right here on Slashdot.

There is one thing that established players fear, and that is concurrence, and when those people can't compete technologically go the legal/marketing(cheaters) way. See Apple teasing Samsung recently.
The deal with MSFT is obscure and against the nature of open source. The deal with digia to sell commercial QT licenses feels like disablement also.

GUIs? What? (0)

Anonymous Coward | more than 3 years ago | (#36302404)

The core stuff in Linux is hardly Qt. If there were ever any issue with the Apache Software Foundation, the GNU Compiler Collection or similar stuff then I would begin to worry. The reality is that Linux is mostly used for server stuff and in my case, I think the best setup is to have a Linux server with either Mac or Windows desktops. Sure, you can do an all Linux, all Mac or all Windows setup but in my opinion going fully with Mac or Windows is too expensive and fully with Linux a little incompatible when it comes to file formats (AutoCAD, some Office stuff) plus the training of clueless users.

It's not just about KDE (1)

shutdown -p now (807394) | more than 3 years ago | (#36302416)

There seems to be a lot of talk about whether KDE might (eventually) need to fork Qt, but this misses an important point - Qt is not just a "KDE widget toolkit". It's the best cross-platform UI (and many other things, actually) framework at the moment. If Nokia drops future development and KDE takes over, will they have desire and resources to maintain Windows and OS X ports? what about embedded?

It would be a damn shame to see Qt relegated to KDE backend, with future development being restricted to X11 version.

Re:It's not just about KDE (1)

bcmm (768152) | more than 3 years ago | (#36302540)

KDE apps are not just for use with the KDE workspace. There are many KDE project actively porting their applications to other environments, including MacOS and Windows.

Re:It's not just about KDE (1)

shutdown -p now (807394) | more than 3 years ago | (#36302572)

Yes, but right now they can do so because they have a huge chunk of that porting effort done for them for "free" by people who develop Qt. I'm not so sure if all those projects would have manpower to maintain - much less further develop - the Qt/Windows and Qt/Mac ports on their own; at least without detrimental effect on their own release schedules.

Nokia will continue free Qt Development.... (1)

mysidia (191772) | more than 3 years ago | (#36302996)

OR the community will [kde.org] , under the Foundation Trolltech assigned rights to so long ago, to address concerns of KDE developers, promote the continued development of KDE, and clear out doubts about Qt's future free status (vs. Gnome's):

The KDE project and Troll Tech AS, the creators of Qt, are pleased to announce the founding of the 'KDE Free Qt Foundation'. The purpose of this foundation is to guarantee the availability of Qt for free software development now and in the future. The foundation will control the rights to the Qt Free Edition and ensure that current and future releases of Qt will be available for free software development at all times.

All changes to the Qt Free Edition license will have to be approved by the KDE Free Qt Foundation which will consist of two members of Troll Tech AS as well as two members of the KDE project. One of the representatives of the KDE project will have a double vote to be used in case of a tie.

Should Troll Tech ever discontinue the Qt Free Edition for any reason including, but not limited to, a buy-out of Troll Tech, a merger or bankruptcy, the latest version of the Qt Free Edition will be released under the BSD license. Furthermore, should Troll Tech cease continued development of Qt, as assessed by a majority of the KDE Free Qt Foundation, and not release a new version at least every 12 months, the Foundation has the right to release the Qt Free Edition under the BSD License.

Cash in (1)

PopeRatzo (965947) | more than 3 years ago | (#36303288)

As soon as Nokia's stock price drops another 8 percent, I'm buying a bunch to hold.

As soon as the Nokia Windows phones start coming out, I'm going to be out of Nokia like a prom dress.

Dear Nokia.... (1)

Lumpy (12016) | more than 3 years ago | (#36303356)

Dont be Douches...

LGPL the whole thing. free it to the world completely. If you want to make a difference do this.

If you want to be jerks... kill it and keep it in a safe forever to rot away.

Because you either can gain great credit and renown, or become that company that squirreled away something you though had value, but was made value-less by the OSS version that will be created within moments of you doing the jerk move.

Re:Dear Nokia.... (1)

Repossessed (1117929) | more than 3 years ago | (#36303514)

They did that years ago. And it was GPLed before that. And there's an option to release it under other licenses if they drop it in their contracts with the KDE foundation (or somebody similar).

Qt is the furure of software development (2)

scorp1us (235526) | more than 3 years ago | (#36304236)

Here's why.
Qt5 will have the maturity needed to accomplish the following:
Whole client-side programs written in Javascript (QML) that use OpenCL/GL and web resources. (Better than Flash)
LGPL (Better than Flash)
Client and server apps (Better than Flash)
One platform for Web, Phone and desktop (same as AIR)

Qt went 4.8-rc-1 recently with all these features, but when Qt5 comes out it'll have the maturity it needs. SceneGraph went into mainline today.

Awesome is coming.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

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>