Why we shouldn't install header files created by UIC

[Richard Dale]

On Wednesday 06 April 2005 19:10, Matt Rogers wrote:
> On Wednesday 06 April 2005 11:57 am, Richard Dale wrote:
> > On Wednesday 06 April 2005 18:32, Matt Rogers wrote:
> > > Hi,
> > >
> > > 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:
> > >
> > > 1. No BC. the header file may or may not change depending on what
> > > version of uic is used to generate the file. If we didn't autogenerate
> > > the .h and the .cpp file everytime, this wouldn't be as much of a
> > > problem, but we do, so it is a problem.
> > >
> > > 2. No encapsulation. All the data members are public. You change a
> > > variable name (as I have done) and you break BC, which goes back to
> > > point number 1.
> > >
> > >
> > > 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.
> >
> > Haven't we already had a discussion about this a couple of months ago?
> > Surely just not installing a .ui generated header file is the solution?
> >
> > -- Richard
>
> No, IIRC, that was about virtual destructors in uic classes when used as
> base class. Yes, not installing a .ui generated header file is a solution,
> but in cases where, for whatever reason, we need to make the UI part of the
> public API, we shouldn't just use the class generated by uic. That was my
> point, which i apparently didn't do a very good job of conveying
>
> Now, the question becomes: Do we need to install settingswidget.h (which is
> created from settingswidget.ui) as public api? If not, does anyone care if
> I change the Makefile.am to not install it?
I think it shouldn't be installed - why would anyone want to customise the 
KDevelop settings UI?

-- Richard