[Development] QStandardPath search paths

[David Faure]

On Wednesday 31 July 2013 11:23:47 Thiago Macieira wrote:
> On quarta-feira, 31 de julho de 2013 11:18:38, Alan Alpert wrote:
> > On Wed, Jul 31, 2013 at 11:13 AM, Thiago Macieira
> > 
> > <thiago.macieira at intel.com> wrote:
> > > On quarta-feira, 31 de julho de 2013 11:05:56, Alan Alpert wrote:
> > >> Search paths make "asset:/main.qml" work on all platforms. I don't see
> > >> how QStandardPaths::locate would work here other than
> > >> 
> > >> #ifndef Q_OS_ANDROID
> > >> QStandardPaths::locate(AssetPath, "main.qml");
> > >> #else
> > >> "asset:/main.qml";
> > >> #endif
> > > 
> > > Why can't QStandardPaths::locate return "asset:/main.qml" ?
> > 
> > Because it's not a proper filepath. Or does not not matter so long as
> > we maintain the VFS characteristics which allow QFile/QDir to pretend
> > it is?
> 
> It's a file engine. File engines are bad. No one disputes that (yet we added
> another one).
> 
> If QFile can open it, what's wrong with returning it, though?

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)

It definitely doesn't fit with the "standard" part of QStandardPaths :-)

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.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5