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 stability). 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 http://lists.qt-project.org/pipermail/development/2013-January/009359.html . In one of the patch sets, the form changed from [email protected] 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: https://developer.blackberry.com/cascades/documentation/ui/resolution/using_static_asset.html ). 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 away. 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
