Scope of UI

[Dumbledore]

I'm looking for a way to manage the complexity of multiple strung together signals that eventually reach the object that knows the addresses of all the qwidgets so as to be able to speak to them.

Some perspective:



Class MainWindow : ui_myUI {
slot:
inline void send(const QString text) {
myWidget->send(text);
}
private:
MyClass containedObject;
};

Class MyClass{
signal:
void relayText(const QString text);
private:
My2ndClass containedObjectNumber2;
};

Class My2ndClass {
//I want to send text through myWidget.
public:
inline void sendText() {
emit: signalToSendText(QString("This is tedious and error prone");
}

signal:
void signalToSendText(const QString text);
};


Can someone talk about how to deal with this without signaling, and relaying signals to slots?

I have been taking a look at postEvent(), but even there, how do you send an event to a specific widget if you don't know its address?

[mattia]

take a look here (http://www.qtcentre.org/forum/f-newbie-4/t-pointer-at-qmainwindow-10011.html)
maybe there is something helpful

[Dumbledore]

It looks like you didn't even know about QT's signals and slots to call methods in ui components. I didn't see anything that pertains to circumventing multiple signals to reach a ui component's slot. This is something that I'm finding extremely annoying, as in order to avoid connecting signals to signals I have to either pass all kinds of pointers or tighten the connection between my classes.

[jacek]

It looks like you didn't even know about QT's signals and slots to call methods in ui components.
There's no point in being rude.


I didn't see anything that pertains to circumventing multiple signals to reach a ui component's slot. This is something that I'm finding extremely annoying, as in order to avoid connecting signals to signals I have to either pass all kinds of pointers or tighten the connection between my classes.
As you have noticed yourself, the problem would persist if you used events instead (the same with direct calls), because it isn't a matter of technology, but your design.

It's hard to propose anything with such abstract example, but maybe you need some central object that will serve as a coordinator? Or maybe you don't need two levels of aggregation?

[wysota]

You could do something like this, it's not a good design but will work:

class MyClass : public QObject {
public:
//...
bool setupConnections(QObject *obj, const char *recv){
return connect(&containedObjectNumber2, SIGNAL(signalToSendText(const QString &)), obj, recv);
}
private:
My2ndClass containedObjectNumber2;
};

Then you can call it llike:


MyClass *cls;
QLineEdit *le;
//...
cls->setupConnections(le, SLOT(setText(const QString &)));

MyClass doesn't even have to be a QObject subclass...

[Dumbledore]

because it isn't a matter of technology


I'd have to disagree there. It is not impossible to make connections universal. Unless there is a terrible and unavoidable consequence that is impossible to avoid as a result that I can not think of, it really should be made possible. (It's not like QT hasn't extended C++ before)



because it isn't a matter of technology, but your design.


I'm interested to know of a good, general way to design in a way that would avoid connecting signals to signals and the like. Perhaps if you know of books related to this, articles, or anything?

Cool wysota, but I am in need of a good design.

P.S. I appologize if I was perceived as being rude. It wasn't my intention.

[wysota]

I'm interested to know of a good, general way to design in a way that would avoid connecting signals to signals and the like. Perhaps if you know of books related to this, articles, or anything?

Cool wysota, but I am in need of a good design.

So I suggest you listen to Jacek and implement a kind of a broker object that will handle manipulating signals.

I second what Jacek said - it isn't a matter of technology, it's a matter of language rules and computer design you have to obey.