[Development] QStandardPath search paths

[Rutledge Shawn]

On 31 Jul 2013, at 2:45 AM, Alan Alpert wrote:

> I was just adding the cross-platform asset directory as a search path
> (https://codereview.qt-project.org/#change,61859 , with functionality
> as discussed as part of adaptable UI) and the question arose: Why
> aren't all (or at least some) standard paths available as search
> paths?
> 
> Self documenting examples of what this would look like:
> QFile ("tmp:/tmpfile");
> QFile ("appData:dataFile");
> QQmlApplicationEngine("assets:/main.qml");
> 
> It would be a nice developer convenience, and easy for me to implement
> along with asset:. But it's not needed in the same way that asset: is,
> which is so that you can write asset: paths outside of #ifdef
> Q_OS_ANDROID blocks.
> 
> Does anyone have an opinion on whether I should or should not add all
> the other QStandardPaths along with assets?

Disclaimer: I haven't used QStandardPaths before, so am just reading the docs...

If the point is to make it easier in QML, I think exposing a QStandardPaths API would be more useful in other contexts (e.g. I need it anyway to make a better file dialog ;-) and less opaque.  In C++ maybe the existing API is good enough?  But one wrinkle is that QStandardPaths::standardLocations returns a list, thus the need for QStandardPaths::locate apparently.  Is that what the "convenience" would actually do, as opposed to concatenating the suffix with the first location from the list and taking no responsibility for whether the file exists or not?

These prefixes could be thought of as URI schemes, right?  so I have another gut feeling that adding several more new ones at the same time is not to be done lightly.  Usually schemes are added for completely different mechanisms to access data, whereas these locations can all be converted to file:// URLs, at least on today's operating systems.

So where and how do you think it would be appropriate to expose QStandardPaths to QtQuick? standardLocations, writableLocation and displayName will be especially useful to the file dialog, whereas locate and locateAll will probably be useful to many types of applications.  Do you think we need to invent a file reading/writing API first, and then StandardPaths would just be a sub-feature of that?