Vladimir Prus ghost at
Mon May 5 07:39:43 UTC 2008

I think I'm almost done with hacking on areas. What we have now:

- We have two default area types: "Code" and "Debug". User can switch
between those.
- Each area has predefined set of views that are shown in it, and
user can add and remove views as he sees fit
- For each area, we remember the set of views, remember which view
is shown on each side, and remember the dimension of each dock area,
if user has explicitly changed that. We also remember number, position
and properties (like text on/off) of toolbars. 

What is desirable to have, but is not done yet:
- Multiple main windows. Right now, there are a couple of design issues
with those, that I've posted previously. Those issues were there before
I touched this code, and make non-first main window mostly useless, so
there's no point to even try to test areas in second window right now.
When that works, we have to arrange that 
- Custom areas. There are commands to create new user-defined window,
but it does not do anything.
- Plugin-line definition of new areas. We'd want to be able to 
define new areas by providing a new plugin/.desktop file, not by
hacking code.
I don't think I'm about to work on those bits right away, so it's up
to grabs.

Of course, I still have to implement the thing that prompted me to
do all this -- automatically switch to debug area when starting debug.
I'll do it when I cleanup the debugger configurations a bit.

I see that a few of sublime tests now fail. In some cases it seems like
the test itself has to be adjusted -- maybe we can discuss that on IRC
one day? Also, I'll try to write some tests for save/restore functionality
(as soon as I know how to run/quit KDevelop several times in a test).

- Volodya

More information about the KDevelop-devel mailing list