The keyword is Model/View (was Re: GDB/MI)
roberto.raggi at trolltech.com
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
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..)
More information about the KDevelop-devel