[Qt-interest] Configure QtDesigner ui.h

[Bo Thorsen]

I hope you will allow me to elaborate a bit on this answer. It's all 
correct, but a little more explanation could be helpful.

As John wrote, it's very convenient to inherit from the UI class 
(private inheritance FTW).

But I almost always use the d-pointer idiom to get my class definitions 
as small as possible. This is to avoid the recompile explosion from 
changing stuff that is included by the header file. And if you are 
building a library, then you should keep binary compatibility when 
possible, and that includes the size in bytes of the class, so you can't 
have the UI file change - the fix again is to use a pointer to the UI 
contents.

I have tried letting my private class inherit the UI class, but I have 
dropped it again. The reason is one that also works for the original 
question:

I want to separate the names from the UI file from the names. Pollution 
of namespaces and scopes is something I take seriously. And it's for 
some reason a lot more difficult to stay disciplined with naming the 
objects in a UI file.

Also, the OP said that it is bad form to do code in the .h file. I 
actually agree with this, and including the ui_xyz.h file in the cpp 
file fixes this problem.

If I'm doing code that's just a quick fire and forget problem, I don't 
have any problems using private inheritance from the UI class - a book 
example would qualify for this. But with all non-trivial code or for any 
of the above reasons, I won't do it.

There isn't a single reason that says "this why you absolutely have to 
avoid that", but put all the reasons together, and there is only a bit 
of convenience in the pro list (which quickly isn't convenience because 
you get used to writing d->ui->...) and a lot of good reasons against. 
To me that makes it an easy choice.

Bo.

Den 02-09-2011 18:15, Ian Thomson skrev:
> You can do it but it can be a bit of a pain if you do it that way.
>
> There a few reasons why but the best one is this: If you make a library
> with a widget using ui through inheritance, when you include the header
> for the library in another project that project also has to have access
> to the produced ui_whatever.h file to be able to compile. As the
> ui_whatever.h file is merely a side-effect of the build process, it
> should not be part of the library's headers. If that file is cleaned up
> with a build-clean then your project which includes the library header
> will no longer compile. That's not a very nice side-effect.
>
> Ian.
>
> John Weeks wrote:
>> Sorry, Bo. I always forget to change the To: field to send to the list...
>>
>> On Sep 1, 2011, at 10:27 PM, Bo Thorsen wrote:
>>
>>> Just remember to make the ui a pointer in the class and do a "new
>>> MyUIThing" in the constructor. Don't let your class inherit the UI class.
>>
>> This caught my eye. Why do you say that? C++ GUI Programming with Qt 4,
>> second edition, page 27 shows their simple example dialog doing exactly
>> that. I rather like the readability of simply naming the widgets instead
>> of lots of "ui->..." stuff.
>>
>> Regards, John Weeks
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at qt.nokia.com
>> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest


Bo Thorsen,
Fionia Software.

-- 

Expert Qt and C++ developer for hire
Contact me if you need expert Qt help
http://www.fioniasoftware.dk