On 11/11/2011 03:24 PM, Olivier Goffart wrote:
Yes, I'll take that suggestion. But is the frameworks branch working
right now?
Is it possible to use it as the main desktop session on my computer, on
a day-to-day basis?
The frameworks branch is not meant to be used in the short term
(it may work, but I don't know)
But it is to be used for development.

So, I may switch my desktop environment to it right now?


There is a lot of work to do there, and little people to do the work.
What's not helping is that  lots of developer are like you and want to get
their feature used as soon as possible (nothing to blame here). So they stick
to 4.x rather than doing work in the framework branch.

Well, I actually need this feature for my secrets management, and I'm not the only one who wants the secret sync tool I proposed. If the frameworks schedule is so far ahead, I think that'll be better to let it go into kdelibs, as I started it, then I'll start helping you with the frameworks. I'm very keen to help you, but I don't have the detailed knowledge you have on KDE core.


That's the reason why kdelibs is frozen, it is to force developper like you to
contribute (and hence tests) the framework.

But I'm wiling to switch to frameworks. I'm also wiling to help develop it. Only I have quite a gap to escalate to reach to your level in KDE core knowledge and working on this API helped me a lot. Perhaps some guidance my help/task dispatching may help me getting into it. But I need my secret sync tool meanwhile :-)

Because by running in frameworks, you will maybe see bugs in other areas of
the framework, and i am sure people on irc are there to help.

People on IRC are great.

FYI, Telepathy team is waiting for this new feature to be released. They
are my first "real" users and already provided some feedback/bug reports
about the deamon.
That's great.
But as far as i know, Thelepathy is in the same situation as you. Meaning they
can use the secretservice libraries without them to be within kdelibs.



Ok - I'm adjusting my view while writing this mail.  So here is my proposal:
- remove all of the ksecretsservice code from kdelibs and kde-runtime,
- do not remove kwallet.cpp code I added for the ksecretsservice infrastructure; also let the check box in the corresponding kcm - that will be easier for those wiling to test this new infrastructure and it has no effect by default, - continue maintaining ksecretsservice related code in kdelibs/4.8/kwallet.cpp, - create an extragear (or playground?) repository holding all the ksecretsservice related stuff ; I cannot use the old repo, as it's name is slightly different,
- documentint it on techbase.kde.org site


--
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)

Reply via email to