<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Hello guys, </FONT></DIV>
<DIV><FONT face=Arial size=2>I think my question of the last evening has put
forward some interesting questions about what is an IDE and what the
relationship between an IDE and and CASE TOOL like Umbrello should be. I think
too that some of you have misunderstood my request,</FONT></DIV>
<DIV><FONT face=Arial size=2>By integration of Umbrello into Gideon, I mean the
possibility of embedding Umbrello features into Gideon and not a merge of the
two projects.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The new architecture on Gideon based on Kparts
framework enables this much more easily than before. Basically Gideon is a
container for its "parts"</FONT></DIV>
<DIV><FONT face=Arial size=2>A part is something like a plugin but with a
widget, the core of gideon manages plugins registry and layout of their
widgets.</FONT></DIV>
<DIV><FONT face=Arial size=2>the other big "Kpart" application is
Konqueror</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>From my user point of view, I'd like to give
you some reasons of considering such an "integration"</FONT></DIV>
<DIV><FONT face=Arial size=2>1. You are now full part of the Kde Project,
Umbrello is into KDE CVS. Interoperability between applications is a goal and
the reason of "Kparts"</FONT></DIV>
<DIV><FONT face=Arial size=2>2.It's a way to bring back to Kdevelop</FONT></DIV>
<DIV><FONT face=Arial size=2>3.You will immediatly increase the number of users
of Umbrello</FONT></DIV>
<DIV><FONT face=Arial size=2>4. The Kdevelop classwizard is very good, but when
you want to redesign , you have to cancell all your stuff by hand. It's simply
not a CASE Tool....</FONT></DIV>
<DIV><FONT face=Arial size=2>5. Roundtrip would be easy</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><BR><FONT face=Arial size=2>>first, IDE's are overly compiler-centric.
developers have to deal with files <BR>>and directories because that's what
the build environment understandes. the <BR>>files don't really correspond to
anything useful from the development <BR>>standpoint. all we care about is
class and implementation - i don't give a <BR>>shit what file its
in.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I totally agree with you<BR><BR>>second, IDE's
are good if all you care about is the code. sure, the class view <BR>>is
useful - i guess, but it doesn't provide a very good abstraction for
<BR>>viewing the project. neither does the file view. its just lists of
classes <BR>>and files and the like.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>it does, there is a "static" view which give you
only inheritance relationshps<BR><BR>>to sum up, i think that IDE's will
be obsolete - at least in their current <BR>>form sometime in the
not-so-distant future. from the other side of the <BR>>argument, we have CASE
tools - like UML modeler's and such.</FONT></DIV>
<DIV><BR><FONT face=Arial size=2>>traditionally, they haven't really been to
useful for development because <BR>>they've not been tied to the IDE. also,
roundtrip engineering (making a <BR>>change to the code affects the design in
real time and vice versa) hasn't <BR>>been implemented very well.
additionally, CASE tools don't provide really <BR>>good mechanisms for
navigating the possible abstractions of your project. <BR>>usually, there's a
tree view with all your classes and use cases and <BR>>diagrams, but that's
pretty weak. UML allows for significantly more <BR>>complicated abstractions
- for example, viewing inheritance or containment <BR>>hierarchies for a
library.<BR><BR>>what a lot of people don't know is that UML is designed to
contain <BR>>implementation as much as specification. in other words, the
CASE tool could <BR>>become the IDE. that, as much as anything is my real
goal for Umbrello - to <BR>>replace the standard IDE with a CASE tool. all
that's missing is adaptations <BR>>to UML to support the modeling of build
environments, compiler options and <BR>>the like. hmmm... that sounds like a
master's thesis.<BR></FONT></DIV>
<DIV><FONT face=Arial size=2>what you are talking about is still an
IDE, which would be "design-oriented"....</FONT></DIV>
<DIV><BR><FONT face=Arial size=2>>as for Umbrello and Gideon - i don't see it
happening - certainly not for 1.x. <BR>>if somebody wants to adapt the design
for 2.0 to support roundtrip <BR>>engineering, its all them - as long as it
doesn't break the design for the <BR>>rest of the application and doesn't
steer umbrello away from what we want it <BR>>to be.<BR><BR><STRONG>I'd like
to look at this issue....</STRONG></FONT></DIV>
<DIV><FONT face=Arial size=2><STRONG></STRONG></FONT> </DIV>
<DIV><FONT face=Arial size=2>Bye Simon,</DIV>
<DIV><BR><BR><BR>-------------------------------------------------------<BR>This
SF.NET email is sponsored by:<BR>SourceForge Enterprise Edition + IBM +
LinuxWorld =omething 2 See!<BR></FONT><A href="http://www.vasoftware.com"><FONT
face=Arial size=2>http://www.vasoftware.com</FONT></A><BR><FONT face=Arial
size=2>_______________________________________________<BR>Uml-devel mailing
list<BR></FONT><A href="mailto:umbrello-devel@kde.org"><FONT face=Arial
size=2>umbrello-devel@kde.org</FONT></A><BR><A
href="https://mail.kde.org/mailman/listinfo/umbrello-devel"><FONT face=Arial
size=2>https://mail.kde.org/mailman/listinfo/umbrello-devel</FONT></A><BR><BR></DIV></BODY></HTML>