Debugger configurations and KCM

[Andreas Pakulat]

On 11.05.08 19:52:38, 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.
> 
> > 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?

+1 from me.

And I'd like to add that the limitation of the current run dialog is not
KConfig, but KConfigSkeleton and how it works (initialized once with a
kconfig + kconfiggroup to read/write from). Depending on how kcm's are
handled in the new vision this might not be a problem anymore - i.e. if
the kcm instances are always re-created we're fine because the
kconfigskeleton stuff can be a non-singleton and thus also gets always
re-created.

Andreas

-- 
Your mode of life will be changed for the better because of new developments.