Documentation is always latest available in the target

[Didier Roche-Tolomelli]

1. Create an Ubuntu SDK 15.04 targetted project
2. Only use import to Ubuntu Components 1.2
3. Select a component keyword and press F1 to open help.

The documentation opened is always the latest available (currently the one for 1.3), and doesn't match the imported component documentation. So, exta properties or features (or even backward compatbility breakage when moving to 2.0) may confuse the developer.

[Benjamin Zeller (zeller-benjamin)]

Not sure if that is a Bug, however there are no distinct 1.1 vs 1.2 vs 1.3 docs as far as I can see. Thus QtCreator can not select any other documentation.
Forwarding to uitk to clear that up.

[Cris Dywan (kalikiana)]

After a little bit of discussion my view is this:

As long as you use chroots you get exactly the docs you're asking for - safe for bugs where QtC may be accidentally not delivering the right files - so if you need to work with 1.2 do use an older chroot. If you use a newer chroot you should indeed consider upgrading what API you use, not only Ubuntu.Components but also QtQuick and others.

The only flawed case is the "desktop" target where most likely you are using something intermediate since only development releases of Ubuntu whilst they are in development can be uptodate, in any other case it's just not well-defined.

[Benjamin Zeller (zeller-benjamin)]

After a bit of digging in the code and talking to upstream I figured out that even though QtC has all the documentation files from the different targets, it always chooses the most recent available documentation. This seems to be "by design" and needs to be fixed (if upstream agrees that this should be changed) in the upstream project.

Should we file a upstream bug for that?

[Didier Roche-Tolomelli (didrocks)]

I guess rather than closing all bug tasks for this projects, it makes more sense to open a bug in QtC indeed.

As we discussed at the sprint, the recommended way is always to use the "desktop" target for developping the application (fetching the documentation, checking imports and so on) is way faster than using the chroot. I don't think that changing the target without changing any import code should be something that the developer needs to be bothered with and should be transparent for him.

I'm then opening (so that this bug still have something to track) the Qtcreator package bug then.