Debugger configurations and KCM

[Vladimir Prus]

On Sunday 11 May 2008 19:27:57 Hamish Rodda wrote:
> On Fri, 9 May 2008 08:09:50 am Vladimir Prus wrote:
> > Hi,
> > right now the project configuration dialog is KSettings::Dialog. I
> > would like to implement "launch configurations" where each project
> > can have several configurations, and for each configuration we have
> > several pages -- application, general GDB settings, maybe specific
> > gdb settings, maybe valgrind settings, so on.
> 
> I started on this, but just for run configuration - you can see in the current 
> run options dialog, you can create new run targets, 

You can try :-) It crashes immediately for me if I try to create new
target.

> but I also ran into  
> KConfig issues and will have to write my own workaround (maybe a generic 
> one?).
> 
> Then we could put the run target selector at the top of the GDB, valgrind etc. 
> configuration dialogs, if the user wants to set specific options, they just 
> select the run target which they want to apply it to, then set the setting.
> 
> What do you think?

Oh, we talked with Andreas on IRC, and my current vision is this:

1. We have a set of launch configurations. Each launch configuration loosely
corresponds to an application. You might have one launch configuration correspond
to C++ application, another to ruby one, another for a unit test, etc.

2. Each launch configuration can be launched in different modes. For example,
C++ application and be run, debugged, profiled, and have syscalls traced.
unit test can be also run and debugged. Not all modes makes sense for all
configurations, of course. You cannot run valgrind on python application.

3. Each launch configuration has a set of config pages.

4. Configurations are arranged in a tree. At the top you have item named
"Global", that has some configurations as direct children, and also
has projects as children. Project has configurations as children.

The UI for that consists of two parts:
1. Some selector for configuration.
2. Tab widget with config pages.

I think this approach is better than putting target select on each
individual page, because it makes the natural hierarchy more apparent
in UI -- it does not seem like the configuration is something specific
to each tab.

How the selection of configuration is done is a question. One solution is
a tree -- it shows the structure clearly, and allows to bulk-delete configurations,
but at the same time it takes up space. Another solution is a breacrumbs widget. 
Yet another solution is a tree, but clicking of a configuration hides the tree
and shows configs for that configuration, with a "back" button to get back to the
tree. I don't know what approach is right, but this can be easily changed.

In addition to the above, I also plan to associate some config pages
with the "GLobal" item and the projects -- for example, so that you
can select gdb binary once for all projects. 

How does this sound?

- Volodya