runpreferences & kconfig question

[Andreas Pakulat]

On 08.12.08 11:25:10, Vladimir Prus wrote:
> On Monday 08 December 2008 00:36:42 Andreas Pakulat wrote:
> > On 07.12.08 21:50:22, Vladimir Prus wrote:
> > > On Sunday 07 December 2008 20:27:23 Andreas Pakulat wrote:
> > > > On 07.12.08 16:33:08, Vladimir Prus wrote:
> > > > > 2. I don't see runconfig.kcfg anywhere -- did you commit it?
> > > > 
> > > > Well, there's not much point to have it, if its not used for generating the
> > > > code.
> > > 
> > > Then, at least the text in runconfig.h saying it's generated by kconfig_compiler
> > > has to be removed.
> > 
> > Sure.
> >  
> > > > > 3. Did you have any specific plan how to clean this up? I'm thinking
> > > > > that we can create LaunchConfigSkeleton class, derived from
> > > > > ProjectConfigSkeleton and specify that inside runconfig.kcfg. Any reason
> > > > > that would not work?
> > > > 
> > > > I don't see why the launch config would need to be project-specific. Sure
> > > > at some point we want to have the ability of moving settings into the
> > > > project, 
> > > 
> > > Yes. Or rather, storing launch configs in project so that they are visible
> > > to other developers. 
> > 
> > Not sure what the difference would be, actually right now there's no way to
> > share anything of a project except whats written into the .kdev4 file
> > during project creation. I'm not sure we can tackle that for 4.0, as it
> > might get kinda complex to do properly (we had something like that when I
> > started to work on kdev4 about 2 years ago and it was rather complex code
> > and almost non-understandable GUI behaviour).
> 
> I'll be happy with not implementing this for 4.0 (if that actually proves hard),
> in which case the LaunchConfigSkeleton won't be related to ProjectConfigSkeleton.
> 
> > > > but generally run-settings should be global - IMHO (think of 
> > > > sharing executables across projects)
> > > 
> > > I was thinking of having hierarchy of launch configs, where you have 'Global'
> > > item on the top, and can edit some properties (like default name of debugger),
> > > then you have global launch configs, and projects as children of that
> > > item. Then you can have project launch configs. Imagine you have a large project
> > > with many targets and the project is for ARM GNU/Linux. It would be nice to specify
> > > the 'arm-none-linux-gnueabi-gdb' in a single place -- not for each binary in that
> > > project.
> > 
> > So we'd have
> > 
> > Global
> >  - launchconfig1
> >  - launchconfig2
> >     - slightlydifferent for project foo
> >     - slightlydifferent for project bar
> 
> Rather
> 
>  Global
>   - launchconfig1
>   - launchconfig2
>   - project foo
> 	- projectlaunchconfig1
> 	- projectlaunchconfig2
> 
> > ? With settings on each level of the tree? How do we provide different
> > config pages for pdb or irb (ruby/python)? 
> 
> Each launch config has a type. E.g "Python Application". Each launch config
> further specifies what config pages it wants -- and Python Application will
> specify the pdb config page as desired

Hmm, sounds ok. We can always have sorting/filtering on the tree if one
just wants to see specific types of launches... 

We could probably still use KCM's with this, but definetly not with
KCMultiDialog. I'm not sure though that would give us any advantage
compared to a page-getter and a setConfigGroup or something like that. So
please do whatever is easiest/fastest to implement.

Andreas

-- 
Stay away from flying saucers today.