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

[Mark Summerfield]

Hi Thiago,

On Thu, 16 Aug 2012 13:07:08 +0200
Thiago Macieira <thiago.macieira at intel.com> wrote:
> 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.

Yes. In which case presumably I can then do everything in C++ and won't
need to touch QML/JavaScript?
 
> 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...

Yes, that sounds great.

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

If the element is created in C++ in the first place and just passed into
the scenegraph, why can't one simply interact via the original element
reference/pointer, i.e., do all the signal/slot connections in C++?

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

Look for example at PyGObject. Basically this exposes the Gtk+ API to
Python: https://live.gnome.org/PyGObject/
But PyGObject is built on GObject, as are a number of other language
bindings.

AFAIK there are 3 different sets of bindings for Qt:
QtScript/JavaScript; PySide/Python; and Jambi/Java. I don't know if
Jambi is maintained anymore but ISTM that if there was one definitive
binding technology used then it would be much easier to not only
maintain the existing ones but to add new ones.

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

I don't know. But having a different binding for every language is a lot
of duplicate work and seems to have failed in the case of Jambi.

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

I think the middleware should certainly include raw sockets as an option
but I suppose one model is where you do signal/slot connections between
a client app and a server app and Qt takes care of the middle bit either
using TCP/IP or some other sensible default or using a technology that
the developer specifies.

> > - A complete API for reading/writing Open Document Format files.
> 
> Outside the scope. You should just use the Calligra libs.

Qt has grown so large I didn't know that anything was outside its
scope;-}
 
> 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.

Graph plotting isn't just something done by scientists and engineers so
I think it isn't so niche these days. And yes, an integration with the
Qwt widgets would be great.

:-)

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Rapid GUI Programming with Python and Qt" - ISBN 0132354187
            http://www.qtrac.eu/pyqtbook.html