Ubuntu UI Toolkit

MainView.applicationName seemingly confuses QSettings

Bug #1241424 reported by Michael Zanetti
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu UI Toolkit
Fix Released
High
Cris Dywan
ubuntu-ui-toolkit (Ubuntu)
Fix Released
Undecided
Unassigned
Vivid
New
Undecided
Unassigned

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++:

QCoreApplication::setOrganizationName("com.ubuntu.developer.developerName.appName");
QCoreApplication::setApplicationName("appName");

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.

See original description

Related branches

lp:~ubuntu-sdk-team/ubuntu-ui-toolkit/organizationDomain
PS Jenkins bot: Approve (continuous-integration)
Zsombor Egri: Approve
Diff: 121 lines (+77/-0)
4 files modified
debian/control (+1/-0)
modules/Ubuntu/Components/plugin/ucapplication.cpp (+2/-0)
tests/unit/tst_mainview/Settings.qml (+34/-0)
tests/unit/tst_mainview/tst_mainview.cpp (+40/-0)
lp:ubuntu/utopic-proposed/ubuntu-ui-toolkit
Michael Zanetti (mzanetti)
description: updated
Tim Peeters (tpeeters)
Changed in ubuntu-ui-toolkit:
assignee: nobody → Christian Dywan (kalikiana)
Revision history for this message
Michał Sawicz (saviq) wrote :

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

Revision history for this message
Cris 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
Revision history for this message
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.

Revision history for this message
Cris 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:

QStandardPaths::writableLocation(QStandardPaths::ConfigLocation)
QStandardPaths::writableLocation(QStandardPaths::DataLocation)
QStandardPaths::writableLocation(QStandardPaths::CacheLocation)

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.

Revision history for this message
Cris 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.

Revision history for this message
Florian Boucault (fboucault) wrote :

Friendly bump :)

Changed in ubuntu-ui-toolkit:
status: New → Confirmed
Zoltan Balogh (bzoltan)
Changed in ubuntu-ui-toolkit:
importance: Undecided → High
Cris Dywan (kalikiana)
Changed in ubuntu-ui-toolkit:
status: Confirmed → In Progress
Revision history for this message
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)
Changed in ubuntu-ui-toolkit:
status: Fix Committed → Fix Released
Zsombor Egri (zsombi)
Changed in ubuntu-ui-toolkit (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.