[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