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