C++ parser integrated to kuml
p_george
p_george at club-internet.fr
Sat Jan 8 14:10:25 GMT 2000
jbb wrote:
> > > Wern't you going to intergrate kuml and kdevelop at some stage in the future?
> >
> > I think for DCOP would be the best solution to handle communications
> > between Kuml and KDevelop2.
I had the idea, in september, to integrate UML to kdevelop. Then, Darius
Stachow told me he has started kuml. So I joined the project. Now comes
the problem of having a standalone kuml, that can cooperate with
kdevelop.
I thought of CORBA and after DCOP, but those will not be avalaible
before KDE2, that is in 6 months I think. So, for the moment there will
be no or few relations between kuml and kdevelop. I would have
personnaly prefered a complete integration of kuml into kdevelop, but
the other developers disagreed, and I joined their advice.
So, for a long time, communication between kdevelop and kuml will happen
through the source files (!)
________
kdevelop --- editor --- > | SOURCE | <--- code generator --- kuml
--------
I suppose you see the problem that occurs when both kuml and kdevelop
are running on a project ...
> Your right that kuml and kdevelop need to coexist separately, but I suspect
> that passing _all_ the class data via DCOP isn't the solution.
Kdevelop is bound to C++, at least for a long time, and kuml needs to
handle other OOP languages. So, if I have to make a Java parser (I hope
I will not !), I will try to make it so that it will resemble to the C++
one and be reusable for kdevelop.
> It would be a good idea to tackle the database issues in the parser so that,
> incremental updates could happen on a header change rather than a full reparse
> and data sharing between kuml and kdevelop via db could be used with DCOP
> "trigger" messages.
Synchronisation problems between the parser (CClassStore), the code
edition and the different views (in kuml and kdevelop) are so important,
that the parsing process is an atomic one, restarted from scratch every
time it is needed. this may be not the best solution, but surely the
safer.
> The application source code should be editable via kuml or kdevelop.
Kuml will not have the capability to edit code, just the diagrams. The
user's choice for a code editor will certainly be kdevelop (at least for
C++).
More information about the KDevelop
mailing list