You're calling QDialog::exec which is for modal-only dialogs, and Qt::Popup isn't for dialogs, leave the window flags be. If you prepare a MWE (the download-and-build type) I can test on Linux (I have no Mac, sorry). Also you might consider filing a bug report if everything else fails.
@SGaist That worked, thank you so much! One issue I may have however is that my main project is written in C++ and when I compile it in Objective-C++ with cmake (adding -x objective-c++ to compile flags), I get all sorts of errors with interpreting the generated .o files. I'm going to google around a bit with what I've learned here and see if I can make it work.
thanks for your help, I have tried to edit my odbc.ini the Mac refused to save the file... That's why I gave up.
As an intern, it's my tutor training who said to me to look at a native component. But if I can't find any solution I will come back to the first idea :)
Above, I describe a small stub setup that downloads a larger payload. However, if your payload is large from the server, you're going to be looking at the screen stuck at the "Running package scripts..." notice and a jammed progress bar while it continues to download over Curl your larger payload. One solution to that in your preinstall Bash script is to do this:
osascript -e 'tell application "System Events" to set visible of process "Installer" to false'
That super neat trick hides the installer so that you can show something else. That way, the customer doesn't think your installer just jammed.
Then, build yourself a simplistic ObjectiveC application that looks just like that Installer but shows a more active progress bar (use a timer) and then displays a few messages like "Downloading..." and "Finishing download..." and stuff like that. Of course, you can do it in Qt, but even the most minimum Mac-based Qt widget app (not statically compiled) is 8.9MB zipped, whereas in ObjectiveC you can make an app that does the same thing in a mere 32K (unzipped). (Oh, and for you QML die-hards out there, a widget-based app has you topped on file size. I was seeing 12.1MB zipped for something comparable in QML.)
Once that Curl has finished, it can then kill the ObjectiveC process and reverse the osascript to get the installer to show you the Finish page.
If deploying a large commercial application, and especially if you need to hook up special high-permission items and require script control, then you may not want to use either the .pkg or .dmg formats at all. This is because, psychologically, customers are not likely to want to download a huge honking 200MB+ DMG or PKG file. Instead, they would be more likely to download a smaller file, run it, and then when it says Installing, it does the rest of the download steps. (I know it's the same wait time, but psychology is important in product marketing.) Take a look at Norton's Antivirus for the Mac. (There's a free trial on their website.) They basically made an ObjectiveC / Cocoa application and then zipped it. However, it's a stub setup that's very small. When you run it, it then shows the typical EULA and then starts downloading components from the web, and putting things into the appropriate places.
Just thought of something: you are trying to cross-compile a linux kernel on OS X. You should rather create a virtual machine using e.g. VirtualBox and do everything directly form Linux. That will save you time.
Lists libraries that the target depends on. Some backends, such as the generators for Visual Studio and Xcode project files, do not support this variable. Generally, this variable is supported internally by these build tools, and it is useful for explicitly listing dependent static libraries.
Apparently I have to include the lib manually in the .xcodeproj file. That worked, but isn't Add Library... supposed to add the necessary commands to the .pro file?
Thank you very much, I used the work-around they proposed
(storing a copy of the certificate in the local resources of the app & adding that to the default CACertificate list before opening the socket)
I'm afraid this won't be a clean long term solution though (the certificate will stay valid for a while, but eventually expires I guess).
If anyone has any idea's for a more clean/permanent solution I'm very much open to suggestions.
In the mean time this will have to do.
Thanks again, I appreciate the comment
If I call glFinish() after my rendering is done, then I can make it work right (given that I specified double-buffering, otherwise the colors appear way too bright).
The downside is that with glFinish(), the rendering takes 30% longer..