Adding QtDesigner custom widget plugin for KConfigXT
mattr at kde.org
Mon Jul 9 00:27:01 UTC 2007
On Sunday 08 July 2007 15:55, Andreas Pakulat wrote:
> On 08.07.07 16:23:15, Adam Treat wrote:
> > On Sunday 08 July 2007, Andreas Pakulat wrote:
> > > 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.
> > They are needed for every external process that KDevelop or one of its
> > plugins will launch. Say the QT_PLUGINS_DIR for the designer plugin.
> You're wrong here, the designer plugin is a proper plugin and thus can
> have a proper configuration where you can select paths.
That may be the case, but possible examples never hurt.
> > Or the QTDIR for the qmake plugin.
> QMake will have a config dialog if its a Qt3 project. For Qt4 only the
> path to qmake needs to be configured.
Same as above. Try not to always be so completely literal. :)
> > It is really simple. The idea was that the user would have the ability
> > to set all environment options in one place and all external processes of
> > KDevelop would use it. Doesn't mean you still couldn't allow multi
> > setups.
> IMHO thats unifying too much. We have multiple projects in KDevelop and
> thus some things will not work correctly when set in a
> global-env-widget, for example QTDIR above. Or as I recently saw in IRC:
> QMAKESPEC pointing to qt3 when building a Qt4 project (as QMake doesn't
> check wether the specs used are for qt3 or qt4).
That's what multi-setups are for.
> > Anyway, it is up to you guys since I won't be coding it besides what is
> > already there, but as a user of KDevelop, I'd really like it if I could
> > set my environment once and be sure that all processes will use it.
> > Makes it brain-dead easy for the user to understand what so and so plugin
> > is actually doing.
> Plugins have configuration dialogs to be configured, there's generally
> no need for env vars there. Or better said: if the plugin runs an
> external process it should provide proper configuration for any env vars
> a user might want to set on that process.
And why can't we unify that bit? For example, the make builder, the run
options, and the debugger will be affected by the environment. You want to
code the same stuff three times? Or think of it this way: as a user, you want
to configure the same stuff three times?
Wouldn't it be better to set up a base environment config, and then as a user,
set up a configuration that uses the project wide environment settings as a
base, but change values for a certain few?
> So I still see only 3 places where a user needs env vars, because its
> visible to the user that here an external process is called and thats
> building, running and debugging a project.
the cmake build manager will need environment variables. it has to run cmake.
so there's four. :)
More information about the KDevelop-devel