[Development] QStandardPath search paths

[Thiago Macieira]

On quinta-feira, 1 de agosto de 2013 10:55:46, David Faure wrote:
> It breaks opening such things with other means than QFile (e.g. native
> APIs).
> 
> It ties in two features together (QStandardPaths and QFile's file engines)

I've made my position clear that I dislike the file engines and search paths 
feature. I said they are implemented at the wrong level of abstraction: their 
presence effectively makes all file names on Qt be part of a "virtual filesystem" 
layer, not a "native filepath" thing.

But they are there. And since we seem to be adding more file engines now with 
the Android port, it seems our de facto position is that a "QString fileName" 
argument is actually a virtual file path in the QFile / QDir engine.

So I can't accept the two arguments above.

Maybe the solution is to un-deprecate the QFile::encodeName function and make 
it resolve to an absolute, native file path.

> It definitely doesn't fit with the "standard" part of QStandardPaths

QStandardPaths returns "paths that are standard in this system". If one of 
them is a Qt file engine, then I don't see a problem in it returning 
"assets:/main.qml".

> I must have missed something in this discussion, because I don't know what 
> asset:/main.qml does. Are we really adding a file engine after we almost 
> deprecated them? I'm lost.

Yes, on Android. My guess is that it uses the JNI to make some Java calls and 
obtain the contents. I'm guessing that Android assets are akin to the Qt 
resources.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- 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/20130801/7632db80/attachment.sig>