Qt / C ++ - запутался в вызывающем / вызываемом объекте, владении объектом

Question

Я создаю графический интерфейс для манипуляции роботизированной рукой. Расположение руки можно описать с помощью 6 поплавков (описывающих положение различных суставов руки.

Интерфейс состоит из QGraphicsView со схемой руки (которую можно нажать, чтобы изменить положение руки - настройка 6 поплавков). Интерфейс также имеет 6 блоков lineEdit, чтобы также отдельно настраивать эти значения.

Когда щелкают по графическому представлению и когда изменяются поля редактирования строк, я бы хотел, чтобы поля редактирования строк / графический вид оставались в синхронизации.

Это приводит меня в замешательство относительно того, как хранить 6 поплавков и запускать события при их обновлении. Моя текущая идея такова:

• Местоположение руки робота должно быть представлено классом RobotArmLocation. Объекты этого класса затем имеют такие методы, как obj.ShoulderRotation () и obj.SetShoulderRotation ().
• MainWindow имеет единственный экземпляр RobotArmLocation.

Дальше я немного запутался в том, как все объединить. Я думаю:

• Основное окно имеет слот ArmLocationChanged. Это сигнализируется всякий раз, когда объект местоположения изменяется.

• Класс диаграммы будет иметь SetRobotArmLocation (RobotArmLocation & loc). Когда диаграмма изменяется, можно свободно изменять объект местоположения и отправлять сигнал в слот ArmLocationChanged.

• Аналогичным образом, изменение любого текстового поля вызовет сигнал в этот слот ArmLocationChanged. В слоте есть код для синхронизации всех элементов.

Мне это кажется беспорядком, у кого-нибудь есть другие предложения? Я также подумал о следующем, есть ли у него какие-либо достоинства?

• Класс RobotArmLocation имеет слот ValueChanged, диаграмма и текстовые поля могут использовать его напрямую и обходить MainWindow напрямую (кажется, чище?)

спасибо за любую мудрость!

Answer 1

За исключением очень простых случаев (например, метка, которая показывает значение ползунка), я не хотел подключаться к межкомпонентным соединениям сигнал / слот в Qt Designer. Вместо этого, пусть компонент, запускающий интересующий сигнал, подключится к слогу, определенному в классе QWidget верхнего уровня, который вы подклассируете (т.е. QMainWidow и т. Д. ... давайте просто назовем его классом Form). Вы также можете пойти другим путем: если у вас есть собственный сигнал в классе Form, вы можете подключить его с Qt Designer к одному из открытых слотов виджетов.

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

1. Я собираюсь предположить, что у вас есть подклассы QMainWindow и QGraphicsView. Давайте назовем подклассы RobotMainWindow и RobotView.
2. RobotMainWindow содержит поля QLineEdit и RobotView. Чтобы указать RobotView в Qt Designer, вставьте QWidget и используйте функцию Повышение до ... , чтобы сообщить Qt, что QWidget следует заменить во время компиляции на ваш пользовательский RobotView.
3. Назовите поля QLineEdit edit1, edit2 ... edit6.
4. В Qt Designer редактор сигналов / слотов определяет слоты в RobotMainWindow, которые будут вызываться при изменении значения в QLineEdit. Есть несколько более элегантных способов сделать это, но для простоты, скажем, вы определили 6 слотов с именами setValue1(float), setValue2(float) и т. Д.
5. В исходном коде для RobotMainWindow, перейдите к объявлению и определите эти слоты, чтобы они обновляли вашу руку, плечо, что угодно.
6. Также в исходном коде определите сигнал valueChanged() (или несколько для каждого поля по вашему выбору). Имейте определенные вами слоты emit valueChanged().
7. Вернувшись в Qt Designer, вы теперь можете связать соответствующий сигнал от каждого QLineEdit с соответствующим слотом в RobotMainWindow.
8. Вернувшись в редактор сигналов / слотов , добавьте сигнал valueChanged() в RobotMainWindow (так, что Qt Designer знает об этом). Подключите этот сигнал к новому слоту в RobotView, используя описанную выше процедуру, чтобы он мог обновить рендеринг.
9. Повторите все это для обработки изменений от RobotView до полей редактирования (через RobotMainWindow.

Короче говоря, я думаю, вы найдете все более простым, если ваш маршрут передает сигналы через ваш Form подкласс (который я считаю Controller на языке MVC).