[Development] QStandardPath search paths

[Alan Alpert]

On Tue, Jul 30, 2013 at 11:34 PM, Rutledge Shawn
<Shawn.Rutledge at digia.com> wrote:
>
> 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,

Nope. This is just something I ran into in QtCore and is intended for
C++ Qt users.

> 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.

That's the difference between search paths and URL schemes - search
paths are a convenience for file paths but always the "file" scheme.
Ergo can be taken a little more lightly than a full URL scheme
handler.

> 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?

Pretty much. At the very least, StandardPaths are not going to be a
useful API when XmlHttpRequest is our only mechanism for loading files
from QML :P.

First we need to answer the question of "what can you usefully do with
file in QML?", because most file use is imperative data processing and
we want to encourage that it is done in C++. But that's a different
discussion, which is larger and much farther ahead in the future.

--
Alan Alpert