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 fine. Unfortunately, the rest of the email thread doesn't lead me to believe that it is. > >> 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). 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
