A fork of Qt...
-
Recently a big event happend - Nokia and Microsoft decided to make Windows a major platform (instead of MeeGo) for all future mobile phones of Nokia. There was a lot of discussions about future of Qt regarding this event. And one discussion is more important than everything else - I mean this blogpost "http://labs.qt.nokia.com/2011/02/18/buckets-of-cold-water". First of all, I would like to say thanks to Vohi for his honesty and second it become clear that Nokia doesn't interested in further development of Qt on desktops. It's sad, but I can understand this - Nokia is not software developer. Despite this fact they promised to continue working on Qt and it's components which make sens for mobile platform. This sounds good... but it's only sounds. I hope this will be reflected in actions.
But as a software developer for desktops who uses Qt in every day work (starting from small text search tools up to large systems consists of many NT services which must work years without stop) I got a cause, which was decisive in making the decision to start a fork.So, I decided to start a fork of Qt framework in which i want to improve Qt by
- modularisation: QtCore have a lot of excelent things which may be usefull without "Signals/Slots" framework and without "QApplication" and many other things in QtCore, for example QString, QByteArray, QTextCodec, QDateTime, QLocale, QAtomicInt etc.
- using 3rd party libraries such as Stlsoft, Boost, Loki etc which should reduce complexity of Qt internal parts.
- using common tunable memory manager, for example Loki has a good one.
- using common build manager - cmake.
So here is a draft version of roadmap for "my fork of Qt":http://gitorious.org/qtfree
- QtCore:
-
- switch to cmake
-
- make a module with all common Qt types (QString, QByteArray, QTextCodec etc). Actualy, this is already done and you can see the result "here":http://sourceforge.net/projects/qttypes Here is a cmake project based on Qt 4.7.1 (with very small fixes) which collects QtCore sources in one module. After building this project you will get a small (~200Kb) library (instead of QtCore ~4.5Mb) with all common types used in Qt. P.S.: I spent only one day to create this project (only to check my approach), so don't judge me severely.
-
- make a module to work with streams (QTextStream, qDebug etc).
-
- make a module to work with file system (QFile, QDir etc).
-
- make a module to work with "Signals/Slots" framework (QObject).
-
- make a module to work with threads (QThread).
-
- make a module to work with shared objects (QSharedMemory).
Any ideas or suggestions are welcome.
-
Congratz, you're fast. (but that's easy on gitorious, right?) Nokia-sponsored gitorious, to be strict :)
Just 3 most visible dents in your strategy:
- Consider following the Qt Modularization initiative instead of duplicating the effort:
http://labs.qt.nokia.com/2011/01/21/status-of-qt-modularization/ - It's disputable if you're proposing improvements. Maybe from some POV. But in the same time "your" version heavily breaks backward compatibility with 4.x series. Thus, it's throwing out all the software written for Qt so far.
- Note that in legal terms Qt is a registered trademark, like everything in the legal world including Linux and Firefox.
- Consider following the Qt Modularization initiative instead of duplicating the effort:
-
Do you have any rationale for this? Major objectives for 4.8 include Qt modularization and open governance. I know that people confidence in Nokia is quite low now, but I totally trust the people involved.
At least, it's a move I would plan for post-4.8 if open governance doesn't come by then.
-
[quote author="jstaniek" date="1299430933"]Congratz, you're fast. (but that's easy on gitorious, right?) Nokia-sponsored gitorious, to be strict :)
Just 3 most visible dents in your strategy:
-
Consider following the Qt Modularization initiative instead of duplicating the effort:
http://labs.qt.nokia.com/2011/01/21/status-of-qt-modularization/ -
It's disputable if you're proposing improvements. Maybe from some POV. But in the same time "your" version heavily breaks backward compatibility with 4.x series. Thus, it's throwing out all the software written for Qt so far.
-
Note that in legal terms Qt is a registered trademark, like everything in the legal world including Linux and Firefox.
[/quote] -
Yes, I am :)
I know about this and I choosed a different approach of modularisation. The main goal in my case is to rely on 3rd party libraries in implementation of internal parts. -
Do you think Qt is ideal optimised framework? Did you look under the hood??? Especially QtNetwork or for example QFile?
Qt is the greatest set of tools and libraries for cross-platform development, but it can be even more efficient.
Ofcourse I wont break binary compability with 4.x series - I only change the internal implementation and increase amount of modules, but binary (and by includes) they will be equal to existing ones. -
Thanks for the tip i will keep that in mind.
-
-
[quote author="Ymilij" date="1299437498"]What can be more funnier?[/quote]
Indeed! :) -
[quote author="peppe" date="1299447044"]bq. 2. Do you think Qt is ideal optimised framework? Did you look under the hood??? Especially QtNetwork or for example QFile?
So, why not contributing with upstream?[/quote]
Yes, this is good idea and may be I will. But first i need to do something, some working libraries, to offer it to upstream.
-
No, I think the whole point of open governance is discussing Qt future, API design, what goes in and what doesn't, in a public, meritocratic fashion. Discuss with the trolls, before doing any work. Doing a hard job and then being told "thank you, we just did the same work and better" or "oh, wow, but you don't support ICC" or "your API is bad, redesign everything" can be very disappointing (OTOH "We want to hire you!" can be very encouraging :-)).
-
As Qt developer and as part of this community (recently)... I just like to say: IMHO it's too early to take a decision so important and with so many consequences. Nokia hasn't stop the Qt route-map and the open governance is coming, so, is this the right time to play our cards? I don't think so... no yet.
-
[quote author="peppe" date="1299449129"]No, I think the whole point of open governance is discussing Qt future, API design, what goes in and what doesn't, in a public, meritocratic fashion. Discuss with the trolls, before doing any work. Doing a hard job and then being told "thank you, we just did the same work and better" or "oh, wow, but you don't support ICC" or "your API is bad, redesign everything" can be very disappointing (OTOH "We want to hire you!" can be very encouraging :-)).[/quote]
Yes, you are right. But firstly "thank you, we just did the same work and better" doesn't scare me and secondly i will try to be up to date with upstream. -
I agree with the comments that claim it is too early for a fork. I don't think it will attract the kind of community backing that would be needed to make it a viable project. Also, I think there currently is no real reason to make a fork. Nokia is still pouring effort into Qt, it seems, so why make a fork now? I think the open governance might have a better chance of resulting in a workable situation. If you don't like the implementation of some of the parts of Qt, you can already create a merge request for a better implementation. If it really is better, I'm sure it will be accepted.
So, good luck, but I will stay with the main (Nokia) version for now.
-
It's far too early to make a decision like this. A fork should be a the last resort at the end of a long road, when it is clear that collaboration will not work out. Look at the folks of OpenOffice/LibreOffice, this was nothing which was decided in two or three nights.
And to be honest: Your plans on Qt look scary to me. You will set up a whole bunch of dependencies on other libraries. I cannot see how this would improve code quality and stability. I, for example, am really happy that I do not have to bother with boost, when I have Qt around.
And I would not bet a single penny on a one-man-show dealing with a complete Qt fork.
-
I really don't think it's an good idea to start forking Qt. There also is no real reason to do so. Forking would just create big incompatibility and quality problems, and it could split the community (although I don't think you can attract many). I also don't like your plan of eg. creating dependencies to other libraries. And by the way, how would you maintain and further develop your fork? It sure would not be one man's project or something like that. Remember that Trolltech was a company too. Sorry but the whole idea of forking Qt is an bad idea. I can't support your idea of forking Qt. I'm goig to stay with the official Qt developed by Nokia.
-
I understand the fork idea clearly, and I though to this, me too for some nights. As a matter of fact, including the actual Nokia directions for development and platforms (hardware, software, MS partnership etc), I agree with the previous two posts. QT - regardless to hist destiny that will be decided by Nokia next months - is "live", and is rare to find a wide-range development platform growing, with the attention QT has at this moment, that is in the meantime open and of high quality. So, probably the very best thing is to work integrating single development experiences (individual or teams) to enhance and help this growing.
It will not be the first time that while a lot of people are working to define some kind of standard of "optimal perfomance platform" there is something - not necessary under the spot - that became the real reference for a bit set of devices simply because there are the capabilities.
If someone has not yet forgotten, think to DOS and see what's happening in the android world... -
If anyone is going to fork Qt, it will be the KDE people. They are the top customer for Qt on the desktop. The mobile-oriented work Nokia is doing is very useful and valuable so it might end up being better for KDE to contribute what they need to Nokia's Qt instead of forking it.
Here's an interesting web page: http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php
(I work at Nokia)
-
bq. The KDE Free Qt Foundation is an organization with the purpose of securing the availability of the Qt toolkit for the development of Free Software and in particular for the development of KDE software. It was originally founded by Trolltech and the KDE e.V. in 1998. After Nokia bought Trolltech, statutes were updated accordingly.
The Foundation has a license agreement with Nokia. This agreement ensures that the Qt will continue to be available under both the LGPL 2.1 and the GPL 3. Should Nokia discontinue the development of the Qt Free Edition under these 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.
The board of the Foundation consists of two members from Nokia and two members from KDE e.V. Decisions of the Foundation are taken by vote of the board members. In case of a tie the votes of the KDE representatives decide.
In May 2004, a first update to the agreement was made. This agreement addressed the purpose in a more precise and complete way. The intention and basic content however, were not changed. In July 2009, the agreement was again updated to respond both to the relicensing of Qt to the LGPL license and to the merger of Trolltech into Nokia. In November 2009, the statutes of the Foundation where also updated to better fit the new situation.Very well, but - I ask honestly - why just at the actual date there is the Qt-SDK and tools version for embedded platforms that is under license only ?
-
Hi,
what happened to you QtFree project at "http://gitorious.org/qtfree":http://gitorious.org/qtfree? I just checked the fork and it seems dead - no activities since March 01? How will you proceed? When can we expect first results? Do you have a documentation set up already?
Was this fork only some kind of joke or can we expect some serious results soon?
-
Hello again. I was sick for a while so there is no activity on gitorius fork. But now I am getting better and I plan to get to work on this fork soon. Ofcourse this is not joke and the first results is QtTypes library on sourceforge.
-
After a "small" research of QtCore I realized that split it into modules not so easy task as it was with corelib\tools. It can be done but amount of changes in code would be so large and I just won't be able to support this code with upstream, at least by my self. More of that, so huge amount of work will be useless at this time.
