Slashdot Mirror


Free Software Faces a Test With Qt

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

132 of 177 comments (clear)

  1. In completely unrelated news by Anonymous Coward · · Score: 2, Informative

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

    1. Re:In completely unrelated news by Compaqt · · Score: 4, Insightful

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

      --
      I'm not a lawyer, but I play one on the Internet. Blog
    2. Re:In completely unrelated news by Anonymous Coward · · Score: 1

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

    3. Re:In completely unrelated news by catalina · · Score: 3, Funny

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

    4. Re:In completely unrelated news by wvmarle · · Score: 1

      On the upside there is increasing confidence they'll be able to ship at least one WP7 product before the end of the year.

      Now that is promising... we're just in June. Not even halfway the year. And "before the end of the year" they hope to have a single model on WP7. That's a complete generation away in the mobile phone world! And then aiming for just a single model? I thought Nokia got large in part because they had so many different models to choose from, low-end to high-end. Now it seems in the lower end they're still strong, Nokia phones are all over the place, and WP7 is high-end work.

      So they're going to be completely out of the high-end phone business for a full generation? That's not good for them.

      Also the announcement by Nokia to switch exclusively to WP7 is at least a few months old. That seems to me quite a long time to release a phone that can run this OS - but apparently they have none yet. And I can't imagine WP7 is that hardware-specific that they have to start from scratch. Mobile phones go the way the PC has gone: standardised hardware, generic software. Point in case: Android OS can run on an iPhone.

      This announcement of completely skipping a generation (and unless MS comes out with an upgrade to WP7 in the meantime having an outdated OS) sounds like either Nokia doesn't know how to properly put together a modern high-end phone (not likely - they're one of the biggest mobile phone makers in the world), or that WP7 is not ready for use (yet it's being installed on phones by other makers already).

      I may be negative but it doesn't sound like an "upside". For neither Nokia nor Microsoft. By the time Nokia comes out with their first WP7 phone, WP7 is already a year old - and that's really old. Apple and Google are by then a generation or two ahead with their offerings, and it doesn't look like the WP7 app ecosystem is taking off anywhere near as strong as the Android and iOS competitors.

      So this 14% drop in stock is what they deserve. Sorry Nokia, but this kind of announcements are very worrisome. You stand a chance if you manage to bring out a complete line of smartphones by the end of the year, AND if Microsoft in the meantime manages to catch up and release a new WP system that can compare to the then-current (not now-current) Android and iOS offerings. Good luck with that.

    5. Re:In completely unrelated news by AvitarX · · Score: 1

      I think there is is potential for WP7 integrated is Live.

      There's a lot of Xbox and Hotmail users, and I know the Google integration is what will keep me on Android unless something really unforeseen happens.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    6. Re:In completely unrelated news by gtall · · Score: 1

      It's clear you have never done development. How do you know how hard it will be to marry WP7 to one of Nokia's platform? The second worst thing Nokia could do is ship a WP7 phone with bugs. The worst thing they could do is ship a WP7 phone.

    7. Re:In completely unrelated news by somersault · · Score: 1

      If only Slashdot's supposedly nerdy user base were capable of understanding the anchor tag. Would be a great business idea, probably.

      FTFY

      --
      which is totally what she said
    8. Re:In completely unrelated news by somersault · · Score: 1

      I can already add my Hotmail account on my Android devices if I wanted, likewise I can use eBuddy for Live Messenger.

      Don't really see the point in Xbox integration with my phone either, what would I use that for? I can't think of anything that I'd actually find useful, unless it actually did something cool like let you stream movies/music from the Xbox network (and they also took the prices down - they're pretty ridiculous right now). I used to have a desktop Widget that showed the last 3 games I'd played on my PS3, but I removed it because it was just a waste of data and space.

      --
      which is totally what she said
    9. Re:In completely unrelated news by somersault · · Score: 1

      I don't know about you, but I don't care how old my phone's OS is, as long as it runs the apps I want and is designed from the ground up for touch integration. If you're always desperate for updates to your OS, that's an indicator that your OS sucks. I'm not saying updates aren't nice, but what has actually changed in this last year that WP7 needs to keep up with? Most of the changes in iOS and Android have been focused on making them work better for tablets.

      --
      which is totally what she said
    10. Re:In completely unrelated news by wvmarle · · Score: 1

      Well no I haven't done development.

      Yet I count on Nokia to not be stupid. By going for a certain piece of software (WP7) while you have a working alternative (Symbian) and a perfectly capable and very popular free alternative (Android) I would expect no less than that they can quickly release a phone with it.

      Many many handset makers opt for Android - and are capable of bringing phones to the market one after another. New makers stand up all the time - no way they can spend a year or longer on development of a model. That has to be done much faster, and apparently it CAN be done faster with Android and many off-the-shelf components that make up a phone.

      Is Nokia using some heavily customised, non-standard hardware platform, and are they opting for an OS that is not designed with that platform in mind? If so it's a wonder WP7 runs on it to begin with.

      Or is WP7 such a pos that it takes ages to make it work?

      If the answer on any of the above two questions is "yes" then Nokia is stupid. Yet I assume Nokia, which has always been one of the more trendy and technically advanced mobile phone makers, is not stupid. They must have a good reason to opt for WP7, and one of the reasons I can think of is that they want to distinguish themselves from the pack (very sensible) but then Android is also highly customisable and apparently far more mature than WP7 considering how seemingly easily it can be adapted to run on all those phones, tables, even dedicated GPS devices.

    11. Re:In completely unrelated news by danieltdp · · Score: 1

      upside-down

      --
      -- dnl
    12. Re:In completely unrelated news by npsimons · · Score: 1

      What fool would buy a Nokia smartphone after all the jerking around of customers and developers?

      I'm actually severely tempted to get another N900 as a backup. Seriously. It's that fucking good. The only reason I haven't is that, going by my previous rate of phone replacement, *something* as open as the N900, with much better hardware, will be out by the time I'm looking to replace my current one. Here's hopin'.

  2. er... by brennanw · · Score: 2

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

    --
    Eviscerati.Org: All Hail the Eviscerati
    1. Re:er... by jonbryce · · Score: 3, Informative

      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.

    2. Re:er... by MrHanky · · Score: 5, Informative

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

    3. Re:er... by Anonymous Coward · · Score: 3, Insightful

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

    4. Re:er... by CSMoran · · Score: 1

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

      --
      Every end has half a stick.
    5. Re:er... by mirix · · Score: 4, Insightful

      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.

      --
      Sent from my PDP-11
    6. Re:er... by jbolden · · Score: 1

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

    7. Re:er... by infolation · · Score: 1

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

      Autodesk Maya
      The Foundry's Nuke

    8. Re:er... by EsbenMoseHansen · · Score: 2

      No, you are just seeing the effect of the "fear of change". Qt development will be slower paced without those payed developers, but it will still happen. Especially given that Qt is probably the best GUI x-platform toolkit presently available, and the best available in the linux world, with GTK as the closest runner-up to the best of my knowledge. What I fear most is that the win32/64 and OSX paths suffers, given that so few OS-developers use and intimately know those platforms.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    9. Re:er... by butlerm · · Score: 1

      pedantic: "paid developers"

    10. Re:er... by EsbenMoseHansen · · Score: 1

      You are right, sorry. Too early in the morning for correct English from me, it seems.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    11. Re:er... by jonbryce · · Score: 1

      It is a strength of OSS. If it was a commercial project and Nokia abandoned it, we would be in a much worse position. That doesn't mean it is guaranteed to survive. Look for example at ReiserFS after Hans Reiser was jailed. I don't think QT will be anything like as bad as that as there are a lot more developers who have an interest in keeping it going and the ability to do so.

    12. Re:er... by gbjbaanb · · Score: 1

      isn't Google Earth written in Qt too?

    13. Re:er... by Kamiza+Ikioi · · Score: 1

      Absolutely correct. Unfortunately to many reporters, even tech reporters, lack of money means technology dies. With (L)GPL and similar licenses, it's lack of use that really kills a project. As long as something is used widely, someone will develop it, or at least keep it running as new hardware comes out. Money helps, certainly, but it is not everything. For instance, Torvalds certainly is no billionare who pays others to make all of his software. Though, that is another option for creating software.

      --
      I8-D
    14. Re:er... by SQLz · · Score: 1

      Also The Foundry's Katana (new awesome product). Qt, specifically PyQt/PySide are huge in VFX industry. I don't know of a large VFX house that is not using PyQt at all levels of the pipeline.

    15. Re:er... by lucian1900 · · Score: 1

      When it comes to the quality of the GUI bits, it's not at all. Things such as ease of binding is where Gtk may win.

  3. No by Anonymous Coward · · Score: 2, Informative

    It hasn't.

  4. First comment on referenced article by Anonymous Coward · · Score: 5, Informative

    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.

    1. Re:First comment on referenced article by eldepeche · · Score: 2

      blah blah windows 98 blah blue screen blah

    2. Re:First comment on referenced article by knotprawn · · Score: 1

      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.

    3. Re:First comment on referenced article by knotprawn · · Score: 1

      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.

    4. Re:First comment on referenced article by ThePhilips · · Score: 2

      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.

      --
      All hope abandon ye who enter here.
    5. Re:First comment on referenced article by Anonymous Coward · · Score: 3, Interesting

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

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

    6. Re:First comment on referenced article by Kjella · · Score: 2

      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.

      --
      Live today, because you never know what tomorrow brings
    7. Re:First comment on referenced article by jbolden · · Score: 1

      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.

    8. Re:First comment on referenced article by pantherace · · Score: 1

      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.

    9. Re:First comment on referenced article by Christopher+Fritz · · Score: 2

      Opera's actually removed its Qt dependency 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.

    10. Re:First comment on referenced article by Locutus · · Score: 1

      but the catch is that MS-Nokia only needs to show some progress and I'm sure that's a very ambiguous clause so therefore it can effectively stall and there's nothing any one can do about it. Get this, Qt is a threat to Microsoft because not only is it NOT a Windows only development kit it's got it's own complete SDK across other platforms. Microsoft has always been hell bent on doing everything to make sure developers are tied to the Windows platform and Qt is 180 out from that business method.

      And just look at all the competitors to Microsoft on the list of Qt based products. And what was the first thing we heard from the Qt people once MS signed up with Nokia? There'll be a new version of Qt, Qt v5, and it will not be binary compatible with the v4.x branch. Really people, this is supposed to show continuity? To me it shows just the opposite, it covers the clause to prevent losing control of the Qt license and also will cause problems due to incompatibility with exiting software. If Microsoft were not involved, I'd be more likely to let them start showing the foot dragging but that is not the case. And remember, Nokia spun off the part of Qt which took in profits from SDK sales so where's the motive to keep Qt going? What they are doing is keeping the license from leaving Nokia and keeping Qt from thriving in the open market. IMO

      LoB

      --
      "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
    11. Re:First comment on referenced article by gbjbaanb · · Score: 1

      1. no need to do a different licence. RedHat and Canonical make enough money with the current 'free as in beer' licences.

      2. The small apps model is the best anyway, because they are easily maintainable. You argue against yourself here as this approach is exactly what the big commercial apps need anyway! And besides, little apps is what lives on mobile phones so expect to see much more of them in the near future.

    12. Re:First comment on referenced article by hairyfeet · · Score: 1

      The little apps model is great for admins and CS grads and abolsute shite on a shingle for everyone else! Can you imagine if people were given a choice of MS Word, or having to use some kludge between LaTex and a small image app and a spellcheck and a half a dozen other tiny programs and pipe the data, that it would get ANY traction at all?

      And just because mobile is small does NOT mean you have tiny snippets or relatively simple code,. which is what the pipe system uses. I just read a really great anecdote by one of the original developers of iDVD on OSX. he said they had come up with all these mockups, with different layouts, and Steve just walked in and completely ignored everything they had done and walked up to a white-board and drew a box. he said 'This is what I want. you have a box. you drop a movie in it, you have a button that says burn and that's it" and walked out.

      Now do you have ANY idea how much work it takes to make an app with THAT level of user simplicity and intuitiveness? Where it does ALL the complex work FOR you and the user has a simple easy to understand GUI? Hell my 68 year old dad got impatient and installed Windows 7 all by himself which I figured would be a mess. Was anything, anything at all, screwed up? Nope because the most complex question it asked was whether he was at home or work and everything from downloading and configuring drivers to patches and updates were all done FOR him. It even pointed out he didn't have an AV at first boot and pointed him to a page with several free and pay choices!

      Linux guys just refuse to face the facts that it is THAT which you are competing against. Look at Windows 7 and OSX and see how much of the work is all done behind the scenes, everything is intuitive, all is simple. Now THAT level of intuitiveness takes serious R&D, it takes a mountain of QA and focus groups, it takes a hell of a lot of work in shine and polish.

      You mention RH but did you know that fully 1/3rd of the webservers out there are running CentOS, a ripoff designed by a company that used to buy RH for their appliances but where too cheap to pay the licenses? Or that last I checked Canonical had yet to make a single profitable quarter, much less pay back the money Shuttleworth invested? You simply can't compete with MSFT and Apple with half ass homebrew, you just can't. And before you mention Android I'd point out that is Google's show, they are investing serious $$$ in it, and I predict the carriers and Google will lock it down ala TiVo by Xmas.

      So I still say if you want a world class OS, one that can proudly be shown besides OSX and Win 7 and have positive comparison, then serious, and I do mean SERIOUS, amounts of money is gonna have to be spent on R&D, QA, bug fixing, and general polish. And the fact that even the top Linux houses like RH make peanuts compared to apple and MSFT just shows why "free as in beer" ultimately hurts the community. If all those webservers running CentOS had to pay just $25 to RH the amount of progress made would be amazing, as RH has always (and I find this true for most FOSS groups) invested the bulk of their profits back into the project. But the competition isn't resting, both MSFT and Apple are spending insane amounts on polish and R&D. If Linux can't come up with the funds in 5 years i could easily see it getting stuck farther behind with each passing quarter. progress costs, and ideals don't feed developers. Sorry.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    13. Re:First comment on referenced article by gbjbaanb · · Score: 1

      I understand that some great video processing apps are actually a bundle of little apps all stuck together under a fancy GUI.

      I know a lot of 'big apps' are also a lot of little apps stuck together under the covers too - though they are sometimes called plugins rather than apps, sometimes they are external exes and sometimes dlls.

      I know a lot of huge applications are actually a lot of modules stuck together too. Some dlls, some exes again.

      Best practice software engineering is about dividing your problem space up into manageable chunks. This was the driving force of modular, structured programming, object-orientation, componentization and now service-oriented-architecture.

      Obviously you don't.

      However, I know you think that CentOS is a 'ripoff'. Strange that people say that about RedHat - after all, they took the very free beer Linux kernel, and all the free beer GNU userspace apps and all the other free beer apps written for Linux, wrapped them all up, added some artwork and started selling it as if it was theirs all along! Nobody really minds that much as they contribute back to the Linux community, but then no-one should complain when CentOS takes the free beer Linux system, and releases it without the proprietary bits RedHat added. In many respects, CentOS acts as a introduction to RedHat for many people - I used to run CentOS for my linux servers, and now I sold rather a lot of RedHat licences to the government. Everyone turns out to be happy, assuming they leave the vitriolic bile you spout alone.

      I'm not sure that making more money than the GDP of a small country counts as beneficial to society as a whole, Microsoft certainly hasn't made Windows 1000x better than Ubuntu, say, despite having thousands of times more profit then them. I'm Shuttleworth doesn't much care that he made so much money in the tech boom that he can afford to give some of it away to Canonical. See, some people aren't driven by a mindless urge to make more money even when they have more than they could ever spend. Maybe Microsoft's shareholders can tell you how that feels.

      Microsoft spends vast sums of money on R&D (and doesn't really get much for it, not if they had to spend another $8.5bn for Skype when their R&D dept could surely have built one to go with the VoIP clients they already have) and polish, though when I go to Display properties in W7, I can't seem to get Explorer's background to change colour. Maybe they need to spend even more money polishing!

      What you will find though is the Linux apps tend to be pretty damn solid in comparison to the Windows ones, but they don't tend to be pretty. Server side, admin type apps where a pretty GUI doesn't really matter if you have a text file to configure it. Windows tends to be very pretty (most of the time) but flaky. I guess that's an aspect of what you're getting - if you focus on pretty GUI, you will not spend as much effort on the back end, and vice-versa. I also guess that's why the majority of all the web, internet, email and embedded runs on Linux. you just don't get to hear how many because there's no single company like Microsoft to release sales figures for it.

      Incidentally, I installed CentOS on a server the other day (needed a new file server). It asked me where I was and what keyboard I was using and then chunked away until it was done. It didn't even bother to download drivers as they were bundled and patching was a simple 'yum update' run afterwards (I like to do that myself, good practice when faced with patch tuesday on a dozen Windows servers that cannot be broken by an update, well - not again)

      Anyway, rant away, it doesn't matter. The future is mobile apps, even Microsoft thinks that which is why they are spending such bogglingly large sums on Windows Phone.

  5. Troll? by Anonymous Coward · · Score: 3, Informative

    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.

    1. Re:Troll? by GameboyRMH · · Score: 1

      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.

      --
      "When information is power, privacy is freedom" - Jah-Wren Ryel
  6. ...so? by betterunixthanunix · · Score: 2
    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.
    --
    Palm trees and 8
    1. Re:...so? by MrHanky · · Score: 5, Insightful

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

    2. Re:...so? by zixxt · · Score: 1

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

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

      --
      ---- GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
    3. Re:...so? by shutdown+-p+now · · Score: 1

      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.

    4. Re:...so? by Tanktalus · · Score: 1

      What, and stop reading slahsdot?

    5. Re:...so? by MrHanky · · Score: 4, Insightful

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

    6. Re:...so? by shutdown+-p+now · · Score: 1

      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?

    7. Re:...so? by Spicerun · · Score: 1

      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.

    8. Re:...so? by shutdown+-p+now · · Score: 1

      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.

  7. Another one of those cases... by hardaker · · Score: 5, Insightful

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

    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 next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
  8. The future of everything is uncertain; thats life by jeffmeden · · Score: 1

    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.

  9. That's not a huge problem... by brennanw · · Score: 2

    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.

    --
    Eviscerati.Org: All Hail the Eviscerati
    1. Re:That's not a huge problem... by Anonymous Coward · · Score: 1

      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.

  10. Wow, how can you be so far off the mark? by t_hunger · · Score: 4, Informative

    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!

    --
    Regards, Tobias
    1. Re:Wow, how can you be so far off the mark? by suy · · Score: 5, Informative

      Exactly, just a quick look at the dev blog 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.

  11. Re:The future of everything is uncertain; thats li by ensignyu · · Score: 4, Informative

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

  12. Report of Qt's death... by VortexCortex · · Score: 1

    Report of Qt's death is greatly exaggerated.

  13. Quicktime is dying? by Anonymous Coward · · Score: 5, Funny

    ITS ABOUT DAMN TIME!

  14. You Can Just Use It As It Is by oldCoder · · Score: 2

    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.

    --

    I18N == Intergalacticization
  15. An alternative to reliance on a single toolkit by byuu · · Score: 5, Interesting

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

    1. Re:An alternative to reliance on a single toolkit by byuu · · Score: 1

      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.

    2. Re:An alternative to reliance on a single toolkit by shutdown+-p+now · · Score: 3, Insightful

      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?

    3. Re:An alternative to reliance on a single toolkit by byuu · · Score: 1

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

    4. Re:An alternative to reliance on a single toolkit by shutdown+-p+now · · Score: 2

      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.

    5. Re:An alternative to reliance on a single toolkit by byuu · · Score: 2

      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.

    6. Re:An alternative to reliance on a single toolkit by shutdown+-p+now · · Score: 1

      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.

    7. Re:An alternative to reliance on a single toolkit by byuu · · Score: 1

      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.

    8. Re:An alternative to reliance on a single toolkit by The+Snowman · · Score: 1

      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.

      --
      24 beers in a case, 24 hours in a day. Coincidence? I think not!
    9. Re:An alternative to reliance on a single toolkit by byuu · · Score: 2

      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.

    10. Re:An alternative to reliance on a single toolkit by Anonymous Coward · · Score: 1

      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.

    11. Re:An alternative to reliance on a single toolkit by shutdown+-p+now · · Score: 1

      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!

    12. Re:An alternative to reliance on a single toolkit by byuu · · Score: 1

      Thank you kindly for testing that for me. The numbers are at least twice as good as Qt, and GTK+ is DLL city. And yeah, ten years will do that to a project. I have noticed the run-time sizes going up with each new release of Qt. Also agree with you on sizes in general. Super Mario World was a 512KB game, and applications used to come on floppy disks. We've really lost our way when it comes to size and speed optimizations in programs.

      I know it's not a big deal for most people, especially with Google Code hosting. But for one example, I had a binary differencing patcher. In the game translation scene, most people like to include a patcher with their patch files. But when the patcher is bigger than the entire game itself ... they tend to scoff and stick with the older DOS-based 40KB IPS patchers. And then you get a site like smwcentral that hosts thousands of patches, and having a patcher with each archive becomes impossible. Make them download a second file, and the less intelligent get confused. So there really are use cases where binary size matters.

    13. Re:An alternative to reliance on a single toolkit by phantomfive · · Score: 1

      Lots of people have actually done this at a personal level. It's fun to do, and gives you more control over what happens. Its not like wxWidgets is particularly beautiful, so why not if you have the time?

      --
      "First they came for the slanderers and i said nothing."
    14. Re:An alternative to reliance on a single toolkit by shutdown+-p+now · · Score: 1

      Oh yes, I know how "just for fun" works in this case. I wrote my own UI toolkit ages ago as well, though that was actually for (and in) my own programming language.

      Anyway, if you follow the thread where the original poster replied, he actually has a rational argument aside from just having fun - his wrapper is thin enough that the output is much less bloated than even wxWidgets.

    15. Re:An alternative to reliance on a single toolkit by phantomfive · · Score: 1

      I've used wxWidgets before, and it's ok, but awkward. It's based on MFC, which is archaic and difficult.

      I am interested though, what was your own language like?

      --
      "First they came for the slanderers and i said nothing."
    16. Re:An alternative to reliance on a single toolkit by shutdown+-p+now · · Score: 1

      I actually remembered one other UI toolkit that, while little known, is also very frugal. Like wxWidgets, it also wraps native widgets, though it seems to do a far better job at it (see below - I figured I'd check it out as well). It also has a distinction of being the only portable ANSI C toolkit wrapping native widgets that I know of.

      The toolkit in question is IUP. Note that, even though they talk about Lua a lot, and it is designed to be used rather conveniently in conjunction with Lua, the library itself is pure C.

      Now for the test, I took their precompiled libraries (which, by the way, means no LTCG, and I'm pretty sure it's optimize-for-speed rather than optimize-for-size), and their MDI sample. That one is actually more featureful than the one I used from wx, because it also showcases some of their widgets in MDI child windows (screenshot). And yet, the binary is a mere 360Kb - now we're talking!

      Too bad they only wrap Win32, Gtk+ and Motif, and not Cocoa.

    17. Re:An alternative to reliance on a single toolkit by shutdown+-p+now · · Score: 1

      I've used wxWidgets before, and it's ok, but awkward. It's based on MFC, which is archaic and difficult.

      It's not really based on MFC - it's a clean source base - but its design is definitely ... MFCish ... mostly due to the use of macro-driven message dispatch maps.

      I am interested though, what was your own language like

      A concise description would be "BASIC with classes".

      There used to be a project called Rapid-Q which was basically that - it was a bytecode interpreter written in Delphi that, effectively, exposed large parts of VCL to its interpreted code. It also attached the bytecode to the interpreter binary, so you ended up with fairly small (~300kb) programs, and it was pretty slick for writing small one-off utility programs, prototyping etc. But then its author got hired to work on RealBASIC, and his project was bought out (it was never FOSS). A few fans set off to write their own replacements, mine being one of them. Ah, those were the days :)

      It's kinda scary, but my original website for that thing is still around. I've lost the password to it long ago, and all emails etc there are long gone, as well. Even more scary is that someone else picked up the code (compiler was under GPL, libs under BSDL), and there is still a project on Sourceforge with some activity - ten years after.

      Well, it sure did teach me a lot about writing parsers.

    18. Re:An alternative to reliance on a single toolkit by karbonforms · · Score: 1

      You should check out JUCE: http://www.rawmaterialsoftware.com/juce.php a very good cross-platform library. high quality C++.

    19. Re:An alternative to reliance on a single toolkit by Lord+Crc · · Score: 1

      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)

      That has been fixed for some time now, no special settings needed. IIRC for 4.6.2 all I had to do was copy a file to and edit it slightly to make the qt build system recognize Visual Studio 2008.

    20. Re:An alternative to reliance on a single toolkit by mooterSkooter · · Score: 1

      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?

      It sounds like you reinvented zsnes?

      Only joshing, I intend to try bsnes at some point (on my arcade cab)

    21. Re:An alternative to reliance on a single toolkit by master_p · · Score: 1

      You nailed it with callbacks that allow using lambdas, but you failed at memory management (Phoenix expects to delete everything on exit) and on containers (why do you define your own?).

    22. Re:An alternative to reliance on a single toolkit by byuu · · Score: 1

      The library is still in progress re: memory management. Right now the idea is that the UI elements won't eat all that much memory, so why waste time with allocation/deallocation? You can of course use pointers anyway, and delete them whenever, but at the moment it'll be your responsibility to ensure they were no longer in use or bad things will happen. I'll add destructors that remove widgets from containers and such in a future release.

      I use my own string class because std::string is garbage. No token replace (eg replace all 'cat' with 'dog'), no tokenize string (split, explode on key), unsafe find/strpos return value on non-matches (boost::optional works much better and throws exceptions when abused), no char transform (PHP strtr), no case-insensitive find, no support for parsing quoted strings (think split on = in a config file, quoted parameter may have = that we want to ignore; or think any kind of scripting/assembly syntax's strings), no math parsing (tell me what "3+2*7+4" equals), has to create a new object to be compatible with the native char* type of the language (c_str()), formatting with ios is torture, and building streams is a pain (no return { "My name is ", name, ", and I am ", age, " years old.\n" }; or openFIle({ baseFileName, ".txt" });) - it prefers the nonsensical operator left-shift over using traits to allow the more natural +, on and on. I could write a book on this class alone.

      I have my own function class because std::function sucks at binding to member function pointers. You have to mix memfn/bind1st in odd ways, and when you get above one parameter I can't even figure out how to use it anymore. With mine: onClose = &globalFuncOrMemberStaticFunc; onClose = { &Class::MemberFunc, &classObject }; onClose = [this]() { closure(); }; can also attach to boost::bind for argument shuffling.

      My version of optional is so you don't need boost to use it, and is four lines long. And that's it. The only thing you are ever exposed to is my string class on some return values, which is castable to and convertible from const char*, so pretend it's that and use with std::string if you like.

    23. Re:An alternative to reliance on a single toolkit by phantomfive · · Score: 1

      Nice! The website doesn't look bad for 2000, either. Feels pretty good to have someone else pick up a project you started.

      --
      "First they came for the slanderers and i said nothing."
    24. Re:An alternative to reliance on a single toolkit by master_p · · Score: 1

      > Right now the idea is that the UI elements won't eat all that much memory, so why waste time with allocation/deallocation?

      The applications I make (defense applications) are required to run for weeks uninterrupted, whereas the user opens and closes windows like there is no tomorrow. Increasing the memory footprint because some widgets are not deleted is not the appropriate solution for me.

      > You can of course use pointers anyway, and delete them whenever, but at the moment it'll be your responsibility to ensure they were no longer in use or bad things will happen.

      Why do you bother at all with memory management, since shared and weak ptrs are part of C++0x? you use all the nice features of c++0x like lambdas. Why not smart pointers?

      Smart pointers are extremely necessary if one wants to write a decent model/view library, into which the view goes away automatically when the model goes away too.

      > I use my own string class because std::string is garbage.

      You can always use STL to provide a library with missing functionality in an std::basic_string subclass. There is no need for a totally new string class.

      > I have my own function class because std::function sucks at binding to member function pointers.

      No, it does not. This is very simple:

      bind(&Class::Member, object)

      > My version of optional

      And it is totally incompatible with the rest of the world.

      > is so you don't need boost to use it

      C++0x contains the boost functions and boost bind, so no need for boost.

      Sorry. For all the effort you put into this library, for me it is a big NO if it does not use standard components, even if they are not the best there can be. There are many reasons why using absolutely standard components is very critical.

  16. The other option by greg1104 · · Score: 1, Interesting

    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.

    1. Re:The other option by Anonymous Coward · · Score: 1

      users will always bitch about any and all changes.

    2. Re:The other option by jedidiah · · Score: 2

      No. Some changes cause more backlash than others.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    3. Re:The other option by tyrione · · Score: 1

      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.

    4. Re:The other option by marcosdumay · · Score: 1

      To be fair, the 3.x branch had quate a big time to reach such stability. I still don't use KDE 4 at my desktops, because they break nfs server I'm using, and I'm not liking it at my laptop because it keeps accessing the disk and battery life goes away. The problem at the desktops is probably a bug at the server, and at the laptop is probably some configuration setting that I don't know about. Except for those, it seems quite stable.

  17. Meanwhile..... by diegocg · · Score: 4, Informative

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

  18. "the truth is that Qt is deprecated" by volkerdi · · Score: 4, Insightful

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

    1. Re:"the truth is that Qt is deprecated" by luther349 · · Score: 1

      man why does slashdot allow a trool article on there mainpage. heck qt5 is on its way. and due to unity and gnome 3 kde lxde xfce etc have all gotten alot more users now.

    2. Re:"the truth is that Qt is deprecated" by Stormtrooper42 · · Score: 1

      Indeed.
      At least, it should have said that Qt is deprecated for mobile development.
      But Qt started as a desktop toolkit, and it's still very good at it.

  19. Time for a GTK wrapper by gr8_phk · · Score: 1

    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?

    1. Re:Time for a GTK wrapper by TD-Linux · · Score: 1

      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.

    2. Re:Time for a GTK wrapper by jbolden · · Score: 1

      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.

    3. Re:Time for a GTK wrapper by bahstid · · Score: 1

      Don't know if I'm missing your question here, but Inkscape and GIMP are fine on KDE - until you mentioned it, I've never actually thought of them as being anything different (or maybe never having been a gnome user than for more than a few hours, didn't notice their gnomishness). Have never bothered to check how much overhead they pull along with them...

  20. Dear Submitter, by BitHive · · Score: 1

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

    1. Re:Dear Submitter, by GigaplexNZ · · Score: 2

      That's a feature, not a bug.

  21. My view of what's happening by Anonymous Coward · · Score: 1

    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.

  22. It's not just about KDE by shutdown+-p+now · · Score: 1

    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.

    1. Re:It's not just about KDE by bcmm · · Score: 1

      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.

      --
      # cat /dev/mem | strings | grep -i llama
      Damn, my RAM is full of llamas.
    2. Re:It's not just about KDE by shutdown+-p+now · · Score: 1

      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.

  23. DOES ANY ONE HERE REMEMBER? by Jeremiah+Cornelius · · Score: 1

    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.

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
    1. Re:DOES ANY ONE HERE REMEMBER? by walshy007 · · Score: 2

      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.

    2. Re:DOES ANY ONE HERE REMEMBER? by AvitarX · · Score: 1

      I think it actually switched to LGPL a few years ago, making it equivalent to GTK in that regard.

      The GPL version still required closed source apps to pay for a commercial license, and precluded non GPL compatible open source licenses from being written.

      I don't think it was truly an equal option for a library until '09.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    3. Re:DOES ANY ONE HERE REMEMBER? by dbIII · · Score: 1

      Sorry to say this - but fuck you and the other idiots that never bothered to read the various versions of the Qt licences over the years and are still not happy that it is GPL. It was a storm in a teacup "no licence but mine" argument where one side didn't bother to even communicate with the other with anything other than insults even AFTER a switch to the GPL.
      The entire issue exposed a sickening lack of maturity upon the part of Miguel and others that have since left gnome to people that can actually write code.

    4. Re:DOES ANY ONE HERE REMEMBER? by walshy007 · · Score: 1

      While true, from a free and open source software's perspective it was irrelevant. Which was the original case in point, since they now offer lgpl too it can be argued that now they are an even more flexible option.

  24. Nokia will continue free Qt Development.... by mysidia · · Score: 1

    OR the community will, 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.

  25. Cash in by PopeRatzo · · Score: 1

    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.

    --
    You are welcome on my lawn.
    1. Re:Cash in by wvmarle · · Score: 1

      WP7 when it was released it was already behind iOS and even Android.

      WP7 was released in November 2010, with a major update expected late 2011. When it was released it was considered by reviewers to be on par with older generations of iOS and Android, not even the then-current Android 2.2 and iOS 4.1. Since then I can find only minor updates, mostly bugfixes and security fixes.

      A month later Android released 2.3, since then it has released 3.0 and expects another major version before the end of this year.

      Apple has since released various updates with many new functions, and is at iOS 4.3.3 with iOS 5.0 due this month.

      MS is falling more and more behind with WP7. Unless a miracle happens for WP8 (but then: where's the marketing hype?) they'll only fall behind more, and Nokia is falling with it.

    2. Re:Cash in by PopeRatzo · · Score: 1

      MS is falling more and more behind with WP7. Unless a miracle happens for WP8 (but then: where's the marketing hype?) they'll only fall behind more, and Nokia is falling with it.

      Of course you're right. That doesn't mean there isn't an opportunity for a little short term profit by a careful (?) investor.

      --
      You are welcome on my lawn.
  26. Dear Nokia.... by Lumpy · · Score: 1

    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.

    --
    Do not look at laser with remaining good eye.
    1. Re:Dear Nokia.... by Repossessed · · Score: 1

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

      --
      Liberte, Egalite, Fraternite (TM)
  27. Qt is the furure of software development by scorp1us · · Score: 2

    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.

    --
    Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
    1. Re:Qt is the furure of software development by scorp1us · · Score: 1

      No, LGPL only requires you publish changes to the library itself.
      GPL and LGPL in no way prevent you from commercial sales or distribution. They do require you to distribute your source code changes - for LGPL changes to the library, and for GPL, your whole app. neither prohibits selling.

      Your app store may have its own restrictions though.

      --
      Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
  28. Re:The future of everything is uncertain; thats li by Vasheron · · Score: 1

    Thank goodness. That is exceptionally good forward thinking on the part of the founders. I almost hope Nokia goes dumps Qt.

  29. You didn't describe it accurately by fnj · · Score: 1

    I'll fix it for you:

    "As opposed to GTK+, where the project is healthy, the toolkit project is changing rapidly, and GNOME's future is uncertain because the Gnome developers lost their goddam minds and shat out a turd called Gnome3."

    1. Re:You didn't describe it accurately by greg1104 · · Score: 1

      That's not the whole story. Don't forget that Ubuntu has shat out a turd called Ubiquity, too.

      With GNOME 3.0, Ubiquity, and the uncertainty around QT/KDE, I haven't been this scared for my Linux desktop in years.

    2. Re:You didn't describe it accurately by joesteeve · · Score: 1

      That's not the whole story. Don't forget that Ubuntu has shat out a turd called Ubiquity, too.

      With GNOME 3.0, Ubiquity, and the uncertainty around QT/KDE, I haven't been this scared for my Linux desktop in years.

      But, why is every one so scared of change? ;)

    3. Re:You didn't describe it accurately by fnj · · Score: 1

      Yes; the despicable horror that is Unity was the only reason I even gave one hour to checking out Gnome3 (much against my better judgement). No more than that. That's an hour of my life I will never get back.

      I am disturbed about some trends recently in the linux kernel itself, but as much as the wanton destruction of the perfectly good Gnome2 desktop angers me, I don't really despair for the linux desktop. Xfce only requires a bit more polish to be a good alternative, and there is LXDE if you don't demand much fanciness at all. But for the time being I'm going with KDE.

    4. Re:You didn't describe it accurately by marcosdumay · · Score: 1

      I really think that the Linux Desktop* was needing some bold changes for a lot of time. Maybe that last crop of bold dumb changes may lead to more and more changes until we get something good at random.

      That said, except for very few problems, I'm quite ok with KDE4.

      * Well, I think the entire desktop idea is ready to change now that computers have so much free resources, but it won't come from any player that is focused on revenue.

  30. Re:Nokia PR and Qt development are different by Locutus · · Score: 1

    so MS-Nokia would lose the Qt license if they didn't update the project so they look like they are covering that and nothing more. Sure sounds like what would be in Microsoft's best interest and given Nokia is run by a former Microsoft executive who immediately handed Nokia to Microsoft this sound like Microsoft.

    People just don't get how vicious the company is and what they'll do to stop a competitor.Qt should be forked or the poison pill dropped so the license can be taken from MS-Nokia ASAP.

    LoB

    --
    "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
  31. Re:Nokia PR and Qt development are different by oiron · · Score: 3, Informative

    Thanks for the tasty FUD!

    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

    Looks like there's quite a bit of activity from just the last week

    -the brand new Qt Developer Network has been deserted by the trolls

    It'd be great if things were deserted by the trolls, I guess... Anyway, it doesn't seem deserted by the users

    -the blog posts on Qt labs are just about future project, never anything concrete for the current library

    Of the five posts on the front page, two are about merges of experimental features (the QML scenegraph and Lighthouse), two about conferences and summits, and one's about the release of QtWebkit 2.1.1. Not current enough for you?

    -the plans for Qt 5 announced recently are ridiculous, no troll was involved in those

    I'm not even going to reply to that one!

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

    Latest commit is dated Jun 1 2011

    Now, WTF are you talking about again?

  32. Re: "Hopelessly retarded"? by afex · · Score: 1

    while i agree that insulting people is generally not a good way to get your point across, what he's saying is that the landline is just about dead - I doubt anyone that moved out of their parent's house after around 2003 or so got one - why would you? When all the boomers (like my parents, and many other's parents) die out, the land lines will die with them.

    don't get me wrong, this is not about me (or anyone else) WANTING the land line to die, and I completely understand why people keep them (everyone has your number, etc) - but for those of us that never got a chance to buy one (i grad'ed college in '05 and already had a cell when i moved to an apt), there's just no reason to ever get one.

  33. Graham Morrison...ah, that explains it. by Dr.Dubious+DDQ · · Score: 1

    Isn't the author here one of the hardcore "WE HATE KDE!"/"Choice is confusing!"/"Why can't Linux just be a version of Mac OSX that we don't have to pay for?" people on the "TuxRadar" podcast?

    That would explain the apparent overexcitement about the imagined doom of Qt. Premature Schadenfreud.

    (Try thinking about baseball next time, ...uh, or cricket, I guess.)