Qt Apps banned from Mac App Store?

[wysota]

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

[dhjdhj]

To paraphrase you, it's a bug

[wysota]

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

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

[dhjdhj]

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

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

[wysota]

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

[dhjdhj]

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

[wysota]

I don't quite understand why it even needs to generate that plist in the first place

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

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

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

[dhjdhj]

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

[wysota]

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

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

[dhjdhj]

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

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

[wysota]

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

[dhjdhj]

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

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

[wysota]

Ah, good old ./configure, make, make install ---- I HATE doing that stuff --- something almost always goes wrong.

You can wrap it all in a button, if you want. I don't care

[dhjdhj]

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

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

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

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

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

---

Added after 59 minutes:

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

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

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

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

[wysota]

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

[dhjdhj]

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

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

[wysota]

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

[dhjdhj]

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

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



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

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

[wysota]

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

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

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

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

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

[dhjdhj]

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

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

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

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

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