[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: KDE designer integration into kdelibs?
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-10-01 16:34:47
[Download RAW message or body]

(CC'ing to Reggie directly :)

On Mon, Oct 01, 2001 at 06:24:29PM +0200, Malte Starostik wrote:
> Am Monday 01 October 2001 18:12 schrieb Simon Hausmann:
> > On Mon, Oct 01, 2001 at 04:35:47PM +0200, Malte Starostik wrote:
> > > Hi again,
> > >
> > > I've thought a little about the KDE widget integration into designer. We
> > > have kdesdk/kdewidgets now to ease the use of KDE widgets in designer.
> > > However, this has the same issues as with a KDE-enabled designer in Qt 2
> > > unless everyone who wants to build uic-generated files with KDE widgets
> > > installs this plugin aswell (also see the library path issue in my
> > > previous mail).
> >
> > I guess I'm missing some obvious point, but why can't uic/designer be
> > changed to include all necessary information to build the .cpp code
> > right into the .ui file for custom widgets? I mean, what does it
> > need in most cases? The class name and the name of the header file?
> > And for that it only needs the extra dso?
> >
> > That way the plugin would only be necessary for the time of designing/
> > editing the .ui file, but not for the actual build of kdelibs/kdebase/* .
> Good point, however with a plugin, the widgets are no longer really "custom" 
> to designer, not that this is a real reason to include that info. Maybe 
> propose that to TT?

Reggie, would that be possible?

> Apart from that I still think, providing the plugin with kdelibs isn't that 
> bad (and distributors could put it into the -devel packages).
> What's wrong with loading the DSO into uic?

That it means unnecessary code (and macros) in kdelibs? :-)
(given that there is possibly a more lightweight solution)


Simon

[prev in list] [next in list] [prev in thread] [next in thread]