Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Идеологически верный выбор инструментов.
Форум на CrossPlatform.RU > Библиотеки > Qt > Qt GUI
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
Цитата(Obey-Kun @ 2.4.2010, 6:29) *
И кстати, выбор инструмента вообще обычно делают в турбаре или где?
Ну, 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
Цитата(Obey-Kun @ 2.4.2010, 21:56) *
То есть чтобы сигнал 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 выполняться попозже, то всё ок, коннект проходит и всё работает.
Есть идеи?
Litkevich Yuriy
Цитата(Obey-Kun @ 3.4.2010, 7:17) *
QObject::connect: Cannot connect (null)::signalToolC...
проблему выделил жирным. Т.е. неизвестно какому классу принадлежит функция

Цитата(Obey-Kun @ 3.4.2010, 7:17) *
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
Цитата(Obey-Kun @ 3.4.2010, 7:28) *
тогда слот придётся делать публичным... так точно обычно делают?
ну слот - функция, просто в отличие от функции-члена класса с ним можно связать сигнал.
А часть функций реализуют публичное 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.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.