ksycoca improvements (Re: assert in kservicetypefactory.cpp)

Martin Graesslin mgraesslin at kde.org
Mon Aug 24 09:08:08 UTC 2015


On Monday, August 24, 2015 10:58:30 AM CEST Martin Graesslin wrote:
> On Monday, August 24, 2015 10:39:57 AM CEST you wrote:
> > On Monday 24 August 2015 10:00:43 Martin Gräßlin wrote:
> > > Am 2015-08-24 01:03, schrieb Kevin Funk:
> > > > Right now whenever I start kdevelop I get the following daemons up and
> > > > running
> > > > on Windows:
> > > > - dbus-daemon
> > > > - kded5
> > > > - kglobalaccel5
> > > > - kioslave
> > > > - klauncher
> > > 
> > > KGlobalAccel should only be started if there is something trying to
> > > interact with KGlobalAccel (it's dbus activated). A git grep in kdevelop
> > > doesn't show it to be used. So I assume it might be a kdevelop-plugin or
> > > maybe a kded module? In general I think there shouldn't be a reason for
> > > kglobalaccel to be started in the case of kdevelop. That certainly
> > > sounds wrong.
> > 
> > I think that kglobalaccel5 is invoked as soon as KXmlGui gets involved
> > (which KDevelop makes use of).
> > 
> > Code in kxmlgui.git somewhat agrees: There are references to
> > KGlobalAccel::self() in, which will initialize KGlobalAccel which in turn
> > starts the kglobalaccel5 daemon (right?). Looks like that is only being
> > done if *global* shortcuts are involved, but I'm not sure whether I'm
> > "free" of global shortcuts...
> 
> I'll have a look at kxmlgui. There certainly should not be calls to
> KGlobalAccel if no global shortcuts are used.

The problematic call seems to be:
KActionCollection::addAction

which interacts with KGlobalAccel::hasShortcut. I'll investigate whether this 
can be changed in a way that kglobalaccel won't be started.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150824/13540fbc/attachment.sig>


More information about the Kde-frameworks-devel mailing list