@dariusz Well the QMenu will still treat it as one item so its also kinda pretending :) I agree. you could also make a complete custom popup (like the drop down in ComboBox) type of menu and open it from a button but its harder to integrated with the rest of the QMenu if you have such one.

@mrjj said in QMenu & QAction get sender button/widget?: Hi Why do you need to know the parent? QAction can be shared so the same function can be activated from multiple sources. But normally action does the same regardless from where is was triggered. I need to adjust action command parameters depending on the parent widget. I tried action->parentWidget() but it did not return anything I could use . Esentially I can have action that does A+B, and if the action is in global widget it would do just that, but if its in local widget then I will need localA + localB... more or less... thus the need to have a way to knowing parent widget while sending command to work. @Chris-Kawa said in QMenu & QAction get sender button/widget?: Instead of starting with the action you can connect to the menu's triggered signal. In the slot sender() will give you the menu and you can go up the parents with parentWidget() to find the toolbar if you need. Hmmmmm that looks very tempting!!! Will give it a go thanks! I was about to write my own action system to handle my needs but perhaps with Chris Kawa reply I can utilize native qt ones ! Thanks! BRB testing. Ok so this gets me half way there. I can now do quite a bit nice stuff with menu & actions, like changing menu default action to do something else based on action clicked and all that - yay ! But... how do I find out that menu parent - QToolbar or QToolButton? Is there a path down from there? And it looks like the toolButton has thesame triggered signal... hmmmm yep this is beautifull, it propagates all the way to toolButton where I can do what I want with the action and its data. Amazing, whoever designed that system is my hero.

@jsulm @mrjj @ig Thanks for all the help. I was able to fix the inheritance issue by creating a new FileMenu instance in the main window.

Hi, In addition to @MrShawn, the slot can have less arguments than the signal, therefore you can keep their current signature.

Hi, for an easy native-styled Android menu (QML-based though), you can also have a look at V-Play Engine, which extends Qt and handles native features and styling for Android and iOS. E.g. for a native styled Navigation, with the V-Play Navigation Components: import VPlayApps 1.0 App { Navigation { NavigationItem { title: "Home" icon: IconType.home NavigationStack { Page { title: "Home" } } } NavigationItem { title: "Favorites" icon: IconType.star NavigationStack { Page { title: "Favorites" } } } } } Best, GTDev

@IMAN4K Hi Im not sure what "material ripple animation" really is so its hard to say which design i would prefer. Copying Paint of QMenu would be last choice as there might be bugs and its involving to keep in sync. If the items can do all the drawing them self i would go for that. (2 i think :)

You can define an accessibleName for your objects and distribute different StyleSheets. either via the designer or QWidget::setAccessibleName(const QString &name); e.g. QPushButton{ background-color: blue; } QPushButton[accessibleName="SpecialButton1"] { background-color: red; }

Hi Just as a note. No (dropdown) menus I have ever used can be triggered by right clicking. ( some offer properties this way) so can I ask why you need that?

I had some similar problem. My QMenu wasn't adjusting to a dynamically changed size of QWidgetAction. I have found this thread http://www.qtcentre.org/threads/26291-QWidgetAction-resize-in-QMenu and suggested workaround worked for me. Qt 5.9.5. QResizeEvent re (QSize(1, 1), size()); qApp->sendEvent(this, &re); adjustSize(); Where this is a pointer to QMenu object. Fake resize event forces all menu items size recalculating and adjustSize() recalculates it. I hope it will help to anyone else.

Thanks Chris for the singleShot timer idea. In the meanwhile, I've posted a bug report: https://bugreports.qt.io/browse/QTBUG-54421.

@SGaist According to comments in the bug report the posted code should work in qt 5.6.1, and I have been able to verify this is indeed the case. So I guess I should consider this question as 'answered' then. Thanx for the help

I have the same issue with updating the context menu with Qt 5.6 on Ubuntu 16.04 KDE Neo.

Hi, IIRC, that's part of the GNOME Human Interface Guidelines so there's no much you can do from a Qt point of view.

I'm not sure I'm following you correctly. Can you show what you have and what you would like to get ?

Very highly unlikely, Qt follows the platform style and thus the settings your users have. Note that modifying menus text size and icon size is likely to interfere with most platforms human interface guidelines which is usually a bad idea.

