MainView.applicationName seemingly confuses QSettings

Bug #1241424 reported by Michael Zanetti on 2013-10-18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu UI Toolkit
Fix Released
Christian Dywan
ubuntu-ui-toolkit (Ubuntu)

Bug Description

MainView has a property applicationName which is set to QApplication::applicationName. The expected value is something like "com.ubuntu.developer.developerName.applicationName". However, the way this is intended to be used by Qt is to combine organisationName and applicationName.

This causes QSettings not to work in confined apps. It is still possible to make it work by doing this in C++:


Next problem is, that the store's automatic checks try to find the applicationName property in QML and reject the app if it's not present. I tried setting the applicationName in QML and again overwrite it in C++. This doesn't work. As soon as applicationName in QML is used, the organisationName is cleared and QSettings tries to store the config in

/home/user/.config/Unknown Organization/com.ubuntu.developer.developerName.appName.conf

This obviously breaks when running the app confined.

To solve this, organisationName should be supported in MainView and Ubuntu specific plugins like the LocalStorage should be adjusted to make use of organisationName AND applicationName just in the same way as Qt itself uses it.

Related branches

description: updated
Tim Peeters (tpeeters) on 2013-10-18
Changed in ubuntu-ui-toolkit:
assignee: nobody → Christian Dywan (kalikiana)
Michał Sawicz (saviq) wrote :

I agree we should keep (or get to) as close to existing Qt APIs as possible.

Christian Dywan (kalikiana) wrote :

The problem here is that QSettings doesn't build the path in the same way all others APIs do. The folders constructed based on applicationName/organisationName are different.

State saving uses QSettings like this, passing the name to the constructor:

new QSettings(UCApplication::instance().applicationName())

summary: - [MainView] applicationName in QML is used wrong
+ MainView.applicationName seemingly confuses QSettings
Michael Zanetti (mzanetti) wrote :

What are "all other APIs"?

I know I can still manually force QSettings to put stuff in some certain place. However I don't think #ifdef'ing every usage of QSettings is what we should recommend to people porting stuff to our platform.

Christian Dywan (kalikiana) wrote :

I should be more precise. Code based on QStandardPaths like the following works as expected both on the desktop and under confinement:


But your point in terms of "out of the box" using QSettings is valid. I'm taking a look at that now, will be back with an update soon.

Christian Dywan (kalikiana) wrote :

And to clarify how QSettings is not respecting the API: other code in Qt doesn't use "unknown organization" but it checks if an organization is set. On Linux you want ~/.config/appname and ~/.cache/appname most apps have no needed for an organization and it's not sensible to have the organization first under confinement.

Florian Boucault (fboucault) wrote :

Friendly bump :)

Changed in ubuntu-ui-toolkit:
status: New → Confirmed
Zoltan Balogh (bzoltan) on 2014-08-08
Changed in ubuntu-ui-toolkit:
importance: Undecided → High
Changed in ubuntu-ui-toolkit:
status: Confirmed → In Progress
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:ubuntu-ui-toolkit/staging at revision None, scheduled for release in ubuntu-ui-toolkit, milestone Unknown

Changed in ubuntu-ui-toolkit:
status: In Progress → Fix Committed
Zoltan Balogh (bzoltan) on 2014-10-01
Changed in ubuntu-ui-toolkit:
status: Fix Committed → Fix Released
Zsombor Egri (zsombi) on 2015-07-14
Changed in ubuntu-ui-toolkit (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers