I'm not aware of all these KDE intrinsics.<br>But I applaude any initative to make KConfig-related classes more lously-coupled.<br><br>Elektra developers had a bad time writing an Elektra backend to KConfig because the interfaces and implementations could not be separated very well, in semantics and in code. So what we saw is that KConfig is very tight to the INI-file implementation.
<br><br>Regards,<br>Avi<br><br><div><span class="gmail_quote">On 5/17/06, <b class="gmail_sendername">Aaron J. Seigo</b> <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
hi....<br><br>for kconfig having multiple backends, it makes the most sense to allow people<br>to provide backends as plugins. the "natural" way of doing this is to query<br>ksycoca for KService's that match, for instance, "KConfigBackend" as their
<br>type.<br><br>of course KService is in kio, however. so this doesn't work. which leaves me<br>with two options:<br><br>a) do everything by hand in KConfig duplicating a lot of KService code<br>b) move the essential KService stuff into kdecore alongside KSycoca*
<br><br>option 'a' is pretty unappealing. unfortunately, option 'b' ends up winding<br>down a long dependency chain. it really gets nasty when KService makes it's<br>one and only call into KServiceTypeFactory with:<br><br>
        t = KServiceTypeFactory::self()->findPropertyTypeByName(_name);<br><br>KServiceTypeFactory relies on KMimeType ... and on and on... well,<br>KServiceTypeFactory has findPropertyByName simply because it is where
<br>KSycoca's header is parsed out into a property dict. i'm thinking that it<br>would be easiest to move this one bit of functionality into KSycoca to remove<br>the dependency.<br><br>that would leave a dependency on KServiceFactory due to 7 methods in KService
<br>that simply wrap KServiceFactory methods that are named exactly the same.<br>typical example is:<br><br>        KService::List KService::allServices()<br>        {<br>          return KServiceFactory::self()->allServices();
<br>        }<br><br>deprecating these static functions in KService and requiring the use of<br>KServiceFactory means no dependency on KServiceFactory.<br><br>this would allow KService to moved into kdecore by itself with KSycoca (and
<br>various Qt classes) being it's only remaining dependencies.<br><br>the downside to this is that KService and the KService "convenience" methods<br>such as KServiceFactory end up in two different libs. but as it is KSycoca
<br>which is pretty key to all these things is already in kdecore and separate<br>from kio.<br><br>what are your thoughts? objections? better ideas?<br><br>--<br>Aaron J. Seigo<br>GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
<br><br>Full time KDE developer sponsored by Trolltech (<a href="http://www.trolltech.com">http://www.trolltech.com</a>)<br><br><br></blockquote></div><br>