KCModuleInfo (Was: Strange problem with KControl)

Matthias Kretz kretz at kde.org
Wed Sep 3 12:39:05 BST 2003


On Wednesday September 03 2003 13:13, Waldo Bastian wrote:
> On Tuesday 02 September 2003 12:55, Sven Lueppken wrote:
> > Hi!
> >
> > I started KControl a few minutes ago and experienced the problem which is
> > shown in the attached screenshot...I don't know what's the problem
> > though, I ran kbuildsycoca but no changes. Maybe the XDG changes from
> > yesterday have something to do with that?
>
> The problem is in KControl. In particular the KCModuleInfo constructor
> tries to derive the group the module should be listed under from the path
> of the . desktop file. That's wrong, it's KServiceGroup that should define
> the grouping.
>
> I don't really understand what KCModuleInfo::groups() is supposed to
> return. One constructor fills it with the path of the desktop-path, while
> the other one fills it with the contents of "X-KDE-Groups".

Yep, that's my code (the 2nd ctor). I disliked the way the _groups variable 
was read in the 1st ctor, but I didn't dare breaking existing (working) code.

> And to make it all slower it reads this last bit of information from the
> desktop file instead of retrieving it from the KService object.

The loadAll() method? I can add the according properties to the servicetype 
and then the method can read it from the service object, ok?

> The way it derives the filename of the .desktop file also assumes that the
> KService is of type "Service" and not of type "Application". I doubt that
> is intended since it isn't reflected in either the docs or assured with an
> assert()

That's only the 2nd ctor, and that one is only used for KSettings::Dialog 
stuff.

> The two constructors can be merged for a great deal btw when you realize
> that you can create a KService using the "KService( const QString &
> _fullpath );" constructor. For those odd cases where your service isn't
> stored in sycoca already. I doubt that happens very often in practice, you
> are probably better of with only the constructor that takes KService and in
> the odd case that the caller wants to use a KService that isn't in KSycoca
> he can create one himself.

The second ctor has never been used for KControl so far...

> I don't see any .desktop file that actually contains "X-KDE-Groups" btw. Is
> this a new feature?

Yes, new - I'm using it in my almost fixed KView locally

To the KServiceGroup thing:
You mean, that the _groups variable should be read from 
KServiceGroup::baseGroupName()? (/me didn't see that method before, so we 
could probably get rid of X-KDE-Groups)

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030903/0442e667/attachment.sig>


More information about the kde-core-devel mailing list