[Development] File Selectors API, still for 5.1?

Alan Alpert 416365416c at gmail.com
Fri Mar 22 22:57:11 CET 2013

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

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.

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?

3) Why directories? This change wasn't discussed on the ML yet, and is
a key difference from the consensus reached in

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.

4) One question (sort-of) that came up in the review (from Jędrzej):
"Without runtime detection of a selector value change, the
QFileSelectors is just a workaround for a deployment problem. It
solves issues that can be solved by an installer script or even by a
dynamically loaded QResource." This goes beyond deployment, and so
also solves some issues that cannot be solved by an installer script
or dynamically loaded QResource. It's a little confusing that one of
the main selectors is "platform" - that's more for consistency (so
that you can place your platform-specific selectors inside the
platform selectors) than because deploying different files to
different platforms is too hard right now.

The loading of graphical assets to match the state at application
launch can involve factors that are not known at deployment time, for
example the current theme (one of the things that BlackBerry currently
uses selectors for:
). Arguably responding to theme and resolution in an application
should be done dynamically, not statically, however that is a lot
harder to do (and for minimal gains in some situations). Until we have
a dynamic solution, offering a simple static solution is still a
marked improvement. The dynamic solution could still make use of
QFileSelectors, if we increase the ability for selectors to update
when re-queried at runtime (compatible with the current API). I'd
argue that it's not worth waiting for the dynamic solution to be fully
conceptualized before providing a static solution, because the static
solution provides value now and the dynamic solution is still very far

Dynamically loaded QResources can provide similar functionality, but
not entirely the same. Even for the overlapping cases there is a lot
of work needed by the application developer to use dynamically loaded
QResources for different situations, so a convenience API is certainly
lacking. On top of being more convenient, QFileSelectors is also not
tied to compile-time artifacts. This allows for much faster
development iteration, as you can just copy graphical assets or data
to the install dir or device without needing a re-compile. This is a
valuable feature for most mobile development, and an essential feature
for interpreted languages like QML.

For improved performance I could see a tool emerging which takes a
QFileSelectors enabled file tree and generates dynamic QResource files
from it, but this would be a separate tool that you use after the
development phase (because you want less compiling during development,
but don't care for deployment) and would still use the same selectors
functionality for a standardized file structure (so it can
automatically manage all your .qrc files) and for picking a qrc file
at runtime in a convenient fashion. That would combine the best of
both worlds, similarly to developing with files and moving them to qrc
resources for final deployment, but would still need QFileSelectors or
a similar API.

Alan Alpert

More information about the Development mailing list