[Development] [Interest] Qt5 - my hopes for when the dust settles...

[Thiago Macieira]

On quinta-feira, 16 de agosto de 2012 10.54.30, Mark Summerfield wrote:
> Hi,
> 
> I hope that Digia proves to be a good steward of Qt---for Qt/Desktop
> users as well as for Qt/Mobile users!
> 
> Here are some of the things I'd like to see in a future Qt.*
> 
> - A full C++ API for all the things that currently can only be done
>   using QML/JavaScript so that everything can be programmed purely in
>   C++ (or purely in whatever language you have bindings for).

Hi Mark

This is one controversial feature. I only agree partially with what you're 
asking for. I think that the building blocks that Qt Quick uses should be 
available from C++. That is, I want access to the OpenGL Scene Graph, so I'm 
able to add my own elements and build my own scene on top of them.

Let's forget JavaScript for the moment. There's nothing in JS that can't be 
done in C++. It just so happens that any expressions in QML are evaluated 
according to JS rules, so you also get things like Math.ceil, Array, Date, 
etc. All of those are available in Qt and in C++ since the dawn of time.

The rest of QML is basically about building elements with a nice syntactic 
sugar. If you have access to the scene graph, you can build your own elements. 
You'll have to replace the property binding with your own slots that 
recalculate something, and you'll need to build your animations on top of 
those. So what? That's imperative programming basics...

The big question I have on my mind is about the elements that are exposed into 
QML. That is, should the developer have the ability to do something like:

	auto rect = parent->newChild("Rectangle");
	rect->setProperty("fill", "parent");
	rect->connectPropertyChanged("width",
		[=](QMLProperty *ctx) { 
			parent->findById("id1")->setProperty("text", ctx->value());
		});

On one hand, it might be useful, so one could make use of QML components 
defined in QML (such as the Desktop Components) from C++. On the other, and 
here's the big catch, there's a HUGE effort necessary in providing that API 
above and it ties our hands in improving the engine internals later.

A C++ API, like the above, can't exist within the next 2 years. We need at 
least that long to stabilise and improve on the engine internals, clean it up, 
design the API and test it.

> - An introspection API similar in spirit to the one provided by Gtk+
>   which is specifically designed to make it as straightforward as
>   possible to add language bindings to Qt.

More info, please. I've seen some posts and other information about the Gtk+ 
Introspection, but I couldn't determine any use of it beyond what what we 
already provide in Qt with moc+QMetaObject.

And the bindings generated by the QtScript binding generator.

> - One or more official language bindings using the introspection API,
>   e.g., for Python and for Java.
> 
>   (This is not a criticism of PySide; indeed I personally prefer using
>    Python, but I think that it would be better if Qt provided a more
>    language-agnostic---and uniform---approach to language bindings.)

I'll leave that to the experts.

But just think about this: is a generic approach to binding the best way to 
produce a tight and efficient binding in any language?

> - A new model/view architecture that is a lot easier to use and which is
>   designed from the ground up to work well with databases.

Yes, indeed.

> - High-level support for client/server programming with the middleware
>   able to be straight TCP/IP (e.g., for LANs), OpenVPN, etc.

More info, please. Do you mean raw sockets?

> - A complete API for reading/writing Open Document Format files.

Outside the scope. You should just use the Calligra libs.

If the Calligra libs can be slimmed down, they could be accepted as addons.

> - An API for reading and writing .gz, .zip, and .tar.gz files.

I'd like this. I think it was one of the targets: lift KArchive from kdecore, 
but give it a make-over.

> - New widgets for displaying 2D and 3D graphs.

Sounds incredibly niche. Isn't that what QwtPlot is supposed to do? In any 
case, QwtPlot or any other solution would be welcome as addons.

> I consider Qt to be the best cross-platform GUI development framework in
> existence---and hope that it long continues to be so:-)
> 
> * Some of the suggestions are in "Advanced Qt Programming"'s epiloge.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120816/4aa9c1cd/attachment.sig>