Extra KDE Telepathy modules moving to Extragear

Kevin Krammer krammer at kde.org
Sun Apr 29 14:42:10 BST 2012


On Sunday, 2012-04-29, Martin Klapetek wrote:
> On Sat, Apr 28, 2012 at 22:44, Kevin Krammer <krammer at kde.org> wrote:
> > On Saturday, 2012-04-28, George Kiagiadakis wrote:
> > > No, the classes that wrap GObjects do not need a d-pointer. All the
> > > calls are forwarded to the underlying GObject and if for any reason we
> > > ever need to save extra data on the wrapper class (which is highly
> > > unlikely), we should use the GObject qdata for that. Wrapper classes
> > > may be destroyed and re-allocated by QtGLib and therefore they
> > > shouldn't hold any data.
> > 
> > So the GObject has a d-pointer?
> > 
> > Any specific reason there is a GObject at all? My very basic
> > understanding of
> > Telepathy was that it is D-Bus based services.
> 
> Telepathy is based on D-Bus services, however this is about Telepathy
> logger [1], which is a GObject-based implementation of a central logging
> Telepathy component, which does not use D-Bus for sending the logs as it is
> quite heavy data and D-Bus for this purpose is rather slow, so it provides
> a direct access API.

The documentation you linked to seems to be quite of of date (most of the 
links in it don't work), so I would still need some clarifications.

The document claims that the logger is an independent service, i.e. it says: 
"Telepathy Logger is a session daemon".

I quite don''t understand the term direct access API in the context of a 
daemon.

Usually daemon refers to a separate process. Communicating with a process is 
to my best understanding never done by linking the daemon code into the client 
applications.

My best guess so far is that there is some library that provides read-only 
access to files the independent logger writes onto disk.

> Our telepathy-logger-qt, which we want to move to
> Extragear, basically just wraps the original logger into Qt-like API, so
> that it can be used with Qt/KDE apps easily.

Based on my guess I would strongly recommend to put the wrapped GObject into 
the wrapper's d-pointer. Otherwise your only way of ever implementing that 
natively is to name a struct GObject and use that as the native 
implementation's d-pointer, making it very hard for any using application to 
link with any library exposing GObject symbols.

Cheers,
Kevin

> [1] - http://telepathy.freedesktop.org/wiki/Logger

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120429/4d927724/attachment.sig>


More information about the kde-core-devel mailing list