Adding QtDesigner custom widget plugin for KConfigXT
mattr at kde.org
Wed Jul 11 03:45:59 UTC 2007
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
>>> 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
>> 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
>> 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
> 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
>> and it does not behave how he'd expect, he has to go
>> searching through all the configuration widgets to find all the
>> places that might impact said process environment. And this *can*
>> 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
> configuration for foo, which stores its values into the project
> configuration of bar.
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.
More information about the KDevelop-devel