Why we shouldn't install header files created by UIC

[Richard Dale]

On Thursday 07 April 2005 01:29, Matt Rogers wrote:
> 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.
Sounds good. I had problems a kdelibs header that was autogenerated from a .ui 
file because it didn't have a KDE_EXPORT* macro, and had to remove it from 
the ruby bindings generation. 

I suppose the way you customise KDevelop settings is to add a completely new 
tab, rather than subclass an existing one.

-- Richard