Why we shouldn't install header files created by UIC

[Tobias Erbsland]

> > > As I'm going through and changing the main settings widget to look
> > > nicer (screenshot at
> > > http://www.sourcextreme.com/projects/kdevelop/newmainsettings.png),
> > > I've noticed that we're installing a header file that's based of a .ui
> > > file and calling it public API (i.e. we're not saying these headers are
> > > private and they shouldn't be used). There are several reasons why this
> > > is bad, and here's the two that i can think of ATM:
> > > (...)
> > > The solution to this is to create a new class that contains a pointer
> > > to the UIC generated class and make this class part of the public
> > > API.We can't base the new class off of the UIC generated class because
> > > you'll still run into the above two points. Anyways, i still plan to go
> > > forward with my changes, so i hope nobody cares that we're breaking BC.
> > This is solved anyway with Qt4.0. In Qt4.0 the UIC is generating a class
> > in a special namespace "Ui". This class has the method "setupUi()" which
> > is called from your constructor.
> Right, i know that, but I'm not particularly interested in things that are
> fixed for Qt4, i'm interested in getting things fixed or worked around or
> whatever now because now is what matters, not 3, 6, or 8 months down the
> line. :)

I mean you can emulate the behaviour of Qt4.x in Qt3.x.

Create foodialogui.ui, with the QWidget class FooDialogUi

Create the "real" QDialog FooDialog.

foodialog.h:
class FooDialogUi;

class FooDialog : public QDialog
{
  // (...)
private:
  FooDialogUi* ui;
}


foodialog.cpp

FooDialog::FooDialog(...)
  : QDialog(...)
{
	QHBoxLayout* l = new QHBoxLayout( this );
	ui = new FooDialogUi( this );
	l->addWidget( ui );
}


because all members of FooDialogUi are public, access to the elements of the 
dialog is quite simple:

FooDialog::foo()
{
	ui->lineEdit->setEnabled( true );

	// or...

	connect( ui->lineEdit, SIGNAL( ... ), SLOT( ... ) ); 
}


best regards
Tobias