jbb at kdevelop.org
Sun Dec 10 18:47:40 UTC 2000
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 :-)
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
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.
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:
More information about the KDevelop-devel