View Single Post
Old 04-08-2017, 09:23 AM   #63
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 28,771
Karma: 206758686
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
Quote:
Originally Posted by KevinH View Post
Normally with framework builds, the relative location of Plugins within the app is set and if you stick with convention no qt.conf file is needed.
That certainly covers the Sigil Qt application itself. But I think you'll find it leaves the Python application (which we launch externally and use to call the PyQt modules--and thus Qt) out in the cold.

That's why I explicitly control the external Python's QProcessEnvironment in PluginRunner:
so I can set the "QT_QPA_PLATFORM_PLUGIN_PATH" and "QT_PLUGIN_PATH" variables for that particular instance of the Python interpreter. Which is not possible when instructing Python to ignore all Python environment variables by launching it with the "-E" switch. The other option was to put a qt.conf file with the correct paths in the bundled Python executable's folder. A solution I found unsatisfactory for my Win/Lin needs (though I think I did include a qt.conf file there in my experimental Linux Sigil binary installer for good measure).

Last edited by DiapDealer; 04-08-2017 at 09:26 AM.
DiapDealer is offline   Reply With Quote