On Mon, Apr 30, 2012 at 11:28 PM, David Edmundson <[email protected]> wrote: > On Sun, Apr 29, 2012 at 2:42 PM, Kevin Krammer <[email protected]> wrote: >> On Sunday, 2012-04-29, Martin Klapetek wrote: >>> On Sat, Apr 28, 2012 at 22:44, Kevin Krammer <[email protected]> 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. >> > Yes, starts whilst you're chatting. Closes when you're done. >> >> My best guess so far is that there is some library that provides read-only >> access to files the independent logger writes onto disk. >> > > Your guess is effectively correct. Telepathy-logger is a bit more > complex as it writes to and reads from multiple backends. > XML files or SQLite and it also reads (read only) Pidgin log files as > their way of importing old log files. > >>> 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. >> > If we ever implemented it natively I would make so many other changes > to the API that I would bump the major version number and not even try > to keep compatibility. > >> Cheers, >> Kevin >> >>> [1] - http://telepathy.freedesktop.org/wiki/Logger >> >> -- >> Kevin Krammer, KDE developer, xdg-utils developer >> KDE user support, developer mentoring
*bump* So to summarise so far: There were some issues with call-ui which are now all fixed. There were also comments about gobjects in the telepathy-logger and d-pointers which I disagree with and have hopefully explained my rationale. Are there any further objections to moving these forward into extragear? David Edmundon
