Qt Apps banned from Mac App Store?

[jfk]

Steve Jobs has recently unveiled his new Mac App Store including a list of restrictions.

Especially jarring are restrictions such as:


Apps that use non-public APIs will be rejected.
Apps must be packaged and submitted using Apple’s packaging technologies included in Xcode – no third party installers allowed
Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected
Apps that change the native user interface elements or behaviors of Mac OS X will be rejected


The full list of restrictions can be found at cultofmac (http://www.cultofmac.com/apples-mac-app-store-approval-guidelines/65022).

Does this affect Qt (C++) software?

[wysota]

Yes, it does.

[jfk]

Does that mean Qt 'Apps' are completely out of the question? Where has Apple drawn the line? After all they distribute Python and Ruby with their Operating System. Surely Objective-C can't be the only guest to the new App Store!

[wysota]

Does that mean Qt 'Apps' are completely out of the question?
Officially, yes.

[squidge]

It's probably more like: Apps that look like standard Mac applications & behave like standard Mac applications will be accepted. All others will be rejected.

So Qt applications will be permitted as long as your careful, but they really want you to create native applications using Cocoa so they can ensure to keep control of the look and feel of applications for their platform (eg. if too many people switch to Qt, people ignore the Apple API and Apple lose control of their own platform, so they keep it on a tight leash)

[wysota]

It's probably more like: Apps that look like standard Mac applications & behave like standard Mac applications will be accepted.
Qt is an "optional library", if at all you can install it through App Store. I doubt they will accept any application that depends on a library you can't install through App Store. Of course when speaking about desktop Macs. For iPhone there is no official Qt port anyway.

[jfk]

It's probably more like: Apps that look like standard Mac applications & behave like standard Mac applications will be accepted. All others will be rejected.

That's what I'm hoping for! On the other hand, I'm already worrying that my App-to be gets rejected according to:
Apps which appear confusingly similar to an existing Apple product will be rejected. In any case I'll give it a shot!

[SixDegrees]

Also, Apple is a notorious for closed systems. Apart from keeping control of the look and feel, this also allows Apple to charge inflated prices for the "official" development toolkit, charge high annual fees for developer "licenses" and otherwise squeeze cash out of their customer base in every way possible.

[jfk]

Also, Apple is a notorious for closed systems. Apart from keeping control of the look and feel, this also allows Apple to charge inflated prices for the "official" development toolkit, charge high annual fees for developer "licenses" and otherwise squeeze cash out of their customer base in every way possible.

True. If they want to reject an App they will - wether it complies with the App Store Guidelines or not.

The dilemma is this: If an indie software developer wants an entry to the market placement in an App Store is almost a necessity.

[SixDegrees]

I'm developing an interest in tablet computing. I may pick up a cheap tablet just to goof around with. If and when I develop apps for it (Apple is attempting, by the way, to copyright the word 'app', another example of massive overreach) it won't be for any Apple products. I have issues with Google as well, but Android is a developer's dream come true - free, well supported by a huge community, and spreading like wildfire.

[ChrisW67]

For the Mac there's nothing stopping you distributing the Qt-based application yourself. As an added bonus you get to keep the 30% Apple tax. Of course, if Apple try to make the App store the only distribution channel for applications on the Mac then that's a different proposition.

I am routinely asked when the iPhone/iPad (and soon Android) versions of my products are due. Notice the absolute assumption that there will be a iPhone/iPad/Android versions.. like it is some deity-given right and as easy as flicking a switch. It is a shame that Qt cannot get me to those platforms.
Some of the Apple store restrictions are also potential show stoppers for me:

Apps that are “beta”, “demo”, “trial”, or “test” versions will be rejected. Would you buy an app for more than a few tens of dollars sight unseen?
Apps containing “rental” content or services that expire after a limited time will be rejected. My app would depend on periodic updates of the data contained within but this is not a free exercise for me. Apple wants you to sell the application over again in order to collect another 30%. To make this work I need to drastically drop the application price thereby devaluing the product on other platforms.
Apps may not use update mechanisms outside of the App Store
Apps that present a license screen at launch will be rejected

[d_stranz]

If Steve were 200 lbs heavier, he could take off his shoe, pound it on the podium, and scream "We will bury you!" at the next press conference. He apparently doesn't read history, at least not the histories associated with other centrally-controlled, dogmatic dictatorial enterprises like the (former) Soviet Union.

The Apple Store restrictions sound to me like an excellent way to reduce your market share in deference to the more open models of other mobile OS platforms.

[wysota]

Well, so far they are successful so it seems the approach was a correct one from a business point of view. They can always change their rules should some other scheme become popular enough.

[serkol]

Qt is an "optional library", if at all you can install it through App Store.

Do you really have to "install" Qt? It does not have to be "installed". Qt is just several files inside your application bundle.

By the way, is it possible to compile a Qt-based application for Mac OS X in such way, that the application file contains all necessary parts of Qt? I'm new to Qt (I'm finishing my first app, targeted to Windows and Mac OS X).

[wysota]

Do you really have to "install" Qt? It does not have to be "installed". Qt is just several files inside your application bundle.
So if you have 10 Qt-based applications you get those "several files" ten times each, right? I know disk space is cheap but is it really a good approach?


By the way, is it possible to compile a Qt-based application for Mac OS X in such way, that the application file contains all necessary parts of Qt? I'm new to Qt (I'm finishing my first app, targeted to Windows and Mac OS X).
Yes, you can compile it statically which makes your application really huge.

[SixDegrees]

Yes, you can compile it statically which makes your application really huge.

Also, you open yourself up to additional licensing issues when you create static builds. The GPL and many of it's variants consider your application to be derivative when statically linked, but not when it is linked dynamically. In general, when you statically link another library you are actively bundling and using it from a legal standpoint, and not simply taking advantage of an existing environment. You run a much higher risk of losing control over your own source code when you statically link, especially with large, complex external libraries whose dependencies may be difficult to discern.

[john_god]

Bought myself one mac some months ago, thinking in giving a shot at iphone development. I'm somewhat disappointed with the xcode tools developer, it doesn't have c++ and compared to Qt, seems like I walking backwards. I really enjoy Qt development, and besides with new technologies there's always a learning curve one has to cross. So for now, I will postpone my i-phone development and keep on playing with Qt. Apple, being the major app store player in the market, for now can afford all the restrictions. Nokia just recently released the ovi store, android market is running wild, so let's see what the future will bring, if with all the competition Apple will keep their restriction policie.

[serkol]

I keep programming my first Qt app (Mac/Win). I try to make the Mac version look as much "native" as possible.

I've came across 2 Qt/Mac bugs that bother me. If they bother you too, could you possible vote for my bug reports, so that they are fixed sooner?

http://bugreports.qt.nokia.com/browse/QTBUG-15474
http://bugreports.qt.nokia.com/browse/QTBUG-15475

[wysota]

And how is this related to the discussion in this thread?

[serkol]

It is related. I don't see any technical reasons for Apple to reject a Qt app that includes Qt framework inside the bundle, UNLESS the app does not look like a native Mac OS X app - breaks the GUI guidelines. One of the 2 bugs - modal dialog that permanently loses its focus - is definitely one of those bugs that can be a reason for Apple to reject a Qt app.

[koan]

So if you have 10 Qt-based applications you get those "several files" ten times each, right? I know disk space is cheap but is it really a good approach?

This is the Mac way; applications are packaged in bundles. It avoids DLL hell but at a cost in disk space. At least you know that installing a new application won't mean updating a library to a version incompatible with another app.

Please see http://doc.qt.nokia.com/4.7/deployment.html


Also, you open yourself up to additional licensing issues when you create static builds.

You dynamically link to the QT libs and include them in the bundle; GPL/LGPL satisfied. However, the Mac store may place other restrictions on top that are not compatible with copyleft licensing, re: http://www.theregister.co.uk/2010/05/27/gnu_go_fsf_apple_itunes/

[wysota]

This is the Mac way; applications are packaged in bundles. It avoids DLL hell but at a cost in disk space. At least you know that installing a new application won't mean updating a library to a version incompatible with another app.
I'm not sure you are right. There is also a concept of "frameworks" and as far as I understand it that's what Qt is.


You dynamically link to the QT libs and include them in the bundle; GPL/LGPL satisfied.
No, you are wrong. GPL will certainly not be satisfied with that. But since SixDegrees meant static builds I don't see how your opinion on dynamic builds is relevant here :)

[koan]

I'm not sure you are right. There is also a concept of "frameworks" and as far as I understand it that's what Qt is.

Frameworks are like libraries and they can be packaged up in the application bundle. Thanks for casting doubt on my answer.


No, you are wrong. GPL will certainly not be satisfied with that. But since SixDegrees meant static builds I don't see how your opinion on dynamic builds is relevant here :)

