mirror of
https://bitbucket.org/smil3y/kde-extraapps.git
synced 2025-02-26 20:03:10 +00:00
59 lines
2.6 KiB
Text
59 lines
2.6 KiB
Text
CVS plugin for KDevelop4
|
|
========================
|
|
(C) Robert Gruber [rgruber A users!sourceforge!net]
|
|
|
|
|
|
The CVS plugin is separated into three part.
|
|
|
|
1) The CvsPart (cvspart.h)
|
|
It is the main entry point to the CVS plugin. By implementing
|
|
the IVersionControl interface it offers a lot of slots that will
|
|
invoke the different CVS actions.
|
|
This class serves as a dispatcher. It takes the urls and options
|
|
for the requested CVS action and passes them to the CvsProxy (#2)
|
|
to get a CvsJob returned. After starting, the job's result() signal
|
|
gets connected either directly to CvsMainView (#3) or to a custom
|
|
output view.
|
|
|
|
2) CvsProxy (cvsproxy.h) and CvsJob (cvsjob.h)
|
|
The CvsProxy serves as a single point of entry for creating the
|
|
CvsJobs. The proxy offers a list of methods for the different
|
|
supported CVS actions. Each of these methods will return a CvsJob
|
|
object. So the caller does not have to worry about the whole
|
|
job and commandline creation. Calling the appropriate method will
|
|
do all the work and return a CvsJob object ready for starting.
|
|
|
|
3) The CvsMainView (cvsmainview.h) and custom view (like editorsview.h)
|
|
The CvsMainView displays output from finished jobs. It holds a
|
|
KTabWidget to which everbody can add custom output views. For
|
|
instance when the user requested a "cvs log" action, a new view
|
|
will be added. This view will then parse the output of the "cvs log"
|
|
job and display it in a nice way.
|
|
But it does not make sense to add new views for every cvs action.
|
|
For example, adding a new view everytime "cvs commit", "cvs edit" or
|
|
similar actions get executed would be an overkill. Therefore
|
|
CvsMainView also provides a generic output view that just displays
|
|
the plain text output from such jobs. Unlike custom views, this
|
|
generic view can not be closed and it will simply append the output
|
|
from each job that got connected to it.
|
|
|
|
|
|
|
|
The workflow of the CVS plugin looks like this:
|
|
1) The user requests a CVS action
|
|
2) The matching slot from CvsPart will be called
|
|
3) Optional: The user may be prompted for additional input
|
|
[ see: CvsPart::commit() ]
|
|
4) CvsPart passes all needed options to the CvsProxy by calling
|
|
it's method for the requested action.
|
|
5) CvsProxy assembles the commandline, creates a CvsJob object and
|
|
returns a pointer to the CvsJobs object
|
|
6) CvsPart calls start() for the returned CvsJob object and continues
|
|
with either #6.1 or #6.2
|
|
6.1) Connectes the job's result() signal to the generic output view
|
|
from CvsMainView
|
|
6.2) Creates a custom view, connects the job's result() signal to it
|
|
and adds the view to CvsMainView
|
|
|
|
|
|
|