Adding QtDesigner custom widget plugin for KConfigXT

[Andreas Pakulat]

On 10.07.07 16:04:35, Adam Treat wrote:
> On Monday 09 July 2007, dukju ahn wrote:
> > I agree.
> > Env vars for plugin process and builder/debugger env vars could be
> > different. Plugins should provide its own env setting page and that's
> > why we will put env setting widget in platform/util.
> 
> One more thing because I'm a liar and can't keep my big mouth shut :)
> 
> Right now, when you are developing stuff via the command line, ask yourself... 
> 
> What do you do?
> 
> You open a shell and setup the environment however you like, right?  Either 
> manually or via scripts.  Then, you expect that ( and this is crucial ) 
> *every* process you run from that command line will run with the environment 
> you just set.  There is no ambiguity.  What you see is what you get.
> 
> Now, what do you do if you need to change the environment??
> 
> You either change the environment in that shell OR you open a new shell and 
> setup the environment and expect that *every* process executed in that shell 
> >from then on forward will run with that environment.
> 
> IMHO, the same should be true for kdevelop.  It just *works* and is exactly 
> what the developer would expect.

I completely agree until here.

> With the way you guys are proposing, if the developer launches a process via 
> plugin/kdevelop

launching processes will be done by a run/debug "action" and you need to
be able to configure the environment for this process, independent of
all other processes. Sure its nice if you can fetch a set of default
values (for example defaults for the project). And that environment
configuration will be in 1 place, the configuration of the run/debug
"action".

> and it does not behave how he'd expect, he has to go 
> searching through all the configuration widgets to find all the different 
> places that might impact said process environment.  And this *can* get 
> complicated.  You are designing KDevelop so that it is extensible via 
> plugins.  That means you have no idea what future plugins are going to do or 
> need WRT environment.

Right, and thats exactly why plugins need to be able to have their own
environment setting.

> With my solution it is unambiguous and clear.  The developer need only look in 
> *one* place and he can expect that all processes or plugins will adhere to 
> this.  If he needs to change something or open a new 'shell' he/she can do so 
> in an easy and straightforward manner.

Thats just not going to work, IMHO. How do you open a new "shell" in
kdevelop? I mean how do you tell kdevelop that you want plugin foo in
project bar to have environment variable PATH including
/opt/myfoobar/bin? I'd say by having a environment widget in the plugin
configuration for foo, which stores its values into the project
configuration of bar.

Andreas

-- 
You are so boring that when I see you my feet go to sleep.