Re: [Nepomuk] The Nepomuk Situation

On 05/16/2012 10:40 PM, Stephen Kelly wrote: > Sebastian Trüg wrote: > >> On 05/16/2012 08:23 PM, Vishesh Handa wrote: >>> What about kdelibs/nepomuk/utils/* and the other ui stuff? >>> >>> Or since those are just APIs they can wait. >> >> I say let's postpone them, they are still in kdelibs. >>

Re: [Nepomuk] The Nepomuk Situation

On 05/16/2012 09:52 PM, Vishesh Handa wrote: > > > On Thu, May 17, 2012 at 1:06 AM, Sebastian Trüg > wrote: > > > > On 05/16/2012 09:16 PM, Vishesh Handa wrote: > > > > > > On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg >

Re: [Nepomuk] The Nepomuk Situation

On Thu, May 17, 2012 at 1:06 AM, Sebastian Trüg wrote: > > > On 05/16/2012 09:16 PM, Vishesh Handa wrote: > > > > > > On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg > > wrote: > > > > Pushed my stuff to branch "feature/nepomuk2Includes". > > > > Feel free to imple

Re: [Nepomuk] The Nepomuk Situation

On 05/16/2012 09:16 PM, Vishesh Handa wrote: > > > On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg > wrote: > > Pushed my stuff to branch "feature/nepomuk2Includes". > > Feel free to implement Ivan's fancier solution. In that case my branch > might at least

Re: [Nepomuk] The Nepomuk Situation

On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg wrote: > Pushed my stuff to branch "feature/nepomuk2Includes". > > Feel free to implement Ivan's fancier solution. In that case my branch > might at least help in finding the places where stuff needs replacing. > If you do not I would appreciate a

Re: [Nepomuk] The Nepomuk Situation

Pushed my stuff to branch "feature/nepomuk2Includes". Feel free to implement Ivan's fancier solution. In that case my branch might at least help in finding the places where stuff needs replacing. If you do not I would appreciate a look over my branch to check if I missed sth. Cheers, Sebastian O

Re: [Nepomuk] The Nepomuk Situation

On 05/16/2012 08:37 PM, Vishesh Handa wrote: > > > On Thu, May 17, 2012 at 12:02 AM, Sebastian Trüg > wrote: > > On 05/16/2012 08:23 PM, Vishesh Handa wrote: > > What about kdelibs/nepomuk/utils/* and the other ui stuff? > > > > Or since those are just APIs

Re: [Nepomuk] The Nepomuk Situation

On Thu, May 17, 2012 at 12:02 AM, Sebastian Trüg wrote: > On 05/16/2012 08:23 PM, Vishesh Handa wrote: > > What about kdelibs/nepomuk/utils/* and the other ui stuff? > > > > Or since those are just APIs they can wait. > > I say let's postpone them, they are still in kdelibs. > The facets are qu

Re: [Nepomuk] The Nepomuk Situation

On 05/16/2012 08:23 PM, Vishesh Handa wrote: > What about kdelibs/nepomuk/utils/* and the other ui stuff? > > Or since those are just APIs they can wait. I say let's postpone them, they are still in kdelibs. The facets are quite weird and I am not sure about releasing them again. The ui stuff -

Re: [Nepomuk] The Nepomuk Situation

What about kdelibs/nepomuk/utils/* and the other ui stuff? Or since those are just APIs they can wait. On Wed, May 16, 2012 at 11:49 PM, Sebastian Trüg wrote: > I now prepared the required repositories: > > scratch/trueg/nepomuk-kde-kio > contains the 3 Nepomuk kio slaves > > scratch/trueg/nep

Re: [Nepomuk] The Nepomuk Situation

I now prepared the required repositories: scratch/trueg/nepomuk-kde-kio contains the 3 Nepomuk kio slaves scratch/trueg/nepomuk-kde-config contains the KCM and the controller systray app The question is: where should we move them? Something like "KDE/Base"? I suppose questions like these hav

Re: [Nepomuk] The Nepomuk Situation

Just as a reminder: most of the issues were already discussed and decided on: http://community.kde.org/Projects/Nepomuk/Irc_meeting_nepomuk_frameworks On 05/11/2012 09:35 AM, Vishesh Handa wrote: > > On Fri, May 11, 2012 at 12:55 PM, Sebastian Trüg > wrote: > > Sounds

Re: [Nepomuk] The Nepomuk Situation

On Fri, May 11, 2012 at 12:55 PM, Sebastian Trüg wrote: > Sounds great. However, it requires one more step: > > Create the new repositories we decided on a while ago for the kcm, the > kio slaves and such. This basically means to do "git filter-branch"[1] > as I did for nepomuk-core. > Have fun

Re: [Nepomuk] The Nepomuk Situation

Sounds great. However, it requires one more step: Create the new repositories we decided on a while ago for the kcm, the kio slaves and such. This basically means to do "git filter-branch"[1] as I did for nepomuk-core. [1] http://gbayer.com/development/moving-files-from-one-git-repository-to-anot

Re: [Nepomuk] The Nepomuk Situation

Does anyone have any objections to the current plan? * Remove kde-runtime/nepomuk * All nepomuk development happens in nepomuk-core * nepomuk-core will install everything with a Nepomuk2 namespace * Applications will have to explicitly depend on nepomuk-core if they want to use the new APIs T

Re: [Nepomuk] The Nepomuk Situation

On Monday 07 May 2012, Vishesh Handa wrote: ... > So, we're down to 3 options - > > *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched. > *Problem:* Overlapping headers and possible mysterious crashes if both > libraries are loaded. > > *2.* nepomuk-core installs headers und

Re: [Nepomuk] The Nepomuk Situation

El Dilluns, 7 de maig de 2012, a les 22:09:01, Vishesh Handa va escriure: > On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid wrote: > > El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure: > > > On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid wrote: > > > > El Dijous, 3 de

Re: [Nepomuk] The Nepomuk Situation

El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure: > On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid wrote: > > El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: > > > Hey everyone! > > > > > > snip > > > > > > The second solution is - > > > * nepo

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 10:57 PM, Albert Astals Cid wrote: > There's some problem of communication here. > > Let me try to explain myself better. As far as I understand: > * Dolphin uses the "old" api at the moment and works "fine" > Yup. > * When the change you propose (adding new apis), you

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 10:21 PM, Kevin Krammer wrote: > On Monday, 2012-05-07, Vishesh Handa wrote: > > On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid wrote: > > > > So you mean yes, they can, they do now and can still do it, even if > using > > > the > > > "old" APIs are suboptimal. > > > >

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 10:12 PM, Sune Vuorela wrote: > On 2012-05-07, Vishesh Handa wrote: > > I'm not okay with applications having to stick with the old faulty APIs > > I'm not okay with a api or abi break in kdelibs. > Of course. But that is not what is happening. The current solution we pr

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid wrote: > El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure: > > On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid wrote: > > > El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va > escriure: > > > > Hey everyone!

Re: [Nepomuk] The Nepomuk Situation

On 05/07/2012 03:47 PM, ivan.cu...@gmail.com wrote: > Maybe there could be something like qt has - BEGIN_NEPOMUK_NAMESPACE... So > that if the same needs to be done in the future, we could just change the > macro value. That would be much more work since each cpp file has the namespaces in the m

Re: [Nepomuk] The Nepomuk Situation

Maybe there could be something like qt has - BEGIN_NEPOMUK_NAMESPACE... So that if the same needs to be done in the future, we could just change the macro value. I don't know, thinking that Nepomuk2 namespace is looking rather ugly :) The dirtiest solution library-wise would be to have everythi

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg wrote: > On 05/07/2012 02:35 PM, Vishesh Handa wrote: > > > > > > On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg > > wrote: > > > > > > On 05/07/2012 12:09 PM, Vishesh Handa wrote: > > > > > So, we're down to 3 options

Re: [Nepomuk] The Nepomuk Situation

On Monday 07 May 2012 13:06:15 Vishesh Handa wrote: > On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela wrote: > > On 2012-05-07, Vishesh Handa wrote: > > > Right. > > > > > > We could maintain BC and SC by not touching the kdelibs nepomuk, and > > > just > > > making nepomuk-core a dependency of kd

Re: [Nepomuk] The Nepomuk Situation

On 05/07/2012 02:35 PM, Vishesh Handa wrote: > > > On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg > wrote: > > > On 05/07/2012 12:09 PM, Vishesh Handa wrote: > > > So, we're down to 3 options - > > > > *1.* nepomuk-core become a dependency of kdelibs

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg wrote: > > On 05/07/2012 12:09 PM, Vishesh Handa wrote: > > > So, we're down to 3 options - > > > > *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched. > > *Problem:* Overlapping headers and possible mysterious crashes if both >

Re: [Nepomuk] The Nepomuk Situation

On 05/07/2012 12:09 PM, Vishesh Handa wrote: > > > On Mon, May 7, 2012 at 3:12 PM, David Faure > wrote: > > On Monday 07 May 2012 13:06:15 Vishesh Handa wrote: > > On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela > wrote: > > > On 20

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 3:12 PM, David Faure wrote: > On Monday 07 May 2012 13:06:15 Vishesh Handa wrote: > > On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela wrote: > > > On 2012-05-07, Vishesh Handa wrote: > > > > Right. > > > > > > > > We could maintain BC and SC by not touching the kdelibs nepo

Re: [Nepomuk] The Nepomuk Situation

On 2012-05-07, Vishesh Handa wrote: > Right. > > We could maintain BC and SC by not touching the kdelibs nepomuk, and just > making nepomuk-core a dependency of kdelibs. But that would result in both > nepomuk-core and kdelibs installing the same headers. what happens if both libraries are loaded

Re: [Nepomuk] The Nepomuk Situation

El Dimecres, 2 de maig de 2012, a les 12:14:00, Ivan Cukic va escriure: > > The first solution - > > * Remove nepomuk from kdelibs and kde-runtime > > +1 This is what has been done with kactivities. Instead of having it in > kdelibs and runtime, it is now all in one repository. > > The only diffe

Re: [Nepomuk] The Nepomuk Situation

El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: > Hey everyone! > > snip > > The second solution is - > * nepomuk-core installs the headers in nepomuk2 > * the library already has a different name, so there are no clashes over > there > * kde-runtime/nepomuk is removed > *

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela wrote: > On 2012-05-07, Vishesh Handa wrote: > > Right. > > > > We could maintain BC and SC by not touching the kdelibs nepomuk, and just > > making nepomuk-core a dependency of kdelibs. But that would result in > both > > nepomuk-core and kdelibs in

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 5:01 AM, Albert Astals Cid wrote: > El Dimecres, 2 de maig de 2012, a les 12:14:00, Ivan Cukic va escriure: > > > The first solution - > > > * Remove nepomuk from kdelibs and kde-runtime > > > > +1 This is what has been done with kactivities. Instead of having it in > > kde

Re: [Nepomuk] The Nepomuk Situation

On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid wrote: > El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: > > Hey everyone! > > > > snip > > > > The second solution is - > > * nepomuk-core installs the headers in nepomuk2 > > * the library already has a different name, s

Re: [Nepomuk] The Nepomuk Situation

nepomuk-core depends on kdelibs. So kdelibs cannot depend on nepomuk-core. We would have to get rid of those dependencies in kdelibs. But that should not be too hard. On 05/03/2012 11:21 AM, Vishesh Handa wrote: > I just noticed that this discussion is no longer cced to kcd. > > On Thu, May 3, 20

Re: [Nepomuk] The Nepomuk Situation

I just noticed that this discussion is no longer cced to kcd. On Thu, May 3, 2012 at 2:47 PM, Christian Mollekopf wrote: > > > On Thu, May 3, 2012, at 02:22 PM, Vishesh Handa wrote: > > > > On Thu, May 3, 2012 at 3:09 AM, Christian Mollekopf > wrote: > > > On Thursday 03 May 2012 00.32:37 Vish

Re: [Nepomuk] The Nepomuk Situation

On Thu, May 3, 2012, at 02:22 PM, Vishesh Handa wrote: On Thu, May 3, 2012 at 3:09 AM, Christian Mollekopf <[1]chrig...@fastmail.fm> wrote: > On Thursday 03 May 2012 00.32:37 Vishesh Handa wrote: > > Hey everyone! > Hey Vishesh, Hey Christian Glad your tackling this, it's indeed a

Re: [Nepomuk] The Nepomuk Situation

On Thu, May 3, 2012 at 3:09 AM, Christian Mollekopf wrote: > > On Thursday 03 May 2012 00.32:37 Vishesh Handa wrote: > > > > Hey everyone! > > > Hey Vishesh, > Hey Christian > > Glad your tackling this, it's indeed a rather painful situation. > > > > > So, we need a solution. > > > > The first s

Re: [Nepomuk] The Nepomuk Situation

On 05/02/2012 11:39 PM, Christian Mollekopf wrote: >> On Thursday 03 May 2012 00.32:37 Vishesh Handa wrote: >> >> Hey everyone! >> > Hey Vishesh, > > Glad your tackling this, it's indeed a rather painful situation. > >> >> So, we need a solution. >> >> The first solution - >> * Remove nepomuk fro

Re: [Nepomuk] The Nepomuk Situation

> On Thursday 03 May 2012 00.32:37 Vishesh Handa wrote: > > Hey everyone! > Hey Vishesh, Glad your tackling this, it's indeed a rather painful situation. > > So, we need a solution. > > The first solution - > * Remove nepomuk from kdelibs and kde-runtime > * Make nepomuk-core a compile time d

Re: [Nepomuk] The Nepomuk Situation

> The first solution - > * Remove nepomuk from kdelibs and kde-runtime +1 This is what has been done with kactivities. Instead of having it in kdelibs and runtime, it is now all in one repository. The only difference here is that nepomuk is not in libs/experimental like libkactivities was. I t

[Nepomuk] The Nepomuk Situation

Hey everyone! I've been meaning to write this forever, but I've gotten sidetracked with real life. Anyway, here it goes - As some of you might know, the Nepomuk source code is distributed over two different repositories. The client API is in kdelibs, and the rest is in kde-runtime. Developing bo