-
Qt Apps banned from Mac App Store?
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.
Does this affect Qt (C++) software?
-
Re: Qt Apps banned from Mac App Store?
-
Re: Qt Apps banned from Mac App Store?
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!
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
jfk
Does that mean Qt 'Apps' are completely out of the question?
Officially, yes.
-
Re: Qt Apps banned from Mac App Store?
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)
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
squidge
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
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:
Code:
Apps which appear confusingly similar to an existing Apple product will be rejected.
In any case I'll give it a shot!
-
Re: Qt Apps banned from Mac App Store?
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
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.
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.
-
Re: Qt Apps banned from Mac App Store?
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.
-
Re: Qt Apps banned from Mac App Store?
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
-
Re: Qt Apps banned from Mac App Store?
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.
-
Re: Qt Apps banned from Mac App Store?
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
wysota
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).
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted 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.
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?
Quote:
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
wysota
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.
-
Re: Qt Apps banned from Mac App Store?
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.
-
Re: Qt Apps banned from Mac App Store?
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
-
Re: Qt Apps banned from Mac App Store?
And how is this related to the discussion in this thread?
-
Re: Qt Apps banned from Mac App Store?
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
wysota
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
Quote:
Originally Posted by
SixDegrees
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..._apple_itunes/
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
koan
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.
Quote:
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 :)
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
wysota
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.
Quote:
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.
-
Re: Qt Apps banned from Mac App Store?
Please also have a look at http://stackoverflow.com/questions/4...624284#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!
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
Oliver Knoll
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.
Quote:
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.
-
Re: Qt Apps banned from Mac App Store?
@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
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
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!
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.
Quote:
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.
Quote:
And that is what this thread is all about?
About sheets? Not really :)
Quote:
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.
-
2 Attachment(s)
Re: Qt Apps banned from Mac App Store?
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
Attachment 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).
Attachment 5727
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
AronR
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
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
Oliver Knoll
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.
Quote:
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.
-
Re: Qt Apps banned from Mac App Store?
@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:
Quote:
Originally Posted by
wysota
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!
Quote:
Originally Posted by
wysota
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:
Quote:
Originally Posted by
wysota
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
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
Oliver Knoll
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.
Quote:
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).
Quote:
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
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.
Microsoft has a patent on the page up/down key now... http://www.tomshardware.com/news/mic...tent,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:
-
Re: Qt Apps banned from Mac App Store?
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).
-
Re: Qt Apps banned from Mac App Store?
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
wysota
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
squidge
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
wysota
Did you see me use the word "binary" anywhere?
Ok, sorry, my wrong.
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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).
Quote:
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.
Quote:
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).
Quote:
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.
Quote:
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!
Quote:
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?
Quote:
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...
Quote:
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...
Quote:
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.
Quote:
They deal with QSettings
... because that is the place through which Qt stores its own global settings...
Quote:
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.
Quote:
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
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
Oliver Knoll
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.
Quote:
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.
Quote:
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.
Quote:
We already agreed to focus on ~/Library/Preferences/com.trolltech.plist for now.
"We"? :)
Quote:
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.
Quote:
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".
Quote:
Even though that was highly offensive I ignored you.
What exactly was highly offensive? This
Quote:
Originally Posted by wysota
You can place your settings wherever you want, nothing needs to be "fixed" for this.
or this one?
Quote:
Originally Posted by wysota
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?
Quote:
Originally Posted by Oliver Knoll
But you kept on saying wrong things like "They won't include it."
"Wrong things"? What "wrong" did I say exactly?
Quote:
(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.
Quote:
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 :)
Quote:
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:
Quote:
As for the "sheets":
Yes, the paragraph is certainly not about the sheets.
Quote:
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.
Quote:
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.
Quote:
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.
-
Re: Qt Apps banned from Mac App Store?
I've posted QTBUG-16549 to Nokia. Make sure to vote for it.
-
Re: Qt Apps banned from Mac App Store?
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".
Quote:
Originally Posted by
wysota
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...
Quote:
(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:
Code:
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).
Quote:
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.
Quote:
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.
Quote:
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...
Quote:
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.
Quote:
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!
Quote:
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.
Quote:
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.
Quote:
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").
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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!
Quote:
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
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
Oliver Knoll
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).
Quote:
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?)
Quote:
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.
Quote:
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.
Quote:
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:
Quote:
Originally Posted by Using qt.conf
The qt.conf file overrides the hard-coded paths that are compiled into the Qt library.
-
Re: Qt Apps banned from Mac App Store?
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
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
wysota
Which changes what exactly? qt.conf will redirect that as well.
You still fail in giving a concrete reference.
Quote:
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.
Quote:
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...
Quote:
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!
Quote:
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?!
Quote:
(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...
Quote:
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.
Quote:
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...
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?
Quote:
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)!
Quote:
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...
Quote:
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!).
Quote:
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...
Quote:
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.
Quote:
Just the very first line from the docs:
You seem to have an exeptional talent to only quote what serves your own purpose of argument. Let me complement your quote: "The qt.conf file overrides the hard-coded paths that are compiled into the Qt library." Just the next sentence in the referenced docs sais:
"These paths are accessible using the QLibraryInfo class."
Aha, so what are these paths? Let's follow the link given in the Qt docs:
http://doc.qt.nokia.com/latest/qlibr...yLocation-enum
Code:
QLibraryInfo::PrefixPath 0 The
default prefix
for all paths.
QLibraryInfo::DocumentationPath 1 The location
for documentation upon install.
...
....
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):
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!
Code:
#include <QtCore/QLibraryInfo>
#include <QtCore/QCoreApplication>
int main(int argc, char *argv[])
{
qDebug("SettingsPath: %s", qPrintable(path));
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
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
Oliver Knoll
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)
Code:
int main(int argc, char** argv)
{
QT_USE_NAMESPACE
app.setOrganizationDomain("trolltech.com");
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
Oliver Knoll
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.
Quote:
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.
Quote:
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.
Quote:
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:
Code:
int main(int argc, char **argv) {
lotsOfStuffHappeningHere();
//...
}
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.
Quote:
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?
Quote:
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.
Quote:
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?
Quote:
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).
Quote:
Ahhh...! Did we not agree that we focus on the "Qt Settings" aka ~/Library/Preferences/com.trolltech.plist?
No, we didn't.
Quote:
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).
Quote:
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
tbscope
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)
Code:
int main(int argc, char** argv)
{
QT_USE_NAMESPACE
app.setOrganizationDomain("trolltech.com");
I found the call:
src/corelib/plugin/qlibrary.cpp:
Code:
#ifndef QT_NO_SETTINGS
if (!settings) {
settings = libraryData()->settings;
if (!settings) {
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
wysota
I found the call:
Unbelievable!
Quote:
Another one is in qfactoryloader.cpp which then calls QLibrary.
Isn't that amazing!
Quote:
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!!!
Quote:
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!
Quote:
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.
Quote:
(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!
Quote:
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)
Quote:
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!!!
Quote:
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)...
Quote:
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!
Quote:
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!"
Quote:
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:
Quote:
Furthermore the easiest way to solve the situation is to patch [any Qt class]
and then just a few lines later:
wysota:
Quote:
The "problem" is not in Qt itself.
Sorry, but I am at a loss of words here, I cannot follow this "logic"...:crying:
-
Re: Qt Apps banned from Mac App Store?
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.
-
Re: Qt Apps banned from Mac App Store?
Quote:
Originally Posted by
tbscope
This can easily be verified.
So far, the only things I see with com.trolltech inside the code are interface names and documentation.
The way it works is documented here: http://doc.trolltech.com/4.7/qsettings.html#basic-usage
So given the combination of "organisation name" and "application name" the name of the actual settings file is derived, according to the following platform-specific rules:
http://doc.trolltech.com/4.7/qsettin...ngs-are-stored
On Mac the application can also explicitly specify the "organisation domain" with e.g. QCoreApplication::setOrganizationDomain("mysoft.co m"), which is then taken.
So you wouldn't actually find the literal string "com.trolltech" anywhere in the Qt sources (except in the places you mentioned).
The Qt library itself makes use of the QSettings and not surprisingly the "organisation name" is set to "Trolltech" (the ".com" part is then automatically derived, since not explicitly set with setOrganizationDomain()).
So what the patch of AronR simply does basically is - if the application wants to do so - it catches the case inside the QSettings where the "domain" is "Trolltech", and if so, it simply "re-routes" these settings from/to the "application's own setting file, totally transparent to the caller (the "Qt library" in this case). It is as easy as that.
Off course things have to be discusses such as where to tell the Qt library when to "merge" the "Qt Settings" (store into the same file as) with the actual applications settings (which off course adhere to the Apple file acceptance criteria). A possible place could be qt.conf. Or an additional method in QSettings. Or...
All these things are currently also discussed at http://bugreports.qt.nokia.com/browse/QTBUG-16549
Cheers, Oliver
Added after 23 minutes:
Quote:
Originally Posted by
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.
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:
Quote:
Originally Posted by
Oliver Knoll
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...! ;)