On 25/06/2012, at 4:22 AM, d3fault wrote: > Apparently I'm smarter than everyone at Nokia. I managed to make a "modern, > fluid" GUI API using the QSG* classes without incurring the additional costs > of: JIT Parsing of .qml files, a JavaScript Interpreter, and a Virtual > Machine. I also did it without using declarative, something claimed by many > to be impossible. > > It's a C++ API, and I only have a few basic elements created so far: Buttons, > Labels, Text Fields, Layout Boxes... planning on doing Radios and Checkboxes > next. > > They look very ugly at the moment, but that doesn't matter. With a bit of > TLC, they can look identical to QWidgets1... use styling, etc. > > Now onto the BUT, > > I can't find a reason to contribute it to the Qt Project.
Then I guess no one will ever see your "groundbreaking" work then, eh? > > A wise man once wrote a chapter in a book on advice about "asking the right > question". > > So my question became: What is Qt? > > IMO: > Qt is a powerful cross-platform C++ framework. > > A framework consists of 2 core parts: > 1) The GUI API > 2) The Utility Libraries > > Going by that definition, it is my opinion (and nothing more) that Nokia has > taken the Qt Project off track from the "Qt Way" (as the founders intended) > with their QML experiment. 5 years is a long time for a GUI experiment, dont ya think? This discussion has taken place ad nauseam, anyway... I agree that some parts of Qt have become neglected, but there's nothing we can do about the past, so let's try to fix that all back up again. > > They paid a pretty penny acquiring Qt, so they have every right to do so. > > The thing is, "The GUI API" is a __CORE__ piece of functionality to thr > framework. > > Which brings me to my next question: > Why should I do Nokia's work (rather, what I think should be their work) for > them? If you've heard the news, Nokia doesn't require Qt anymore. So you wouldn't be doing Nokia's work. Besides, Nokia didn't want widgets. > > Sure, they offloaded Qt Commercial to Digia... but that's besides the point. > The fact remains that Qt is a valuable product, and I am sitting on a [very > unfinished] core piece of functionality. I am convinced that my functionality > has value, so why would I contribute/GIVE it to the Qt Project and let > Nokia/Digia profit from my work? Because otherwise this email is just hotair. Why contribute to any project, some other company is just going to try and profit from your work? > > Sure, I could contribute QWidgets2 as an add-on... but remember the bit about > it being CORE functionality? Core functionality does not belong in an add-on. The time for adding new features to 5.0 are over. Especially of this magnitude. Perhaps 5.1 would be a better target? I take it you have also written autotests and documentation already? and made sure it compiles and runs well on all platforms? > > Which brings me to this thing I keep mentioning (which triggers accusations > of trolling): a fork. > > Don't get me wrong, the Qt Project requires a large amount of active > contributors/maintainers to stay alive... > ... but does it reall require that many to maintain a fork? You could just > pull every change from the upstream/Qt Project... rename it (scripted)... > apply your changes... and release/sell. The selling would just be commercial > support (can't re-license Qt like Digia/Nokia can)... but at least the > commercial support would be going to the contributors... not the corporation > taking the project in the wrong direction. > > That being said, I don't want to fork. Then why even mention it? > I'm too lazy AND I dont want to split the community. The point I'm trying to > put in everyone's faces, however, is this: The current contributing model > surrounding the Qt Project is unhealthy. It sure is. I can't currently contribute anything but bugfixes without going through lawyers first... but that's another story. > It makes people want to fork. Sure, I'm too lazy... but what about the next > guy? I want Qt to be all it can be (lol Army). This means that the issue > needs to be dealt with if we want Qt to thrive. You do want Qt to thrive, > don't you? We need to keep the community together in order for that to happen. It takes more than one or two people to keep up and maintain Qt, much less develop new features. Again, it's open source, and people are able to fork if they so desire. Would you believe the Qtopia codebase can now run on Qt 4.7? Qtmoko project is an example of a good fork. > > d3fault > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
