jbb at kdevelop.org
Tue Dec 12 19:58:59 UTC 2000
On Wed, 13 Dec 2000 07:51, Sandy Meier wrote:
> > 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
> > 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
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
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
More information about the KDevelop-devel