Debugger configurations and KCM

[Vladimir Prus]

On Monday 12 May 2008 23:08:59 Hamish Rodda wrote:
> On Mon, 12 May 2008 01:52:38 am Vladimir Prus wrote:
> > 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.
> 
> It's on my list to fix when I get home in a week.
> 
> > > 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.
> 
> Yes, we have the infrastructure for this in place already, I called them 
> instrumentors.

Yes, I've noticed and what I propose is based on that.

> > 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.
> 
> Ok, that's more a layout thing.

Exactly.

> > 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.
> 
> Yes, we can experiment.  Some writing down of use cases could be helpful.

I guess code first, at this point. With something working, we can try best UI
for such funny cases as "gdb running on remote host XXX, target running on 
remote host YYY" :-)

> 
> > 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.
> 
> Yes, this is of course the "root" item of the tree, I presume.

Yes.

- Volodya