kservice/docs/servicetype-inheritance-design.txt

0001 Service types
0002 =============
0003 A service type is a capability that a set of services (applications or plugins) have.
0004 For instance the service type KParts/ReadOnlyPart means "this plugin has the capability
0005 to provide a class that derives from KParts::ReadOnlyPart" (i.e. an embeddable viewer).
0006 The coincidence in naming is just a coincidence, we could have named that servicetype
0007 "EmbeddableKPartsViewer" or whatever, it's just a name.
0008
0009 A service type is defined by a .desktop file (installed into the servicetypes directory),
0010 containing name, translated description, and a few additional things like inheritance
0011 and additional properties.
0012
0013 Mime types
0014 ==========
0015 In KDE3 and KDE4, a mimetype was a special kind of servicetype.
0016 However since KF5 we are moving away from this, and splitting out the two.
0017 This document was written before that, however.
0018
0019 Service type inheritance (X-KDE-Derived)
0020 ========================================
0021 X-KDE-Derived is the desktop file key that defines inheritance for a service type.
0022 "ST1 derives from ST2" means "ST1 is more specific than ST2".
0023 If a service implements ST1, it also implements ST2, but not the other way round.
0024
0025 For instance, KoDocument derives from KParts/ReadWritePart, which derives from KParts/ReadOnlyPart,
0026 so KWord's part (which implements KoDocument) can be used as a readonly viewer for KWord files
0027 in Konqueror (which looks for a KParts/ReadOnlyPart).
0028
0029 Mimetype "inheritance"
0030 ======================
0031 For mimetypes, we need a mechanism to also say that "text/xml is a special case of text/plain",
0032 or "text/docbook is a kind of text/sgml", or "application/x-smb-workgroup is a kind
0033 of inode/directory", etc. See below.
0034
0035 Why mimetype "inheritance" doesn't use X-KDE-Derived
0036 ====================================================
0037 The confusing thing is that we said "a mimetype is a servicetype". But that's not exactly correct.
0038 As Waldo noted, "the ability to open a mimetype" is what's a servicetype.
0039 So if text/xml said X-KDE-Derived=text/plain (i.e. ST1=text/xml, ST2=text/plain),
0040 then an application opening text/xml (ST1) would end up being associated with any text/plain (ST2) file,
0041 which would be wrong.
0042
0043 We want the other way round: to be able to open special kinds of text/plain in a plain text editor.
0044 This is why mimetypes have their own inheritance mechanism ("X-KDE-IsAlso" in KDE3, and since KDE4,
0045 the inheritance mechanism defined in shared-mime-info).
0046 It kind of "works the other way" than X-KDE-Derived.
0047 If M1 is a special kind of M2 (mimetypes), then "the ability to open M2" derives from "the ability to open M1"
0048 The ability to open any text/plain file derives (is more specific than) the ability to open text/xml only.
0049 "text/xml inherits from text/plain" means that applications that can open text/plain can also open text/xml.