[Qt-interest] question about mixing gui and non gui classess

[Ross Bencina]

Hello Marek

It is always going to be a project-specific decision as to how you organise 
things. But there are some general principles that might help:

- Separation of interface and core behavior:
It sounds like you really have two systems: (1) a network subsystem with 
gui-thread proxies exposing the data and (2) a GUI that displays the data. 
This is a common structure ("model" and "view" in classical MVC 
http://c2.com/cgi/wiki?ModelViewController). I usually seek to keep these 
separate so that reusing a core with a different GUI, or no GUI at all is 
easy. It sounds to me like you have things tangled up -- as a starting point 
(thought experiment) you could think about making a command line version of 
your data pump and then adding the GUI, and always keep both options 
possible.

I think it's helpful with GUI display widgets to separate the 
_configuration_ of "what they view" (the Model)  from the GUI objects 
themselves. An existing example in Qt is the Model-View classes, for example 
QTableView, here the View can visualise any Model and you can change which 
model the view is displaying by calling QTableView::setModel().. perhaps you 
could have a similar thing where your display widgets have a setDataSource() 
method. This way you can implement how they are configured in some other 
function (implement policy elsewhere).

- Object lifetimes:
Does your data objects need to know about the GUI or can it exist separate 
from it? Should the GUI views really be responsible for creating the data 
objects? Conceptually do the data objects have the same lifetime as the GUI? 
Perhaps the data should outlive the GUI objects and be owned by the 
QApplication or some other object? Or maybe not, perhaps the data objects 
are just transient GUI-thread proxies that are only created when needed by 
the GUI.

- Layered systems:
In general you should seek to implement systems in layers where the upper 
layers depend on the lower layers, but not the other way around. 
Notification systems such as signals/slots (or the Observer pattern) allow 
you to invert dependencies so that events may flow from lower layers (your 
data objects) to upper layers (the GUI) without the lower layers being 
explicitly aware of the upper layers.

- Implement policy separate from behavior:
In general you don't want leaf classes (such as GUI widgets) making policy 
decisions (such as how to display something, or what to display). It is 
often better to design things so that some higher level object makes the 
decisions and tells the widgets what to display and how to display it. This 
could manifest in different ways: properties to set display parameters, 
different GUI widgets for different types of displays that the caller 
chooses, etc. You see this kind of thing in standard Qt designer based forms 
where Designer generates a setup_ui function that *from a high level* 
combines all the low level components together and makes decisions about how 
they are configured.


Sorry if that doesn't quite answer your question but perhaps it's some 
things to start you thinking...

Ross.





----- Original Message ----- 
From: "franki" <franki at franki.eu.org>
To: "qt-interest" <qt-interest at qt.nokia.com>
Sent: Tuesday, May 17, 2011 3:56 AM
Subject: [Qt-interest] question about mixing gui and non gui classess


> Hi all,
>
> I have app which communicates with server to display temperature from
> different devices. Question is how to lay out classess which interacts 
> with
> GUI and classess responsible for holding/calculating data. Let's say, I 
> have
> 4 pages (widgets of QStackedWidget), each page is separate object (a 
> class)
> that displays data and interact with user, next there are three objects
> (different classess) that are holding data, and exchanging it with 
> different
> QThread that is running network-manager to get/send data from/to server
> So far I have such a layout:
>
> MainPages: public QStackedWidget - main class that has GUI pages,
> inside this class four other gui classess are created, and pointer for
> managing gui widgets (UI::MainPages ui) is passed to each class, each 
> class
> is responsible for one page of QStackedWidget.
> Apart from this, there are three objects that inherits QObject (to be able 
> to
> send signals) also created inside MainPages class, these just share and
> calculate data received from server.
> Now, when data arrives from server it first goes to one of three objects, 
> it
> is calculated, and then it goes to one or more "gui" classess to display
> result.
>
> What is worrying me is that all these objects are not related to each 
> other,
> thus all communication between them goes by signal-slot solution. I have 
> more
> than 50 defined connections between these objects and it looks like a mess
> when I look at this.I would like to reorganize it in such a way:
>
> MainPages - creates main Temperature class (pointer for gui objects is 
> passed
> to that class), Temperature class creates "gui" classess as a child 
> objects
> (again pointer for gui is passed), plus classes to calculate data received
> from network-manager are created as children of Temperature class.
> Now, lots of data I need to display (after calculation inside Temperature
> class) can be passed to "gui" classess by simple function calls, and I 
> think
> it's simpler and more organized in that way.
>
> The disadvantage of this approach (or at least I think so) is that I need 
> to
> pass pointer to gui elements from MainPages class deep inside classess
> hierarchy, and to the classess that are only  responsible for calculating
> data received from network-manager.
>
> But should that ever worry me?
> What is "blessed" way of laying out objects that are gui related
> and these that are only calculating data? And is it safe to pass pointer 
> for
> graphic elements deep inside class hierarchy?
>
> best regards
> Marek
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest