[Uml-devel] [Bug 290952] migrate remaining qt3 classes to qt4

[Ralf Habacker]

https://bugs.kde.org/show_bug.cgi?id=290952





--- Comment #4 from Ralf Habacker <ralf habacker freenet de>  2012-01-09 14:28:48 ---
nice work. 

the remaining stuff in umbrello-soc is unfortunally a mixture of 

1. the basic QGraphics... port 
2. unrelated class doc changes (from header into source)
3. unrelated widget api changes 
4. uncomplete widget changes (for example AssociationManager) 
5. experimental widget style change
6 something else ?? 

which we canot merge at once. We need to find the important parts and how to
merge in which order without breaking trunk functionality. 

Currently our efforts are concentrated to reduce the difference between trunk
and umbrello-soc to be able to see more the important changes.
At the current level of unstanding I see the following issues/todo for merging
the basic QGraphics... port: 

1. type differences (QPoint/QRect -> QPointF/QRectF) 
2. scene classes api differences 
3. Which methods and class member belongs to UMLView and which one to UMLScene
   The umbrello-soc branch moved already some methods and class members to
UMLScene - the question is if these move are reasonable 
4. migrate UMLScene from Q3Canvas to QGraphicsScene api
5. migrate UMLView from Q3CanvasView to QGraphicsView api

There are already solutions for some of the issues listed above:

1. type differences (QPoint/QRect -> QPointF/QRectF) 

rename related ocurrence of QPoint/QRect in class UMLView and widgets class to
UMLScenePoint and UMLSceneRect 
They are currently defined in umlscene.h as 

typedef QPoint UMLScenePoint;
typedef QRect UMLSceneRect;

and after the merge as

typedef QPointF UMLScenePoint;
typedef QRectF UMLSceneRect;

2. scene classes api differences 
An easy way to solve class api differences is by adding wrapper classes
providing the missing or different api. After the merge is complety the related
widgets methods may be refactored to get rid of the wrapper classes. 

As initial step typedef wrappers for the related classes has been added: 

// event types
typedef QKeyEvent UMLSceneKeyEvent;
typedef QHoverEvent UMLSceneHoverEvent;
typedef QContextMenuEvent UMLSceneContextMenuEvent;
//typedef QDragDropEvent UMLSceneDragDropEvent;

typedef Q3CanvasLine UMLSceneLine;
typedef Q3CanvasRectangle UMLSceneRectangle;
typedef Q3CanvasItem UMLSceneItem;
typedef Q3CanvasPolygon UMLScenePolygon;
typedef Q3CanvasEllipse UMLSceneEllipse;
typedef Q3CanvasItemList UMLSceneItemList;

An example for such a wrapper is shown below: 

class  UMLSceneMouseEvent : public QMouseEvent 
{
public:
    UMLSceneMouseEvent(Type type, const QPoint & position, Qt::MouseButton
button, Qt::MouseButtons buttons, Qt::KeyboardModifiers modifiers) 
     : QMouseEvent(type, position, button, buttons, modifiers) {}
    UMLScenePoint scenePos() { return pos(); }
};

As an experiment I found out that the following wrapper class is usable to
replace Q3CanvasRectangle (still using the Q3 int type) 

class UMLSceneRectangle : public QGraphicsRectItem
{
public:
    UMLSceneRectangle(UMLScene *scene);
    UMLSceneRectangle(int x, int y, int w, int h,  UMLScene *scene);
    ~UMLSceneRectangle();

    int height() const;
    int width() const;

    int z() const;
    void setZ(int value);
    QRect rect() const;
    void setSize(int width, int height);
};


3. Which methods and class member belongs to UMLView and which one to UMLScene
   In trunk there has been created a UMLScene class, which is derived from
UMLView to provide all methods from UMLView. 
   The next step in this area is to move the related UMLView methods into. 

4. migrate UMLScene from Q3Canvas to QGraphicsScene api
   ... 

5. migrate UMLView from Q3CanvasView to QGraphicsView api
   ... 

Are there any additional hints or ideas ?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.