[Development] File Selectors API, still for 5.1?

[Thiago Macieira]

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.

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

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

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

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130324/eac2079d/attachment.sig>