Re: Review Request: KJS: Implement Object.GetOwnPropertyDescriptor & Object.DefineProperty

Re: Review Request: kjs: Implement JSON.stringify

Re: Review Request: kjs: Implement Object.create

Re: Review Request: Remove additional directories from shortcuts scheme export path

Re: Review Request: kjs: Implement Object.create

Re: Review Request: KJS: Implement Object.GetOwnPropertyDescriptor & Object.DefineProperty

Please fix nepomuk-core buildsystem

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

Please fix kde-runtime buildsystem

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
-----------------------

It should use a proper macro_log_feature reporting system.

Cheers,
  Albert

Please fix kde-runtime buildsystem (2nd issue)

It seems kde-runtime needs shared-desktop-ontologies 0.9

I would a macro_log_feature error instead of  
nepomuk/kioslaves/nepomuk/resourcepagegenerator.cpp failing to compile

Cheers,
  Albert

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
> 
> <david <at> davidedmundson.co.uk> wrote:
> > On Sun, Apr 29, 2012 at 2:42 PM, Kevin Krammer <krammer <at> kde.org> wrote:
> >> On Sunday, 2012-04-29, Martin Klapetek wrote:
> >>> On Sat, Apr 28, 2012 at 22:44, Kevin Krammer <krammer <at> 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