kdevelop2.0

[John Birch]

On Wed, 13 Dec 2000 07:51, Sandy Meier wrote:
> Hi!
>
> > Also grepview does know the api for the projectview that is "set in
> > concrete" in the framework. This is not ideal...
>
> Sorry, I don't understand what you mean. :-(

Because the api for grepview/projectview and others is in the framework if 
you want to change that api then you need a new framework => a new kdevelop 
version. So removing some components and replacing them with others may not 
be that easy depending on what you want to do.

Perhaps I missunderstand the code. I confess I haven't looked as closely as I 
should.

> > I also believe the perceived loss of efficience is a "red herring". Show
> > me a compute bound problem in the framework and I'll show you a solution
> > :-)
>
> I didn't meant performance efficience, but source code efficience. If I
> know the interface I can directly use it and write sourcecode much  faster.
> Ok, it a "red herring" as you would say.:-)

Well, yes and no - knowing the interface is part of the puzzle - being able 
to change the interface easily is another part...

Lets say that when the user saves a source file then some components need to 
react and do something. For each of those components you have to fish out the 
KDevEditorManager pointer, connect to the sigSavedFile(blah) signal and do 
your stuff. Okay, replace that with an event model. You need to know the 
event and put the event in your event filter and do your stuff. Quite a 
similiar anount of coding and knowledge required... so far

Now lets say you change the ProjectManager to also save files (this is just 
for argument sake only :-) Each of the components that reacts to save file 
now needs to be changed to know the interface to ProjectSpace (remember they 
also needed to know the KDevEditorManager interface as well), connect to the 
changed file signal in ProjectSpace and do your stuff. But in the event model 
it'll just work with _no_ change to the components code.

Which did you say was easier to program? :-)

Now before you respond saying well I just connect blah blah - I know this. 
Sooner or later you will run into these issues. And don't forget this will 
probably break users custom components.

And of course the event model also has it's problems...

> > I suspect we should stop this now. I will not convince you that there is
> > a better way, just as you will not convince me that I am wrong.
> >
> > My last word
> > The code Bernd has written is still excellent. It'll be a great pleasure
> > to work within this framework. For that I've extremely grateful to him.
> > :-)
>
> Yes, I hope that we release a cool KDevelop2 with this framework.:-) If we
> got full Pascal/Delphi support sometimes, we will know that this framework
> works.

Well I lied. It's not my last word :-)

I conclude the only reason you guys don't agree with me is that you live in 
the Northern Hemisphere and are therefore upside down, gazing at the wrong 
stars :-))

jbb

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«