Adding QtDesigner custom widget plugin for KConfigXT

I'd like to port kdev3's environment variable widgets into
current makebuilder project setting page. Currently it uses
KEditListBox.

I found that to be used with kconfig compiler, custom widget
should
have name "kcfg_name" in qtdesigner file. That
means, we have
no way but to add custom widget plugin for designer.
kdelibs
already installs its own designer plugins.

Is it allowed thing that kdevelop installs widget plugin
for
qt designer? Or is there any simpler approach that custom
widgets
are compatible with KConfigXT? I want to check before I
start.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 06.07.07 08:55:08, dukju ahn wrote:
> I'd like to port kdev3's environment variable widgets
into
> current makebuilder project setting page. Currently it
uses KEditListBox.

Make sure you choose the one that allows to view the current
environment
settings. Not sure which one that is though.

> I found that to be used with kconfig compiler, custom
widget should
> have name "kcfg_name" in qtdesigner file.
That means, we have
> no way but to add custom widget plugin for designer.
kdelibs
> already installs its own designer plugins.
> 
> Is it allowed thing that kdevelop installs widget
plugin for
> qt designer?

In general I don't think there's a problem with that,
however as I said
this widget (and its plugin if needed) should be in
kdevplatform/util
not in kdevelop. 

> Or is there any simpler approach that custom widgets
> are compatible with KConfigXT?

I think the promote to custom widget way should also work,
after all
KConfigXT uses the object names in the actual code to find
the widgets,
that is it just walks through the object hierarchy and
searches for
objects with kcfg prefix. So put in a KEditListBox in the
.ui file,
right-click it and select "promote to custom
widget" then choose the
class name and header file of the new widget.

