RFC: Improving Qt4 designer support in kdevelop3.4

Hi,

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.kdeve
lop.org/mediawiki/index.php/FAQ#How_can_I_develop_with_Qt4_a
nd_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.

In both cases I'd like to make this a project specific
option, because
that's what it really is. I also think the
"integrated-designer" option
should then go into the project specific part, because this
option
doesn't make any sense when working on a Qt4 project.

So what do the kdevelop dev's think about this, should I go
the kdeinit
way or try the specify-qtdir option?

Andreas

-- 
Your mode of life will be changed for the better because of
good news soon.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 19.07.06 19:47:02, Andreas Pakulat wrote:
> Hi,
> 
> 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.kdeve
lop.org/mediawiki/index.php/FAQ#How_can_I_develop_with_Qt4_a
nd_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.

Andreas

-- 
Ships are safe in harbor, but they were never meant to stay
there.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Wednesday 19 July 2006 13:33, Andreas Pakulat wrote:
> On 19.07.06 19:47:02, Andreas Pakulat wrote:
> > Hi,
> >
> > 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.
>
> Andreas

Looking forward to seeing the patch. 
--
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

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
fine).

Andreas

-- 
Do not overtax your powers.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

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
fine).

Andreas

-- 
Do not overtax your powers.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

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
fine).

Andreas

-- 
Do not overtax your powers.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 7/20/06, Andreas Pakulat <apakugmx.de> wrote:

> 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
> fine).
>

Something along these lines (untested):

QDomDocument * dom = API::getInstance()->projectDom();
if ( dom != 0 )
{
  QString property = DomUtil::readEntry( *dom,
"/path/to/property" );
}


Of course, this will (apparently, I'm out of the loop right
now)
change in KDev4...


// jens

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 7/20/06, Andreas Pakulat <apakugmx.de> wrote:

> 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
> fine).
>

Something along these lines (untested):

QDomDocument * dom = API::getInstance()->projectDom();
if ( dom != 0 )
{
  QString property = DomUtil::readEntry( *dom,
"/path/to/property" );
}


Of course, this will (apparently, I'm out of the loop right
now)
change in KDev4...


// jens

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 7/20/06, Andreas Pakulat <apakugmx.de> wrote:

> 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
> fine).
>

Something along these lines (untested):

QDomDocument * dom = API::getInstance()->projectDom();
if ( dom != 0 )
{
  QString property = DomUtil::readEntry( *dom,
"/path/to/property" );
}


Of course, this will (apparently, I'm out of the loop right
now)
change in KDev4...


// jens

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On 20.07.06 11:41:34, Jens Dagerbo wrote:
> On 7/20/06, Andreas Pakulat <apakugmx.de> wrote:
> 
> > 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
> > fine).
> >
> 
> Something along these lines (untested):
> 
> QDomDocument * dom =
API::getInstance()->projectDom();
> if ( dom != 0 )
> {
>   QString property = DomUtil::readEntry( *dom,
"/path/to/property" );
> }

Thanks for that, now I know this is not really the right
place to ask,
but as there's a modeline in the cpp configuration widget
for kate:

How do I tell kate to not always change to 2 space indent
when I write a
brace or semicolon in a line? It always makes 2 spaces out
of the 4 I
put into the line for indentation.

Andreas

-- 
Everything that you know is wrong, but you can be
straightened out.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel