[Qt-interest] Refactoring app to use QStackedWidgets with opaque widget pointers, rather than one large QStackedWidgets to cut compilation dependencies

[John Moran]

Hi André,

Thanks for getting back to me.

I'm working on a solution that I think is satisfactory (it cuts down
on compilation dependencies, and doesn't require dynamic loading of UI
classes). I happen to think that having compile-time variables, rather
than acquiring ptrs to resources from dynamically loaded UI files at
run-time is a good thing to have from a correctness and
maintainability perspective - it's certainly not something I'd like to
give up wholesale. I recall the advice of Herb Sutter: "Prefer
compile-time assertions".

I maintain my fairly monolithic widget class (the argument for
refactoring to split it into small classes that represent each page is
weak, because the pages necessarily transfer data so promiscuously).
Rather than using one big UI generated class, I use a hand written
class that resembles my old UI generated class. It contains the
QStackedWidget, which the monolithic class manipulates directly, and
it contains opaque pointers to dynamically allocated "page" widgets,
which each translation unit of the monolithic class manipulates
directly (only the relevant TUs have the definition of the pages that
they require included).

So, we access pages like this:

#include "ui_first_page.h"

void mainwidget::something()
{
   mymainscreen.first_page->logo->setPixmap(my_pixmap);
}

However, this approach, which I think ought to work fine, has caused
bizarre undefined behaviour for only a few of the pages, for reasons I
have not yet managed to isolate. See the other post I made yesterday
to the list about it for more information.


Thanks a lot,
John