Идеологически верный выбор инструментов. Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[Obey-Kun]

Есть mainwindow. Там тулбары с экшнами, менюшки, указатель на мой QGraphicsView.

В моём унаследованном от QGraphicsView виджете есть Tool *m_tool. Tool — абстрактный класс инструмента (всякие выделения, создание наборов итемов в сцене и т. п). Во вью также есть enum'ный флаг выбранного инструмента. В зависимости от выбранного флага при нажатии ЛКМ создаётся соответственный инструмент.

Так вот. Как идеологически верно менять значения флага выбранного инструмента во вью?

Пока видится так: QToolBar'ы по дефолту испускают сигнал actionTriggered ( QAction * action ). В мейнвиндове я создам слот, который принимал бы этот сигнал и испускал в зависимости от нажатого экшна что-то типа signalChangeToolType(const MyView::ToolTypeEnum& type). Ну а этот сигнал принимался бы слотом во вью slotSetToolType(const ToolTypeEnum& type), что меняло бы флаг.

Это правильно? И кстати, выбор инструмента вообще обычно делают в турбаре или где?
P:S: делаю что-то похожее на Cad.

[Litkevich Yuriy]

И кстати, выбор инструмента вообще обычно делают в турбаре или где?

Ну, QToolBar - панель инструментов, т.е. место, где размещаются инструменты.

Называй вещи своими именами, а не транслитом и всё станет понятно

[Obey-Kun]

фублин.
посмотрел на то, как панель с инструментами и палитра сделана в KDE'шном KolourPaint — и правда обычный QToolBar . А раньше думал, что тулбары это только мелкие кнопочки сверху под менюбаром .
И насчёт сигналов. А можно в мейнвиндове сделать вот так?

connect( m_pick_rectangle_selection, SIGNAL(triggered()), m_view, SLOT(pickInstrument( MyView::rectangle_selection )));

То есть чтобы сигнал triggered() запускал слот с конкретным параметром.
(m_pick_rectangle_selection -- указатель на QAction, а m_view -- указатель на мой объект-отображние)

[Litkevich Yuriy]

То есть чтобы сигнал triggered() запускал слот с конкретным параметром.

нет, только через промежуточный слот.
И, кстати, слот со своим типом данных в качестве аргумента требует некоторых телодвижений - регистрация типа в системе метаинформаци Qt.

[Obey-Kun]

Речь шла об этом?

CMakeFiles/../../qfrostgui.dir/area.cpp.o: In function `qfgui::Area::qt_metacall(QMetaObject::Call, int, void**)':                                                
area.cpp:(.text+0xe1f): undefined reference to `qfgui::Area::slotSetTool(qfgui::QFrost::ToolType)'

Странно, даже enum не даёт использовать.

где почитать про то, о чём вы упомянули (регистрация типа в системе метаинформаци Qt)?

[Litkevich Yuriy]

вообще-то ошибки компиляции быть не должно, просто соединение может не установиться.
Покажи полностью объявление класса, в котором объявлен слот pickInstrument

вообще существуем много всяких примочек в Qt, чтобы зарегестрировать свои типы данных:
Q_ENUMS
Q_DECLARE_METATYPE
qRegisterMetaType()
...

[Obey-Kun]

я балбес, декларэйшн не написал
теперь заработало

и я не свой объект передаю, а енумную фигню

спасибо

Кстати, правлильная ошибка из-за отсутствия соответствующих макросов выглядит примерно так:

QObject::connect: Cannot connect (null)::signalToolChosen(QFrost::ToolType) to qfgui::Area::slotSetTool(QFrost::ToolType)

добавил Q_ENUMS(QFrost::ToolType) после макроса Q_OBJECT в хедерах классов, где енум надо использовать в системе сигналов-слотов, но это не помогло... как надо-то?

странно...

смотрите, сейчас сделано так:

Area::Area(MainWindow* parent)    : QGraphicsView(parent),
    //...
{
    //...

    connect(parent, SIGNAL(signalToolChosen(QFrost::ToolType)),
            SLOT(slotSetTool(QFrost::ToolType)));
}

И ругается

QObject::connect: Cannot connect (null)::signalToolChosen(QFrost::ToolType) to qfgui::Area::slotSetTool(QFrost::ToolType)

Если заставить этот connect выполняться попозже, то всё ок, коннект проходит и всё работает.
Есть идеи?

Сообщение отредактировал Obey-Kun - 3.4.2010, 3:08

[Litkevich Yuriy]

QObject::connect: Cannot connect (null)::signalToolC...

проблему выделил жирным. Т.е. неизвестно какому классу принадлежит функция

connect(parent, SIGNAL(signalToolChosen(QFrost::ToolType)),
SLOT(slotSetTool(QFrost::ToolType)));

вообще соединять в дочернем объекте сигнал родителя - плохая идея, т.к., как минимум, при чтении кода, сначала читается код верхнего, по иерархии, объекта. И лишь при возникновении непонимания лезишь внутрь дочернего.
Поэтому такое соединение нужно делать в родительском объекте.

[Obey-Kun]

Экспериментировал. В MainWindow было:

    area = new Area;
    scene = new Scene;
    area->setScene(scene);
    setCentralWidget(area);

Ясен пень, что connect(parent, SIGNAL(signalToolChosen(QFrost::ToolType)), SLOT(slotSetTool(QFrost::ToolType))); в конструкторе Area как надо не работало, ведь создавалось оно без родительского виджета, а потом уже он назначался. Исправил на:

    area = new Area(this);
    scene = new Scene;
    area->setScene(scene);
    setCentralWidget(area);

Разумеется, всё заработало.

[Litkevich Yuriy]

мало того объявления родительского сигнала в дочернем объекте не видно, обычно. Наверное это и есть причина ошибки. Дело в том, что компилятор не контролирует соединение

[Obey-Kun]

вообще соединять в дочернем объекте сигнал родителя - плохая идея, т.к., как минимум, при чтении кода, сначала читается код верхнего, по иерархии, объекта. И лишь при возникновении непонимания лезишь внутрь дочернего.
Поэтому такое соединение нужно делать в родительском объекте.

Вот-вот . Теперь всегда буду так делать.

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

[Litkevich Yuriy]

тогда слот придётся делать публичным... так точно обычно делают?

ну слот - функция, просто в отличие от функции-члена класса с ним можно связать сигнал.
А часть функций реализуют публичное API класса.
Например:
QLabel::setText() - открытый слот

[Obey-Kun]

ну слот - функция, просто в отличие от функции-члена класса с ним можно связать сигнал.

Да я знаю. Просто по-хорошему в моём случае слот можно сделать приватным и коннектить к нему сигнал пэрента в конструкторе. Это ради нормальной инкапсуляции и всё такое.

[Litkevich Yuriy]

при таком подходе тебе нужно будет сделать видимым объявление перечисления внутри класса дочернего объекта.
Инкапсуляция похоронена заживо. А самое главное - похоронена концепция компонентного подхода (предоставляемая сигналами и слотами), т.к. компонент стал жёстко зависеть от конкретного includ'а

можно конечно отказатся от объявления в сигнале и слоте перечисления и использовать int, но тогда контроль области определения функции (диаппазона изменения int'а) будешь делать своими глазами

[Obey-Kun]

при таком подходе тебе нужно будет сделать видимым объявление перечисления внутри класса дочернего объекта.

Так ведь в любом случае надо делать объявление перечисления видимым как минимум в MainWindow (он испускает сигнал) и во Вью (там слот).

У меня enum объявлен в файле с константнами, типа того:

Раскрывающийся текст

#pragma once
#ifndef QFGUI_QFROST_H
#define QFGUI_QFROST_H

namespace qfgui
{

struct QFrost {
    public:
    /**
      * Расстояние в единицах сцены между узлами сетки,
      * ставится в соответствие одной единице чертежа (безотносительно реальных
      * единиц измерения).
      * @warning не следует путать сетку с видимой сеткой!
      */
    static const unsigned int unitsInGridStep = 10;

    /// Сколько метров в одной единице чертежа
    static const double metersInUnit;

    /// Перечисление типов инструментов
    enum ToolType {
        /// Создавалка ячеек
        cell_creator,
        /// Создавал граничных условий
        boundary_creator,
        /// Прямоугольное выделение
        rectangle_selection,
        /// Эллиптическое выделение
        ellipse_selection
    };
};

}

#endif // QFGUI_QFROST_H

Ну а файл с константами подключается там, где надо. Так что не страшно.

Кстати, всё почему-то заработало без ковыряния с Q_ENUMS.

Сообщение отредактировал Obey-Kun - 3.4.2010, 4:12