[Development] So I've made a QWidgets2 design/prototype... BUT...

d3fault d3faultdotxbe at gmail.com
Sun Jun 24 20:22:01 CEST 2012


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.

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.

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?

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?

This is what I meant when I said "The Qt Project is, in this very moment,
in the worst state it could possibly be in". Add to that Nokia's cutting
back of the Qt division's resources (something yet to even be officially
addressed (poor communication = yet another reason)) and Microsoft's
predicted acquisition of Nokia (whether they do or not is irrelevant. Nokia
depends on Microsoft for survival right now which means Microsoft has the
upper hand and can pressure Nokia into cutting back Qt resources even
further) and you'll start to understand why I made the statement.

The code base is not in a bad condition... it's the contributing model
surrounding it that's unhealthy.

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.

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

d3fault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120624/60e3e45e/attachment.html>


More information about the Development mailing list