If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

A delay which forces further maturation(read: bug squashing) might be just what the doctor ordered.

Yeah but this is not what pushy people at Nokia are ordering. They want proven customer cases to show the paying crowd. And KDE is a nice puppet who follows Qt. So you will se (an attempt) to port to Qt5 even before Qt5 is ready and KDE is ready. Sad but true.

uhm because linux is being dumped bigtime on Qt right now. And before you start to argue against it, let me remind you of Nokias next billion Qt devices which were supposed to be served on MeeGo and Meltemi. It is fucking gone.

Nobody knows where Qt is heading now. If Qt stays with Nokia or it is sold to RIM or Digia it will never turn good for linux and free software. And that is really troubling.

You know we never had a massive Qt developer base in mobile to begin with right?
There was symbian for a time but it wasn't the majority by any strech. Maemo was GTK.

Qt hasn't dropped support for Linux at all. Qt's strong points have always been about embedded and desktop. Mobile was never really that big with Qt beyond some apps with symbian..

Yeah but this is not what pushy people at Nokia are ordering. They want proven customer cases to show the paying crowd. And KDE is a nice puppet who follows Qt. So you will se (an attempt) to port to Qt5 even before Qt5 is ready and KDE is ready. Sad but true.

How ready is a .0 release going to be. The only concerns I have with Qt 5.0 are moving a way from C++ to Javascript (IMO bad) and less features (the point of the article). Bugs have never been a really big problem with Qt IMO.
KDE is another story. All their releases are buggy.

How ready is a .0 release going to be. The only concerns I have with Qt 5.0 are moving a way from C++ to Javascript (IMO bad) and less features (the point of the article). Bugs have never been a really big problem with Qt IMO.
KDE is another story. All their releases are buggy.

Truth is that neither KDE or Qt5 is ready yet. And wont be for a loong time.

for the 3384893828423894203490234902347812371236874678346 time Qt is already LGPL and most of this code is already in git as LGPL, the team manager is not making this code addons cuz digia will evily hide the code but cuz the current maintainers future is unknown hence is better to hold back until is sure a proper maintainer will review the code[or the same but working in another company], is just a precaution.

beside the risk of digia[or other company] will risk their bussiness keeping a parallel version of Qt is very narrow like i said no one will pay support for a broken piece of software that has 2 different sets of API and if digia is stupid enough to do it i bet most of their clients will choose to stay with the open one[cuz will be lots more active and reviewed after all they came to Qt for something!! if not they had stayed with microsoft tech].

those blogs are useless to the discussion since those charts is an external developed by digia product unrelated to the Qt framework[they are not forbidden to create products from Qt nor anyone else LOL] and btw QNX port exist in Qt since 2009 same as vxworks [btw qnx and vxworks are closed source to the bone hence making no sense to keep rooting/polluting the LGPL version][who the hell is still using QNX?? i have years without hearing anything about it except for RIM <--- real question btw], so as far as they dont compromise the base Qt framework they can use it to create flying cars for what i care.

digia is just trying to improve their bussiness income eating their own food developing external goodies using Qt[what is so evil about it?? you prefer them to use .NET??] now an alarming thing would be that for example QSceneGraph use only software rendering in LGPL and opengl/dx in the pay version[cuz you are affecting the framework here] but even on that case community just add opengl and rename the project and .I. digia cuz the code is already LGPL

A delay in QT5 might not be all bad. I mean, there's a silver lining in everything.

KDE4 in the last few releases(4.6, 4.7, and especially 4.8) has simply been amazing. I'm looking forward here soon to installing 4.9 and having a go at it. (amazing with a caveat - sure, I've noticed bugs here and there. That's to be expected in a community environment where we are the bug testers)

From what I understand, KDE5 isn't planned to be so earth-shattering as KDE4 was, but still. A KDE 4.10, 4.11, 4.12 and so forth that further builds upon the already matured code base longer than it otherwise would have might be a good thing, before QT5 and thus KDE5 arrives.

How many times to you see people around here complain about how buggy that KDE is? A delay which forces further maturation(read: bug squashing) might be just what the doctor ordered.

I'd port KDE4.xx to Qt5.0 and call this KDE5.
There is actually nothing left under KDE hood that has to be polished.

I, also, don't understand this whole critizism behind current dual-licensed Qt.
You are offered feature-parity and if anyone decides to base his closed-source code on Qt, he has to pay for closed source Qt version - and as such he pushes Qt development.
If he wants to use it within his opensourced code (regardless if he makes money with this or not), he has opensource version.
Both versions have feature parity.

The only single thing in this model left is - upstream unwilling to accept patches, as it was with Oracle.
Then, the whole model turns from opensource into opencore, and THATs unacceptable, as it does reduce the functionality of open software to shareware equivalent.
This is why openoffice was forked.

for the 3384893828423894203490234902347812371236874678346 time Qt is already LGPL and most of this code is already in git as LGPL, the team manager is not making this code addons cuz digia will evily hide the code but cuz the current maintainers future is unknown hence is better to hold back until is sure a proper maintainer will review the code[or the same but working in another company], is just a precaution....

digia is just trying to improve their bussiness income eating their own food developing external goodies using Qt[what is so evil about it?? you prefer them to use .NET??] now an alarming thing would be that for example QSceneGraph use only software rendering in LGPL and opengl/dx in the pay version[cuz you are affecting the framework here] but even on that case community just add opengl and rename the project and .I. digia cuz the code is already LGPL

I don't know why people are acting like Qt is on life support. You are right in that Digia only wants to help. Qt has many investors ( mentioned by n3wu53r a few posts ago) and Digia is making sure people will still pay for a commerical license (by maintaining older versions -- versions that the open source community will leave behind when adopting the newer versions fairly quickly ).

So many people complain that Qt is not as open as GTK as it had a closed license, then with the QPL, and even now as it carries the LGPL. Now without argument, Qt will be as open as GTK, with a much larger community and clearly more cross-platform-compatible code. There's no way that Nokia selling Qt will hurt it. I don't even understand how they can sell it at this point. Does Nokia even own more than the "Qt" trademark at this point? How could Nokia even affect "qt-project.org" in anyway? Can they affect Digia's right to sell a commerical license of Qt?

Well, with the dual license, I guess that one thing people wouldn't like to see is it turning into what OpenAL is now - a once open-source project turned proprietary, with the proprietary part having all the really good features (EFX equivalent to EAX Advanced HD 5.0, for instance). OpenAL Soft couldn't match what Creative did, so what makes you certain that it will be different with Qt, in case the company that owns it turns the project proprietary?

Hold on a second, I just realized the proprietary addon digia is providing isn't much of an addon as it is just a few pre-made widgets. Hell Digia isn't the only company doing this, anyone can do it! Look: http://www.kdab.com/kdab-products/kd-tools/

Not to mention the widgets Digia sells are similar to Qwt which is LGPL only.

So digia hasn't done any foul here at all.

There's no way that Nokia selling Qt will hurt it. I don't even understand how they can sell it at this point. Does Nokia even own more than the "Qt" trademark at this point? How could Nokia even affect "qt-project.org" in anyway? Can they affect Digia's right to sell a commerical license of Qt?

They still pay a lot of Qt developers and Nokia still owns the copyrights, as well as their stake in qt-project.

What ?!? Moving away from C++ to JavaScript ?!?

They aren't dropping C++. But they are becoming more Javascript centric (QML).

While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term