On 11/14/2011 09:19 PM, Aaron J. Seigo wrote:
Valentin: please let me know when ksecretservice is in its own repo,
I just removed ksecretsservice from kdelibs and kde-runtime.
Next move will be inclusion in ksecrets repository.
--
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former
On Monday, November 14, 2011 21:43:12 Valentin Rusu wrote:
> What would be the current "beautiful" plug-in implementation to take as an
> example?
there are some tutorials here:
http://techbase.kde.org/Development/Tutorials#Services:_Applications_and_Plugins
this one gets right to it:
http://te
On Monday 14 November 2011 21:42:27 Valentin Rusu wrote:
> The libs part would lead to a Tier2 library - I expected that and your
> other mail confirms it.
> May it contain the other ksecretsservice components such as the deamon
> and the sync tool (those who are already under kdeutils)?
> Dependin
Kevin Ottens wrote:
> * Introducing a plugin loading approach inside of the KWallet convenience
> API
> * Make your current code for the KWallet convenience API a plugin for
> the above mechanism (seeing your code right now, it'll even map fairly
> well as in most places it's right now "if (m_secre
On 11/14/2011 09:19 PM, Aaron J. Seigo wrote:
On Monday, November 14, 2011 18:04:08 Kevin Ottens wrote:
> * Introducing a plugin loading approach inside of the KWallet
convenience
> API * Make your current code for the KWallet convenience API a
plugin for
> the above mechanism (seeing you
On 11/14/2011 06:04 PM, Kevin Ottens wrote:
On Saturday 12 November 2011 11:35:22 Valentin Rusu wrote:
And the circular dependency will be there as long as kdecore (where
KCompositeJob lives) and kdeui (where KWallet lives) are tied together.
Here is the schema :
- KWallet legacy code *needs* KS
On Monday, November 14, 2011 18:04:08 Kevin Ottens wrote:
> * Introducing a plugin loading approach inside of the KWallet convenience
> API * Make your current code for the KWallet convenience API a plugin for
> the above mechanism (seeing your code right now, it'll even map fairly well
> as in mo
On Monday, 2011-11-14, Kevin Ottens wrote:
> Right. Although I don't expect a kdeui to still exist in the end. The
> relevant KWallet code might end up in a kde4support I think. For that to
> happen we'd need a similar convenience API in libksecretservice itself if
> deemed appropriate (the whole
On Monday 14 November 2011 06:48:50 Aaron J. Seigo wrote:
> On Saturday, November 12, 2011 13:38:47 Valentin Rusu wrote:
> > Ok, I'll then move it somewhere else. I'm very tempted by the kdecore
> > module, the place where it's main dependency, KCompositeJob, lives.
> >
> > But I think the best pla
On Saturday 12 November 2011 11:35:22 Valentin Rusu wrote:
> On 11/12/2011 11:24 AM, Kevin Ottens wrote:
> > So that was the intent of my previous email, now that the red flag got
> > raised for inclusion in kdelibs master, why not going for a separate
> > repository?
> That's exactly what I'm doin
On Saturday, November 12, 2011 13:38:47 Valentin Rusu wrote:
> Ok, I'll then move it somewhere else. I'm very tempted by the kdecore
> module, the place where it's main dependency, KCompositeJob, lives.
>
> But I think the best place would be the *experimental* module. Ok for that?
if this indeed
Sebastian Kügler wrote:
> On Saturday, November 12, 2011 08:12:27 Kevin Kofler wrote:
>> All this stuff is going to make things much more work for us packagers
>> (just like the separate kactivities), for no good reason other than some
>> arbitrary "we froze kdelibs" decision!
>
> Calling it an
On Saturday, November 12, 2011 08:12:27 Kevin Kofler wrote:
> All this stuff is going to make things much more work for us packagers
> (just like the separate kactivities), for no good reason other than some
> arbitrary "we froze kdelibs" decision!
Calling it an arbitrary decision shows either of
On 11/12/2011 12:55 PM, Christoph Feck wrote:
Since it was me who raised this issue on IRC, I should clarify:
I have no problem with the ksecrets stuff in *kdelibs*, but I do not
like that it has been added to *kdeui*. The only reason given was that
kwallet API is also part of kdeui, but why sho
Since it was me who raised this issue on IRC, I should clarify:
I have no problem with the ksecrets stuff in *kdelibs*, but I do not
like that it has been added to *kdeui*. The only reason given was that
kwallet API is also part of kdeui, but why should we make this mistake
again?
Christoph Fe
Valentin Rusu wrote:
> However, I should remove the ksecretsserviced from kde-runtime and let
> it go the the ksecrets repository, under kdeutils. And I'll do it later
> today.
Uhm, kde-runtime isn't frozen like kdelibs…
Kevin Kofler
On 11/12/2011 11:55 AM, Alexander Neundorf wrote:
And that's where my question comes from, I thought the consensus with the
involved parties after that new discussion was for a new repository, but I
might have missed something.
So that was the intent of my previous email, now that the red flag g
On Saturday 12 November 2011, Kevin Ottens wrote:
> On Saturday 12 November 2011 11:14:35 Valentin Rusu wrote:
> > On 11/12/2011 10:11 AM, Kevin Ottens wrote:
> > > Any particular reason why you didn't stick to the separate repo
> > > solution as proposed earlier? For some reason I fail to see what
On 11/12/2011 11:24 AM, Kevin Ottens wrote:
Please see my response to Aaron.
And that's where my question comes from, I thought the consensus with the
involved parties after that new discussion was for a new repository, but I
might have missed something.
Well, the discussion came *after* I merge
On Saturday 12 November 2011 11:14:35 Valentin Rusu wrote:
> On 11/12/2011 10:11 AM, Kevin Ottens wrote:
> > Any particular reason why you didn't stick to the separate repo solution
> > as proposed earlier? For some reason I fail to see what motivated your
> > change on that.
>
> Well, as I explain
On 11/12/2011 10:11 AM, Kevin Ottens wrote:
On Saturday 12 November 2011 01:01:15 Valentin Rusu wrote:
As you may already know, the ksecretsservice API merging to the
kdelibs/4.7 branch was no longer an acceptable solution because of
recent frameworks related decisions. It was suggested to put i
On Saturday 12 November 2011 08:12:27 Kevin Kofler wrote:
> Circular dependencies are an absolute PITA for packaging.
Yes, obviously we're going to try to avoid that.
Regards.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud patron of KDE, http://www.kdab.com
signature.asc
Description: T
On Saturday 12 November 2011 01:01:15 Valentin Rusu wrote:
> As you may already know, the ksecretsservice API merging to the
> kdelibs/4.7 branch was no longer an acceptable solution because of
> recent frameworks related decisions. It was suggested to put it into
> it's separate repository, alongs
On Saturday 12 November 2011 08:12:27 Kevin Kofler wrote:
> We definitely do want your ksecretsservice work ASAP and I don't see why it
> can't be in kdelibs where it belongs.
*sigh* could we please stop adding this whining about the frozen kdelibs in
each thread on kde-core-devel.
Yes we got tha
Valentin Rusu wrote:
> As you may already know, the ksecretsservice API merging to the
> kdelibs/4.7 branch was no longer an acceptable solution because of
> recent frameworks related decisions. It was suggested to put it into
> it's separate repository, alongside with the
> kde-runtime/ksecretsser
25 matches
Mail list logo
