El Dijous, 31 de maig de 2012, a les 20:10:08, David Edmundson va escriure: > On Mon, Apr 30, 2012 at 11:28 PM, David Edmundson > > <da...@davidedmundson.co.uk> wrote: > > On Sun, Apr 29, 2012 at 2:42 PM, Kevin Krammer <kram...@kde.org> wrote: > >> On Sunday, 2012-04-29, Martin Klapetek wrote: > >>> On Sat, Apr 28, 2012 at 22:44, Kevin Krammer <kram...@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. > > > > 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?
Yes, my mail about SearchHit struct and weird \ in pending-search.h seems to have been ignored. Albert > > David Edmundon