Debugger configurations and KCM

[Hamish Rodda]

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.

> 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.

> 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.

> 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.

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080513/98ac9cd6/attachment.sig>