On Sun, Jun 3, 2012 at 10:45 PM, Albert Astals Cid <[email protected]> wrote: > 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 >> >> <[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? > > Yes, my mail about SearchHit struct and weird \ in pending-search.h seems to > have been ignored. > Forgotten rather than ignored. Not that that's much of an excuse.
Fixed now. Thanks. > Albert > >> >> David Edmundon
