On Thursday, September 6, 2012 14:22:28 Kevin Krammer wrote: > Without checking the implementation details I would have guessed that > "allowing content to be introspected" needs support for that introspection > in every single application
in the same way that every application that opens files stored on disk needs to support file open/read/write. in reality, very few of our applications make direct libc calls to achieve this and instead rely on (much) higher level libraries to keep such details at arms length. we don't even need to patch every single application thanks to KDE's libraries. by patching specific classes in our libs, we are able to get the functionality in many of our apps instantly. example: we have written and maintain a rather small patch that makes kparts use ResourceInstance. this small change in one library makes every single kparts-using application instantly work as desired. KDE's dev framework is pretty awesome like that. some applications will require some patches, however. that's already been done in dolphin (as one example), so we know how dificult it is: not very. these patches are small and very simple to write (i gave an example code snippet in a previous email), and only need to be done where other suitable frameworks (e.g. kparts) are not used. > and that support would need to be updated when > the introspector changes the way it introspects. that's why we have a library like libkactivities: to provide an easy to use, long-lived API that hides the implementation details. the API in libkactivities is built around the design ("expose what is being viewed in a window") not the implementation ("we connect to a daemon using dbus and then.."). the introspection mechanism is completely encapsulated in libkactivities and no application need (or should) care now or in the future about the implementation details. in frameworks 5 libkactivities will end up being a Qt- only library. the dbus API is also available in a well-formed dbus xml service definition so it can be readily reused by other applications which don't use Qt. so .. no. the individual application should never need to be updated even if kactivitymanagerd changes, is replaced, or whatever. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<