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 tr...@kde.org wrote:
I now prepared the required repositories:
scratch/trueg/nepomuk-kde-kio
contains the 3 Nepomuk kio slaves
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 -
On Thu, May 17, 2012 at 12:02 AM, Sebastian Trüg tr...@kde.org 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
On 05/16/2012 08:37 PM, Vishesh Handa wrote:
On Thu, May 17, 2012 at 12:02 AM, Sebastian Trüg tr...@kde.org
mailto:tr...@kde.org 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
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
On
On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg tr...@kde.org 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
On 05/16/2012 09:16 PM, Vishesh Handa wrote:
On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg tr...@kde.org
mailto:tr...@kde.org wrote:
Pushed my stuff to branch feature/nepomuk2Includes.
Feel free to implement Ivan's fancier solution. In that case my branch
might at
On Thu, May 17, 2012 at 1:06 AM, Sebastian Trüg tr...@kde.org wrote:
On 05/16/2012 09:16 PM, Vishesh Handa wrote:
On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg tr...@kde.org
mailto:tr...@kde.org wrote:
Pushed my stuff to branch feature/nepomuk2Includes.
Feel free to
On 05/16/2012 09:52 PM, Vishesh Handa wrote:
On Thu, May 17, 2012 at 1:06 AM, Sebastian Trüg tr...@kde.org
mailto:tr...@kde.org wrote:
On 05/16/2012 09:16 PM, Vishesh Handa wrote:
On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg tr...@kde.org
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 tr...@kde.org
mailto:tr...@kde.org wrote:
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
Seems perfect, no breaking, no kdelibs modification.
On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid aa...@kde.org 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, so
On Mon, May 7, 2012 at 5:01 AM, Albert Astals Cid aa...@kde.org 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
On 2012-05-07, Vishesh Handa m...@vhanda.in 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
On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela nos...@vuorela.dk wrote:
On 2012-05-07, Vishesh Handa m...@vhanda.in 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
On Monday 07 May 2012 13:06:15 Vishesh Handa wrote:
On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela nos...@vuorela.dk wrote:
On 2012-05-07, Vishesh Handa m...@vhanda.in wrote:
Right.
We could maintain BC and SC by not touching the kdelibs nepomuk, and
just
making nepomuk-core a
On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg tr...@kde.org 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
On 05/07/2012 02:35 PM, Vishesh Handa wrote:
On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg tr...@kde.org
mailto:tr...@kde.org 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.
On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg tr...@kde.org wrote:
On 05/07/2012 02:35 PM, Vishesh Handa wrote:
On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg tr...@kde.org
mailto:tr...@kde.org wrote:
On 05/07/2012 12:09 PM, Vishesh Handa wrote:
So, we're down to 3
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
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
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 aa...@kde.org wrote:
El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure:
Hey everyone!
snip
The second solution is -
*
On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org 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 aa...@kde.org wrote:
El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va
escriure:
On Mon, May 7, 2012 at 10:12 PM, Sune Vuorela nos...@vuorela.dk wrote:
On 2012-05-07, Vishesh Handa m...@vhanda.in 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.
On Monday, 2012-05-07, Vishesh Handa wrote:
On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org wrote:
So you mean yes, they can, they do now and can still do it, even if using
the
old APIs are suboptimal.
Right?
I'm sorry. What?
I think what Albert is asking is
On Mon, May 7, 2012 at 10:21 PM, Kevin Krammer kram...@kde.org wrote:
On Monday, 2012-05-07, Vishesh Handa wrote:
On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org wrote:
So you mean yes, they can, they do now and can still do it, even if
using
the
old APIs are
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 aa...@kde.org 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 aa...@kde.org wrote:
On Mon, May 7, 2012 at 10:57 PM, Albert Astals Cid aa...@kde.org 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),
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 under
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 difference
I just noticed that this discussion is no longer cced to kcd.
On Thu, May 3, 2012 at 2:47 PM, Christian Mollekopf chrig...@fastmail.fmwrote:
On Thu, May 3, 2012, at 02:22 PM, Vishesh Handa wrote:
On Thu, May 3, 2012 at 3:09 AM, Christian Mollekopf chrig...@fastmail.fm
wrote:
On
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, 2012
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
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
35 matches
Mail list logo
