Qt.conf since 5.3.1 ignored ?

[sierdzio]

This question is more suited for Interest mailing list, where much more Qt developers can read and respond. I suggest sending a message there.

[nen777w]

Ok, thanks.
Could you get me detailed information about this mailing list?

[sierdzio]

Sure. "Link":http://lists.qt-project.org/mailman/listinfo/interest.

[hskoglund]

Hmm (sorry sierdzio for answering here ;-) but it sounds like you've been bitten by "this bug":https://bugreports.qt-project.org/browse/QTBUG-38598

Perhaps you are calling QCoreApplication::applicationDirPath() before QApplication app (argc, argv)?

[sierdzio]

No need to apologise, this is an important hint.

-I think it is vitally important to remember, that Qt does not support instantiating any QObjects before QCoreApplication is constructed. If you do that, you are on your own (which sort of makes that bug invalid). Looking through Qt docs right now, I notice that this fact is not mentioned by the documentation. I am not an expert on this, but I think that is a bug instead.-

Edit: apologies, the paragraph above is only true for QApplication and UI objects (QWidgets).

Edit 2: actually, it's not as easy. See my next post.

[hskoglund]

Well that bug was reported because of "this discussion":http://qt-project.org/forums/viewthread/41594/

-You mean if I call the static method QCoreApplication::libraryPaths() it creates a QObject for me?-
sorry talking too much in telephone, didn't see your edit :-)

[sierdzio]

I have found the conversation I have based my last post on: "link":http://comments.gmane.org/gmane.comp.lib.qt.user/13469.

Thiago, who advances the claim that you should always construct a Q*Application first, is the maintainer of QtCore module and has deep knowledge of how it all works internally.

[hskoglund]

Interesting, I like Thiago's answer: "Qt is not supported before the creation of QCoreApplication. Your use-case is not supported, so no answer is necessary."
He's right, if you look at the startup source code, you'll see that Qt is a bit confused/braindead before the constructor is done.

[A Former User]

qlibraryinfo.cpp line 154:
QSettings *QLibraryInfoPrivate::findConfiguration()

Does Qt find the path to the qt.conf?

[nen777w]

I'm sorry I forgot write about result.
Was and not working:
@
QSettings settings_app(APP_VENDOR_NAME_C, APP_NAME_C SETTING_APP);

if(!settings_app.value(KEY_NATIVE_UI, false).toBool()) {
    QApplication::setStyle(new CMStyle());
}    

QApplication a(argc, argv);

@

Become and working:
@
QApplication a(argc, argv);

QSettings settings_app(APP_VENDOR_NAME_C, APP_NAME_C SETTING_APP);

if(!settings_app.value(KEY_NATIVE_UI, false).toBool()) {
    QApplication::setStyle(new CMStyle());
}

@

The reason in following: befor version 5.3.1 this call QApplication::setStyle(new CMStyle()); did not lead to the initialization of the search paths plugins.
I. e. it happened when QApplication is constructed.

see QFactoryLoader::update() line 114 call:
QStringList paths = QCoreApplication::libraryPaths();

But from 5.3.1 when you call the installation style QApplication :: setStyle () initializes the variable which keep the path to the plug-ins
(But plugins is not being loaded YET !!!, just intialize) but when QApplication is constructed, Qt "sees" that the path to the plug-ins already have and ignores the path from the config and load libraris with plugins.

see: qtbase/src/corelib/plugin/qlibrary_win.cpp function
bool QLibraryPrivate::load_sys() line 117
pHnd = LoadLibrary((wchar_t*)QDir::toNativeSeparators(attempt).utf16());
This is the place where plugins dll is loading.