On Donnerstag, 25. Juli 2013 14:06:44 CEST, Pali Rohár wrote:
It looks like that shared kde4 kabc library which is linked to
kde addressbook trojita plugin (which was loaded before kwallet
plugin). Order of loading trojita plugins is now undefined. And I
do not want to have some linear ordering for loading plugins...
No, but you could ensure to have a proper KComponentData in place before
touching the problematic code in the kabc lib (unless it had a static call on
lib instantiation... but that would make little sense and break and break about
every KDE application linking it) - likely some constructor.
This my change only set program name only if current name is
empty.
What i meant is that your code can fail for changes out of your control.
Right now it looks like:
const KComponentData &KGlobal::mainComponent()
{
PRIVATE_DATA;
return d->mainComponent.isValid() ? d->mainComponent : *fakeComponent;
}
but could eg. change to
const KComponentData &KGlobal::mainComponent()
{
PRIVATE_DATA;
KComponentData data(d->mainComponent.isValid() ? d->mainComponent :
*fakeComponent); // return is const, so we can legally enforce that condition
return data;
}
or on an ABI break:
KComponentData KGlobal::mainComponent() // spot missing "&"
{
PRIVATE_DATA;
return d->mainComponent.isValid() ? d->mainComponent : *fakeComponent;
}
I don't say this will happen, but could.
Also the programName() becomes arbitrary for other users - what if kabc or akonadi or
whatever tries to internally use kwallet as well before this plugin "fixed" it?
The normal approach is to create the proper component data before instantiating the
KApplication (and pass it), since that's not possible in this case, it should be ensured
to be "correct" before ever possibly touched, ie. all KDE related code should
first ensure to set a common component data (content)
Thomas
