[Development] File Selectors API, still for 5.1?
thiago.macieira at intel.com
Tue Mar 26 19:04:58 CET 2013
On segunda-feira, 25 de março de 2013 10.42.27, Alan Alpert wrote:
> > 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...
Ok, that sounds more like nitpicking. We can always rename a class before it's
released. That doesn't stop the integration, though, if everything else is
Unfortunately, the rest of the email thread doesn't lead me to believe that it
> >> 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
What is a selector? Maybe I should just read the documentation...
" QFileSelectors provides a convenient way of selecting file variants based
on platform or device characteristics."
(BTW, the docs are missing the \brief)
"Multiplexer" is too complex a term. "Switcher" gives the impression that you
can switch it -- as in switching from Android to iOS to QNX. That doesn't look
right to me. So "Selector" is better -- singular since it's what the class
does, not that it applies "selectors" to the name.
> > 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.
Ok, then I agree the class belongs in QtCore.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Development