Projects/Nepomuk/Irc meeting nepomuk frameworks: Difference between revisions
m (→Decisions) |
|||
| Line 24: | Line 24: | ||
=== Git Repositories === | === Git Repositories === | ||
Which repositories will we use and which components will they contain. The decision was based on the question of which parts of Nepomuk we want always to be available and which are optional. | Which repositories will we use and which components will they contain. The decision was based on the question of which parts of Nepomuk we want always to be available and which are optional. | ||
# nepomuk-core | # '''nepomuk-core''' | ||
#* Nepomukserver | #* Nepomukserver | ||
#* nepomukservicestub | #* nepomukservicestub | ||
| Line 30: | Line 30: | ||
#* Core services: Storage/DMS, Query service, Filewatch service, File indexer | #* Core services: Storage/DMS, Query service, Filewatch service, File indexer | ||
#* Core libraries: see below. | #* Core libraries: see below. | ||
# nepomuk-ui | # '''nepomuk-ui''' | ||
#* UI libraries: see below | #* UI libraries: see below | ||
# nepomuk-kde-kio | # '''nepomuk-kde-kio''' | ||
#* KIO slaves: nepomuksearch, timeline, nepomuk | #* KIO slaves: nepomuksearch, timeline, nepomuk | ||
# nepomuk-kde-config-ui | # '''nepomuk-kde-config-ui''' | ||
#* nepomukcontroller | #* nepomukcontroller | ||
#* Nepomuk KCM | #* Nepomuk KCM | ||
| Line 41: | Line 41: | ||
====New Libraries==== | ====New Libraries==== | ||
Which libraries do we want to have in the end? | Which libraries do we want to have in the end? | ||
# nepomukcore - The core libraries which are always installed and everything else depends on | # '''nepomukcore''' - The core libraries which are always installed and everything else depends on | ||
#* libnepomukdatamanagement | #* libnepomukdatamanagement | ||
#* The current kdelibs/nepomuk/core | #* The current kdelibs/nepomuk/core | ||
| Line 47: | Line 47: | ||
#* The current kdelibs/nepomuk/types | #* The current kdelibs/nepomuk/types | ||
#* Nepomuk::formatPropertyValue - maybe rename to propertyToString to indicate that it is the basic formatting method | #* Nepomuk::formatPropertyValue - maybe rename to propertyToString to indicate that it is the basic formatting method | ||
# nepomukui - UI elements build upon nepomukcore | # '''nepomukui''' - UI elements build upon nepomukcore | ||
#* The current kdelibs/nepomuk/utils/searchlineedit.h/.cpp, searchwidget.h/.cpp | #* The current kdelibs/nepomuk/utils/searchlineedit.h/.cpp, searchwidget.h/.cpp | ||
#* KFileMetaDataWidget - with a new name and in Nepomuk namespace (is in dire need of a rewrite) | #* KFileMetaDataWidget - with a new name and in Nepomuk namespace (is in dire need of a rewrite) | ||
Revision as of 13:24, 29 August 2011
Topic
For KDE 5.0 kdelibs and kde-runtime will be split into several parts/components/repositories in order to be more modular and reach a larger audience. This development is at the moment going on in the frameworks branch of kdelibs. There is basically three groups of repositories:
- 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
Due to our central runtime parts basically all our components are in Tier 3. The only exception is Soprano which is in Tier 1.
The goal of this meeting is to determine what to do with Nepomuk in KDE 5.
Items of Discussion
- How do we split libnepomuk for kdelibs 5.0
- Which parts do we drop (besides the already deprecated API)
- Which new parts do we introduce (candidate: nepomukdatamanagement) and how do we combine them with existing libs (maybe merge)
- What do we do with ResourceManager::mainModel()? Do we drop it altogether? Do we introduce an alternative which is purely DBus based? Do we extend the QueryServiceClient to provide better SPARQL result support?
- We need to move nepomuk-dependent code from KIO to our libs
- We need to make the rest of KIO independent of Nepomuk. This is mainly the download tracking. David Faure suggested to introduce a DBus signal which one of our services can connect to. Maybe similar to the KDirNotify signals.
Participants
- Vishesh Handa
- Artem Serebinsky
- Sebastian Trueg
Decisions
Git Repositories
Which repositories will we use and which components will they contain. The decision was based on the question of which parts of Nepomuk we want always to be available and which are optional.
- nepomuk-core
- Nepomukserver
- nepomukservicestub
- Extension ontologies
- Core services: Storage/DMS, Query service, Filewatch service, File indexer
- Core libraries: see below.
- nepomuk-ui
- UI libraries: see below
- nepomuk-kde-kio
- KIO slaves: nepomuksearch, timeline, nepomuk
- nepomuk-kde-config-ui
- nepomukcontroller
- Nepomuk KCM
Libraries
New Libraries
Which libraries do we want to have in the end?
- nepomukcore - The core libraries which are always installed and everything else depends on
- libnepomukdatamanagement
- The current kdelibs/nepomuk/core
- The current libnepomukquery
- The current kdelibs/nepomuk/types
- Nepomuk::formatPropertyValue - maybe rename to propertyToString to indicate that it is the basic formatting method
- nepomukui - UI elements build upon nepomukcore
- The current kdelibs/nepomuk/utils/searchlineedit.h/.cpp, searchwidget.h/.cpp
- KFileMetaDataWidget - with a new name and in Nepomuk namespace (is in dire need of a rewrite)
API to drop
- For now we drop the facet API and move it to playground since it was forced and is weird
- We drop all in kdelibs/nepomuk/ui from public API and only copy what we need for the metadatawidget