[Development] File Selectors API, still for 5.1?

[Alan Alpert]

On Sun, Mar 24, 2013 at 9:57 AM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On sexta-feira, 22 de março de 2013 14.57.11, Alan Alpert wrote:
>> There are a few questions left on the QFileSelectors API addition,
>> https://codereview.qt-project.org/#change,48334 :
>>
>> 1) Did it miss the feature freeze for 5.1?
>
> Technically, yes.
>
>> It did not merge into dev before the dev->stable merge, so it has
>> technically missed the freeze. But I'd like to ask for a special
>> exception, on the following two grounds. Firstly, since before the
>> freeze the change has only been blocked on documentation and naming
>> comments (relevant to a quality product, but not really affecting
>> stability).
>
> This is not good enough a reason. Any new feature can only be accepted in
> *dev* once it's complete: that is, it is there, works, unit-tested,
> documented, with examples if necessary, and an initial API review has been
> done. If your feature is still discussing the class name, it indicates that
> the initial API review is not concluded.

I got the impression that the initial API review was done. Then
someone brought up that they didn't like the name...

>
>> Secondly, this is time-sensitive. At least Plasma and BlackBerry
>> already have conflicting schemes to provide this functionality on top
>> of Qt 4. A disruptive change to their file structures is only going to
>> work on a major version change, like when they start using Qt 5 (both
>> aim to start with 5.1 I believe). Missing this window means that they
>> both continue to use their own conflicting directory structures in
>> their next major versions, which is a blow to cross-platform
>> application development.
>>
>> This exception is of course contingent on reviewers agreeing that it's
>> done; currently that appears to just mean agreement on a class name.
>> Obviously there can't be an exception to the freeze for a feature
>> which can't merge because it's not done.
>
> We could grant an exception for the feature freeze and I hope it would not
> take more than 15 minutes to agree on a class name.
>
> But the important question is: have Plasma devs looked at your proposed API
> and solutions? Have they said that they could replace their implementation
> with yours? You're claiming unifying the uses as a claim for exception to the
> feature freeze, so I would like to know whether the unification is really
> happening.

I've been having trouble getting a response from them (mostly trying
to reach Aaron). I've looked at their implementation and verified that
it can be replaced and that the new implementation would solve the
known issues they have listed. Maybe I should try the plasma-devel ML,
since I have trouble catching them awake on IRC...

Honestly, I had the impression that BlackBerry would be the harder
group to convince so I've been focusing there. Despite my being "on
the inside" for BlackBerry, the plasma devs still seem friendlier.

>
>> If it doesn't get a feature freeze exception, we at least need to
>> support it being implemented by others in QML (because while doing
>> this kind of thing yourself with just C++ is fairly easy, it's really
>> hard to reach into the QML engine to have this effect applied to QML
>> files). This could either mean moving QFileSelectors to QtQml (which
>> would mean giving up on all the non-QML usecases, like the res: scheme
>> in the original thread) or have QML use an abstract class which can
>> later be powered by QFileSelectors (but in the interim will lead all
>> platforms to implement their own conflicting schemes).
>>
>> 2) What to call it?
>> Oswald suggested "QPathSelector. or QPathSwitch[er]. or
>> QPathMultiplexer."  I'm still leaning towards QFileSelectors, but I'd
>> also be happy with Q[File|Path]Switcher or QPathMultiplexer. I know
>> that everyone has an opinion on naming matters, is there something
>> even better that we haven't thought of yet?
>
> Explain here in a few words what the class is meant to do and how it does
> that. That's two things I'm asking for: what and how. The name should come
> from one or both.

Applies selectors to file paths. Hence QFileSelectors (QPathSelectors maybe).

>> 3) Why directories? This change wasn't discussed on the ML yet, and is
>> a key difference from the consensus reached in
>> http://lists.qt-project.org/pipermail/development/2013-January/009359.html
>> .
>>
>> In one of the patch sets, the form changed from file at selector.png to
>> +selector/file.png . Feedback from designers in BlackBerry suggested
>> that they were more comfortable with directories, especially when
>> using it to swap out graphical assets for device variants (which can
>> lead to a lot of selected files). It's much easier for them to deal
>> with a group of selected files via directory, which I presume is
>> because from a GUI file manager you don't have the shell globbing that
>> I'm accustomed to using. The switch from @ to + is because that works
>> with my shell auto-complete (~ is already special, @ makes it think
>> it's part of a URL). Having a special character in the directory name
>> helps reduce the risk of accidental collisions, and makes selector
>> directories clear compared to normal directories.
>
> Rich claimed that + is special on FAT. Looking up online, it seems that + *is*
> reserved in FAT for the short filenames (8.3), but is allowed on long filenames.
> Therefore, I'd say it's ok to use it.
>
>> 4) One question (sort-of) that came up in the review (from Jędrzej):
>
> 5) the question of which library it belongs to.
>
> As I told you on IRC, I'd like you to give me one use-case or example of the
> new API being used for something completely and entirely non-graphical, like
> translations. If you can come up with an example, then I'll have no objections
> of it belonging to QtCore. It can be with an imagined future extension to the
> API too.
>
> That doesn't mean that it must move if you can't find a good example.

The examples in the API docs switched to locale and platform. They no
longer reference graphical assets. You could use this for locale
related data to store it alongside translations, or you could use it
for platform-specific assets for a consistent file structure.

There are future imagined uses of tooling support where the tools
(like QtCreator) make cross-platform development easier by combining
this and a platform specific data url (like androids asset://) so that
you have a readable directory structure when developing, both on
desktop and on device, but for final deployment QRC files are built
automatically and the appropriate one is dynamically loaded. With that
level of convenience, file selectors would likely replace #ifdefs for
loading platform specific data in non-graphical situations.

--
Alan Alpert