Of course as we get more and more widgets in util/ or some
widgets/
library in platform we probably should create a plugin that
serves all
these widgets (you don't need one plugin per widget).

Andreas

-- 
You look like a million dollars.  All green and wrinkled.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Jul 6, 2007, at 7:55 AM, dukju ahn wrote:

> I'd like to port kdev3's environment variable widgets
into
> current makebuilder project setting page. Currently it
uses  
> KEditListBox.
>
> I found that to be used with kconfig compiler, custom
widget should
> have name "kcfg_name" in qtdesigner file.
That means, we have
> no way but to add custom widget plugin for designer.
kdelibs
> already installs its own designer plugins.
>
> Is it allowed thing that kdevelop installs widget
plugin for
> qt designer? Or is there any simpler approach that
custom widgets
> are compatible with KConfigXT? I want to check before I
start.
>

What happened to the environment stuff that we had recently
that Adam  
had written? IMHO, we need to unify the environment
handling, which  
means having one place in the project options to configure
it and  
having that apply everywhere.

Thoughts?
--
Matt



_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 07.07.07 23:26:42, Matt Rogers wrote:
> 
> On Jul 6, 2007, at 7:55 AM, dukju ahn wrote:
> 
> > I'd like to port kdev3's environment variable
widgets into
> > current makebuilder project setting page.
Currently it uses  
> > KEditListBox.
> >
> > I found that to be used with kconfig compiler,
custom widget should
> > have name "kcfg_name" in qtdesigner
file. That means, we have
> > no way but to add custom widget plugin for
designer. kdelibs
> > already installs its own designer plugins.
> >
> > Is it allowed thing that kdevelop installs widget
plugin for
> > qt designer? Or is there any simpler approach that
custom widgets
> > are compatible with KConfigXT? I want to check
before I start.
> >
> 
> What happened to the environment stuff that we had
recently that Adam  
> had written?

IIRC that was part of the settings folder in lib/ which got
nuked. I
just had a look, it seems to be feasible and a bit easier to
use than
the kde3 one.

So I guess the widget from that should be put into
kdevplatform/lib/util.

Dukju: please fetch the lib/settings directory in kdevelop
from revision
641348 and use the env-widget from there, it should be fully
functional
and uses model/view for editing.

> IMHO, we need to unify the environment handling, which 

> means having one place in the project options to
configure it and  
> having that apply everywhere.

IMHO thats not right. At least not if we want to allow to
have multiple
run/debug setups for each project. Then you'll also want to
have
different environment for each of them. So you'd also need a
different
environment setting for the build process.

Andreas

-- 
Your boss is a few sandwiches short of a picnic.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 08 July 2007, Andreas Pakulat wrote:
> IMHO thats not right. At least not if we want to allow
to have multiple
> run/debug setups for each project. Then you'll also
want to have
> different environment for each of them. So you'd also
need a different
> environment setting for the build process.

Then have multiple run/debug setups for each project. 
Doesn't mean that the 
rest of KDevelop can't sync environment when you change the
setup though.

Just use the widget and let everything sync to that and
provide a way for 
switching setups.  The environment settings should be
universal for all 
external processes though and the user should only have to
set it once, not 8 
different times in different places.

My 2' cents,
Adam

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 08.07.07 08:10:42, Adam Treat wrote:
> On Sunday 08 July 2007, Andreas Pakulat wrote:
> > IMHO thats not right. At least not if we want to
allow to have multiple
> > run/debug setups for each project. Then you'll
also want to have
> > different environment for each of them. So you'd
also need a different
> > environment setting for the build process.
> 
> Then have multiple run/debug setups for each project. 
Doesn't mean that the 
> rest of KDevelop can't sync environment when you change
the setup though.
> 
> Just use the widget and let everything sync to that and
provide a way for 
> switching setups.  The environment settings should be
universal for all 
> external processes though and the user should only have
to set it once, not 8 
> different times in different places.

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.

So the only case where one might want to have unified
environment is
when multiple projects need the same environment. So we'd
need a way to
make sure that the user can define this and then the widget
should
update the related projects when changes are made in one.
(or have that
as a button "propagate changes to related
projects").

Andreas

-- 
You will be advanced socially, without any special effort on
your part.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/7/8, Andreas Pakulat <apakugmx.de>:
> On 07.07.07 23:26:42, Matt Rogers wrote:
> >
> > What happened to the environment stuff that we had
recently that Adam
> > had written?
>
> IIRC that was part of the settings folder in lib/ which
got nuked. I
> just had a look, it seems to be feasible and a bit
easier to use than
> the kde3 one.
>
> So I guess the widget from that should be put into
> kdevplatform/lib/util.
>
> Dukju: please fetch the lib/settings directory in
kdevelop from revision
> 641348 and use the env-widget from there, it should be
fully functional
> and uses model/view for editing.

Wow, I should have known the existance of this widget.
One question: What is the meaning of "process
default" in this widget?

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 08.07.07 10:36:10, dukju ahn wrote:
> 2007/7/8, Andreas Pakulat <apakugmx.de>:
> > On 07.07.07 23:26:42, Matt Rogers wrote:
> > >
> > > What happened to the environment stuff that
we had recently that Adam
> > > had written?
> >
> > IIRC that was part of the settings folder in lib/
which got nuked. I
> > just had a look, it seems to be feasible and a bit
easier to use than
> > the kde3 one.
> >
> > So I guess the widget from that should be put
into
> > kdevplatform/lib/util.
> >
> > Dukju: please fetch the lib/settings directory in
kdevelop from revision
> > 641348 and use the env-widget from there, it
should be fully functional
> > and uses model/view for editing.
> 
> Wow, I should have known the existance of this widget.
> One question: What is the meaning of "process
default" in this widget?

I might be wrong but I'd expect that to be the environment
that is set
when kdevelop is started. Either that or its
QProcess::systemEnvironment (might be the same at the end)

Andreas

-- 
Don't read any sky-writing for the next two weeks.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/7/8, Andreas Pakulat <apakugmx.de>:
> On 08.07.07 08:10:42, Adam Treat wrote:
> > On Sunday 08 July 2007, Andreas Pakulat wrote:
> > > IMHO thats not right. At least not if we want
to allow to have multiple
> > > run/debug setups for each project. Then
you'll also want to have
> > > different environment for each of them. So
you'd also need a different
> > > environment setting for the build process.
> >
> > Then have multiple run/debug setups for each
project.  Doesn't mean that the
> > rest of KDevelop can't sync environment when you
change the setup though.
> >
> > Just use the widget and let everything sync to
that and provide a way for
> > switching setups.  The environment settings should
be universal for all
> > external processes though and the user should only
have to set it once, not 8
> > different times in different places.
>
> 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.
>
> So the only case where one might want to have unified
environment is
> when multiple projects need the same environment. So
we'd need a way to
> make sure that the user can define this and then the
widget should
> update the related projects when changes are made in
one. (or have that
> as a button "propagate changes to related
projects").

Basically it seems good, but how can we keep track of and
store
the project relationships? I think that gains little benefit
while
requiring much more coding.
Rather then storing relationships, we can just have some
menu
where it installs common env variables to all( or selected )
already
opened projects. But that's not that big priority -- IMHO.

The current widget plus switching combobox seems
sufficient,
at least for current state.
We can add and discuss more features when things get some
shape.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 08.07.07 13:15:32, dukju ahn wrote:
> 2007/7/8, Andreas Pakulat <apakugmx.de>:
> > On 08.07.07 08:10:42, Adam Treat wrote:
> > > On Sunday 08 July 2007, Andreas Pakulat
wrote:
> > > > IMHO thats not right. At least not if we
want to allow to have multiple
> > > > run/debug setups for each project. Then
you'll also want to have
> > > > different environment for each of them.
So you'd also need a different
> > > > environment setting for the build
process.
> > >
> > > Then have multiple run/debug setups for each
project.  Doesn't mean that the
> > > rest of KDevelop can't sync environment when
you change the setup though.
> > >
> > > Just use the widget and let everything sync
to that and provide a way for
> > > switching setups.  The environment settings
should be universal for all
> > > external processes though and the user should
only have to set it once, not 8
> > > different times in different places.
> >
> > 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.
> >
> > So the only case where one might want to have
unified environment is
> > when multiple projects need the same environment.
So we'd need a way to
> > make sure that the user can define this and then
the widget should
> > update the related projects when changes are made
in one. (or have that
> > as a button "propagate changes to related
projects").
> 
> Basically it seems good, but how can we keep track of
and store
> the project relationships? I think that gains little
benefit while
> requiring much more coding.

Uhm, we will have at least dependecy between projects, so
the builders
know they have to build project foo before project bar. And
storage of
such deps would be done in project configuration, by just
referencing
the .kdev4 file. 

> Rather then storing relationships, we can just have
some menu
> where it installs common env variables to all( or
selected ) already
> opened projects. But that's not that big priority --
IMHO.

But how/where do you store the selection of projects? Also
this would
mean another extra place for env vars, also you'd need to
choose wether
these global vars are for building, running or debugging (or
any
combination of these three). Not going to work.

Anyway, I'm with you in that for now its enough that we have
a common
widget and each plugin that needs environment settings can
use it.

Andreas

-- 
Write yourself a threatening letter and pen a defiant
reply.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel