Adding QtDesigner custom widget plugin for KConfigXT

Andreas Pakulat apaku at
Sun Jul 8 17:45:16 UTC 2007

On 08.07.07 13:15:32, dukju ahn wrote:
> 2007/7/8, Andreas Pakulat <apaku at>:
> > On 08.07.07 08:10:42, Adam Treat wrote:
> > > On Sunday 08 July 2007, Andreas Pakulat wrote:
> > > > IMHO thats not right. At least not if we want to allow to have multiple
> > > > run/debug setups for each project. Then you'll also want to have
> > > > different environment for each of them. So you'd also need a different
> > > > environment setting for the build process.
> > >
> > > Then have multiple run/debug setups for each project.  Doesn't mean that the
> > > rest of KDevelop can't sync environment when you change the setup though.
> > >
> > > Just use the widget and let everything sync to that and provide a way for
> > > switching setups.  The environment settings should be universal for all
> > > external processes though and the user should only have to set it once, not 8
> > > different times in different places.
> >
> > I think I'm missing something here. Where exactly are changes to
> > environment settings needed? As far as I can tell that may be needed for
> > running an executable (or debugging, which shouldn't differ from
> > running) and for building a project.
> >
> > So the only case where one might want to have unified environment is
> > when multiple projects need the same environment. So we'd need a way to
> > make sure that the user can define this and then the widget should
> > update the related projects when changes are made in one. (or have that
> > as a button "propagate changes to related projects").
> Basically it seems good, but how can we keep track of and store
> the project relationships? I think that gains little benefit while
> requiring much more coding.

Uhm, we will have at least dependecy between projects, so the builders
know they have to build project foo before project bar. And storage of
such deps would be done in project configuration, by just referencing
the .kdev4 file. 

> Rather then storing relationships, we can just have some menu
> where it installs common env variables to all( or selected ) already
> opened projects. But that's not that big priority -- IMHO.

But how/where do you store the selection of projects? Also this would
mean another extra place for env vars, also you'd need to choose wether
these global vars are for building, running or debugging (or any
combination of these three). Not going to work.

Anyway, I'm with you in that for now its enough that we have a common
widget and each plugin that needs environment settings can use it.


Write yourself a threatening letter and pen a defiant reply.

More information about the KDevelop-devel mailing list