kdevelop2.0

[John Birch]

Hi,

I see the latest changes in kdevcomponent has removed  heaps of signals from 
it. This is excellent but ... I think exposing the parts through this 
interface is suboptimal.

We should try and make the parts "stand-alone" and the best way of doing this 
is by making the base framework not know what components it is dealing with. 
All it knows is that it has a set of kdevcomponets to load and it sets up a 
simple event loop for the communication between parts.

The reason to do this is so that we can change any (and all components) 
without changing the framework. If you decide that you don't like a part (eg 
my editor manager) then you are free to implement your own part with whatever 
name you like.

In the current implementation, you must write an editor manager otherwise 
somewhere a component will blow up when it tries to access it and this may 
not be in a component that we write... And there may be some horrible runtime 
problems when components have been compiled against different implementations 
of a part (I'm unsure about this but don't want to have to find out :-)

Sandy,
you wanted feedback on KDevActions. Well it's a good idea As far as I can 
figure out it falls into the pattern "I'm about to do something, but I need 
information from other components before I can". We have other instances of 
this, eg getting the config widget before displaying the dialog. I like to 
think of these as "reverse events" ie not trying to push data out to everyone 
because something has happened, but trying to suck data to you because 
something happened. 
It would be good if the framework could deal in this concept without the 
details - perhaps something like

void getData(KDataEvent* data);

and subclassing the KDataEvent to the special knowledge required.

I'm sure the ideas I have also have problems, but I suspect our fundementally 
difference in thinking is that I'm not wanting us to write the whole ide, but 
to allow others to write their ide _without_ having to modify the framework.

I think the framework (and also the scope of this project) really needs to be 
discussed openly rather that just implemented.

jbb

PS I reserve the right to be wrong...

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