interfaces / implementations separation (was Let's discuss KDevelop4 interfaces and shell)

[Andras Mantia]

Hi,

 I mostly agree with Alexander, with one remark: when it doesn't make 
sense to have alternative implementation, like for the shell or 
pluginloader, I don't see why would we need abstract interfaces and why 
can't we have the code for shell and the others directly in the library 
(platform)? Sure, care has to be taken for BC in those implementations, 
but only in the public interface for them. 
 In my eyes - as I stated many times -  the platform provides a way to 
create different KDevelop plugins, so by just writing different kind of 
plugins, it is possible to have either a completely new application 
(like Quanta or KDevelop/Ruby) or a mixed application that can load any 
installed plugins, which we can call "KDevelop". This "KDevelop" could 
load Quanta projects and turn itself into "Quanta" or C++ projects and 
turn itself "KDevelop/C++" or ruby projects and turn itself 
into "KDevelop/Ruby". 
 For this there is a public API for writing plugins (including new 
project managers) and to access some internals of the platform/shell. I 
can't tell right now what needs to be exposed, this will become visible 
only when coding.
 Sicnerely, coding of Quanta4 against KDevelop4 was pretty much 
abandoned since some months partly (but not only) due to the lack of 
direction of KDevelop4 and afraid of "losing" our work. I'm glad that 
this thread was started now. I'm going to update KDevelop4 so I 
actually can see the code what we have there at this moment.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070120/5755d81a/attachment.sig>