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

List:       kde-mac
Subject:    Re: [kdepim-users] [KDE/Mac] Usenet/GMane users and the (lack of) future of KNode
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2016-11-12 11:59:38
Message-ID: 13836224.BYrEot31qa () portia ! local
[Download RAW message or body]

On Friday February 12 2016 11:44:05 Sandro Knauß wrote:

> But now you step up and feell responsible for this software - great. If you 
> start with your work and take over mantainership, this software has not to 
> die. And we will help you where we can.

I can't find the reply I'm sure I sent on this, so let me resume: I've started \
looking around in the code, and came to an initial conclusion very quickly that \
there's too much going on in there that I don't understand (things I think are \
handled through KItemModels nowadays). Documentation of such APIs focusses on how you \
use them when you already know what you'd want to use them for so that's not really \
helping. In short, it seems highly unlikely that I'll be able to do anything useful \
in terms of porting if it's not under some form of guidance - and clearly there are \
no others here who care enough about KNode to see what they could do.

Hence this thread revival: it seems that KNode could be split off from KDE PIM into a \
standalone project (at least for the time being). I just checked a hunch that as \
basically a KDE3 app it doesn't use Akonadi and turns out to be true in the sense \
that it works fine without akonadi running. I didn't check if it puts up a DBus \
interface that could clash with KDEPIM5, but if not it looks like it should be able \
to run alongside KDEPIM5 apps.

Would splitting this off (and bundling whatever it needs from kdepimlibs4) make it \
easier to find someone to take over the project?

I hear it's time to propose SoK projects, wouldn't KNode be a good candidate?

R.


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