I meant to say LGPL would be satisfied up to this point, but as I said the other restrictions would probably invalidate this and the possibility to try GPL. Since dynamic builds would have been feasible had this not been the case then there would have been no need to be worried about static builds.

[Oliver Knoll]

Please also have a look at http://stackoverflow.com/questions/4337855/qt-applications-on-new-mac-app-store/4624284#4624284

A similar discussion is going on there.

And yes, whether Qt Apps really behave like "native Mac apps" is relevant as well, even though posting individual bug reports here is maybe really the wrong place (even though I voted on them ;)

For instance, if Qt creates ~/Library/Preferences/com.trolltech.plist files which might be on the wrong place (in the above link I rather suspect the file path ~/Applications/APPname.app/Contents/Resources/databasename.sqlite, since ~/Applications is not a standard location) then this is an issue and should be fixed by Nokia.

Also if the Apple guidelines require "sheet" dialogs instead of modal dialogs (and I honestly don't know the detailed Apple requirements - yet ;) and those are buggy and that would be a reason for Apple to reject the app... well then, let's hope it gets fixed as soon as possible!

But that said: these are issues which are relatively easy to fix (file paths, dialog focus issues...).

But the good news is that according to Stack Overflow the app in question did not get rejected (yet?) because it was using Qt per se!

[wysota]

For instance, if Qt creates ~/Library/Preferences/com.trolltech.plist files which might be on the wrong place (in the above link I rather suspect the file path ~/Applications/APPname.app/Contents/Resources/databasename.sqlite, since ~/Applications is not a standard location) then this is an issue and should be fixed by Nokia.
You can place your settings wherever you want, nothing needs to be "fixed" for this.


Also if the Apple guidelines require "sheet" dialogs instead of modal dialogs (and I honestly don't know the detailed Apple requirements - yet ;) and those are buggy and that would be a reason for Apple to reject the app... well then, let's hope it gets fixed as soon as possible!
Sheets are available in Qt for ages now so no fix needed here as well. People just need to use them.

[Oliver Knoll]

@wysota: Off course can paths be fixed! The question is by whom, the application itself or Qt. I have never used the mySQL lite in Qt, but since the mentioned path is related to that DB the question is justified whether it is the DB writing that file by itself, or whether the app has control over that location!

As for the "sheets": Did you understand to what my comment relates? The topic was that sheets are buggy and someone said that this does not belong here, and I backed up another opinion that it really does, as this might influence Apple's acceptance testing! And that is what this thread is all about? Did you not read the previous posts? Did you not understand the context of this discussion?

Cheers

[wysota]

@wysota: Off course can paths be fixed! The question is by whom, the application itself or Qt. I have never used the mySQL lite in Qt, but since the mentioned path is related to that DB the question is justified whether it is the DB writing that file by itself, or whether the app has control over that location!
By the application, of course. If Qt was upgraded just like that, it would break all the existing applications that previously saved the database in the default place.


As for the "sheets": Did you understand to what my comment relates?
Maybe I didn't because there is a missing closing bracket in your post and the place where you put the bracket changes the meaning of your whole sentence completely.


And that is what this thread is all about?
About sheets? Not really :)


Did you not read the previous posts? Did you not understand the context of this discussion?
Bearing the fact that I particiapated in this discussion from the very beginning you should probably answer your question yourself.

[AronR]

So we submitted a Qt based app to the App Store and had it rejected for the following reasons:

- Improperly named files in ~/Library/Application Support/*
- File created at ~/Library/Preferences/com.trolltech.plist

The first was a result of using QDesktopServices::storageLocation() for QDesktopServices::dataLocation or QDesktopServices::cacheLocation

They need you to create the directory not like
~/Library/Application Support/Company Name/Product Name

but as

~/Library/Application Support/bundleId (com.company.App)
The following patch will change Qt to use the QCoreApplication::organizationDomain() and QCoreApplication::applicationName() fields to build the path to store for data and cache. This is ONLY valid if you bundle Id exactly matches the above values
5728


The following patch will add an exported function called void qt_force_trolltech_settings_to_app_area(bool bVal) which you must call FIRST thing in your main function. To access declare an extern to it for proper linking. This will put all items found formally in com.trolltech.plist as a group "Trolltech" inside the default plist file for your app (See above patch about domain and name for proper bundle id usage).
5727

[Oliver Knoll]

So we submitted a Qt based app to the App Store and had it rejected for the following reasons: [...]

They need you to create the directory not like
~/Library/Application Support/Company Name/Product Name

but as

~/Library/Application Support/bundleId (com.company.App)


Now that was a really informative post on that subject, thanks for sharing even the patches.

One question though: did you in any form contact/inform Nokia about this, e.g. as a "Suggestion" at http://bugreports.qt.nokia.com/?

I haven't studied your patches in detail yet, but I think there should be a Qt API which lets the application control where the Qt configuration is stored, and how the own application settings are called.

From what I understand from your post is that currently one has to patch the Qt sources, as to make certain functions visible, is that right?

Thanks for sharing!
Oliver

[wysota]

One question though: did you in any form contact/inform Nokia about this, e.g. as a "Suggestion" at http://bugreports.qt.nokia.com/?
They won't include it. It would break compatibility with existing apps. Since this is something the application developer is fully in control of there is no point in modifying Qt. You just have to go past the happy "hey, let's use the defaults" approach.


I haven't studied your patches in detail yet, but I think there should be a Qt API which lets the application control where the Qt configuration is stored, and how the own application settings are called.
There is. Have a look at available constructors for QSettings.

[Oliver Knoll]

@wysota, could you please stop replying to my posts please, thank you! You have proven several times that you did not understand the issues/topics being discussed, what you write is often simply wrong or proves otherwise your ignorance and need of self-portraying here! Let me give you a few examples of what I mean:


They won't include it. It would break compatibility with existing apps.


That's absolutely not true and may be due to your lack of understanding what binary compatibility means! Adding methods never breaks binary compatibility! Why do you think that the currrent Qt 4.7 is still binary compatible with Qt 4.0? I mean, you did notice that methods have been added since then, now do you?

And just for you, clear-text: No one here was talking to include the patches as-is into the current Qt source code, neither did I suggest to apply those patches! Read again: I suggested to contact Nokia, as to make them aware of the current problematic, that Qt writes a configruation file of its own - and just for you again: ~/Library/Preferences/com.trolltech.plist - and that is a problem when it comes to acceptance testing by Apple! Believe it or not, that is a fact, as just shown to us by AronR. Yes, please, go and read the post again if necessary!


Since this is something the application developer is fully in control of there is no point in modifying Qt. You just have to go past the happy "hey, let's use the defaults" approach.


Wrong again! We are talking about the Qt configuration file which is generated by Qt, not by the application. Why can't you just read and understand what people write here in the forum? And please stop with your arrogant comments like "You just have to go past the happy ... approach", no one wants to read that! And it is simply embarassing, as you just have shown that you again did not understand what it was all about, by the following:



There is. Have a look at available constructors for QSettings.

See what I mean? We are not talking - I repeat extra for you - not talking about QSettings! We are talking about the ~/Library/Preferences/com.trolltech.plist. And the current Qt API does not provide a way to control the location, as just shown by AronR.

Okay, since this is my last reply for you anyway, let's have a look at a few other posts from you:

Question: "[List of restrictions given] Does this affect Qt (C++) software?"

You: "Yes it does"

Wow, how helpful was that! But at least the answer is not wrong at this point.

Question: "Does that mean Qt 'Apps' are completely out of the question?"

You: "Officially, yes."

How the heck would you know at that point (note: before the store actually opened or anyone submitted a Qt app)? By now reality has shown that you were simply plain wrong, since it seems that Qt apps per se are allowed (there are a few glitches with files, but nothing serious). But again: Qt per se is not restricted - at least as far as we know so far!

Statement: "It's probably more like: Apps that look like standard Mac applications & behave like standard Mac applications will be accepted. ..."

You: "Qt is an "optional library", if at all you can install it through App Store. I doubt they will accept any application that depends on a library you can't install through App Store."

Now this post clearly shows that you have apparently no clue about how applications on Mac are deployed, namely that they provide all Frameworks/libraries themselves in the so-called App Bundle. So your doubt is absolutely unjustified here, since it totally does not matter whether a user could download an "optional Qt library" or not. The app simply provides it, point!

Correction by serkol: "Do you really have to "install" Qt? It does not have to be "installed". Qt is just several files inside your application bundle."

Your reply: "So if you have 10 Qt-based applications you get those "several files" ten times each, right? I know disk space is cheap but is it really a good approach?"

Again that definitively shows that you have no clue about app deployment on a Mac! Yes, disk space is wasted! Yes, every Qt app would ship along their own set of Qt libraries (by the way, like this it is also made sure that an application does not accidentally overwrite a newer Qt library installation, see "DLL hell" on Windows).

By the way also on Windows you have the same situation. The only OS where this is different is Linux, since there you have a proper package manager which installs Qt as well as a depenedency.

But just for you: Mac apps ship all their dependencies which are not by default on a Mac OS installation in their bundle. That is the way it is, has been and will be! If you did not know that... now you know!

You can complain about wasted disk space with Apple, if you feel like.

You: "Yes, you can compile it statically which makes your application really huge."

Again simply wrong, given the alternative that the application ships the Qt libraries inside the bundle (dynamically linked). The static build will at max be as large as the dynamic build, but in practise much smaller, since only the *.o files which are really needed are linked into the static application! And that size is often < size(your app + all required shared libraries).

(You are right under the assumption however that there would be exactly one Qt installation in the OS - but we have already learnt above that in the case of Mac this is not the case. And this thread is about the Mac).

Statement: "I've came across 2 Qt/Mac bugs that bother me." + Qt issue tracker links given. One of the issue is about "sheets"

You: "And how is this related to the discussion in this thread?"

Well, somewhat justified question. Posting issue URLs and ask people to vote for them is maybe not appropriate in this forum. But given the fact that we talk about "Qt acceptance" and these issues are Mac related these issues do have some relevance here in this discussion.

Opinion to your statement: "It is related. [...] - is definitely one of those bugs that can be a reason for Apple to reject a Qt app."

Correction to one of your previous statements regarding "disk space": "This is the Mac way; applications are packaged in bundles..."

You: "I'm not sure you are right. There is also a concept of "frameworks" and as far as I understand it that's what Qt is."

At least here you show that you are actually quite uncertain what "a framework actually is". Well, that is not bad, you can always learn. I am not going to repeat what other people have told you so far. But it gets better:

Statement: "You dynamically link to the QT libs and include them in the bundle; GPL/LGPL satisfied."

You: "No, you are wrong. GPL will certainly not be satisfied with that."

Now you are actually wrong here (again)! Whether you link against the Framework under /Library/Frameworks/Qt... or place that Framwork inside your own App Bundle still makes your application link dynamically against Qt! But you have proven previously that you did not understand of app deployment on Macs, so you are somewhat excused here with your ignorance...

Me: "For instance, if Qt creates ~/Library/Preferences/com.trolltech.plist ..."

You: "You can place your settings wherever you want, nothing needs to be "fixed" for this."

Again you are wrong: We are not talking about application settings. We are talking about the file being created by Qt, so call it "Qt settings" if you wish. I am not saying that there is currently no way in the Qt API to control that place, but you did not give any URL to doc.trolltech.com, and I doubt there is any such API!

You: "Sheets are available in Qt for ages now so no fix needed here as well. People just need to use them."

Now this shows both your misunderstanding of the previous discussion - as already pointed out by me - and it proves again your arrogance ("People just need to use them."). Fact: "Sheets are somewhat broken", an URL to a Qt issue (!) had been provided. So how come you saying "no fix needed here"? But it seems you do not understand written text so well, since you argue "sheets are available in Qt for ages". So? How is that related to the fact that there is a bug in the implementation? Who are you to say "People just need to use them"?

This was the point where I really had to tell you "Hey, please read - and understand - what other people say before giving bold statements!"

The fact that later on you quoted me incompletely and the fact that you freak out because of a missing ("because there is a missing closing bracket in your post and the place where you put the bracket changes the meaning of your whole sentence completely") is simply ridiculous (by the way, just for you: the closing bracket was there - it just was part of a ;) smiley which gets converted into a real smiley - that is the way I close brackets and a ;) at the same time - sorry if that confused you so much.

Thank God that English language (just as any other language) is higly redundant and most people's brain has a very good error detection and correction mechanism. That works for 99.9999999437% of all people on this planet. Count yourself as part of the other group...


Thanks for understanding,

Oliver

[wysota]

That's absolutely not true and may be due to your lack of understanding what binary compatibility means!
Did you see me use the word "binary" anywhere? If an application writes all its settings in place X and then you upgrade Qt and suddenly the same application tries to read those same settings from place Y (and of course fails) then in my world this breaks backwards compatibility. Unless of course it's ok for you to for example lose access to all your emails or photos without prior notice. I didn't say a word abour *binary* compatibility.

Qt can't be upgraded to change the location automatically because lots of already existing applications would be broken. It is solely the reponsibility of the author of an application that wants to be accepted by *any* store/site/whatever to be compliant with this store/site/whatever's requirements and it can be done without breaking all other existing applications. The problem you describe is nothing new and not only related to Macs. But changing this behaviour in Qt4 on a global level simply can't be done because of the reason I mentioned. If the settings storage is really the only thing preventing Qt apps from being accepted by Apple (which I doubt is the case) then there is no problem in adjusting the path where this particular application stores its settings as it is fully in control of the developer.


Wrong again! We are talking about the Qt configuration file which is generated by Qt, not by the application.
The settings you mention can be fully controlled by a file called qt.conf which is scanned for by Qt in several places including the resource system, the Resource directory inside the application bundle (on Mac) and the application directory. This file controls default locations for things such as libraries, plugins, imports and settings. Since both patches posted by AronR modify the way QSettings work (edit: sorry, one deals with QDesktopServices and one with QSettings) so both (edit: probably just one, the other can be fixed by not using QDesktopServices, it seems qt.conf doesn't allow to change the cache location, at least docs don't mention it) cases should be fixed with qt.conf (the only "special" thing about the patch is it deals with organization name called "Trolltech"). Plus you don't need any persistent configuration files for any of the Qt-bundled applications to deploy your own application with settings and all. At least in most cases (I can see some plugin configs are stuffed in there).


We are not talking - I repeat extra for you - not talking about QSettings! We are talking about the ~/Library/Preferences/com.trolltech.plist.
So how exactly do the patches posted fix this? They deal with QSettings and QDesktopServices, you know :)

I will skip answering the rest of your highly cultural post.

[pheonixstorm]

I'm developing an interest in tablet computing. I may pick up a cheap tablet just to goof around with. If and when I develop apps for it (Apple is attempting, by the way, to copyright the word 'app', another example of massive overreach) it won't be for any Apple products. I have issues with Google as well, but Android is a developer's dream come true - free, well supported by a huge community, and spreading like wildfire.

Microsoft has a patent on the page up/down key now... http://www.tomshardware.com/news/microsoft-keyboard-patent,6307.html so a copyright on the word app is not as stupid as one would think. At least they don't want to patent it :rolleyes:

[wysota]

I don't think you can patent a word. A copyright on the word App does make sense. Remember it doesn't apply to a common meaning/use of the word, only to names, titles and such. Just like Sony has a copyright on the name of Walkman (I don't know how it is in your countries but in Poland we used to refer to every personal cassette player as a walkman).

[squidge]

Your right, you can't patent a word. You can only patent an idea. So Microsoft didn't patent the page up/page down keys, they patented the idea (the function) of those keys. However, if anyone can prove that function was used in public before the patent was filed, it can easily be thrown out by any challenger.

A copyright on the word 'App' doesn't make sense, but making it a 'Trademark' does.

[pheonixstorm]

I don't think you can patent a word. From my (limited) understanding of trademark and copyright laws phrases and words can have an associated copyright/trademark if its original. So when the walkman first came out I can see how the term walkman could have be filed as a copyright/trademark though the term can now no longer hold up in court as anything that looks like a sony walkman is now refered to as a walkman even if it isn't. The term has become too widespread and overused to descibe any portable cassete or cd player. As for the idea of creating a copyright over the term App, even as a trademark I don't think apple has a snowballs chance in hell of pulling it off. The phrase is too widespread and has been for a long time since it is a short hand version of application (unless apple can create some new meaning for the word that falls outside the widely used and commonly accepted meaning.

[wysota]

So Microsoft didn't patent the page up/page down keys, they patented the idea (the function) of those keys.
In the patent there is a math formula for calculating the offsets. I think that's the core of the patent. You can probably modify the formula slightly and workaround the patent.

[Oliver Knoll]

Did you see me use the word "binary" anywhere?

Ok, sorry, my wrong.


If an application writes all its settings in place X and then you upgrade Qt and suddenly the same application tries to read those same settings from place Y (and of course fails) then in my world this breaks backwards compatibility.

Unfortunatelly your conclusion is again wrong here: If you had understood the idea of the provided patch you would have noticed that "Qt does not suddenly write its config file to place Y"!

The idea of the patch is that an application can deliberately decide that the Qt configuration is to be written into the application settings file. And again, please notice the distinction between "Qt settings" aka ~/Library/Preferences/com.trolltech.plist and application settings.


Qt can't be upgraded to change the location automatically because lots of already existing applications would be broken.

Again, please read and understand the original proposition of the patch: nowhere it sais that these changes are automatic! The idea is that an additional method in the Qt API would be provided and the application could control where the (content of) com.trolltech.plist would be written.


It is solely the reponsibility of the author of an application that wants to be accepted by *any* store/site/whatever to be compliant with this store/site/whatever's requirements and it can be done without breaking all other existing applications.

Correct. However - for whatever reasons - you seem to wilfully ignore the fact that the current Qt API does not provide any means to control the location of the generated file com.trolltech.plist. Or at least the generation thereof.

On Mac deploying the qt.conf file inside the App Bundle is usually done, as to define the plugin paths etc. 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.

And again: if an application creates a configuration file which does not adhere to the Mac Store acceptance/name convention tests, such as ~/Library/Preferences/com.trolltech.plist, then this is a no-go.

The patch - or lets call it "temporary workaround" - provided by AronR exactly helps in this situation, whereas your comments like "You can place your settings wherever you want, nothing needs to be "fixed" for this." show either your arrogance or your complete misunderstanding of the problem at hand.



The problem you describe is nothing new and not only related to Macs.

For once correct. The ~/Library/Preferences/com.trolltech.plist is probably generated since Qt 4.0, maybe even before. So what's your point? And on Windows and Linux one faces the same. But so far this was not an issue, since no 3rd party like Apple cares in this case.

But yes, if I run my Qt app on a virgin Windows installation I most likely also get all kind of Qt related registry entries (not explicitly created by my app through QSettings).


But changing this behaviour in Qt4 on a global level simply can't be done because of the reason I mentioned.

Yes, it can, as shown above: existing Qt apps would still read the same - and untouched - ~/Library/Preferences/com.trolltech.plist, whereas Qt apps "designed for the Mac Store" would call the appropriate Qt method and store/read their global Qt settings form their own private configuration file, which would adhere to the naming and location standards of Apple. Exactly what the patch does and suggests.


If the settings storage is really the only thing preventing Qt apps from being accepted by Apple (which I doubt is the case)

On what basis do you doubt so? So far we only know that Apple has rejected apps due to file paths, as also being discussed on Stack Overflow! Then there is the issue with "sheets", which most likely would also be fixed before Apple would accept them (unless the Apple tests do not realise the "focus" issue which apparently exists).


then there is no problem in adjusting the path where this particular application stores its settings as it is fully in control of the developer.

... there will be no problem if future Qt APIs provide any means to control the location of the global Qt settings.


The settings you mention can be fully controlled by a file called qt.conf .... This file controls default locations for things such as libraries, plugins, imports and settings.

And I am sure you have some concrete URL which would also show how to control the location of the global Qt globa settings. Because all the other things like the plugin locations do not help! So why don't you enlighten us and show us the concrete entry in qt.conf which controls the location of ~/Library/Preferences/com.trolltech.plist? I already gave an URL which does not mention anything about ~/Library/Preferences/com.trolltech.plist!


Since both patches posted by AronR modify the way QSettings work (edit: sorry, one deals with QDesktopServices and one with QSettings) so both (edit: probably just one, the other can be fixed by not using QDesktopServices, it seems qt.conf doesn't allow to change the cache location, at least docs don't mention it)


For simplicity's sake let's focus on ~/Library/Preferences/com.trolltech.plist, shall we?


cases should be fixed with qt.conf (the only "special" thing about the patch is it deals with organization name called "Trolltech").

And how? Again you missed to give the concrete entry necessary to control the location/creation of ~/Library/Preferences/com.trolltech.plist!

And the patch naturally modifies QSettings because this is also the mean by which Qt itself stores its global settings, not surprisingly. And yes, this "special thing", the name Trolltech, is exactly among the things which the Apple tests complain about! Besides the location of the file itself I guess...


Plus you don't need any persistent configuration files for any of the Qt-bundled applications to deploy your own application with settings and all.

Not sure what that is supposed to mean...


So how exactly do the patches posted fix this?

By controlling where the global Qt settings are stored: not in ~/Library/Preferences/com.trolltech.plist, but in the application configuration file, which adheres to location and naming conventions given by Apple.


They deal with QSettings

... because that is the place through which Qt stores its own global settings...


and QDesktopServices

We already agreed to focus on ~/Library/Preferences/com.trolltech.plist for now. I agree that in case of the QDesktopServices that is under control by the application and can be fixed on an application level.


I will skip answering the rest of your highly cultural post.

You may refuse to comment on my concrete objections to the way you answer to people. Let me just tell you why I was so upset by your arrogang posts, as in "People just need to use that", "there is nothing to fix" etc.

It is at the lowest level of newsgroups communication culture to put words into other people's mouth they never said by quoting them wrong or incompletely! Even though that was highly offensive I ignored you. But you kept on saying wrong things like "They won't include it." (How would you know?) and "It would break compatibility with existing apps." (which it doesn't, q.e.d.), because either you just like to object to other people's statement or because of lack of undertanding of the topic being discussed.

In any case, lets me - exceptionally - show you what I mean by "putting words into other people's mouth":

Me: "...as this might influence Apple's acceptance testing! And that is what this thread is all about?"

You [after conveniently for you only quoting the 2nd sentence]: "About sheets? Not really ;)"

I don't know how you derive from Apple's acceptance testing and that the relation "sheets". Off course you did this on purpose, to make me look ridiculous or whatever.

I don't have a problem with people who are beginners and ask "stupid questions". I don't have a problem with people who are wrong, as long as they show their willingness to learn and accept the fact that they said something wrong. I don't have a problem with people that say something stupid or unfriendly, as long as they apologise later on.

However I do have a problem with people acting teacherlike, ignorant and say wrong or unhelpful things, and all that with an arrogant tone! I was also following your comments on another topic here with regards to Gestures, so it is not the first time that I noticed your unhelpful posts, even though I must admit you do exhibit some knowledge about Qt - if you would just read and understand what other people say!

Your reaction to my critique (which was also put in harsh words, I agree) just proves your inability to take and react to it:

Private mail from you:
"You have received an infraction at Qt Centre Forum.

Reason: Inappropriate Language
-------
Please do not use words that can be considered offensive towards other people."

Ha, like I care! One point minus, so what!


However, I do care that you apparently are administrator in this forum. That means I cannot put you on my ignore lists, as I already tried before ("Adminstrators cannot be ignored").

So either you try to improve (or at least don't reply to my posts), or I kindly ask you to put me on your ignore lists, so you are not tempted to answer my posts. And in the best case I would then not see your posts either. Is that possible?

Thanks for your understanding!
Oliver

[wysota]

For once correct. The ~/Library/Preferences/com.trolltech.plist is probably generated since Qt 4.0, maybe even before. So what's your point? And on Windows and Linux one faces the same. But so far this was not an issue, since no 3rd party like Apple cares in this case.
Freedesktop.org cares, LSB cares.


And how? Again you missed to give the concrete entry necessary to control the location/creation of ~/Library/Preferences/com.trolltech.plist!
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 (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. It is in no way different than any other use of QSettings.



Not sure what that is supposed to mean...
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.


We already agreed to focus on ~/Library/Preferences/com.trolltech.plist for now.
"We"? :)


You may refuse to comment on my concrete objections to the way you answer to people.
When you start insulting me then I certainly won't go into such flame wars, I can disscuss the technical layer of your posts, not the personal one.


It is at the lowest level of newsgroups communication culture to put words into other people's mouth they never said by quoting them wrong or incompletely!
Please point out where I quoted you "wrong or incompletely". All your posts are there for people to see so 1) nothing of your posts was changed (so all you have written is available for others to read), 2) my quotes are your original full sentences meant to direct which parts of your statements my response relates to and 3) it is you who started picking on my words not me picking on yours. 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" and after one meritorical post (although the accuracy of it is for everyone to be judged) you started a personal war against me. Think yourself if it is not "at the lowest level of newsgroup communication culture".


Even though that was highly offensive I ignored you.
What exactly was highly offensive? This

You can place your settings wherever you want, nothing needs to be "fixed" for this.
or this one?

Sheets are available in Qt for ages now so no fix needed here as well. People just need to use them.
State what exactly offended you, please?


But you kept on saying wrong things like "They won't include it."
"Wrong things"? What "wrong" did I say exactly?


(How would you know?)
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'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. Just have a look at QProxyModel and QAbstractProxyModel, that's a classic example of what I mean. Any location change to QDesktopServices is out of the question as applications expect their files to be found in particular places. 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, Linguist and Assistant and some people who are using those custom configs might not be happy about it. Whether it also applies to the plugin cache, I don't know, I never had any serious problems with plugins anyway. I'm sorry to say this but so far you have been stating things without enough research to back up your words. You admitted yourself you didn't look closely at the patches provided (I have) yet you argue about them. You obviously didn't know about qt.conf yet you claim there is no API to change the location where settings are stored. You register to a site and start a flamewar with a person you know nothing about claiming he lacks skills, knowledge or understanding of Qt. Very strangely I have been thanked here almost 3k times and you exactly 0 times so far. What you say and how you act says more about you than about me. If you have skills, use them to help others instead of engaging in flames with people.


In any case, lets me - exceptionally - show you what I mean by "putting words into other people's mouth":
Oh, great. Let's look at that :)


Me: "...as this might influence Apple's acceptance testing! And that is what this thread is all about?"

You [after conveniently for you only quoting the 2nd sentence]: "About sheets? Not really ;)"
Hey, you are quoting yourself incompletely. Let's see how the paragraph starts:

As for the "sheets":
Yes, the paragraph is certainly not about the sheets.


I don't have a problem with people who are beginners and ask "stupid questions". I don't have a problem with people who are wrong, as long as they show their willingness to learn and accept the fact that they said something wrong. I don't have a problem with people that say something stupid or unfriendly, as long as they apologise later on.
Yet you have a problem with me, assuming in your opinion the characteristics you just mentioned apply in some degree to me. So far you have been wrong a couple of times, you have said something stupid (like... "binary compatibility" thing) and unfriendly (like the part about language redundancy and my brain). I didn't see you apologise for any of this.


Your reaction to my critique (which was also put in harsh words, I agree) just proves your inability to take and react to it:

Private mail from you:

(...)

Ha, like I care! One point minus, so what!
It's a formal warning. If you want to discuss it, please follow the site rules. If you keep misbehaving, at some point you will simply lose the ability to misbehave. It is to protect others not to "make you care". Putting it straight - we (as in community, not as in myself) don't like trolls here and we would prefer not having them around. For five years this has been a quiet and respected place and it is expected that it stays this way.


So either you try to improve (or at least don't reply to my posts), or I kindly ask you to put me on your ignore lists, so you are not tempted to answer my posts
Sorry, request denied. If you say something wrong, I have to see your posts and be able to react on them. This site is not your private playground nor it is mine. If you don't want to be corrected then don't say something you are not 100% sure of. If you are sure of something and you still say something which is not correct then I have every right to comment on your words and you can only blame yourself for not dedicating enough time to verify your opinion. Hey, I'm often wrong too and I sometimes state things I'm not 100% sure of. But I don't insult people who are proving me wrong and I'm not afraid to admit I was in error.

[mgoetz]

I've posted QTBUG-16549 (http://bugreports.qt.nokia.com/browse/QTBUG-16549) to Nokia. Make sure to vote for it.

[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")))
...


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/qlibraryinfo.html#LibraryLocation-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.


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;
}


<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");

[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);
//...
}

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");

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

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"...:crying:

[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/qsettings.html#locations-where-application-settings-are-stored

On Mac the application can also explicitly specify the "organisation domain" with e.g. QCoreApplication::setOrganizationDomain("mysoft.com"), 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"...:crying:

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"...:crying:
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
// ...
}

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


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.comp.lib.qt.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.

[dhjdhj]

I don't know what that statement actually means --- I have not found a way to stop my Macintosh application from creating the trolltech.plist in ~/Library/Preferences when it runs.

If anyone has step-by-step instructions for how to accomplish this (without having to become a Qt Guru), I'd really appreciate it --- our app got rejected for specifically this issue and we'd love to get it accepted.


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.

[janorcutt]

ok lads the biggest problem here is that Apple only want the appstore to contain apps written with there libs/frameworks/tools.
Also Qt was not originally written for mac os / ios, and neither should it be in my opinion.
i would only consider writing a Qt app for the ipod touch or iphone if and when it was fully supported, I know it'll never happen as long as mr jobs is alive so i'm not losing any sleep over it now.
wysota, if you could furnish us with the method you use to change the paths using qt.conf, i would appreciate it greatly, you've helped me before and as it happens i totally agree with you on this matter.
oliver, i do not wish to be rude or crass, however i find wysota's grasp of english to be excellent, and so i don't understand how you could have gotten so incandescent.
oh and chaps, if you wish to contribute to Qt then write the source code and submit it to trolltech/nokia for approval and/or inclusion, bitching (apologies for the language) will get us all exactly nowhere
agree with me or not people it is your choice, and as that is one of the underlying principles of the non commercial version of qt, and linux, i'll keep using them in that spirit.
l8r peeps

[dhjdhj]

Does Apple actually say anythere that Qt-based apps are banned?

Assuming they have not said that, is there any progress with a version of Qt that will be compliant with the required file locations?


ok lads the biggest problem here is that Apple only want the appstore to contain apps written with there libs/frameworks/tools.

[wysota]

There is another thread about Mac App Store where someone claims his Qt app got accepted without modifying Qt in any way. So the file discussed here must have been present there as well. This is in conflict with what people claim here, maybe you should come up with a verified version of the truth instead of chasing ghosts.

[janorcutt]

Does Apple actually say anythere that Qt-based apps are banned?

I don't believe that apple have banned Qt. However the point stands, apples platforms are proprietary and they sell access to the development framework to make money, that is after all what they are in business for. Therefore they are bound to want to discourage people from developing apps that get around this by using different tools/libs. This means that apple are bound to place strict restrictions on what enters the app store making it easier for a lot of companies/people just to buy apples tools/licenses. hope that made some sense. IMO projects such as qt should remain free, an interesting subject since it's owned by nokia who as i'm sure you are all aware just signed a deal with microsoft for windows phone 7 to be on nokia's handsets!!!

[nish]

I don't believe that apple have banned Qt. However the point stands, apples platforms are proprietary and they sell access to the development framework to make money, that is after all what they are in business for. Therefore they are bound to want to discourage people from developing apps that get around this by using different tools/libs.

long time ago when i was developing on Mac with Qt, we always needed XCode toolset for compiling Qt apps. So if this is true till this date, i believe apple will not hate qt.

[dhjdhj]

I have observed that if I create a qt.conf file in the Resources subfolder of my application and just put the single line [paths] in it, then my app no longer created the com.trolltech.plist file, at least not in ~/Library/Preferences

I haven't determined if it puts it somewhere else (but I haven't found it anywhere else so far) and I'm wondering if in fact this solves the problem on the macintosh?

[kodabb]

I have observed that if I create a qt.conf file in the Resources subfolder of my application and just put the single line [paths] in it, then my app no longer created the com.trolltech.plist file, at least not in ~/Library/Preferences

I haven't determined if it puts it somewhere else (but I haven't found it anywhere else so far) and I'm wondering if in fact this solves the problem on the macintosh?

i *have* a qt.conf file in the Resources folder with this content

[Paths]
Plugins = PlugIns
but if i put what you suggest ([paths] or [Paths] single line) it still creates com.trolltech.plist under ~/Library/Preferences

has anyone come up with a _real_ solution without having to compile all qt again?

[wysota]

Could someone verify if the trick with $HOME works or not?

If someone donates enough money for me to buy a Mac, I'll check it myself :cool:

[dhjdhj]

It does not --- I tried modifying my main function to temporarily set the PATH per your example earlier but it made no difference (and I don't have any plugins in my app).

[wysota]

It's not about PATH, it is about HOME. What did you set it to?

[dhjdhj]

I just mistyped the last entry --- I did in fact use HOME.

[wysota]

If you change HOME then there is no chance the file can appear in the offending directory simply because your app will not know where your home dir is. Your app may crash or something but it shouldn't write to this location.

[dhjdhj]

I tried the suggestion as described at the bottom of your post (http://www.qtcentre.org/threads/35292-Qt-Apps-banned-from-Mac-App-Store?p=173577#post173577)

[wysota]

Ok but what did you set HOME to? What was the value of path variable that you used?

[dhjdhj]

/Users/dhj/scratch/Qt

(Made sure that those subfolders already existed as well)

[wysota]

What does this return?

#include <QtCore>

int main(){
qputenv("HOME", "/Users/dhj/scratch/Qt");
qDebug() << QDir::homePath();
return 0;
}

[dhjdhj]

As expected

"/Users/dhj/scratch/Qt"

[wysota]

Ok, and this one?

#include <QtCore>

int main(){
qputenv("HOME", "/Users/dhj/scratch/Qt");
QSettings settings(QSettings::NativeFormat, QSettings::UserScope, "Trolltech");
qDebug() << settings.fileName();
return 0;
}

[dhjdhj]

"/Users/dhj/scratch/Qt/Library/Preferences/com.trolltech.plist"

Added after 6 minutes:

Let me add that if I leave out the 'return' and so continue with my main application (AND there is no qt.conf in the Resources folder), then the com.trolltech.plist is still crated in ~/Library/Preferences

If I use the qt.conf trick, then I don't have to play with the environment.

[wysota]

That's strange because this is exactly how the file is created by Qt.

[dhjdhj]

To paraphrase you, it's a bug ;)

[wysota]

No, it means there is a different call somewhere that causes the file to appear.

What happens if you move the offending file to "/Users/dhj/scratch/Qt/Library/Preferences/com.trolltech.plist" and run your app again? Does the file get recreated in ~/Library/Preferences?

[dhjdhj]

We've discovered that as soon as we run macdeployqt and put the 'Plugins=PlugIns' line back into qt.conf, we are stuck again with the com.trolltech.plist being created in ~/Library/Preferences.
Including the HOME redirection stuff makes absolutely no difference.

I think we're going to have to throw out Qt and find a different tool to get our program into the Mac App Store....it's getting too hard to deal with what should be a non-issue (I don't quite understand why it even needs to generate that plist in the first place) and candidly I don't want to have to become a Qt expert.

[wysota]

Did it occur to you that macdeployqt is a Qt-based app so it will naturally create the plist file if it doesn't already exist? Maybe that's the problem and not your app.

[dhjdhj]

No, it never occurred to me --- I delete the com.trolltech.plist file before I run the actual deployed application and it comes back the next time I run my application.

[wysota]

I don't quite understand why it even needs to generate that plist in the first place
The file contains a plugin cache and is not really required although there is currently no way to disable its use. The idea is that Qt has to scan the plugins directory for the plugins it knows. In some cases the directory will only contain files that are actual Qt plugins but in others the directory structure may contain an undefined number of other files. The cache prevents Qt from having to scan the directories every time an application is started. You can notice that if you delete the plugin cache and start some Qt app, it will take significantly longer to initialize than when you start it the next time.

I analyzed the code responsible for settings files on Mac and because Qt dives immediately into the native API when doing this, I don't see a way of circumventing creation of this file with Qt API. What you could do is use some access control list API to deny your application write access to this directory which might prevent the file from being created. Unless of course an external service creates the file on behalf of your app. Then you can only try to convince the service it shouldn't create the file there.

But anyway since some other Qt app got accepted into the app store withouth struggling with this problem, it might be that it's not something that would be the sole reason of preventing your app from being accepted.

[dhjdhj]

The Apple Store explicitly referred to the com.trolltech.plist being written into ~/Library/Preferences as one of the reasons for rejecting the app. The other reasons were trivial to correct so this is the only issue standing in our way. It's extremely frustrating.

[wysota]

Have you seen this thread?
http://www.qtcentre.org/threads/35967-Mac-App-Store

Try contacting the user who managed to get his Qt app approved, maybe you can somehow reach a positive conclusion. And remember you can always solve your problem by recompiling Qt which is a very easy thing to do.

[dhjdhj]

Well, I was wondering how to do that without having to become a Qt expert. Are there step-by-step accurate instructions anywhere for how to do this?


And remember you can always solve your problem by recompiling Qt which is a very easy thing to do.

[wysota]

You don't have to be an expert. Just download the sources, patch the code (I can even give you a patch if you want), run configure (optionally with some parameters if you want, run configure -help for details), then make and you're done. You might need some development packages for your system though, that's the only difficulty but there is a good chance you don't need them or you already have them.

[dhjdhj]

Ah, good old ./configure, make, make install ---- I HATE doing that stuff --- something almost always goes wrong. I'll give it a shot. Once I've built it and rebuilt my application, I'll have a go at modifying those functions, or if there's an "official" patch, even better.

I appreciate the information, even if I'm grouchy about it :-)

[wysota]

Ah, good old ./configure, make, make install ---- I HATE doing that stuff --- something almost always goes wrong.
You can wrap it all in a button, if you want. I don't care :)

[dhjdhj]

OK ---- one last question ---- the make process seems to have completed flawlessly (congrats to the Qt team, this is probably the first "deep" environment I've ever been able to build without running into at least one issue somewhere).

However, I don't think it installed stuff into the same locations as when I just downloaded the binary package which leaves me with a dilemma as it's not at all clear where everything is now supposed to live.

I seem to have both a /usr/local/Trolltech/Qt-4.7.1 and a /usr/local/Qt4.7 (the latter which seems to contain nothing more than the mkspecs folder) and so I'm left wondering what else is different about this installation (in terms of where the existing libraries are supposed to be, etc)

So the question is whether the make install process properly replaced everything that was previously installed through the pkg installer or whether I now have two parallel installations.

I'll go hunting around but I bet somebody else already knows the answer to this.

Added after 59 minutes:

Well, so much for my comment about not running into any issues!

It looks like some more environment variables need to be set than are mentioned in the build instructions (http://doc.qt.nokia.com/4.7/install-mac.html) or else there has to be another step to put the Qt frameworks into the /Library/Frameworks folder.

I came across a reference to QMAKE_LIBDIR_QT (in qt_functions.prf) which looks like it might be a way to point to the correct frameworks. Is that the correct way to proceed?

Looks like there are similar environment variables needed to refer to the correct header files too. What else?

[wysota]

You don't want to replace the binary installation that you downloaded. You want the installation to be in a seprate place so that you can choose which of the two to use by running the appropriate qmake executable. I don't know much about frameworks but I'd run configure -help to see if there is an option to install Qt in a framework. Even if not, you have a working Qt installation.

[dhjdhj]

Ah --- I will see if I can figure out how to change that from Qt Creator

You want the installation to be in a seprate place so that you can choose which of the two to use by running the appropriate qmake executable.

[wysota]

Tools->Options->Qt4. Add a new version and point Creator to your new qmake binary.

[dhjdhj]

Still getting the following error at link time. I mentioned this in another thread....there's a _qt_plugin_instance symbol in the libqjpeg library (found with nm) but not a _qt_plugin_instance_qjpeg

Undefined symbols for architecture x86_64:
"qt_plugin_instance_qjpeg()", referenced from:
StaticqjpegPluginInstance::StaticqjpegPluginInstan ce()in main.o



It would be awfully nice if the document at http://doc.qt.nokia.com/4.7/install-mac.html mentioned that crucial nit (sigh) instead of just saying to set an environment variable.

Tools->Options->Qt4. Add a new version and point Creator to your new qmake binary.

[wysota]

Still getting the following error at link time. I mentioned this in another thread....there's a _qt_plugin_instance symbol in the libqjpeg library (found with nm) but not a _qt_plugin_instance_qjpeg

Undefined symbols for architecture x86_64:
"qt_plugin_instance_qjpeg()", referenced from:
StaticqjpegPluginInstance::StaticqjpegPluginInstan ce()in main.o
It seems you are trying to link a static qjpeg plugin that you probably don't have. How does your .pro file look?




It would be awfully nice if the document at http://doc.qt.nokia.com/4.7/install-mac.html mentioned that crucial nit (sigh) instead of just saying to set an environment variable.
Qt and Qt Creator are two different things, don't forget that. What you want is documented in QtCreator's manual.

[dhjdhj]

Ah, that could be .... not sure why I don't have it though. This was an attempt to try and avoid the Plugins issue at all. I was following instructions I found on another page in this site.
QTPLUGIN += qjpeg qgif
However, now that I have an explicit build from source, hopefully applying the patch will address the issue without having to go down that route.

It seems you are trying to link a static qjpeg plugin that you probably don't have. How does your .pro file look?


That's true to a purist but not obvious to average non-expert users. Presumably the Qt developers are familiar with Qt Creator :rolleyes: given its importance in recent times and at the least the build instructions for Qt could have mentioned that extra step. You know, a single sentence like :
"If you are using Qt Creator, you will need to configure it to use your new qmake. Please refer to the Qt Creator documentation for how to do this"
Such a heads up would save time for lots of people.

However, I really appreciate your having taken the time to continually answer my questions and hopefully this interchange will help others trying to do the same thing.

Qt and Qt Creator are two different things, don't forget that. What you want is documented in QtCreator's manual.

[wysota]

Ah, that could be .... not sure why I don't have it though. This was an attempt to try and avoid the Plugins issue at all. I was following instructions I found on another page in this site.
QTPLUGIN += qjpeg qgif
You need static plugins for this to work. Your plugins are not static.


That's true to a purist but not obvious to average non-expert users.
The download page for Qt SDK clearly states that the SDK consists of Qt libraries, Qt Creator and other development tools. You don't have to be a Qt expert, it's enough to "read what you click".


Presumably the Qt developers are familiar with Qt Creator :rolleyes: given its importance in recent times and at the least the build instructions for Qt could have mentioned that extra step.
I don't think Windows manual states how to install Visual Studio. I'm pretty much sure Windows developers are aware of Visual Studio and its importance to Windows programming :)


You know, a single sentence like :
"If you are using Qt Creator, you will need to configure it to use your new qmake. Please refer to the Qt Creator documentation for how to do this"
Such a heads up would save time for lots of people.
Even if such a statement was put in Qt docs (although I still think it shouldn't be) it surely wouldn't be in the mac installation section.

[dhjdhj]

Windows/Visual Studio is hardly analagous to Qt/Qt Creator so I'm sure you're correct. On the other hand, .NET framework/Visual Studio would be a good analogy and if you were to go to the appropriate MS development center to pull down .NET frameworks, you will find plenty of references mentioning/reminding that you need to configure VS to use specific versions. Similarly, if you go to places that provide Java libraries for developers, the installation instructions will typically explain in gory detail exactly what you need to do to Eclipse and/or Netbeans to use those libraries.

This is not worth debating ---


I don't think Windows manual states how to install Visual Studio. I'm pretty much sure Windows developers are aware of Visual Studio and its importance to Windows programming

[wysota]

All you say might be true only because vendors try to convince you that you should be using their IDE for development. This is not the case with Qt and QtCreator. These are really two separate products and that's a common mistake that people treat them as one.

[dhjdhj]

So I patched the system, rebuilt everything, added that qt_force_trolltech_settings_to_app_area(true) call at the very beginning of my program.

The good news is that there is no longer a file called com.trolltech.plist being created in ~/Library/Preferences.
The bad news is that is now a file called com.deskew.plist being created in ~/Library/Preferences, containing the stuff that was in com.trolltech.plist.

I thought the whole point of this patch was so that the files would be created in ~/Application/Preferences instead. Is there an extra magic incantation required to make that happened.

[wysota]

There is a much better solution available.

Somewhere around #110 of src/corelib/plugin/qfactoryloader.cpp there is:

QSettings settings(QSettings::UserScope, QLatin1String("Trolltech"));
Change it to:

QSettings *settings_override = 0;
QByteArray settings_override_setting = qgetenv("PLUGINCACHE_OVERRIDE");
if(settings.isEmpty() || settings.toInt()==0) {
settings_override = new QSettings(QSettings::UserScope, QLatin1String("Trolltech"));
} else {
settings_override = new QSettings(QSettings::IniFormat, QSettings::UserScope, QLatin1String("Trolltech"));
}

QSettings& settings(*settings_override);
After line #195 (just before "#else") add:

delete settings_override;

In file src/corelib/plugin/qlibrary.cpp line #630 contains:

settings = new QSettings(QSettings::UserScope, QLatin1String("Trolltech"));
Change it to:

QByteArray settings_override_setting = qgetenv("PLUGINCACHE_OVERRIDE");
if(settings.isEmpty() || settings.toInt()==0) {
settings = new QSettings(QSettings::UserScope, QLatin1String("Trolltech"));
} else {
settings = new QSettings(QSettings::IniFormat, QSettings::UserScope, QLatin1String("Trolltech"));
}

Now you can add this to your main() before instantiating QApplication:

int main(...) {
qputenv("PLUGINCACHE_OVERRIDE", "1");
QApplication app(...);
// ...
}
And it should cause the plugin cache to be created as an .ini file which in itself should solve the problem but even if not, you can use qt.conf to control it.

I hope the trick with a reference works but I haven't tested it so you might need to change object based access to pointer based access to QSettings in qfactoryloader.cpp.

[dhjdhj]

Thank you for the suggestion --- I was just getting ready to hunt through the code to do something like this. I have two questions though.

1) I don't understand the purpose of the declaration QByteArray settings_override_setting = qgetenv("PLUGINCACHE_OVERRIDE"); as I don't see that new variable actually used anywhere. I.e, you're setting it from the environment variable but not referring to it anywhere. What's it for?

2) The issue isn't so much as whether the created file is a .ini or a .plist. The issue is the LOCATION where the file is created.

[wysota]

Ouch, true. The next line after the one you refer to should read:

if(settings_override_setting.isEmpty() || settings_override_setting.toInt()==0) {

As for your second concern - you can't control the placement of .plist files but you can control the placement of .ini files. That's why converting the plugin cache to an .ini file solves the problem. Then you can place it i.e. in your application's bundle which in my opinion is a reasonable place for it. You can even play with the lines creating the settings files and put them in a location of your choice by specifying different parameters for QSettings constructor. It's much easier this way than to look in Qt's code how you can place the plist file elsewhere.

[dhjdhj]

Is your patch proposed as an alternative to patching Qt as decribed in the earlier post by Aron?

[wysota]

You said you didn't like what his patch did so I quickly came up with another one.

[dhjdhj]

No, I didn't say I didn't like it --- I said it didn't work as expected and I wondered whether there was some magic extra incantation needed to make it store files in the correct location.

Added after 1 11 minutes:

Is there any way to build an application against a Qt environment that has been "maked" but not actually installed....i.e. to have everything refer to qt-everywhere-opensource-src-4.7.1 instead of /usr/local/Trolltech.....

I tried changing the environment variables from within Qt Creator (QTDIR and PATH) to reflect that reference as well as the argument to qmake but when I watch the build, the compiler and linker still use the /usr/local/Trolltech paths

The reason I want to do this of course is so that I can make quick changes to the Qt source and not have to though a complete reinstall every time.

I'm also wondering what needs to be done to be able to single-step through the Qt source.

Thanks

[wysota]

No, I didn't say I didn't like it --- I said it didn't work as expected and I wondered whether there was some magic extra incantation needed to make it store files in the correct location.
In my world it means you didn't like it :)


Is there any way to build an application against a Qt environment that has been "maked" but not actually installed....i.e. to have everything refer to qt-everywhere-opensource-src-4.7.1 instead of /usr/local/Trolltech.....

I tried changing the environment variables from within Qt Creator (QTDIR and PATH) to reflect that reference as well as the argument to qmake but when I watch the build, the compiler and linker still use the /usr/local/Trolltech paths

The reason I want to do this of course is so that I can make quick changes to the Qt source and not have to though a complete reinstall every time.
Reinstall takes a relatively short time compared to trying to find a solution for this problem :) You can try using qmake -query and qmake -set but I can't guarantee it will work. You can use the -prefix option of configure to point the installation to the build directory itself but again I have never tried it myself.


I'm also wondering what needs to be done to be able to single-step through the Qt source.
You need Qt built in both release and debug mode. configure -help should give you a couple of insights.

[dhjdhj]

Unfortunately, that's just not true. A very easy way to find out who is invoking a particular call somewhere deep down in a library is to set a breakpoint in it and then look at the stack. If you can't do that easily, then the next approach is to throw in printf (or qDebug()) statements into the library. But that has two problems. The minor one is having to rebuild/reinstall, which takes about 5 minutes each time. The major one is that it's actually quite difficult to throw in printf statements in the right place due to the terrible practice of using return statements in the middle of functions so you can't easily get at the values you want to see.

Reinstall takes a relatively short time compared to trying to find a solution for this problem


The question is how I can get Qt Creator to step into code in the Qt Library.

You need Qt built in both release and debug mode. configure -help should give you a couple of insights.

Flawed logic. My children often don't work (behave) as expected. It doesn't mean I don't like them!:)

In my world it means you didn't like it

[wysota]

If you can't do that easily,
Why can't you do that easily?


The minor one is having to rebuild/reinstall, which takes about 5 minutes each time.
You can reduce that time by rebuilding/reinstalling only that part that really changes. If you wish to rebuild/reinstall only QtCore then cd into src/corelib and run make/make install there.


The major one is that it's actually quite difficult to throw in printf statements in the right place due to the terrible practice of using return statements in the middle of functions so you can't easily get at the values you want to see.
Have a look at this: http://blog.wysota.eu.org/index.php/2009/11/17/little-debugging-helper/
If you use it, it doesn't matter where return statements are. You can modify this little class to suit your needs.


The question is how I can get Qt Creator to step into code in the Qt Library.
I already told you - build Qt (and your app) in debug mode and use breakpoints. This works the same as with any other app/lib.


Flawed logic. My children often don't work (behave) as expected. It doesn't mean I don't like them!:)
There is more than one meaning to the word "like". For instance one is "to be fond of" (as in the case of children) and another "to be satisfied with" (as in case of the patch).

Oh, one remark - please try to place your post content below the relevant quote and not over it. It's much less confusing this way.

[dhjdhj]

Why can't you do that easily?Because, in spite of your "how to step through Qt library code", I haven't yet been able to make that work.



If you use it, it doesn't matter where return statements are. You can modify this little class to suit your needs.That stuff doesn't help at all. When people write code in the style (I can't get the indentation to display properly on this system)

if (foo)
then return bar;
else if (x)
then return y;
else return z;

then you have to do a lot more work to see what value actually got returned. On the other hand, if one writes


QString result;
if (foo)
then result = bar;
else if (x)
then result= y;
else result = z;
return result;

it then becomes trivial to just throw in a single printf (or qDebug) just before the return. There are other benefits beyond the scope of this conversation. (Hint --- see the writings of Dijkstra, Hoare and others on the value of structured programming)


There is more than one meaning to the word "like". Yes ---- that's why one can have humor! (sigh)


We are getting off topic ---- I am just trying to find the place in the code that is causing ANY settings to be written into ~/Library/Preferences instead of ~/Library/Application Support. I found one place in qsettings_mac.cpp and changed it but that didn't seem to stop some stuff from being written into ~/Library/Preferences.

[wysota]

Here you go:
$ grep -R "Library/Preferences" *
configure: QT_INSTALL_SETTINGS=/Library/Preferences/Qt
doc/html/qsettings.html:<li><tt>$HOME/Library/Preferences/com.MySoft.Star Runner.plist</tt></li>
doc/html/qsettings.html:<li><tt>$HOME/Library/Preferences/com.MySoft.plist</tt></li>
doc/html/qsettings.html:<li><tt>/Library/Preferences/com.MySoft.Star Runner.plist</tt></li>
doc/html/qsettings.html:<li><tt>/Library/Preferences/com.MySoft.plist</tt></li>
doc-build/html-qt/qsettings.html:<li><tt>$HOME/Library/Preferences/com.MySoft.Star Runner.plist</tt></li>
doc-build/html-qt/qsettings.html:<li><tt>$HOME/Library/Preferences/com.MySoft.plist</tt></li>
doc-build/html-qt/qsettings.html:<li><tt>/Library/Preferences/com.MySoft.Star Runner.plist</tt></li>
doc-build/html-qt/qsettings.html:<li><tt>/Library/Preferences/com.MySoft.plist</tt></li>
src/corelib/io/qsettings_mac.cpp: result += QLatin1String("/Library/Preferences/");
src/corelib/io/qsettings.cpp: \o \c{$HOME/Library/Preferences/com.MySoft.Star Runner.plist}
src/corelib/io/qsettings.cpp: \o \c{$HOME/Library/Preferences/com.MySoft.plist}
src/corelib/io/qsettings.cpp: \o \c{/Library/Preferences/com.MySoft.Star Runner.plist}
src/corelib/io/qsettings.cpp: \o \c{/Library/Preferences/com.MySoft.plist}
src/3rdparty/webkit/WebCore/plugins/mac/PluginPackageMac.cpp: WTF::RetainPtr<CFStringRef> path = CFStringCreateWithFormat(0, 0, CFSTR("%@/Library/Preferences/%@"), homeDir.get(), fileName.get());
src/plugins/bearer/corewlan/qcorewlanengine.mm: QString userProfilePath = QDir::homePath() + "/Library/Preferences/com.apple.eap.profiles.plist";
src/plugins/bearer/corewlan/qcorewlanengine.mm: NSString *filePath = @"/Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist";
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s1.fileName(), QDir::homePath() + "/Library/Preferences/com.apple.Console.plist");
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s2.fileName(), QDir::homePath() + "/Library/Preferences/com.apple.plist");
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s3.fileName(), QString("/Library/Preferences/com.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s4.fileName(), QString("/Library/Preferences/com.apple.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s5.fileName(), QString("/Library/Preferences/com.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s6.fileName(), QString("/Library/Preferences/com.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s7.fileName(), QString("/Library/Preferences/com.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s8.fileName(), QString("/Library/Preferences/fr.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s9.fileName(), QString("/Library/Preferences/jp.co.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s10.fileName(), QString("/Library/Preferences/org.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s11.fileName(), QString("/Library/Preferences/net.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s12.fileName(), QString("/Library/Preferences/museum.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s13.fileName(), QString("/Library/Preferences/fr.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s14.fileName(), QString("/Library/Preferences/museum.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s15.fileName(), QString("/Library/Preferences/zz.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s15_prime.fileName(), QString("/Library/Preferences/com.apple-foo.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s16.fileName(), QString("/Library/Preferences/com.apple-f.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s17.fileName(), QString("/Library/Preferences/com.apple.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s18.fileName(), QString("/Library/Preferences/com.foo-inc.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s19.fileName(), QString("/Library/Preferences/com.foo, inc.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s20.fileName(), QLatin1String("/Library/Preferences/com. ") + QChar(0xbd) + QLatin1String("foo : barxxx baz!()#@.Console.plist"));
tests/auto/qsettings/tst_qsettings.cpp: QCOMPARE(s21.fileName(), QString("/Library/Preferences/com.foo-bar-baz.Console.plist"));

[dhjdhj]

Sigh --- thank you, I know how to do a grep --- I would like not to have to change ALL of those files --- just the one that is relevant!

[wysota]

Most of them are tests, so these need not be changed. Only line #11 and #16-18 are relevant. Plus optionally line #2. But the latter can be changed with a configure parameter. But I still think you should store the plugin cache as an ini file inside the bundle.

[dhjdhj]

Wysota, I really appreciate the information you're giving me. Unfortunately, a bit like the old hot air balloon joke, the information by itself is not that helpful.

SOMEWHERE in the qt library, whatever is setting up the plist file containing stuff like

<dict>
<key>Trolltech.Qt Factory Cache

is causing that file to be created in ~/Library/Preferences. Yes, it is no longer called com.trolltech.plist but it doesn't help for it to be called with my company name if it is still being created in ~/Library/Preferences.

[wysota]

I already gave you a solution to this problem. This "somewhere" is qfactoryloader.cpp in line #110. The solution is to place the settings elsewhere. QSettings gives you a number of possibilities to do it including registering your own settings format and redirecting the file there if you don't want to use ini files.

You can even create the file like this:

QSettings(QDir::homePath()+"/Application/Preferences/qt.plist", QSettings::NativeFormat);

[jh]

Opera in Mac Store!
Isn't Opera build with Qt? So, there should be no problem to get you Qt app to the MacStore.
Regards,
jh

[weaver4]

Anyone know if the new 4.7.3 Beta Release fixes this issue?

[dhjdhj]

I am wondering the same thing.....a month later!

[cnnbboy]

http://lynxline.com/submiting-to-mac-app-store/
see it,it's really?

[cincirin]

seems to be really. GLC_Player (http://itunes.apple.com/fr/app/glc-player/id417065209?mt=12) is other Qt based application placed on Mac App Store

[claurel]

I just had my Qt-based app Cosmographia approved by Apple. They review process was quick: three and a half days, including a rejection because I had messed up and linked the executable to Qt framesworks outside the bundle.

Here's what I did:

- Rebuilt the Qt 4.7.3 libraries with the three patches from Aron Rosenberg: https://bugreports.qt.nokia.com//browse/QTBUG-16549
- Added "-gdwarf-2" to QMAKE_CFLAGS and QMAKE_CXXFLAGS to force building the Release version with DWARF+dSYM mode
- Created a custom Info.plist with the app category and bundle ID; forced qmake to use this instead of the default by setting QMAKE_INFO_PLIST in the project file
- Did a full rebuild
- Generated symbols:
dsymutil AppName.app/Contents/MacOS/AppName -o AppName.app.dSYM
- Signed the app bundle:
codesign -f -s “3rd Party Mac Developer Application: My Name” AppName.app
- Built the package:
productbuild \
--component AppName.app /Applications \
--sign “3rd Party Mac Developer Installer: My Name” \
AppName.pkg

Definitely test the package afterward so you don't get rejected for a silly reason:
sudo installer -store -pkg AppName.pkg -target /

My app uses nearly the full set of Qt libraries, including QtDeclarative. Apple doesn't seem to mind as long as the app works and doesn't write files outside of its sandbox.

--Chris

[ChrisW67]

Are you using Qt under the commercial licence or LGPL?

[SirBabyface]

Hi,

We have 5 different applications approved by Mac AppStore.

All of them use Qt 4.7.3 LGPL version. We have compiled our self. In one of them we also use Ogre 3D engine + CEGUI and it was also approved (it has approved in 2 days)

So from my experience you can use Qt 4.7.3 without any problems.

[claurel]

Are you using Qt under the commercial licence or LGPL?

I'm using the LGPL license. The code for my app is mostly LGPL as well.

--Chris

[ChrisW67]

Thanks guys.

[bruce2011]

I have submit my app to mac app store, Application Loader report
"the application bundle may not contain tools or frameworks provided by apple, or using bundle identifiers in the 'com.apple' namespace"
I have use QT 4.7.3, I have write two myself framework, one App.
Please help me.

[bruce2011]

I have the steps as you described, and the installer-store-pkg have "has valid signature for submission: 3rd Party Mac Developer Installer:".
Why apple send mail to me "Invalid Signature".
Please help me, Thanks.