[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Proposal: move libKMetaData (aka Nepomuk-KDE) into kdelibs
From:       Sebastian =?utf-8?q?Tr=C3=BCg?= <strueg () mandriva ! com>
Date:       2007-03-13 8:27:59
Message-ID: 200703130928.00078.strueg () mandriva ! com
[Download RAW message or body]

On Monday 12 March 2007 22:37:59 Aaron J. Seigo wrote:
> On March 12, 2007, Sebastian Trüg wrote:
> > it took way longer than I hoped but finally KMetaData has reached a state
> > that allows a move to the kdelibs.
>
> personally, i appreciate that you took the time it needed.
>
> > There is still some work to be done and
> > not everything is final but I think it is time that more people have a
> > look at it and find weaknesses through usage.
>
> i agree that it should be moved to kdesupport and kdelibs as you noted, and
> that the Next Steps you outlined make a good amount of sense.
>
> some comments on the API:
>
> kmetadata/datetime.h. it's really just a namespace rather than a class, no?
> would it make sense to merge the parsing functionality into KDateTime
> (kdelibs/kdecore/data/kdatetime.h)? in fact, does KDateTime::fromString
> with TimeFormat ISODate already do what you need? (ditto for toString)

Hey, I did not see that. Yes, of course it can be merged and yes, probably it 
already does what I need. Hmm.. there is a lot of "hidden" power in the 
kdelibs.

> would you be adverse to switching the code style to the kdelibs style[1]?

without a doubt. There is an xemacs file for that in kdesdk, right?

> why are there public data members (even though they are static and const)
> in ontology.h? would an accessor in the implementation that returns a
> string literal be enough?

The Ontology class is bad and needs to be rewritten to represent an arbitrary 
ontology. I'd like to combine it with an ontology parser. Combined with RDF/S 
labels and comments in different languages it will then provide names and 
tooltips for all known metadata types. This will allow for GUIs to display 
arbitrary metadata without knowing what it is about.
And yes, there is no need for public static members. It was just the quickest 
way to go about it at the time.

> are the OTHERCLASSES and METHODS special flags in resource.h perhaps a bit
> generic? could they be given names that are more explanatory or is that out
> of your hands? either way a bit of a comment before each of them might make
> it easier for those who come after to understand why they are there?

We can give them names as we please. They are replaced by the lass generator 
to expand the Resource class. Maybe I should even rename resource.h to 
resource.h.in?

> is the rcgen app meant to be installed? if so, perhaps it should have a
> less generic name as well?

Yes, it will be installed at some point. It is not yet and for that we need a 
better name.

> i'd also recommend not providing a BC guarantee in 4.0 for this new set of
> APIs so we have the opporutnity to fix problems if they arise for 4.1.

agreed.

> [1] http://techbase.kde.org/Policies/Kdelibs_Coding_Style


thanks, Aaron.
I will fix the code style and look at KDateTime as a replacement for 
KMetaData::DateTime.

Cheers,
Sebastian

[prev in list] [next in list] [prev in thread] [next in thread]