Development of kdelibs 5.0 has begun in the framework branch of its git repository. The main goal for kdelibs 5.0 is that there will be no more kdelibs as it is now. kdelibs (and kde-runtime) will be split up into smaller pieces to lower the barrier for non-KDE developers to use part of the power we as a KDE development community provide. The rough idea is that there will be three groups of libraries/frameworks:
- Tier 1: components which only depend on Qt and no other lib/component from KDE.
- Tier 2: components which depend on Qt and other libraries from Tier 1.
- Tier 3: components which depend on anything.
This of course includes Nepomuk and is a great opportunity for us to reorganize code and get rid of deprecated junk we needed to keep around for binary compatibility.
To this end we had two meetings on IRC this week to discuss how we want to proceed for KDE frameworks. It was a lot of fun (at least for me), mostly because it was rather easy to reach good decisions and fun to radically kick stuff that has been bugging us for a long time. The result is documented in a wiki page but let me summarize the basics again:
We will have four new git repositories:
- nepomuk-core – The main Nepomuk repository which is required in any case and provides the basic Nepomuk functionality including storage, query, and the like. I already began work on this in a nepomuk-core scratch repo. This repository will contain:
- Nepomukserver
- nepomukservicestub
- Extension ontologies
- Core services: Storage/DMS, Query service, Filewatch service, File indexer
- Core library: the current libnepomuk including Nepomuk::Resource and Nepomuk::Types, libnepomukquery, and libnepomukdatamanagement
- nepomuk-ui – A repository containing Nepomuk UI extensions. For starters this will contain:
- SearchLineEdit and SearchWidget
- KFileMetaDataWidget which is currently living in KIO
- nepomuk-kde-kio – A KIO Nepomuk extension repository which contains the KIO slaves we currently provide in kde-runtime:
- nepomuksearch – General purpose queries
- timeline – browse files by date
- nepomuk – a simple kio slave which allows browsing of Nepomuk resources via HTML pages
- nepomuk-kde-config-ui – The repository for Nepomuk configuration extensions based on KDE technology. It contains:
- nepomukcontroller
- Nepomuk KCM
We feel this gives a clean separation and will actually urge packagers to not split those repositories up any further.
Apart from that we decided a few more things – which API to drop, some internals, how to get rid of Soprano::Model in the Nepomuk API altogether, and so on. Actually I am very happy to soon have dedicated Nepomuk repositories as that will make development easier.
And BTW: kde-runtime/nepomuk master is frozen for commits. Development already moved to the new nepomuk-core repository.
Trueg's Blog 
Unfortunately, I haven’t been able to make it to the meetings.
Just a quick note for UI repository – it is planned for kdelibs to have two different UI modules – widgets and declarative. Can’t remember the actual names, you should check with aaron (I think) so that the nepomuk-ui can get a propper name synced with the libs names.
Yes, the plan is “-widgets” for stuff needing QWidget, “-ui” for the parts which are “core” GUI features (think colors, icons, etc.) so independent of the widgetry, and “-declarative” for the code which uses QtQuick.
It basically mirrors what’s happening for Qt5: QtGui, QtWidgets, QtDeclarative modules will be separate.
Do see if I understand correctly: that would mean we would need three repositories: nepomuk-ui, nepomuk-widgets, and nepomuk-declarative? Or is this about libs only which can live in the same repository?
Also: is there some wiki page or anything where one can read up on these decisions? And please do not give me a link to google docs. ;)
If you have common classes for qwidgets and declarative that are not for core, than you should have -ui.
Otherwise, you should only have -widgets currently since you don’t have anything related to declarative atm :)
As for the links, have no clue :)
Well, I’m talking about libraries here, you’re then free to organize your repos as you see fit. Assuming you have nepomuk-gui, nepomuk-widgets and nepomuk-declarative libraries they could all be developed in a nepomuk-ui repository if you make sure the dependencies are right. ;-)
As for the link:
http://community.kde.org/KDE_Core/Platform_11/kdelibsDependencies
You could take the “Frameworks matrix” PDF from there, the block in the bottom right corner gives an overview of that type of splitting.
From the wiki page: “Due to our central runtime parts basically all our components are in Tier 3. The only exception is Soprano which is in Tier 1. ”
Does the core library really have to be in Tier 3?
If it was in Tier 2 (or even Tier 1), it might also be interesting for Qt applications that don’t want to link to the whole kdelibs.
Maybe I misunderstand the whole tier N thing but I thought that the runtime dependency was an issue, too. And our libs depend on the services to run.
Tiers are about link time dependencies indeed. Solution/Integration/Functional are about intent of use and runtime dependencies.
Because of the runtime dependencies and use, most of Nepomuk is likely Solution. Regarding the tier, that’ll depend what you do at link time. ;-)
As great as nepomuk is, there are some people who do not need / want the functionality that nepomuk provides.
Would it be possible to make it so that nepomuk is not a hard dependancy of the KDE desktop?
That is already the case.
Kinda, sorta, but not really… The 4.7.0 workspace fires up Akonadi on startup, which complains loudly if Nepomuk is not active. See e.g. https://bugzilla.redhat.com/show_bug.cgi?id=731269 – I was forced to enable Nepomuk on the Fedora KDE Live CD. (We used to have it enabled by default after installation, but not on the live CD itself.)
Is the UI part now more for the coders or is there something for end users?
Just asking that is the current search UI in Dolphin and elsewhere the final idea?
As in my humble opinion, it is terrible <:-/
Oh, no, it certainly is not. It is in fact a crude try in getting something out there. There is more to come.
Pingback: Nepomuk – What Comes Next | Trueg's Blog
Please plan also a way to *completely* disable nepomuk, akondai and strigi. I am running 4.8 and am tired of having my disk trashed for minutes after login by nepomuk doing things I do not need.
This whole semantic desktop looks like a fun project for theorists, scientists and/or students. But for many real-world users it is just something they do not need. Or at least the necessary marketing has not been done to convince the users they need it, and show them in what it helps to get their work done.
I started to use KDE in 1999, and it’s the first time I feel it’s getting in my way.