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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
