Let's discuss KDevelop4 interfaces and shell

[Richard Dale]

On Friday 19 January 2007 01:07, Matt Rogers wrote:
> On Thursday 18 January 2007 5:35 pm, dymo at ukrpost.ua wrote:
> > Hi! I've started my work of Sublime UI integration and first looked at
> > kdev4 architecture and code in lib/ and src/. So I'd like to share some
> > thoughts about what I saw. This will be lengthy email, so prepare ;)
I haven't looked at the code for KDevelop4, and so I'm more concerned with 
commenting on the design process rather than any code produced so far. I 
would rather we stepped through the use cases for what we were trying to do 
with KDevelop3, saying what was wrong and what was right and based the design 
of KDevelop4 with reference to that. In my case I could comment on what I 
tried to do with the ruby dev environment, what problems I had and what sort 
of things I couldn't do at all. For instance, there are four sorts of ruby 
projects; straight scripts, gui projects with qtruby, gui automake based kde 
ruby (or cmake for kdevelop4) projects and finally rails projects. The 
assumption with the kdevelop3 design was that they would all be the same, and 
the problems with the recent release of kdevelop 3.4 were related to my hacks 
to get round architectural problems.

I'm busy with other things, but if I could start working on Ruby support I 
would still rather hold off. This is because of my experience with the 
disasterous initial attempt to produce KDevelop2. I tried to get 
java/objective-c support in there right from  the start, thinking that was 
the best way to 'bake in' support for non-c++ languages. It was a waste of 
time though, my stuff kept breaking as the app changed, and I had to keep 
working on it just to stand still. In the end that project was scrapped as 
KMDI was just too complicated to get working in conjunction with various 
other over-ambitous developments. Bernd Gehrmann replaced it with gideon 
which was stripped down to just the minimal plugin architecture to get 
started, with no excess abstractions that would only be used in the future.

The KDevelop4 design process seems to be a bit too abstract. Someone decides 
it is a better idea to move all the sources from lib and src into src, 
because it will be a good idea in the future, when a 'platform' is created. 
But we aren't yet sure exactly what a 'platform' is though, and so we can't 
do it just yet. We seem to be ignoring any lessons from the past, and not 
discussing use cases we already have, but just designing in a vacuum.

-- Richard