Re: Extra KDE Telepathy modules moving to Extragear
Are there any further objections to moving these forward into extragear? No objections, just a question: How much of this works on Windows ? Unsure about the call UI, but I presume the logger could at least ? Best Regards, Laszlo Papp
Re: Extra KDE Telepathy modules moving to Extragear
On Thu, Jun 7, 2012 at 4:42 PM, Laszlo Papp lp...@kde.org wrote:
Are there any further objections to moving these forward into extragear?
This is probably not the best way:
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/libktpcall/CMakeLists.txt#L25
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/src/CMakeLists.txt#L21
Also, FoobarConfig{Version}.cmake is in favor of FindFoobar.cmake in this case:
https://projects.kde.org/projects/kdereview/ktp-call-ui/repository/revisions/master/entry/cmake/modules/FindKTp.cmake
I do not find a shipped FoobarConfig{Version}.cmake for the other one.
Best Regards,
Laszlo Papp
Re: Extra KDE Telepathy modules moving to Extragear
No objections, just a question: How much of this works on Windows ? Unsure about the call UI, but I presume the logger could at least ? Last time I tried, I had issues with python3 that the KDE Windows project had been using. I have mentioned that to George. It would be nice in the future (so not now instantly) to get that resolved. I presume this would mean a python3 porting or some other way around. Best Regards, Laszlo Papp
Re: Extra KDE Telepathy modules moving to Extragear
On Sun, Jun 3, 2012 at 10:45 PM, Albert Astals Cid aa...@kde.org 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 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. Forgotten rather than ignored. Not that that's much of an excuse. Fixed now. Thanks. Albert David Edmundon
Re: Extra KDE Telepathy modules moving to Extragear
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
Re: Extra KDE Telepathy modules moving to Extragear
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
Re: Extra KDE Telepathy modules moving to Extragear
On 2012-04-28, George Kiagiadakis kiagiadakis.geo...@gmail.com 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. aren't you this way also locking your self to always require just to wrap the GObject classes and not actually have the possibility to do teh implementation without the GObject classes at all ? /Sune
Re: Extra KDE Telepathy modules moving to Extragear
On Sun, Apr 29, 2012 at 2:34 PM, Sune Vuorela nos...@vuorela.dk wrote: On 2012-04-28, George Kiagiadakis kiagiadakis.geo...@gmail.com 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. aren't you this way also locking your self to always require just to wrap the GObject classes and not actually have the possibility to do teh implementation without the GObject classes at all ? Yes, this is the design of QtGLib. Tbh, this was intended for use only in QtGStreamer, which couldn't ever possibly be separated from GObject, but it also ended up being used here. I'm not totally happy with it, but for the moment we can live with it. This is possibly going to change in the future. The API/ABI will need to break at some point anyway, as I will be doing adjustments in QtGLib/QtGStreamer to support Qt5 and GStreamer 1.0. Btw, Albert, there are indeed a couple of problems in certain classes and in the build system. I'll go through them in the next few days.
Re: Extra KDE Telepathy modules moving to Extragear
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. 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 signature.asc Description: This is a digitally signed message part.
Re: Extra KDE Telepathy modules moving to Extragear
On Thu, Apr 26, 2012 at 11:07 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 25 d'abril de 2012, a les 18:15:00, David Edmundson va escriure: We would like to move 2 more KDE Telepathy modules to Extragear, to join our existing code. KTp Call UI [1] Provides a GUI for making video calls in telepathy. For details see [2][3] Could you add some context to Answer? To the translator it's not obvious if it's the name or the verb that he is translating. Done. Telepathy Logger Qt [4] This provides Qt bindings for Telepathy-Logger a daemon that logs all text messages received. This is an optional dependency for ktp-text-ui which allows us to show a backlog and a way to view old log messages. This was imported from Collabora's git repository. I moved it into KDE playground where I'm maintaining it after Collabora seemed to lose any interest in keeping it up to date or making a release. This has been discussed on their mailing list. [5]. utils.h is installed but its class not exported? What's the reason for that? Looks like a mistake. I'll fix it. Some installed headers do not have a dpointer, i know this is a obscure library, but i think you should at least try to d-pointify them if you are making this a public library. 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.
Re: Extra KDE Telepathy modules moving to Extragear
El Dissabte, 28 d'abril de 2012, a les 16:08:41, George Kiagiadakis va escriure: On Thu, Apr 26, 2012 at 11:07 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 25 d'abril de 2012, a les 18:15:00, David Edmundson va escriure: We would like to move 2 more KDE Telepathy modules to Extragear, to join our existing code. KTp Call UI [1] Provides a GUI for making video calls in telepathy. For details see [2][3] Could you add some context to Answer? To the translator it's not obvious if it's the name or the verb that he is translating. Done. Telepathy Logger Qt [4] This provides Qt bindings for Telepathy-Logger a daemon that logs all text messages received. This is an optional dependency for ktp-text-ui which allows us to show a backlog and a way to view old log messages. This was imported from Collabora's git repository. I moved it into KDE playground where I'm maintaining it after Collabora seemed to lose any interest in keeping it up to date or making a release. This has been discussed on their mailing list. [5]. utils.h is installed but its class not exported? What's the reason for that? Looks like a mistake. I'll fix it. Some installed headers do not have a dpointer, i know this is a obscure library, but i think you should at least try to d-pointify them if you are making this a public library. 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. What about the SearchHit struct? On a second header inspection i've also found a weird \ in pending-search.h Cheers, Albert
Re: Extra KDE Telepathy modules moving to Extragear
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. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Extra KDE Telepathy modules moving to Extragear
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. 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. [1] - http://telepathy.freedesktop.org/wiki/Logger -- Martin Klapetek | KDE Developer
Re: Extra KDE Telepathy modules moving to Extragear
El Dimecres, 25 d'abril de 2012, a les 18:15:00, David Edmundson va escriure: We would like to move 2 more KDE Telepathy modules to Extragear, to join our existing code. KTp Call UI [1] Provides a GUI for making video calls in telepathy. For details see [2][3] Could you add some context to Answer? To the translator it's not obvious if it's the name or the verb that he is translating. Telepathy Logger Qt [4] This provides Qt bindings for Telepathy-Logger a daemon that logs all text messages received. This is an optional dependency for ktp-text-ui which allows us to show a backlog and a way to view old log messages. This was imported from Collabora's git repository. I moved it into KDE playground where I'm maintaining it after Collabora seemed to lose any interest in keeping it up to date or making a release. This has been discussed on their mailing list. [5]. utils.h is installed but its class not exported? What's the reason for that? Some installed headers do not have a dpointer, i know this is a obscure library, but i think you should at least try to d-pointify them if you are making this a public library. Cheers, Albert Thanks in advance David Edmundson [1] https://projects.kde.org/projects/kdereview/ktp-call-ui [2] http://gkiagia.wordpress.com/2012/03/29/video-calls-in-kde-telepathy/ [3] http://community.kde.org/Real-Time_Communication_and_Collaboration/Componen ts/Call_UI [4] https://projects.kde.org/projects/kdereview/telepathy-logger-qt [5] http://mail.kde.org/pipermail/kde-telepathy/2012-January/005064.html
Extra KDE Telepathy modules moving to Extragear
We would like to move 2 more KDE Telepathy modules to Extragear, to join our existing code. KTp Call UI [1] Provides a GUI for making video calls in telepathy. For details see [2][3] Telepathy Logger Qt [4] This provides Qt bindings for Telepathy-Logger a daemon that logs all text messages received. This is an optional dependency for ktp-text-ui which allows us to show a backlog and a way to view old log messages. This was imported from Collabora's git repository. I moved it into KDE playground where I'm maintaining it after Collabora seemed to lose any interest in keeping it up to date or making a release. This has been discussed on their mailing list. [5]. Thanks in advance David Edmundson [1] https://projects.kde.org/projects/kdereview/ktp-call-ui [2] http://gkiagia.wordpress.com/2012/03/29/video-calls-in-kde-telepathy/ [3] http://community.kde.org/Real-Time_Communication_and_Collaboration/Components/Call_UI [4] https://projects.kde.org/projects/kdereview/telepathy-logger-qt [5] http://mail.kde.org/pipermail/kde-telepathy/2012-January/005064.html
