The keyword is Model/View (was Re: GDB/MI)

Roberto Raggi roberto.raggi at
Wed Sep 14 17:44:36 UTC 2005


On Wednesday 14 September 2005 09:41, jbb wrote:
> FWIW. I think the frontend isn't a lot of code, (it's just a bit intricate
> in places :-) So a rewrite isn't quite as large a task as it may sound.

Please guys remember that we want to push the model/view stuff in KDevelop4. 
The goal is to be able to create different views showing the same data. This 
is very important for the next generation of KDevelop. For instance, would be 
nice to be able to "clone the existing" toplevel window(The KDevelop Main 
Window) and change the current profile at runtime(perspective with the 
eclipse naming convension). This will solve many of our usability problems, 
like the incredible amount of "tool windows" embedded in KDevelop. 

Another thing. Remember we need to load multiple programming language support 
at the same time! KDE is switching to SCons/BKSYS. So we should be able to 
load a "primitive python support" for advanced users that want to change the 
SCons project file *by hand*, the C++ support(if the user is working with 
C++), the javascript and XML support if the project can be extended at 
runtime! and so on..
For sure we don't want to show all the possible views! So we need to be able 
to create new "top level windows(a.k.a MainWindow)", the tool windows, and 
change perspective at runtime(== don't store your data in the View) :-)

Note this mean we're going to drop Project-Scope plugins. Project-Scope 
plugins are dangerous. For instance we don't want to load/unload the C++ 
support everytime the user switch Project :-) Remember that each plugin has 
full-access to KDevelop. So it's a job of the plugin to cleanup the state 
when it's unloaded(too dangerous). 

We need something different. We need a sort of *Lazy* plugin. Where the GUI is 
separated from the CORE(model, data, logic, etc..)

ciao robe

More information about the KDevelop-devel mailing list