Missing KServiceType Info

[ian geiser]

On Monday 07 February 2005 01:32 pm, David Faure wrote:
> On Monday 07 February 2005 14:21, ian geiser wrote:
> > On Monday 07 February 2005 05:57 am, David Faure wrote:
> > > On Sunday 06 February 2005 20:05, Ian Reinhart Geiser wrote:
> > > > Greetings,
> > > >  I am trying to get a list of propties for a given service type using
> > > > the servicetype info from the KServiceType class.  But for the life
> > > > of me I cannot figure out where stuff like X-KDE-Library is defined.
> > >
> > > As I found out myself the hard way, and documented in the KTrader
> > > online doc, X-KDE-Library is a bit special because it is published as
> > > "Library" in the service properties, and not "X-KDE-Library" like one
> > > would expect.
> >
> > Okay, this is interesting, so why is it not found in the KServiceType
> > properties?
>
> It's a standard KService property. I think you're confusing KService and
> KServiceType. KServices (apps and modules) can have properties (Foo=Value).
> The KService class itself knows the builtin ones. Custom ones can be
> defined in custom service types (e.g. all koffice services have an
> X-KDE-NativeOasisMimeType property, defined in kofficepart.desktop).
>
> Service types themselves can have properties (like X-KDE-text in mimetype
> .desktop files), but that's completely unrelated (the servicetype defines
> the type AND the value).
>
Okay this makes a bit less sense then.  I had hoped there was a rational 
explanation for this.  Basicly whats confusing is from what you are saying 
services can randomly declare any property they please as long as it has 
X-KDE- in the front?  All this confusion seems like overkill, basicly all i 
really wanted to do was get the possible properties for each service via some 
API.  If I understand what you are saying, this is impossible save for some 
random cases where the service type actually defines a value for what seems 
to me as a completely random reason ;)

Now I'm sure you have an answer that makes perfect sense to you, so ideally 
you can share it.
> > So why are so many of them missing?
>
> I see none missing. Can you be more specific?
>
I guess this is my confusion over where some of these properties come from. 
Are there rules for different service types?  I understand if a KPart gets a 
Library tacked on (that is really X-KDE-Library) but is this gets confusing 
fast since there is no clear documentation on what properties are silently 
added to each type.  If I understand what you are saying DocPath, 
X-KDE-Library and InitialPreference are magicly added in some cases that 
still remain unclear, but are explicitly not added by placing this data in a 
service type description file.

> > So what about Initial Preference, Keywords etc... ?  There are tons of
> > properties that are available in service desktop files that are defined
> > nowhere.
>
> They are defined by the fact that they are returned by
> KService::propertyNames(). Or what do you mean? You mean in terms of
> documentation?
Why are some properties returned by KService and some by KServiceType?  This 
is very confusing. 
> > > > Do we add these buggers automagicly somewhere?  Do we need to update
> > > > our service type files?
> > >
> > > No and no :)
> >
> > Why, and why? ;)
>
> Because they are simply all equal to the fields we read from any service -
> no matter of which service types. Type, Name, Comment, GenericName, Icon,
> etc. etc.
Okay now that I have pointed out that this makes even less sense than when I 
had talked to Waldo, I am going to try to get this thread back under control.  
Now I am sure there is some wildly clever and magical way this all works, but 
lucky I'm not interested.  Basicly all I want to do is say: "Give me all the 
properties for the 'KParts/ReadOnlyPart'" and be returned a list of these 
properties so I can populate them without having to note every single service 
type out there.  Now there are hints that KServiceType can do this.  Yet this 
fails in most cases.  A good example is KDevelops 
"kdevpart_documentation.desktop".  Now this may very well be a bug on their 
end, so bear with me.  If I ask KServiceType for all of the properties as 
well as the parents properties I get the standard Name, Icon, Comment etc.. 
but there are properties: X-KDevelop-Mode, X-KDevelop-Scope and 
X-KDevelop-Version that do not appear in that list.  If I grasp what you are 
saying above, this is okay, and developers can do this.  The thing that 
bothers me is why is it okay that they do not have to be in the KServiceType 
then, or is this a bug on KDevelop's part?  

I apologize about being so dense on this but this (other than xmlgui) has to 
be the most unclear, undocumented, and complex part of KDE ;)

Cheers
 -ian reinhart geiser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050208/6eb3088c/attachment.sig>