Adding QtDesigner custom widget plugin for KConfigXT

[Matt Rogers]

On Jul 10, 2007, at 6:44 PM, Andreas Pakulat wrote:

> 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

I don't know if it's the language barrier here or not, but it seems  
you're taking things said in this thread a bit too literally. What  
Adam means with the last sentence is that if the user needs to change  
their environment settings, they can do so in a straightforward manner.
--
Matt