RFC: Improving Qt4 designer support in kdevelop3.4
apaku at gmx.de
Thu Jul 20 09:27:46 UTC 2006
On 19.07.06 18:55:04, Matt Rogers wrote:
> On Wednesday 19 July 2006 13:33, Andreas Pakulat wrote:
> > On 19.07.06 19:47:02, Andreas Pakulat wrote:
> > > I started to look at how the designer support for kdevelop3.4 could be
> > > improved. Working my way through the FAQ I stumbled upon:
> > >
> > > http://www.kdevelop.org/mediawiki/index.php/FAQ#How_can_I_develop_with_Qt
> > >4_and_KDevelop-3.3.x.3F
> > >
> > > which says that kdevelop starts designer through kdeinit. So before I
> > > start to dig into kdevelop's code, I'd like to ask if you guys want to
> > > keep it that way or if it would be Ok to specify the path to the
> > > designer within kdevelop and kdevelop just runs that.
> > >
> > > The drawback of the kdeinit option is that if no desktop file for either
> > > qt3 designer or qt4 designer is installed in the system the user needs
> > > to create one (this is the case currently for qt4 on debian). Also the
> > > second option would allow kdevelop to run the "proper" version of other
> > > Qt tools, such as qmake, automagically without fiddeling around with
> > > PATH.
> > Should've looked at the source first, before trusting a (possibly
> > outdated) FAQ entry. KDevelop uses KRun::run with a QString, which
> > doesn't invoke kdeinit. So I'm definetly going with the 2nd option,
> > specifying the qtdir.
> Looking forward to seeing the patch. :)
Me too ;-) However I just got stuck yesterday, due to the following:
The code that executes designer is in src/partcontroller.cpp and I
haven't yet found a way to access the project configuration from
there... So all I can see that would be possible atm is a possibility to
choose the designer binary inside the kdevelop settings dialog...
Any pointers as to how I could get the information from the current
project would be appreciated (pointers to the classes to be used are
Do not overtax your powers.
More information about the KDevelop-devel