Hi, Good question but I haven't had the use case. One thing that looks "incorrect" is that you don't add your action to the menu the usual way: m_colourAction = m_contextMenu->addAction(tr("Colour")); If not, then you should also make the menu the parent of your QAction rather than your IModelElement. Out of curiosity, why the two casts one after the other ? You should also rather use qobject_cast since your IModelElement is also a QObject. On a side note, did you take into account the memory consumption of your model ? You are creating as many menus and actions (and also QObjects) as you have elements in your model for a functionality that doesn't really demand it.

For now I found following solution to prevent GUI from freeze: { Q_OBJECT public: QCustomMenu(QObject *parent = 0){}; void showEvent(QShowEvent *) { emit show(); QMenu::closeEvent(new QCloseEven()); QMenu::hideEvent(new QHideEvent()); } signals: void show(); }; And also now I've changed logic: on show() signal I exec() my dialog: QCustomMenu *menu = new QCustomMenu(toolbar); connect(menu, SIGNAL(show()), this, SLOT(execMyMenu())); But after closing my dialog UI waits for mouse click somewhere to start responding for further actions. May be it is possible to make programmatically click somewhere ? I didn't find any solution yet.

@m_jero I don't know why nobody answers this question. Maybe because you didn't supply any code snippets as recommended. Anyway, I suppose you used the exec() function to show the qmenu. Try to use popup() instead and see if it works.

Thanks SGaist for replay. I took the example itself from Qt : examples\activeqt\menus\main.cpp, menus.cpp I updated menus.cpp and added following code: QMenus::QMenus(QWidget *parent) : QMainWindow(parent, 0) { QAction *action; QMenu *file = new QMenu(this); file->setTearOffEnabled(true); //<= MY CHANGE action = new QAction(QPixmap((const char**)fileopen), "&Open", this); action->setShortcut(tr("CTRL+O")); connect(action, SIGNAL(triggered()), this, SLOT(fileOpen())); file->addAction(action); action = new QAction(QPixmap((const char**)filesave),"&Save", this); action->setShortcut(tr("CTRL+S")); connect(action, SIGNAL(triggered()), this, SLOT(fileSave())); file->addAction(action); //<= MY CHANGE file->addSeparator(); //<= MY CHANGE QWidgetAction* waction1 = new QWidgetAction(this); //<= MY CHANGE QLabel* label = new QLabel("My Data"); //<= MY CHANGE label->setAlignment(Qt::AlignHCenter); //<= MY CHANGE waction1->setDefaultWidget(label); //<= MY CHANGE file->addAction(waction1); //<= MY CHANGE //<= MY CHANGE QWidgetAction* waction2 = new QWidgetAction(this); //<= MY CHANGE QCheckBox* chk = new QCheckBox("Personal Data"); //<= MY CHANGE waction2->setDefaultWidget(chk); //<= MY CHANGE file->addAction(waction2); //<= MY CHANGE So, after tearoff, Label and checkbox are missing/hidden. Further I found following defect which looks to be not addressed yet. https://bugreports.qt.io/browse/QTBUG-1017 I tried 4.8.6 and 5.5. Is there any way out for this?

Working code: void MainWindow::listWidgetContextMenu(const QPoint &pos) { QPoint globalpos = ui->listWidget->mapToGlobal(pos); QMenu menuBeyondItem; QAction* action_addElement = menuBeyondItem.addAction("Add"); QMenu menuForItem; QAction* action_editElement = menuForItem.addAction("Edit"); QListWidgetItem* pointedItem = ui->listWidget->itemAt(pos); QAction* selectedAction; if(!pointedItem) { selectedAction = menuBeyondItem.exec(globalpos); if(selectedAction) { if(selectedAction == action_addElement) { qDebug() << "Add"; } } } else { selectedAction = menuForItem.exec(globalpos); if(selectedAction) { if(selectedAction == action_editElement) { qDebug() << "Edit"; } } } } What I didn't know was existence of QListWidget::itemAt(QPoint) function. For QListView use QModelIndex QListView::indexAt(const QPoint & p) const function.

I really just need to know if someone has had this same problem and what they did to fix it. Or, what the method/property is on the menu to check/set the starting position.

Hi SGaist, Thanks for the tip. I made a comment on the linked bug. Hopefully, that helps someone!

I have found the solution btw, if anyone ever gets the same problem. It was quite easy actually: setLayoutDirection( Qt::RightToLeft );