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.
