[Development] Qt 5 file hierarchy

[Thiago Macieira]

On segunda-feira, 24 de setembro de 2012 07.08.58, Koehne Kai wrote:
> Note that didn't have any .qml files defining libraries in stock Qt 4.x: All
> the plugins are libraries here. Now for Qt 5 there are indeed some .qml
> files installed in the directory (I counted 42) ... I see that it would be
> nice to have them in an arch-independent directory, but on the other side
> it's IMO not a real world problem if they're duplicated between a lib32 and
> lib64 directory.

Agreed. The duplication is not a big deal for a handful of files that also 
require plugins anyway.

What I'm trying to do is to ensure that arch-independent .qml files don't have 
to be duplicated. In the case of arch-independent QML projects, one does not 
know what the most often used Qt arch is and shouldn't care. That's why it 
should be in a different place.

> > With Qt 5, it becomes worse because Qt Quick 1 and 2 share the same
> > directory.
> 
> That's not completely true. The QtQuick1 library adds a custom import
> directory "$$QT_IMPORT_DIR/QtQuick1" which is always searched first. That's
> why we can have a QtQuick1 and QtQuick2 version of e.g.
> Qt.labs.folderlistmodel . (Not that I find this solution particularly
> elegant...)

Ok, but at least it exists. By parallelism, there should be a QtQuick2 subdir 
searched too. That would suit my needs and we wouldn't need to change the 
imports dir.

But we would need to change QtQuick1 (the QtDeclarative library), which I 
believe we don't want to. So I'd rather we simply change QtQuick2 to use the 
new scheme.

> > Instead, I recommend we immediately change QML2 to the system that Perl
> > uses:
> > put the arch-specific files inside the lib hierarchy, for which
> > distributions have already solved the multiarch problem, but put
> > arch-independent files in the share hierarchy.
> > 
> > In addition, the loader should be clever to merge similar names from the
> > two different paths. That is, imagine a .qml file in share/qml2 that
> > requires a
> > plugin: if the loader is a 32-bit application, it would search for the
> > plugin in lib/qt5/qml2, but if it's a 64-bit application it would search
> > in
> > lib64/qt5/qml2.
> > 
> > Additionally, if we're still using QML2 by the Qt 6 release, the plugins
> > could be made available in lib/qt6/qml2.
> 
> I think your proposal is sound, but I also don't see an immediate need to
> fix the imports for 5.0.

I agree with you only if you're also suggesting that QtQuick2 not be released 
with Qt 5.0. :-)

The searched directory structure needs to be fixed by the time of the first 
release of QtQuick2. I am suggesting we leave QtQuick1 alone with its broken 
scheme -- even in spite of the fact that EVERYONE that uses Qt Quick, uses 
version 1.

-- 
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/20120924/f849b943/attachment.sig>