[PROPOSAL] cvs support in KDE (long)

Christian Loose christian.loose at hamburg.de
Fri Jan 17 18:19:02 GMT 2003


Am Freitag, 17. Januar 2003 13:54 schrieb Andras Mantia:
> On 2003. January 17., Friday 14:15, Christian Loose wrote:
> > Hi!
> >
[snip]
> > The two parts that might be interesting for code reuse (IMO) are a layer
> > which provides easy access to the functionality of the command line
> > client and a GUI layer with the dialogs to display the data (like the
> > Browse Log dialog of Cervisia).
> >
> > For Cervisia I decided to create DCOP service for the first layer and I
> > was thinking about using KParts plugins for the second layer.
>
> I haven't looked at the new DCOP service of Cervisia, but it sounds great.
> Being able to use Cervisia only as a KPart is not the perfect solution, as
> we would like to have some CVS functionality (commit/check out/update/diff)
> from the various trees, like the project handling tree. Just like in
> KDevelop. Implementing it again wouldn't make much sense.
>

Thank you Andras for you answer. Further down you will find a small 
description of how the DCOP service works in order to give you a good start 
before you dig into the source code. :-)

The CVS DCOP service consists of the following three parts:

1. CvsService - The main interface to the functionality of the CVS command
line client. There is one method for each CVS command, e.g. add, checkout, 
commit, etc... The methods assemble the command line arguments, create a 
CvsJob and return a DCOPRef to the job. There is one instance of this service 
for each application instance.

2. Repository - This DCOPObject manages the configuration data of the
current CVS repository like CVS_RSH or the compression level. The data is 
automatically updated when other service instances change it.

3. CvsJob - This class represents a cvs job. You can execute and cancel it,
and you can retrieve the output of the CVS client by connecting to the proper 
DCOP signals. There are two types of jobs. First the non-concurrent job which 
has to run alone like update or import. Second the jobs which can run 
concurrently like log or annotate.

Note: The DCOP service doesn't offer a GUI!

Improvements, ideas, corrections are very welcome! Also do you think that a 
DCOP service is a good way to offer this functionality?

Christian



PS: A simplified example how to use this service
---------------------------------------------------

// start service
QString error; 
QCString appId;
KApplication::startServiceByName("CvsService", QStringList(), &error, &appId);

// create stub for repository
Repository_stub repository(appId, "CvsRepository");

// set directory of working copy
repository.setWorkingCopy("/home/user/kde/kdesdk/cervisia");

// create stub for service
CvsService_stub cvsService(appId, "CvsService");

// call "cvs log" for cervisiapart.h source
DCOPRef job = cvsService.log("cervisiapart.h");

// connect to signals to get output
connectDCOPSignal(job.app(), job.obj(), "jobExited(bool, int)", [MY SLOT]);
connectDCOPSignal(job.app(), job.obj(), "receivedStdout(QString)", [MY SLOT]);

// execute the command
job.execute();

// handle output in the slots




More information about the kde-core-devel mailing list