Why we shouldn't install header files created by UIC

[Matt Rogers]

On Wednesday 06 April 2005 12:22 pm, Richard Dale wrote:
> 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?
>

I don't know. I'll go ahead and remove it from the list of installed headers 
then (we've been installing it for quite some time now, so i guess i'll have 
to figure out a way to uninstall it) and it'll be part of the patch i post to 
the list for the new UI after i get the kconf_update script written.

thanks,
Matt