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

List:       kde-core-devel
Subject:    Re: Cervisia development
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2001-09-13 16:57:11
[Download RAW message or body]



Bernd Gehrmann wrote:
> 
> On Tue, 11 Sep 2001, Richard Moore wrote:
> > I've been thinking about how we should deal with the Cervisia
> > development issues (mainly how to maintain a stable 2.x codebase).
> > You've already said that you want to keep the sourceforge CVS
> > running on KDE 2.x, so how about we make the kdesdk version the
> > 'development tree' which would aim to work with 2.x, but would
> > have the KDE 3.x HEAD as the primary target. We should be able
> > to sync compatible patches between the two trees without too much
> > problem, I guess. Whenever I'm happy with a feature, and have a
> > tested 2.x patch I'll mail it to you for inclusion in the
> > sourceforge tree. What do you think, is this ok?
> 
> Well, if you can make the version in kdesdk work with both KDE versions,
> I don't think it's necessary to maintain a separate one else-
> where. Maybe that becomes more convenient when the differences are
> more than a couple of small #ifdef's, but I think we'll see early
> enough whether that's the case.
> 
> Currently, I have a local copy that is approximately the stuff
> after your KAction changes, but before the use of KParts, plus
> some bugfixes. I hope to implement some micro-features in this
> source tree next weekend (and merge them into the KDE repository)
> and release all that as 1.5 afterwards. I think that's
> a good intermediate step instead of publishing the bugfixes that
> have accumulated during the last months and your more 'radical'
> changes together.
> 
> > Currently my local copy has diverged quite a bit from both CVS
> > versions, as I've been separating the front and back ends of the
> > app. This change has let me write a Cervisia plugin for other
> > apps. The plugin can extend arbitrary KParts (eg. Kate and KHTML
> > (and hopefully the KOffice apps too)) by adding a 'Version
> > Control' sub-menu to their file menus. The menu operates directly
> > on the file open in the part, but there is a bit more work still
> > needed to make everything integrate nicely (eg. the part should
> > be reloaded after a cvs update). Adding a DCOP interface to allow
> > scripting is trivial now I have a standalone API for invoking the
> > Cervisia actions, and should be working RSN.
> 
> Great :-)

I got the DCOP interface written last night, works nicely :-)
I still have some issues to tidy up with the refactored code before
it is releasable quality, but things seem to be coming together. 

Cheers

Rich.

> 
> Bernd.

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