uri on ContentStore qml binding isn't set before getting the first transfer
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| content-hub (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
A simple app with:
ContentStore {
id: appContentStore
scope: ContentScope.App
}
Doesn't have any appContentStore.uri content and print this warning:
"Accessing ContentStore uri with NULL internal store"
However, the ContentStore uri only depends on the ContentScope associated with it. I wanted to do some cleanups and check on the backend side while fetching it. But setStore() which initialized the uri is only available after the first transfer using that ContentStore.
The C++ side is doing that inside the constructor, I think the QML one should do the same to make ContentStore a little bit more useful.
ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: content-hub 0.0+15.
ProcVersionSign
Uname: Linux 4.1.0-3-generic x86_64
ApportVersion: 2.18-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Sep 2 15:47:31 2015
InstallationDate: Installed on 2012-05-28 (1191 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
SourcePackage: content-hub
UpgradeStatus: Upgraded to wily on 2014-10-31 (306 days ago)
| Didier Roche-Tolomelli (didrocks) wrote | #1 |
| Ken VanDine (ken-vandine) wrote | #2 |
| Changed in content-hub (Ubuntu): | |
| importance: | Undecided → Wishlist |
| status: | New → Triaged |
In further investigation, I see this is actually intentional. The ContentStore has to know the ContentType to properly construct the uri. So this gets set when the transfer uses the store.
To make ContentStore more generally usable, outside of just transfers we should look at solving that. Perhaps we could add an optional property for contentType. We can consider that for the next API bump.