Qt Apps banned from Mac App Store?

[Oliver Knoll]

First off, I never questioned your Qt skills as such! I did go to your website and you do have plenty of posts.

So let's focus on the "Qt settings issue".

Come on man. Open up your reference manual, open the search tab and type in "qt.conf". ~/Library/Preferences/com.trolltech.plist is generated when QSettings is passed "trolltech.com" as organization domain

The point here to note is that it is not the application who passes along trolltech.com (to any of the methods of QSettings), that name is hard-coded in the Qt sources, and it is the Qt library itself who writes these settings.

And AFAIR the proposed patch exactly "fixes" that location where that name is hardcoded.

Probably that would go wrong on Windows where these settings are stored in the registry (in the case where your app writes to *.ini files for instance), under HKEY_CURRENT_USER\Software\Trolltech - that's what I meant I did not look too closely at the patch. I just figured out its intention, not in detail how it solves that.

And yes, the implementation is off course not elegant, hence my previous calling it a "workaround".

But let's go on...

(or Trolltech as organization name, I don't remember - take a look at the source code). If you change the location of all QSettings entries (for example move them inside a directory of your choice like either the application bundle or the directory where Apple allows your app to store its files), your "com.trolltech.plist" location will be changed as well.

That's where I don't follow you: what do you mean with "If you change the location of all QSettings entries"? How do you do that?

Again I think you are wrong here: all arguments - organisation name, application name and what else - only affect the application settings, that is the settings your own application writes/reads via QSettings.

Internally Qt also keeps track of its own settings, also via QSettings off course, but the organisation name etc. is hard-coded to "Trolltech". This is reflected by this newly line in the patch:

if(bForceTrolltechSettingsToAppArea && (organization == QLatin1String("Trolltech")))
...

if(bForceTrolltechSettingsToAppArea && (organization == QLatin1String("Trolltech")))
...

To copy to clipboard, switch view to plain text mode 

In other words: IF the application wants to do AND the organisation name equals "Trolltech" (hard-coded somewhere else in the Qt sources), then store whatever comes in the newly created location (of which the logic I haven't studied in detail, but it seems to save in under ~/Library/Preferences/com.yourapp.whatever.plist - and that file is fine for Apple).

It is in no way different than any other use of QSettings.

... except the application has no control over where these settings are stored, since this is handled inside the Qt code, with hardcoded domain names etc. - so no way currently to change the location from ~/Library/Preferences/com.trolltech.plist to something else.

It means you don't need a ~/Library/Preferences/com.trolltech.plist to have a working Qt app. Qt apps can even work on read-only systems without deploying any "Qt-specific" configuration first.

No one said that file is needed. In fact it would be okay if that file was never generated for "Mac Store Qt Apps" and Qt would hence need to re-scan all known plugin paths each time (or whatever is stored inside that trolltech.com.plist file).

But fact is that if the FS is writeable that file is created by Qt once you start your first application. And that is a problem.

Please point out where I quoted you "wrong or incompletely".

As a matter of fact I just did. I could have also just written "scroll up a few pages". But you figured out that yourself later on...

It is you who came here over a month after the discussion burned out, didn't even say "Hello, my name is Oliver, I'm a really nice guy and I want to be part of your community"

I usually don't tell my whole CV, and AFAICR I never started a new topic here, so there was no need to tell "Hi my name is Oliver" - which is very obvious, because that's my profile name anyway.

But since you asked I use Qt since Qt 2.2. The rest is "on Google" I only "stranded" here due to some research in the course of discussions on qt-interest.

I've been talking to those people in person since 2006, I've been analysing Qt code and reading Qt articles (I have even written a couple myself) and bug reports.

I never questioned these things!

I'd say I have a "not bad" understanding on how the Trolls think. They tend to provide new APIs to keep the original ones backwards compatible (even if they are not entirely correct) instead of changing the original ones.

The only case I remember of "binary incompatibilty" (yes, you read correct was somewhere between 3.1.x to 3.1.y when they accidentally dropped a default argument. Other "incompatibilites" are of behavioural nature (how things are painted, for instance) and to be honest I cannot think of any significant example right now.

(DISCLAIMER: I have never tried to actually run a "Qt 4.0 application on a Qt 4.7 installation" - but compilationwise that was never a big deal)

So I'd say the Trolls do an excellent job at keeping up compatibilty.

Any location change to QDesktopServices is out of the question as applications expect their files to be found in particular places.

You refer to the patch with regards of the "cache" and "data" locations. I agree, that would definitely break compatibilty, the way the patch would work currently. But that could be easily "worked around" on an application level, by not using QDesktopServices at all (in case of "App Store Apps").

But again, let's focus on the ~/Library/Preferences/com.trolltech.plist issue.

The case with QSettings is more interesting but since applications such as Designer store their configs under the Trolltech domain, changing that location would mean losing all custom configuration of Designer

Again, the patch provides lets the application choose where to expect the global Qt configurations ("bForceTrolltechSettingsToAppArea"), so existing apps would not be affected. And the existing ~/Library/Preferences/trolltech.com.plist would not be removed or touched in any way!

And I think you still seem to confuse the "Qt settings" with the actual application settings such as those from Designer etc.: these applications do not, I repeat, do not store their settings under ~/Library/Preferences/trolltech.com.plist! They go under ~/Library/Preferences/designer.trolltech.com.plist (I assume, am not at my Mac right now - but on Windows they also go under HKEY_CURRENT_USER\Software\Trolltech\Designer).

In other words, if Qt Designer was developed by a company called Elk Software then the Designer settings would go under ~/Library/Preferences/designer.elksoftware.com.plist (which would be fine, from an "App Store point of view"), but the "Qt Settings" would still go under ~/Library/Preferences/trolltech.com.plist - which is bad (probably because domain name does not match with "Elk Software").

I'm sorry to say this but so far you have been stating things without enough research to back up your words.

So far I was the only one providing concrete URLs to both Qt documentation and other discussions such as on stack overflow.

You admitted yourself you didn't look closely at the patches provided

See above: I understand what it does, but not in detail how! Because that is not under discussion.

You obviously didn't know about qt.conf

Except that I just recently packaged that file into my own Qt Mac application, but you could not have known that. And so far you did not provide the concrete setting.

On an application level all you see from this qt.conf file is http://doc.trolltech.com/4.7/qlibraryinfo.html - but all these paths are useless in controlling where to store the com.trolltech.plist file! Unless you show us what setting would affect that location.

yet you claim there is no API to change the location where settings are stored.

Not just me: otherwise other people would not have come up with patches. And unless proven otherwise I still stand to that opinion. I agree that the fact that I did not find it yet does not prove it does not exist. But so far we have not found it!

Very strangely I have been thanked here almost 3k times and you exactly 0 times so far.

That's not very strange: you post on average 14 times a day, since 2006 , including Saturday and Sunday, whereas I just registered during research for a specific topic. I am not a big fan of these "ranks" anyway. I am on qt-interest.

My sincere apoligies for the other mis-understandings!


So as I see it there is still no way to control the location of ~/Library/Preferences/com.trolltech.plist. This file is generated automatically when the Qt application first starts, and cannot be controlled by the application.

A patch was provided which lets the application work around this issue.

Cheers, Oliver

---

Added after 24 minutes:

Cross-reference: http://bugreports.qt.nokia.com/browse/QTBUG-16549

[wysota]

The point here to note is that it is not the application who passes along trolltech.com (to any of the methods of QSettings), that name is hard-coded in the Qt sources,

Which changes what exactly? qt.conf will redirect that as well. You can probably even point Qt to read the configuration from within the resource system in your binary (although I might be wrong here).

and it is the Qt library itself who writes these settings.

From within your program which is totally under your control. Untill you call the constructor of Q(Core)Application, nothing will be written anywhere, I assure you. It is you - by instantiating QCoreApplication - who causes initialization of a couple of things which might cause things like regeneration of the plugin cache which then saves the cache to the location under the Trolltech domain (note it is still called Trolltech and not Nokia although since over two years Trolltech is owned by Nokia - have you thought why?)

And AFAIR the proposed patch exactly "fixes" that location where that name is hardcoded.

The proposed patch looks for a hardcoded string and reacts on it not the other way round.

Probably that would go wrong on Windows where these settings are stored in the registry (in the case where your app writes to *.ini files for instance), under HKEY_CURRENT_USER\Software\Trolltech - that's what I meant I did not look too closely at the patch. I just figured out its intention, not in detail how it solves that.

No, it wouldn't, it only modifies the Mac-related file.

And yes, the implementation is off course not elegant, hence my previous calling it a "workaround".

I would say the implementation is elegant (to a point). But the quality of it doesn't change the fact the meritorical changes as such can't be accepted to Qt. Regardless what code makes it tick. QDesktopServices can't suddenly start pointing elsewhere because it breaks a myriad of other applications. If you need it only for your application then go ahead, patch Qt in whatever way you like, build it and dump it inside your bundle as a private framework. As long as you comply to the licencing scheme, nobody will say a bad word about it. But it simply can't be solved on a global level like this. I can imagine that again qt.conf may be used to change the way this specific setting works to comply with someone's requirements and at the same time provide a fallback to the default behaviour of what we have today. But still the default will be the default and to change it you'd have to use qt.conf. And unless you use qt.conf breaking out of the "happy 'let's use the defaults' approach" as I called it earlier you will still receive a behaviour that you currently call "incorrect". The thing is you can do the same thing today without modifying Qt. That was my point all along.

That's all I wanted to say, I don't want to continue this pointless discussion. If you want to know what (and foremost why) qt.conf does and how it works then spend a while over Qt's source code and documentation and find out yourself if my explanations so far were not clear enough. Just the very first line from the docs:

The qt.conf file overrides the hard-coded paths that are compiled into the Qt library.

[flaviotordini]

I tried to edit the qt.conf in a "bundled" mac app adding a "Settings = path" entry. Qt seems to ignore it and it always creates the dreaded ~/Library/Preferences/com.trolltech.plist. Also my app settings keep on being read from ~/Library/Preferences/com.myapp.plist

The qt.conf file is in my.app/Contents/Resources/qt.conf just like the docs say. http://doc.qt.nokia.com/latest/qt-conf.html

[Oliver Knoll]

Which changes what exactly? qt.conf will redirect that as well.

You still fail in giving a concrete reference.

You can probably even point Qt to read the configuration from within the resource system in your binary

Probably, maybe, supposedly... until you show us either a concrete setting in qt.conf or a Qt API (URLs please!) we simply have to assume that such a possibility does not exist.

From within your program which is totally under your control.

No, no, no, no! Is that so hard to understand?!

1. somewhere in the Qt code com.trolltech is "hardcoded"
2. Qt uses this domain to store its own "Qt settings"
3. The application (until proven otherwise) has NO control over that location

Where in the above 3 points do you not agree? Or what did you not understand? That drives me crazy, honestly! Each time I give you an argument, you simply ignore it, twist it, and later on you come again and state the opposite to what I wrote earlier. We are turning in circles here.

Oh and yes, I'll stop argueing with you, too - For a moment I really thought you would seriously want to engage in a constructive discussion, but it is a waste of time. You just don't seem to want to understand what we are actually discussing here...

Untill you call the constructor of Q(Core)Application, nothing will be written anywhere, I assure you.

Oh, thanks a lot for that assurance: You could have as well suggested not to #include any of the Qt headers, or not write any code at all!

We are talking "Qt desktop applications" here! Not even a simple Qt "Hello World!" would work without instantiating at least QCoreApplication!

So what exactly is your point here!

It is you - by instantiating QCoreApplication - who causes initialization of a couple of things which might cause things like regeneration of the plugin cache which then saves the cache to the location under the Trolltech domain

You don't say! Mine and how many other Qt applications in this world exactly do instantiate at least QCoreApplication?

Are you seriously suggesting to simply avoid instantiating Q(Core)Application in your app and then submit that app to the Mac store? Or what on earth is your point here?!

But I am a bit afraid that would fail because of the following:

2.8 "Apps that are not very useful or do not provide any lasting entertainment value may be rejected"

No seriously, what's your point here? Your argument is ridiculous! WE KNOW THAT INSTANTIATING QCOREAPPLICATION INSTANTIATES QT RESOURCES! (and somewhere along that way reads/writes the Qt Settings) So honestly, what's your point here?!

(note it is still called Trolltech and not Nokia although since over two years Trolltech is owned by Nokia - have you thought why?)

Oh, is that so? Now that changes the whole situation then...

No, it wouldn't, it only modifies the Mac-related file.

Well then... but we are not discussing the implementation of the patch itself anyway.

But the quality of it doesn't change the fact the meritorical changes as such can't be accepted to Qt.

You seem to be very sure of what you say... well, Nokia opened an issue for that, so we will see...

QDesktopServices

Ahhh...! Did we not agree that we focus on the "Qt Settings" aka ~/Library/Preferences/com.trolltech.plist?

How come you argue now with QDesktopSettings?

can't suddenly start pointing elsewhere because it breaks a myriad of other applications.

No one said otherwise! WE KNOW THAT CHANGING THE QDESKTOPSERVICES LOCATIONS (WITHOUT FURTHER PRE-CAUTIONS) BRAKES COMPATIBILTY! Unfortunatelly we are currently NOT talking about QDesktopSettings! We are talking for quite a while now about the "Qt Settings", for God's sake! Don't take arguments from one thing (QDesktopSettings) and apply them to something different (com.trolltech.plist)!

But it simply can't be solved on a global level like this.

It can't be solved on a discussion level with you, agreed. For me the discussion takes place elsewhere now...

I can imagine that again qt.conf may be used to change the way this specific setting works to comply with someone's requirements and at the same time provide a fallback to the default behaviour of what we have today.

So why don't you use your imagination and show us - again - the concrete Qt API and/or qt.conf setting, which you seem to be so sure it exists, and enlighten us? Many Qt developers would be greatly thankful, including me! And again, I am talking about the control of the location of ~/Library/Preferences/com.trolltech.plist - NOTHING ELSE! Is that so hard for you to understand? I mean, it can't get any simpler than that (oh, and just for you, before you quote me wrong again: "that" refers to the fact that it cannot get any simpler, not to this "paragraph" or your "imagination" or any other word of your choice I wrote recently!).

The thing is you can do the same thing today without modifying Qt. That was my point all along.

So please, please, please, why don't you tell us how to control the location of com.trolltech.plist? You seem to know more than Nokia and every other developer on qt-interest, stack overflow and Qt Centre in this respect...

If you want to know what (and foremost why) qt.conf does and how it works then spend a while over Qt's source code and documentation and find out yourself if my explanations so far were not clear enough.

Yes, right, I will forward your suggestion to all developers and to Nokia. Because now it is Totally Clear(tm) what you meant, we just have to "spend a while over Qt's source code and documenation and find out" ourselves.

Just the very first line from the docs:

You seem to have an exeptional talent to only quote what serves your own purpose of argument. Let me complement your quote: "The qt.conf file overrides the hard-coded paths that are compiled into the Qt library." Just the next sentence in the referenced docs sais:

"These paths are accessible using the QLibraryInfo class."

Aha, so what are these paths? Let's follow the link given in the Qt docs:

http://doc.qt.nokia.com/latest/qlibr...yLocation-enum

QLibraryInfo::PrefixPath	0	The default prefix for all paths.
QLibraryInfo::DocumentationPath	1	The location for documentation upon install.
QLibraryInfo::HeadersPath	2	The location for all headers.
...
QLibraryInfo::SettingsPath	8	The location for Qt settings.
....
QLibraryInfo::DemosPath	9	The location for demos upon install.

QLibraryInfo::PrefixPath	0	The default prefix for all paths.
QLibraryInfo::DocumentationPath	1	The location for documentation upon install.
QLibraryInfo::HeadersPath	2	The location for all headers.
...
QLibraryInfo::SettingsPath	8	The location for Qt settings.
....
QLibraryInfo::DemosPath	9	The location for demos upon install.

To copy to clipboard, switch view to plain text mode 

Haleluja! And believe it or not, I already wrote that:

(My own quote from some previous post):

However a quick look at http://doc.trolltech.com/4.7/qt-conf.html did not reveal any possibility to change the location of said com.trolltech.plist.

Why? Because none of these mentioned paths refers to the location of ~/Library/Preferences/com.trolltech.plist! The only candidate member (and I guess that's the one which mis-lead you, but which you did not even care to mention so far in this discussion) would be QLibraryInfo::SettingsPath - which I tested already a few days ago, but that's NOT the desired setting! On Windows it points to (e.g.) C:/Qt/4.7.1.

And going a bit further these FILE paths could not work, not even in principle, because on Windows these settings are in the REGISTRY! So no way these FILE paths could point to that! (I agree on Mac they could, but I am pretty sure on Mac SettingsPath would point somewhere to /Library/Frameworks/Qt/... or the like. But certainly NOT to ~/Library/Preferences/com.trolltech.plist!

#include <QtCore/QLibraryInfo>
#include <QtCore/QCoreApplication>
int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);
 
    QString path = QLibraryInfo::location(QLibraryInfo::SettingsPath);
    qDebug("SettingsPath: %s", qPrintable(path));
    path = QLibraryInfo::location(QLibraryInfo::DataPath);
    qDebug("DataPath: %s", qPrintable(path));
    return 0;
}

#include <QtCore/QLibraryInfo>
#include <QtCore/QCoreApplication>
int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QString path = QLibraryInfo::location(QLibraryInfo::SettingsPath);
    qDebug("SettingsPath: %s", qPrintable(path));
    path = QLibraryInfo::location(QLibraryInfo::DataPath);
    qDebug("DataPath: %s", qPrintable(path));
    return 0;
}

To copy to clipboard, switch view to plain text mode 

<zynism>"Oh, look Mom! What a surprise, we instantiated QCoreApplication! Damn, we could not even submit this to the App Store now...!"</zynism>

The End.
Oliver

[tbscope]

No, no, no, no! Is that so hard to understand?!

1. somewhere in the Qt code com.trolltech is "hardcoded"
2. Qt uses this domain to store its own "Qt settings"
3. The application (until proven otherwise) has NO control over that location

This can easily be verified.
So far, the only things I see with com.trolltech inside the code are interface names and documentation.

Edit:
qconfig sets the path hardcoded (but that's just qconfig)

int main(int argc, char** argv)
{
    QT_USE_NAMESPACE
    QApplication app(argc,argv);
    app.setOrganizationDomain("trolltech.com");

int main(int argc, char** argv)
{
    QT_USE_NAMESPACE
    QApplication app(argc,argv);
    app.setOrganizationDomain("trolltech.com");

To copy to clipboard, switch view to plain text mode 

[wysota]

Probably, maybe, supposedly... until you show us either a concrete setting in qt.conf or a Qt API (URLs please!) we simply have to assume that such a possibility does not exist.

Assume what you want. I don't have a Mac at hand so I can't verify the exact code path on Mac. If you want then write an example to test it.

No, no, no, no! Is that so hard to understand?!

1. somewhere in the Qt code com.trolltech is "hardcoded"
2. Qt uses this domain to store its own "Qt settings"
3. The application (until proven otherwise) has NO control over that location

Where in the above 3 points do you not agree? Or what did you not understand? That drives me crazy, honestly!

There is no magical entity called "Qt" that is roaming over your Mac. It's a library consisting of calls that are performed by the application. So whatever "Qt" stores anywhere, it happens from inside your app. If your application redirects all settings to another place, those magical "Qt settings" will be affected as well.

Each time I give you an argument, you simply ignore it, twist it, and later on you come again and state the opposite to what I wrote earlier. We are turning in circles here.

Please stop giving me arguments and find the place "somewhere in Qt code" where "trolltech.com" is hardcoded. When you do check out when this code is executed. Then start giving arguments.

Oh, thanks a lot for that assurance: You could have as well suggested not to #include any of the Qt headers, or not write any code at all!

We are talking "Qt desktop applications" here! Not even a simple Qt "Hello World!" would work without instantiating at least QCoreApplication!

So what exactly is your point here!

Are you serious? Ok, let me give you an example:

int main(int argc, char **argv) {
  lotsOfStuffHappeningHere();
  QCoreApplication app(argc, argv);
  //...
}

int main(int argc, char **argv) {
  lotsOfStuffHappeningHere();
  QCoreApplication app(argc, argv);
  //...
}

To copy to clipboard, switch view to plain text mode 

The sentence "until you call the constructor of QCoreApplication" means the lotsOfStuffHappeningHere() call. You can do things before any routine in Qt tries to write anything on your disk. But that's not the point. The point is it is your call to QCoreApplication() that may optionally (or may not) possibly write something to your disk (although on my system no such thing takes place). There is no magic happening here.

Are you seriously suggesting to simply avoid instantiating Q(Core)Application in your app and then submit that app to the Mac store?

No, I don't. How did that even come to your mind?

Oh, is that so? Now that changes the whole situation then...

Ok, let me spell this out for you - the "Trolltech" name is used instead of "Nokia" to preserve the behaviour that was originally implemented. Which is an argument in favour of what I said in my earlier posts regarding backward compatibility.

Well then... but we are not discussing the implementation of the patch itself anyway.

It's the second time you claimed to have seen the patch code and the second time you were proved otherwise. So maybe you should read the patch, understand it and then discuss it not the other way round?

You seem to be very sure of what you say... well, Nokia opened an issue for that, so we will see...

It's an automated submisson, not reviewed by a person yet so Nokia did not open anything. The changes to QDesktopServices have to be rejected, it's as simple as that. The changes to QSettings will also be rejected as if such a change is going to be implemented then qt.conf is the natural way to do it. But still qt.conf already allows you to modify the paths in question only not in an extremely flexible manner (meaning you can adjust the root directory for settings, not the individual file names).

Ahhh...! Did we not agree that we focus on the "Qt Settings" aka ~/Library/Preferences/com.trolltech.plist?

No, we didn't.

Many Qt developers would be greatly thankful, including me! And again, [B]I am talking about the control of the location of ~/Library/Preferences/com.trolltech.plist - NOTHING ELSE!

Again, there is nothing special in com.trolltech.plist. You either redirect default path for all the settings or none. If you want your settings to be elsewhere then instantiate QSettings with a path of your choice letting the defaults handle whatever is embedded inside QCoreApplication (although I more and more doubt there is anything there).

You seem to know more than Nokia and every other developer on qt-interest, stack overflow and Qt Centre in this respect...

So exactly how many replies from Nokia did you get that this can't be done currently?

Ok, I just finished grepping Qt's sources. There is nothing using any hardcoded "trolltech.com" domain (or "Trolltech" name), besides qconfig which tbscope already pointed out. So maybe we should ask another question - what exactly is the contents of ~/Library/Preferences/com.trolltech.plist on your system? Backup the directory somewhere else, delete it and run your application (from the commandline, not from QtCreator or anything). Then close it and post the contents of the offending directory, please. Let's see what's in there.


Edit: It seems the native Mac settings format path may not be overriden like that. qt.conf is the proper way to override the paths but it looks like the native Mac format will not be affected. There is an API for this (i.e. either QSettings::setPath() or qt.conf) but for some reason (by design, I guess or simply because Qt may delegate the task to the native API) it is not affecting plist files. However it seems the location of the Mac plist repository location may be dependant on the value of the $HOME environment variable so changing this variable inside your program should point QSettings elsewhere should you need it (then you can revert the value back to its original state). Without knowing what exactly gets stored in the offending directory and what path triggers it, it is not possible to say more.

Edit2: Yes, changing $HOME should work on Mac.

For qt.conf or QSettings::setPath() to work QMSP::fileName() needs to be modified to respect QSettings::getPath(). From the technical point of view there is nothing preventing Qt from doing it.

[wysota]

This can easily be verified.
So far, the only things I see with com.trolltech inside the code are interface names and documentation.

Edit:
qconfig sets the path hardcoded (but that's just qconfig)

int main(int argc, char** argv)
{
    QT_USE_NAMESPACE
    QApplication app(argc,argv);
    app.setOrganizationDomain("trolltech.com");

int main(int argc, char** argv)
{
    QT_USE_NAMESPACE
    QApplication app(argc,argv);
    app.setOrganizationDomain("trolltech.com");

To copy to clipboard, switch view to plain text mode 

I found the call:

src/corelib/plugin/qlibrary.cpp:

#ifndef QT_NO_SETTINGS                                                                                                        
    if (!settings) {                                                                                                          
        settings = libraryData()->settings;                                                                                   
        if (!settings) {                                                                                                      
            settings = new QSettings(QSettings::UserScope, QLatin1String("Trolltech"));                                       
            libraryData()->settings = settings;                                                                               
        }                                                                                                                     
    }                                                                                                                         
    reg = settings->value(regkey).toStringList();                                                                             
#endif

#ifndef QT_NO_SETTINGS                                                                                                        
    if (!settings) {                                                                                                          
        settings = libraryData()->settings;                                                                                   
        if (!settings) {                                                                                                      
            settings = new QSettings(QSettings::UserScope, QLatin1String("Trolltech"));                                       
            libraryData()->settings = settings;                                                                               
        }                                                                                                                     
    }                                                                                                                         
    reg = settings->value(regkey).toStringList();                                                                             
#endif

To copy to clipboard, switch view to plain text mode 

Another one is in qfactoryloader.cpp which then calls QLibrary.

The file gets created when a plugin is first loaded. Which immediately means that if an application doesn't use plugins (it's statically compiled or it simply doesn't use any plugins) the file will probably not be created - the condition is that there are no files available in the plugin location (you can override it with qt.conf) so that QLibrary doesn't try to populate the cache. Furthermore if the file exists in the global location, it will not be created in the user home directory. Furthermore the easiest way to solve the situation is to patch QLibrary (and QFactoryLoader) and not QSettings or to disable creating the plugin/factory cache. Well... actually the easiest way is to compile statically... Then nothing needs to be done.


Anyway, nothing solves the real problem - what happens if the application uses some 3rd party library that stores its own settings using QSettings? The same problem will arise and the only possible solution is to make QSettings::setPath() alter the location of preferences repository on Mac (or use the $HOME hack). The "problem" is not in Qt itself.

[Oliver Knoll]

I found the call:

Unbelievable!

Another one is in qfactoryloader.cpp which then calls QLibrary.

Isn't that amazing!

The file gets created when a plugin is first loaded.

What a break-through! Finally we have an agreement that it really is Qt (and NOT the application itself!) who is responsible for reading/writing "~/Library/Preferences/com.trolltech.plist"! Isn't that amazing!!!

Which immediately means that if an application doesn't use plugins (it's statically compiled or it simply doesn't use any plugins) the file will probably not be created

What an insight!

the condition is that there are no files available in the plugin location

Unfortunatelly that is impractical - we also want to have a solution which works with Qt plugins and dynamic linking. But your self-enlightenment here and development of understanding is amazing! After all these arguments of "nothing to fix", "just use the defaults", "you did not look at the patch!" etc. etc.

(you can override it with qt.conf) so that QLibrary doesn't try to populate the cache.

How? Again, please backup your statements with concrete evidence!

Furthermore if the file exists in the global location, it will not be created in the user home directory.

Okay, here again we have a steep drop-off of understanding the actual problem... Apple does not allow your application to create that file! Not in your HOME directory AND FOR SURE NOT ANYWHERE ELSE! (but we had that before, hence my shouting here)

Furthermore the easiest way to solve the situation is to patch QLibrary (and QFactoryLoader) and not QSettings or to disable creating the plugin/factory cache.

Can I quote you on that and print it out in BIG, BOLD LETTERS that you finally - FINALLY - agreed that some sort of change inside Qt is needed - as being discussed on http://bugreports.qt.nokia.com/browse/QTBUG-16549 - and burn it into the Google cache forever? May I? And you promise that within the course of this discussion you will never ever say different (unless of course we do find a possibility in the current Qt API/configuration, that is)? Thanks so much for that!!!

Well... actually the easiest way is to compile statically... Then nothing needs to be done.

Maybe... except that said file stores more than just the Qt plugin paths, also the "Qt Factory Cache". Besides that still does not help if we want to extend our app with more Qt plugins, or we simply want to link dynamically (for whatever reasons)...

Anyway, nothing solves the real problem - what happens if the application uses some 3rd party library that stores its own settings using QSettings?

That 3rd party software would have to be fixed as well? Because Apple does not allow files stored under differenent "domains"? Easy. Next question!

The same problem will arise and the only possible solution is to make QSettings::setPath() alter the location of preferences repository on Mac (or use the $HOME hack).

"Brillant observation, Watson!"

The "problem" is not in Qt itself.

And a steeeeeep fall-back to the beginning! The learning curve was looking so promisingly! The only remaining problem IS the com.trolltech.plist which (as of now) cannot be solved except by patching Qt! Everything else - like application settings form "3rd party libraries" CAN/MUST be fixed in the way you figured out yourself (in an amazing brainstorming)!

And isn't that amazing how people can so easily contradict themselves within a single post? Let's do it again:

wysota:

Furthermore the easiest way to solve the situation is to patch [any Qt class]

and then just a few lines later:

wysota:

The "problem" is not in Qt itself.

Sorry, but I am at a loss of words here, I cannot follow this "logic"...

[tbscope]

You can build Qt with QT_NO_SETTINGS as the snippet of code shows.

You don't have QSettings anymore, but the problem that the paths are not allowed are fixed.

[Oliver Knoll]

This can easily be verified.
So far, the only things I see with com.trolltech inside the code are interface names and documentation.

The way it works is documented here: http://doc.trolltech.com/4.7/qsettings.html#basic-usage

So given the combination of "organisation name" and "application name" the name of the actual settings file is derived, according to the following platform-specific rules:

http://doc.trolltech.com/4.7/qsettin...ngs-are-stored

On Mac the application can also explicitly specify the "organisation domain" with e.g. QCoreApplication::setOrganizationDomain("mysoft.co m"), which is then taken.

So you wouldn't actually find the literal string "com.trolltech" anywhere in the Qt sources (except in the places you mentioned).

The Qt library itself makes use of the QSettings and not surprisingly the "organisation name" is set to "Trolltech" (the ".com" part is then automatically derived, since not explicitly set with setOrganizationDomain()).

So what the patch of AronR simply does basically is - if the application wants to do so - it catches the case inside the QSettings where the "domain" is "Trolltech", and if so, it simply "re-routes" these settings from/to the "application's own setting file, totally transparent to the caller (the "Qt library" in this case). It is as easy as that.

Off course things have to be discusses such as where to tell the Qt library when to "merge" the "Qt Settings" (store into the same file as) with the actual applications settings (which off course adhere to the Apple file acceptance criteria). A possible place could be qt.conf. Or an additional method in QSettings. Or...

All these things are currently also discussed at http://bugreports.qt.nokia.com/browse/QTBUG-16549

Cheers, Oliver

---

Added after 23 minutes:

You can build Qt with QT_NO_SETTINGS as the snippet of code shows.

You don't have QSettings anymore, but the problem that the paths are not allowed are fixed.

Interesting! But that still would not solve the case where an application actually does need QSettings (for its own settings).

Cheers, Oliver

---

Added after 5 minutes:

Sorry, but I am at a loss of words here, I cannot follow this "logic"...

Ahhh, finally I have the answer, it was all the time in front of my eyes! In wysota's signature, off course!

Your biological and technological distinctiveness will be added to our own. Resistance is futile.

I give up, wysota!



p.s. Sorry, but I had to...!

[wysota]

What a break-through! Finally we have an agreement that it really is Qt (and NOT the application itself!) who is responsible for reading/writing "~/Library/Preferences/com.trolltech.plist"! Isn't that amazing!!!

No, it's the application that causes the file to be written. As I said there is no magical "Qt" entity anywhere. I can configure my application to not write that file by placing it in another place where QSettings will find it or by denying my application rights to write files in a particular location.

Unfortunatelly that is impractical - we also want to have a solution which works with Qt plugins and dynamic linking.

If you deploy Qt as a private framework then in many cases there is no benefit from linking Qt dynamically (or using plugins, actually). If you deploy Qt as a public framework, you can't save its settings in your private space. As for Qt plugins, you can always load them statically. Anyway the $HOME workaround should do the trick in any configuration.

But your self-enlightenment here and development of understanding is amazing! After all these arguments of "nothing to fix", "just use the defaults", "you did not look at the patch!" etc. etc.

Well, the patch doesn't fix the real problem, it's just a temporary workaround for a specific case. And I still say there is nothing to fix in Qt API, the call is there, it just doesn't work in this specific case. For instance it works just fine on my system with using either qt.conf or QSettings::setPath(). Everything I said was true and I'm not backing out from any of it. The real problem is that you can't redirect the place where plist files are stored the same way as you can redirect the place where ini files are stored. The fact whether it is a file written in trolltech.com domain or in any other domain is meaningless.

How? Again, please backup your statements with concrete evidence!

Oh, that's very simple, you add an entry for "Plugins" to qt.conf (change to the library paths in your app should also work) and point it to a directory that doesn't contain any files.

Okay, here again we have a steep drop-off of understanding the actual problem... Apple does not allow your application to create that file! Not in your HOME directory AND FOR SURE NOT ANYWHERE ELSE! (but we had that before, hence my shouting here)

I'm not talking about Apple but about a general case. And I'm sure "not anywhere else" is not true. Besides, the file is not needed, only its representation in memory is. I spent my time and analyzed the code path and I'm sharing my findings now so please don't comment on my every sentence. If this is not something interesting for you then just skip the paragraph. I'm really sick and tired of you now.

Can I quote you on that and print it out in BIG, BOLD LETTERS that you finally - FINALLY - agreed that some sort of change inside Qt is needed

No change in Qt is needed. At least not in the place you'd think. I would say Qt is lacking a define to prevent the plugin cache from being written to a permanent storage and maybe also a switch for Mac to read the cache from within the bundle (or anywhere else actually) in case it is deployed as a private framework. Otherwise if you have more than one application deploying Qt as a private framework they will be overwriting their caches, AppStore or no AppStore. It's no big deal but it defeats the purpose of storing the cache in the first place. A similar thing would be needed on Windows where the cache is forced to the registry. On Unix you can easily override it because qt.conf works as it should. I would suggest adding an entry to qt.conf which if present would override the native storage for the plugin cache with the one specified.

Maybe... except that said file stores more than just the Qt plugin paths, also the "Qt Factory Cache".

It's generated by the same mechanism.

That 3rd party software would have to be fixed as well? Because Apple does not allow files stored under differenent "domains"? Easy.

Well, it's not that easy as you'd think. Say you deploy a library for use with some webservice and this webservice requires an API key, a cache or any other thing that needs to be stored permanently. If you store this API key in a per-application location then you require each application to have a different API key or risk breaking other applications (if registering a new key invalidates any older key). The thing is sharing such things across applications is a proper solution. It is AppStore's (not really Apple per se) policy that is a bit weird here. I can understand why they do this but it is not a good approach. Of course all would be solved if AppStore allowed installing public frameworks that could be shared by different applications which I guess is not the case right now, is it?

And a steeeeeep fall-back to the beginning! The learning curve was looking so promisingly! The only remaining problem IS the com.trolltech.plist which (as of now) cannot be solved except by patching Qt! Everything else - like application settings form "3rd party libraries" CAN/MUST be fixed in the way you figured out yourself (in an amazing brainstorming)!

Well, Qt is a 3rd party library too, Sherlock. It's by no mean different than any other library. And it can be solved, I already told you how, you just keep ignoring it. I don't know whether it is on purpose or not. Especially that "fixing" this little problem will not get your application accepted. As shown in the other thread on AppStore, Qt is incompatible with AppStore's requirements which brings us to the beginning of our civilized discussion where I said that Qt apps can't be accepted to the store because of the sole fact of being Qt apps and you started a flamewar on this. I could write you a myriad of apps using Qt that will be accepted into the store but only because of carefully avoiding all the pitfalls around. It won't make Qt apps acceptible by the site in general.

Sorry, but I am at a loss of words here, I cannot follow this "logic"...

Because you are not trying to. You are just trying to prove me wrong.

You can build Qt with QT_NO_SETTINGS as the snippet of code shows.

You don't have QSettings anymore, but the problem that the paths are not allowed are fixed.

That's not really a good solution. If you are to rebuild Qt, you can comment out one "if" in the source code that will cause the settings to be stored in an ini file instead of the native format and the problem is no longer there. There are other approaches that don't cause any feature loss - see the end of my post.

So you wouldn't actually find the literal string "com.trolltech" anywhere in the Qt sources (except in the places you mentioned).

The Qt library itself makes use of the QSettings and not surprisingly the "organisation name" is set to "Trolltech" (the ".com" part is then automatically derived, since not explicitly set with setOrganizationDomain()).

Yes, it's brilliant when someone does the work for you and then you can wisely nod your head and say "I told you so". But in reality you said yourself "trolltech.com" has to be embedded somewhere in the sources.

Ahhh, finally I have the answer, it was all the time in front of my eyes! In wysota's signature, off course!

Here you go for a possible real solution.

int main(int argc, char **argv){
  QByteArray home = qgetenv("HOME");
  qputenv("HOME", path);
  QApplication app(argc, argv);
  // make sure some Qt plugin gets loaded and then...
  qputenv("HOME", home);
  // and continue your work
  // ...
}

int main(int argc, char **argv){
  QByteArray home = qgetenv("HOME");
  qputenv("HOME", path);
  QApplication app(argc, argv);
  // make sure some Qt plugin gets loaded and then...
  qputenv("HOME", home);
  // and continue your work
  // ...
}

To copy to clipboard, switch view to plain text mode 

Now the question what to put inside "path". My first try would be a directory that doesn't exist. If things don't explode (Qt doesn't exit with some funny message about CFPreferences) that would be the best choice as the cache would simply not be written to disk. If that doesn't work then I'd try a directory you don't have write access to but it's possible the result would be the same. Then my choice (and I think it is the best) would be to pass the application bundle directory (or a directory underneath). This allows you to save the cache inside the bundle and you can even deploy your app with the cache already in place so that Apple doesn't complain that you write inside the bundle (I don't know if you're allowed to do that). Since the list of plugins never changes, the cache will never have to be rewritten and your app will simply be reading it from there. A fallback would be to redirect HOME to a plist repository under your domain so that the settings are stored there but I don't know if Apple might complain as the settings would be written under the Library/Preferences hierarchy. This all will work IF Apple's API for storing preferences does allow to store them in a custom place (and it should, otherwise Qt would not be assembling the path on its own). An alternative approach is to use Linux, it's guaranteed to work

[slimscsi]

WOW, this thread is just painful to read. Lets all stop bitching, and come up with a solution.

I have tried to compile using QT_NO_SETTING, but failed (QSettings object not defined error. go figure)

I also tried to edit the qt.conf file, but that didn't work because the "Trolltech" string is hard coded. So It would appear that a patch to the Qt source is necessary in qtlibrary.cpp and qfactoryloader.cpp (anywhere else?)

Does QTBUG-16549 need to be update to reflect these findings?

AS for the other issues:
~/Application:
I have never saw Qt access this path. Is is a error on the part of the developer and not the SDK?

~/Library/Application Support/<app-identifier>:
According to Apple app-identifier does NOT have to be your bundle id. I quote:
"where <app-identifier> can be your application's bundle identifier, its name, or your company’s name. These strings must match what you provided through iTunes Connect for this application."

[wysota]

I have tried to compile using QT_NO_SETTING, but failed (QSettings object not defined error. go figure)

Did you build your app with QT_NO_SETTINGS (I assume the lacking "S" is just a typo in your post) or did you compile Qt with QT_NO_SETTINGS? You need to do the latter and then build your app.

I also tried to edit the qt.conf file, but that didn't work because the "Trolltech" string is hard coded.

The fact that Trolltech is hardcoded is irrelevant here. The relevant part is that the native Mac storage is not affected by qt.conf.

So It would appear that a patch to the Qt source is necessary in qtlibrary.cpp and qfactoryloader.cpp (anywhere else?)

Try my solution with $HOME, it should work.

[slimscsi]

Did you build your app with QT_NO_SETTINGS (I assume the lacking "S" is just a typo in your post) or did you compile Qt with QT_NO_SETTINGS? You need to do the latter and then build your app.


The fact that Trolltech is hardcoded is irrelevant here. The relevant part is that the native Mac storage is not affected by qt.conf.


Try my solution with $HOME, it should work.

Yes, I did try to recompile Qt itself with -DQT_NO_SETTINGS

io/qsettings_p.h:190: error: ISO C++ forbids declaration of ‘QSettings’ with no type

io/qsettings_p.h:190: error: ISO C++ forbids declaration of ‘QSettings’ with no type

To copy to clipboard, switch view to plain text mode 

As this is not a great solution anyway. I'm not going to dig any further.

[wysota]

You must have done it wrong. io/qsettings_p.h shouldn't be included at all. Did you use qconfig to generate a proper configuration file? Or did you modify qfeatures.h by hand? It seems to be building fine for me... QtCore just finished building.

[AronR]

Let me provide a little more detail.

1. The QDesktopServices patch - I did this because my companies name gets localized in some locales. Within the App Store, Apple does not support this and because QDesktopServices uses QCoreApplication::companyName() and applicationName() to build the path, in several languages it was causing a directory to be created that did not match the "Company Name" in Apple's iTunesConnect / App Store setup. That is against the rules. That patch breaks compatibility since it moved the data and cache location. I was a little lazy to not make it a global function (which it should be for proper acceptance). I would think that most people do NOT need this patch since they don't have legal entities in multiple countries under different operating names.

2. The QSettings patch: As written, only effects Mac QSettings and ONLY does something if your app explicitly calls the function before making your QApplication / QCoreApplication object. There is no other way to workaround this. qt.conf changes don't work. As others pointed out, this behavior fixes the hardcoded QSettings object found in:
QFactoryLoader
QLibrary
QColorDialog
QFileDialog
TCP Local Server
QScriptEngineDebugger
PostScript print engine
QApplication Mac internal

[slimscsi]

You must have done it wrong. io/qsettings_p.h shouldn't be included at all. Did you use qconfig to generate a proper configuration file? Or did you modify qfeatures.h by hand? It seems to be building fine for me... QtCore just finished building.

I was using ./configure and modifying mkspecs/common/mac-g++.conf to include -DQT_NO_SETTINGS.
Is there a better way?

./configiure -DQT_NO_SETTINGS did not seem to work eaither

[Oliver Knoll]

The fact whether it is a file written in trolltech.com domain or in any other domain is meaningless.

Let me just comment this very statement from you which

a) just contradicts what you said before (in the same posting, notably), that there is no file being created by Qt and

b) demonstrates that you still have no idea what the actual problem is:

The fact that Qt generates a file called trolltech.com is exactly the problem!


I sincerely apologize for my tone in this discussion, for tearing your arguments apart in a very zynical way. I am sorry for that.

Cheers, Oliver

---

Added after 27 minutes:

WOW, this thread is just painful to read. Lets all stop bitching, and come up with a solution.

Yes, totally agreed! Again I apologize here for polluting this thread, but otherwise I would have to cut my hands off as not to reply to these unbelievable statements given earlier...

I have tried to compile using QT_NO_SETTING, but failed (QSettings object not defined error. go figure)

Even if that worked it would mean that your own app couln't write settings either.

I also tried to edit the qt.conf file, but that didn't work because the "Trolltech" string is hard coded. So It would appear that a patch to the Qt source is necessary in qtlibrary.cpp and qfactoryloader.cpp (anywhere else?)

Right. qt.conf has no effect on the Qt's own QSettings file. It specifies where to look for "Qt directories" such as plugins.

Does QTBUG-16549 need to be update to reflect these findings?

I already did post some findings there, including an example application which shows all relevant Qt paths from QDesktopServices, QSettings (but only those paths relevant for the application settings, not the "Qt settings") and QLibraryInfo (the later reflecting the paths as set in qt.conf).

AS for the other issues:
~/Application:
I have never saw Qt access this path. Is is a error on the part of the developer and not the SDK?

Very much likely

~/Library/Application Support/<app-identifier>:
According to Apple app-identifier does NOT have to be your bundle id. I quote:
"where <app-identifier> can be your application's bundle identifier, its name, or your company’s name. These strings must match what you provided through iTunes Connect for this application."

Correct, as AronR already mentioned: the best way for the fix of Qt would be that in case of Mac the application identifier inside the Info.plist (CFBundleIdentifier) would be used to generate the proper "application settings" *.plist file. The content of the current com.trolltech.plist would simply go into that same file (as requested by the application by some setting/flag/method call/whatever).

---

Added after 44 minutes:

On Unix you can easily override it because qt.conf works as it should.

Just as other people don't get a wrong understanding of qt.conf this statement needs to be corrected here: again, qt.conf has no influence on where/if the "Qt settings" are stored. That is on any desktop platform, also on Linux/Unix! So the statement here is simply wrong.

Qt Settings (plugin cache and other "global" data) are currently stored at:

- Mac: ~/Library/Preferences/com.trolltech.plist
- Unix/Linux: ~/.config/Trolltech.conf
- Windows: Registry key HKEY_CURRENT_USER\Software\Trolltech\OrganizationD efaults

On neither platform exists currently a way to control the location of these files/registry entries by any Qt means, except (in theory) re-compiling Qt without QSettings support. That works if the Qt app does not need to store its own settings (via QSettings). Trying hacks as setting $HOME env variable temporarily to a non-existing folder might work as well.

A proper solution has been started here: http://bugreports.qt.nokia.com/browse/QTBUG-16549 which also features an example Qt application which lists all the paths controlled by qt.conf (among other more or less relevant paths which might play a role when it comes to Apple App Store acceptance testing). The "Qt settings" paths above are not available via QLibraryInfo, which directly reflects the settings as done in qt.conf!

I would suggest adding an entry to qt.conf which if present would override the native storage for the plugin cache with the one specified.

Oh, what a coincidence! That's exactly the same suggestion I already gave elsewhere a few days ago: http://permalink.gmane.org/gmane.com....general/38317

[dhjdhj]

It's a pity that Nokia and Apple can't have a civilized conversation about temporarily allowing Qt apps to write into ~Library/Preferences .... it's not like it's an unreasonable location for preferences, applications have been doing it for years. But I guess Apple doesn't owe Nokia anything.

At this point, there is so much "noise" in this thread that I can't figure out EXACTLY what I'm supposed to do to prevent the error from occuring in my app (which was also recently rejected from the App store for this very reason).

[wysota]

Just as other people don't get a wrong understanding of qt.conf this statement needs to be corrected here: again, qt.conf has no influence on where/if the "Qt settings" are stored. That is on any desktop platform, also on Linux/Unix! So the statement here is simply wrong.

Qt Settings (plugin cache and other "global" data) are currently stored at:

- Mac: ~/Library/Preferences/com.trolltech.plist
- Unix/Linux: ~/.config/Trolltech.conf
- Windows: Registry key HKEY_CURRENT_USER\Software\Trolltech\OrganizationD efaults

On neither platform exists currently a way to control the location of these files/registry entries by any Qt means,

Well, maybe you can't do it. It works pretty well for me. I can move my ~/.config/Trolltech.conf file to a directory pointed by qt.conf and Qt will happily use it.