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
Fwd: Drkonqi - i find an original message ambiguous
Initially i sent this message to the kde-doc list but i was suggested to send it in this list: -- Προωθημένο μήνυμα -- Θέμα: Drkonqi - i find an original message ambiguous Ημερομηνία: 04/06/2012, 08:50:11 Dimitrios GlentadakisΑπό: dgl...@gmail.com Προς: KDE i18n-doc kde-i18n-...@kde.org Κοιν.: andresbajotie...@gmail.com In drkonqi when we are in the step with the window with the probably duplicate reports, we have the buttons: Open selected report, Back 'Forward. If we select a report and click on Next the report it is not selected (we have a message that there is no report selected). What we have to do is to click on Open selected report and after click on Suggest this report I think that the button's name Open selected report it is ambiguous. It does nt only open the report but it selects it too. Every time that i am in this step i am not sure for what i have to do. Click on the duplicate and click on Next or Open the selected report first. http://quickgit.kde.org/index.php?p=clones%2Fkde-runtime%2Fgkiagia%2Fdrkonqi.gita=blobh=e2c16333eccfa557055536c05e68c7bf7c00f93fhb=7ba590f06160120fbf6eb65523f740054001fa13f=drkonqi%2Freportassistantpages_bugzilla_duplicates.cpp *I wrote it here because i did nt found a mailing list for drkonqi - -- Dimitrios Glentadakis
Re: Please fix nepomuk-core buildsystem
Please note, that these (this issue, and the two others reported by Albert to k-c-d) are not just random reports, but problems Albert found while preparing the beta1 packages. These issues are very annoying, yet we didn't consider them showstoppers for the 4.9 beta1, but they might become showstoppers in one of the next pre-releases. We'd like this to not escalate through the release team, as it will endanger our releases (we have only very limited manpower and cannot do all kinds of fixes, we rely on responsible developers for that.) On Sunday, June 03, 2012 18:59:41 Albert Astals Cid wrote: I find it quite annoying that it tells me -- Soprano version 2.7.5 is too old. Please install 2.7.56 or newer and then tells me - -- The following external packages were located on your system. -- This installation will have the extra features provided by these packages. --- -- * Soprano - Soprano is the Qt-based RDF storage and parsing solution - -- Congratulations! All external packages have been found. - If i get a Congratulations! message I expect that it will build. Cheers, Albert -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Please fix kde-runtime buildsystem
On Sunday, June 03, 2012 08:26:36 PM Albert Astals Cid wrote: If kactivities is not found it gives --- CMake Error at plasma/declarativeimports/plasmaextracomponents/CMakeLists.txt:3 (find_package): Could not find module FindKActivities.cmake or a configuration file for package KActivities. Adjust CMAKE_MODULE_PATH to find FindKActivities.cmake or set KActivities_DIR to the directory containing a CMake configuration file for KActivities. The file will have one of the following names: KActivitiesConfig.cmake kactivities-config.cmake Is KActivities intended to be found via its installed config.cmake file ? If so, please add the NO_MODULE parameter to the find_package() call. This makes it clear that the config.cmake file is searched, and that not FindKActivities.cmake should be there. Alex --- It should use a proper macro_log_feature reporting system. Cheers, Albert
Re: Please fix kde-runtime buildsystem
On Sunday, June 3, 2012 20:26:36 Albert Astals Cid wrote: If kactivities is not found it gives done. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
kdelibs splitting: May results, plans for June
Hello, So May was beautiful, so much that I almost forgot to send now my traditional what happens in the kdelibs splitting email. That's what you get for spacing out in the garden I guess... :-) # May results So you're probably all wondering did we perform better in May than April?. Turns out we did! So it seems the change of plans to get as much of kdeui out of the way as possible was a good move. Thus all the splits planned for May were completed in time. We completed the following three new frameworks: * karchive * kconfig * kidletime # Plans for June June presents a similar picture than May. It's light on the number of frameworks we want to split. Namely the following ones are planned: * kbookmarks (Julien Desgats volunteered to do the split and maintain it); * kservice (no volunteer yet although David started some of the work AFAICT); * kconfiggui (which turned out to be done alongside the rest of kconfig in May). That should put us in a good position to complete that batch as there should be no real blocker. # A few words about kdeui Work on kdeui continues in the background, mainly led by Stephen who moves classes as he goes. Most of it should be moved in new frameworks by the end of July. Hopefully we'll see great progresses around it during Akademy. # It's not only about splitting! Since it's apparently necessary to remind it, here is a specific section: I covered here the splitted (or to be splitted frameworks), but it's not the only work going on! We also have background work on general cleanups in kdelibs which enable those splits. Feel free to volunteer for those cleanups, they are generally easier tasks and more self-contained than splitting a full fledged framework. Details here: http://community.kde.org/Frameworks/Epics/kdelibs_cleanups Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
