[Qt] Иерархия и сигналы-слоты

Как вариант в конструкторе виджета: передавать ему указатель на сцену

Еще один вариант для больших приложений. Создать отдельный класс-коммутатор, который будет соединять сигналы и слоты.

> Создать отдельный класс-коммутатор, который будет соединять сигналы и слоты.

Хм... как такое реализовать? Если виджет динамически создаётся только когда надо.

Шину сообщений сконструируй общую

А можешь кинуть ссылок, почитать про такое?

Скажу, как у меня сделано сейчас.

В MainWindow есть функция Scene *qfScene(), возвращающая указатель на сцену. Объект мой может представать или просто виджетом (при этом родитель — дочка мейнвиндова в 3 поколении), либо в качестве дочки диалога.

В конструкторе этого виджета я делаю необходимые коннекты со сценой примерно таким образом:

MainWindow *m = static_cast<MainWindow *>(parent->parent()->parent())
connect(m->qfScene(), SIGNAL(selectionChanged(bool)),this, SLOT(updateButtons(bool))
 

Ну если я создаю диалог с этим виджетом, то я пользуюсь тем, что диалог можно создавать в принципе с любым пэрентом. И я создаю его с таким пэрентом, чтобы получилось, чтобы его пэрентом в 3 поколении оказалось главное окно. Так-то.

Коряво, но ничего другого в голову не пришло, вот и создал тему.

Я бы сделал метод Widget::setScene(QGraphicsScene * scene), в котором бы и связывал виджет со сценой.

Да, так получше, ибо обременять конструкторы кучей аргументов (по идеологии Qt) — плохо.

Да, так получше, ибо обременять конструкторы кучей аргументов (по идеологии Qt) — плохо.

Это, конечно, тоже. Но меня смутил вот этот код:

MainWindow *m = static_cast<MainWindow *>(parent->parent()->parent())
connect(m->qfScene(), SIGNAL(selectionChanged(bool)),this, SLOT(updateButtons(bool))

> parent->parent()->parent()

шедеврально

parent->parent()->parent()

Опасность!

Код выше — пример, у меня оно страшнее. Вот копипаста прямо из проекта.

void SoilsWidget::newSoil()
{
    QUndoStack *stack = static_cast<MainWindow*>(parent()->parent()->parent()->parent()->parent())->undoStack();
    stack->beginMacro(tr("Create and edit soil"));
    m_original_soils_model->createNewSoil();
    SoilEditDialog add_dialog(m_original_soils_model, -1, this);
    add_dialog.exec();
    stack->endMacro();
    
    if(add_dialog.result() == QDialog::Rejected) {
        //FIXME: suxx till QTBUG-15764 will become fixed
        stack->undo();
    }
}

Правда, данная копипаста непосредственно с сигналами-слотами не связана. Но к вопросу имеет прямое отношение. Видится два решения:

1. Оставить всё как есть. Ведь всё работает.

2. Добавить функцию setMainWindow(), которая делала бы нужные коннекты и запоминала указатель на главное окно в приватное поле (чтобы этот указатель использовать в местах типа того, что я только что привёл).

Склоняюсь ко второму варианту, т.к. так код станет понятнее и сложней будет ошибиться.

Уважаемые, очень странно, что до сих пор никто не упомянул ни findChild, ни findChildren, ни connectSlotsByName… А ведь это, по-моему, очень удобное и хорошее решение.

добавить кастомный сигнал всем, кто может делать твой внезапный виджет? на сигналы виджета, при его созжании, подписывать его парента, а парент, при наличии сигнала в виджете, будет пулять свой, кастомный, сигнал. дальше, как я понимаю, у тебя все знают, какой сигнал хотят получить.

Притянуто за уши. Ну то есть я так делал на начальных этапах своего проекта, но когда таких дублирующих сигналов стало много, отказался от этой идеи.

> Уважаемые, очень странно, что до сих пор никто не упомянул ни findChild, ни findChildren, ни connectSlotsByName… А ведь это, по-моему, очень удобное и хорошее решение.

Тьфу, не годится, ведь чилд-то динамически создаётся. Вот был бы findparent :)...

Пришло в голову 3 сумасшедших идеи. Они помогут забыть о головной боли из-за поиска MainWindow.

Идея 1. Функция template<typename T> T findNearestParent(). Делает вложенный parent() до тех пор, пока qobject_cast<T> для полученного объекта станет не NULL. Таким образом, можно находить, скажем, MainWindow, в котором находится виджет.

Идея 2. Функция findNearestObjectByName(const QString &name). Делает parent(). Там делает findchild(name). Не нашло — идёт выше в иерархии объектов. Пока не найдёт. Эта штука нелепа, но почему-то тоже пришла в голову.

Идея 3. Статический член MainWindow *main_win в MainWindow. В конструкторе MainWindow делается main_win = this. Всё бы хорошо, но но это позволяет иметь только одно главное окно в одной инстанции программы.

Что скажете насчёт идей 1 и 3?

ну хорошо, а static чем не нравится?

В дзене питоновода очень хорошие правила написаны. (Сам питон не использую). ИМХО им следовать должен любой уважающий себя программист. Так вот:

Явное лучше, чем неявное. Простое лучше, чем сложное. Читаемость имеет значение. Если реализацию сложно объяснить — идея плоха.

А теперь посмотри на свои костыли с этой точки зрения и сравни его с моим предложенным решением (первом пост).

>> Создать отдельный класс-коммутатор, который будет соединять сигналы и слоты.

Хм... как такое реализовать? Если виджет динамически создаётся только когда надо.

Я это вижу так: создаешь класс-синглтон (если MainWindow всего один), который содержит слоты рассылки сигналов. Т.е. каждый его слот просто высылает соответствующий сигнал.

Далее к сигналам коммутатора цепляешь сцену, а создаваемые доки цепляешь к слотам коммутатора. Если различных сигналов-слотов не много, то все ок.

> Пришло в голову 3 сумасшедших идеи.

ну да, вместо чтения документации лучше велосипеды изобретать

есть же QWidget::nativeParentWidget()

ХЗ где можно про это почитать =) В википедии можно, в принципе.

В целом это комбинация синглтона и, например, обсервера наоборот.

не то, ибо если виджет в диалоге, то оно указывает на диалог.