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 hereYou dynamically link to the QT libs and include them in the bundle; GPL/LGPL satisfied.
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.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
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!
Sheets are available in Qt for ages now so no fix needed here as well. People just need to use them.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!
@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?
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.As for the "sheets": Did you understand to what my comment relates?
About sheets? Not reallyAnd that is what this thread is all about?
Bearing the fact that I particiapated in this discussion from the very beginning you should probably answer your question yourself.Did you not read the previous posts? Did you not understand the context of this discussion?
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
~/Library/Application Support/bundleId (com.company.App)
The following patch will change Qt to use the QCoreApplication:rganizationDomain() 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
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).
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!
There is. Have a look at available constructors for QSettings.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.
@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:
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!
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,
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.
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).Wrong again! We are talking about the Qt configuration file which is generated by Qt, not by the application.
So how exactly do the patches posted fix this? They deal with QSettings and QDesktopServices, you knowWe are not talking - I repeat extra for you - not talking about QSettings! We are talking about the ~/Library/Preferences/com.trolltech.plist.
I will skip answering the rest of your highly cultural post.
Last edited by wysota; 8th January 2011 at 19:30.
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
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).
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.
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"!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.
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.
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.Qt can't be upgraded to change the location automatically because lots of already existing applications would be broken.
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.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.
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.
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.The problem you describe is nothing new and not only related to Macs.
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).
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.But changing this behaviour in Qt4 on a global level simply can't be done because of the reason I mentioned.
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).If the settings storage is really the only thing preventing Qt apps from being accepted by Apple (which I doubt is the case)
... there will be no problem if future Qt APIs provide any means to control the location of the global Qt settings.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.
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!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.
For simplicity's sake let's focus on ~/Library/Preferences/com.trolltech.plist, shall we?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)
And how? Again you missed to give the concrete entry necessary to control the location/creation of ~/Library/Preferences/com.trolltech.plist!cases should be fixed with qt.conf (the only "special" thing about the patch is it deals with organization name called "Trolltech").
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...
Not sure what that is supposed to mean...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.
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.So how exactly do the patches posted fix this?
... because that is the place through which Qt stores its own global settings...They deal with QSettings
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.and QDesktopServices
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.I will skip answering the rest of your highly cultural post.
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!
Last edited by Oliver Knoll; 10th January 2011 at 11:24. Reason: missing [code] tags
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.And how? Again you missed to give the concrete entry necessary to control the location/creation of ~/Library/Preferences/com.trolltech.plist!
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.Not sure what that is supposed to mean...
"We"?We already agreed to focus on ~/Library/Preferences/com.trolltech.plist for now.
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.You may refuse to comment on my concrete objections to the way you answer to people.
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".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!
What exactly was highly offensive? ThisEven though that was highly offensive I ignored you.
or this one?Originally Posted by wysota
State what exactly offended you, please?Originally Posted by wysota
"Wrong things"? What "wrong" did I say exactly?Originally Posted by Oliver Knoll
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.(How would you know?)
Oh, great. Let's look at thatIn any case, lets me - exceptionally - show you what I mean by "putting words into other people's mouth":
Hey, you are quoting yourself incompletely. Let's see how the paragraph starts: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 "
Yes, the paragraph is certainly not about the sheets.As for the "sheets":
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.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.
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.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!
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.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
I've posted QTBUG-16549 to Nokia. Make sure to vote for it.
Disclaimer: Although I work on Qt for Nokia, anything I post here is personal