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)