[Development] Another method of registering QML types

[Olivier Goffart]

On Thursday 08 November 2012 19:23:37 Shawn Rutledge wrote:
> On Thu, Nov 08, 2012 at 07:14:52PM +0100, Olivier Goffart wrote:
> > On Thursday 08 November 2012 09:57:05 Alan Alpert wrote:
> > > Currently, there is no way to register QML files as types from C++.
> > > This is the exact same functionality that qmldir provides, but I think
> > > there are situations where you'll want to do this progamatically
> > > instead of with a qmldir file. There is a very specific example I have
> > > in mind: Platform Components.
> > > 
> > > I'm suggesting another qmlRegisterTypes function, one that takes a URL
> > > instead of a C++ type:
> > > 
> > > qmlRegisterType(const char* url, const char *uri, int versionMajor,
> > > int versionMinor, const char *qmlName).
> > 
> > Paths should be QString.
> > We support unicode paths.
>
> const char* doesn't preclude UTF-8,

Yes, but in Qt we use QString for all the strings that might contains unicode.

In particular, QFile and all the IO stack uses QString for filename, so it 
means it will be converted to QString eventually

It is nonsens I have to argue for that: it is how Qt API is.
Don't put char* in the Qt API for stuff like that, please.


> whereas QStrings have to be explicitly constructed nowadays. 

Use QStringLiteral and you're fine.
Also notice that since you want to construct the url programatically, you will 
have to do that with QString or QByteArray anyway. 
 And the code can't keep the raw pointer as it, it needs to copy it anyway, 
because it is out of scope after the function call.

> That is annoying in many other contexts; I don't quite understand why we
> didn't just change the assumption from Latin1 to UTF-8 and keep the
> transparent conversion working the way it used to.

We did change to default UTF8, but char* has much more drawback.
Who keeps the ownership and how long does it have to be valid?

-- 
Olivier

Woboq - Qt services and support - http://woboq.com