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

Ralf Habacker ralf.habacker at gmail.com
Sat Jun 2 08:33:36 UTC 2012


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

--- Comment #16 from Ralf Habacker <ralf.habacker at gmail.com> ---
An additional merging topic are changes in the way popup menu are constructed. 

Trunk uses virtual methods based on UMLWidget::setupPopupMenu(ListPopupMenu *)
to create popup menus. popup creation is triggered by
UMLWidgetController::mouseReleaseEvent(), which calls
UMLWidgetController::setupPopupMenu(QMouseEvent *), which  calls
UMLWidget::setupPopupMenu(ListPopupMenu *) 

The soc-branch uses the QGraphicsScene supported way: 
QGraphicsScene provides a virtual method contextMenuEvent() which is routed to
the top most graphics item
http://qt-project.org/doc/qt-4.8/qgraphicsscene.html#contextMenuEvent

Graphics items constructs a menu instance
/**
 * Reimplemented to show appropriate context menu.
 */
void WidgetBase::contextMenuEvent(UMLSceneContextMenuEvent *event)
{
    event->accept();
    ...
    setSelected(true);
    QPointer<ListPopupMenu> menu = new ListPopupMenu(0, this, false, false);
    setupContextMenuActions(*(menu.data()));
    QAction *triggered = menu->exec(event->screenPos());
    ListPopupMenu *parentMenu = ListPopupMenu::menuFromAction(triggered);
    ....
}

The menu instance is not stored in the m_pMenu class member and requires the
mentioned ugly hack in listpopmenu::setupActionData() 
/**
 * Sets up actions added to the ListPopupMenu to have their data field set to
 * pointer to this ListPopupMenu object, so that this menu pointer can be
 * retrieved in UMLWidget::slotMenuSelection
 *
 * @note This might seem like an ugly hack, but this is the only solution which
 *       helped in avoiding storage of ListPopupMenu pointer in each UMLWidget.
 */

What is bad with storing a menu pointer in UMLWidget ?

-- 
You are receiving this mail because:
You are the assignee for the bug.




More information about the umbrello-devel mailing list