resize item'a с помощью маркеров

[KontAr]

Подскажите пожалуйста, как грамотно реализовать изменение размера итема. сейчас у меня есть унаследованный итем (пусть линия), ресайзИтем (квадратный маркер, как в КОМПАСЕ, COREL), сцена, которая содержит все итемы, и view, управляющий созданием и удалением ресайзИтемов. Правильно ли это?  Может есть подобный механизм в самом итеме?

У меня получается, что myGraphicsView управляет всем: созданием, изменением всех элементов, в том числе маркеров.
4 инструмента + 7 позиций маркера = хаос((

[panAlexey]

4 инструмента + 7 позиций маркера = хаос((

Вообще-то у маркера 8 позиций.
+ еще одна, если требуется ротаре.
вот заготовочка, только делалась она не для сцены, а тупо для виджета, может поможет.
смысл: разметить определенные области картинок для ловли кликов по ним и реакции на клики.
генерирует тексовый файл с координатами.
Работает только с прямоугольными областями. Других вроде не надо было.
По клику мыши добавляет квадрат с маркерами на виджет, квадрат можно перемещать, удалять менять размер.

[KontAr]

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

[panAlexey]

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

uoDiaLayer управляет коллекцией QRect, используя события QWidget в который он встраивается.
Он отрисовывает свои QRect, маркеры в текущем QRect, реагируя на события мышки меняет текущий QRect, растягивает его и т.п.
Он не является итемом, а скорее менеджером поверх QWidget.
На его основе можно легко построить простенький редактор диалогов например.

[KontAr]

тогда, думаю, у меня правильное направление: сцена - это контейнер итемов, а все управление возложу на view. спасибо за ответы

[_OLEGator_]

Я реализовывал такое поведение, когда сам айтем себя менял и сам задавал свое поведение.
Точнее даже не так, это был базовый класс для объектов, отрисовывающий себя с маркерами для манипуляции и отслеживающий все необходимые действия.
Все остальные айтемы были от него унаследованы.

Можно как вариант создать один такой айтем и при необходимости манипуляции помещать в него редактируемый айтем.

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

[KontAr]

а этот базовый класс был сам по себе или унаследован от чего-либо?

я немного поясню, делаю векторный редактор, очень простой. из инструментов линия (отпрыск от QGraphicsLineItem), прямоугольник (от QGraphicsRectItem), эллипс (соотв). то есть базовый класс получается QGraphicsItem.

мне нужны маркеры не по краям какой-то области, а на самих элементах: по концам линии, в углах прямоугольника...
P.S. а про гибкость я уже понял, просто не знаю как иначе

[_OLEGator_]

Базовый класс от QGraphicsItem.
По сути даже один общий абстрактный класс (не QGraphicsItem) с общими данными и несколько наследников (QGraphicsItem), например класс для маркеров для линейных объектов, для прямоугольных объектов.

По сути можно наследоваться от абстрактного класса со всей общей логикой, данными и функциями для изменения размеров, который НЕ QGraphicsItem и от требуемого QGraphicsItem, например так можно сделать кнопку с изменяющимися размерами.

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

[KontAr]

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

Код:

#ifndef ITEMRESIZE_H
#define ITEMRESIZE_H

#include <QGraphicsPolygonItem>

class ItemResize : public QGraphicsPolygonItem
{
public:
    enum {Type = UserType + 37};
    enum resizePositions { None, UpperLeft, LowerRight, UpperRight, LowerLeft, Top, Bottom, Left, Right, Center };

    ItemResize();
    int type() const { return Type; }

    void setResizePosition(resizePositions position);
    resizePositions getResizePosition() {return resizeposition;}


    resizePositions resizeposition;
};

#endif // ITEMRESIZE_H

[_OLEGator_]

Если ты желаешь реализовывать наследованием, то приблизительно так:

Код

C++ (Qt)
class ItemResize
{
    ///Все перечисления, переменные и прочее...
    resizeFunction(...);
}
 
class MyRect : public QGraphicsPolygonItem, ItemResize
{
 
}

Суть в том, чтобы максимально вынести все расчеты и перемещения в этот базовый класс (вообще по максимуму все что является общим для наследников), чтобы по минимуму определить вызовы нужных функция в наследниках.
Например функция пересчета размеров айтема в базовом классе может принимать события мышки и возвращать новый прямоугольник, либо можно сделать виртуальную функцию по изменению геометрии в базовом классе, которую переопределить в наследнике. Вариантов много.

Плюс еще надо определить в базовом классе метод отрисовки контрольных точек, который в обязательном порядке надо вызвать в переопределенном методе QGraphicsItem::paint().

[KontAr]

я попробовал такой вариант: в свой класс линии (унаследован только от QGraphicsLineItem) я включил 2 объекта маркера, передав в каждый указатель на эту линию, и положение маркера. линия теперь сама создает и удаляет маркеры из сцены. но для изменения размеров не удалось обойтись без явного приведения типов. то есть вся каша перекочевала из вью в класс маркера. получается это тупик?
мне непонятно, как в вашем базовом классе реализованы методы отрисовки маркеров, ведь он не от QGraphicsItem. Был бы рад простейшему образцу

[_OLEGator_]

А разве чтобы рисовать надо обязательно наследовать от QGraphicsItem?

В базовом классе реализовать функцию

Код

C++ (Qt)
void paintMarkers(QPainter* painter);

В наследнике в переопределенном методе

Код

C++ (Qt)
void QGraphicsItem::paint ( QPainter * painter, const QStyleOptionGraphicsItem * option, QWidget * widget = 0 );

ее вызывать

[KontAr]

как в базовом классе указать координаты маркера, они ведь есть только только в наследнике?

[_OLEGator_]

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

Совсем проблемно с проектированием?

[KontAr]

с графикой впервые работаю, до этого только БД. не скажу, что сильно проблемно, просто иногда простую мысль не сразу вижу