Is a `QMenu` item supposed to be able to be checkable?

JonB

I use Qt 5.1.5.x under Linux. Creator is 6.0.2. Both come as-supplied by distro.

Before anyone jumps in and says "You put QActions on QMenus and they can be checkable". I know this, that works! That is not my question!

My question is the checkability, or not, of QMenu items. Where an item in a menu itself has a sub-menu. So it becomes a QMenu, not a QAction.

Here I achieved what I want in Designer.
Screenshot from 2023-04-11 15-58-11.png

Note that Use Threads is a QMenu not a QAction. It started out as a QAction, and I made it checkable. Then I clicked the little "+" to give it a child menu (and added some actions on that). It changed the type from QAction to QMenu. So that's how I got to this stage.

The checkbox against Use Threads is not accessible from within Designer. I'm not even 100% sure what is making it still display it. But it is just what I want.

When I compile and run this, at runtime that checkbox simply does not appear. So in code I added:

    // make the "Use Threads" menu item checkable (can't access it at design-time)
    ui->menuUseThreads->menuAction()->setCheckable(true);

That makes it appear at runtime:
Screenshot from 2023-04-11 16-05-09.png

Looks just how I intended! But it does not "work": if I click on that Use Threads checkbox, I see it go grey (like tri-state?), but it doesn't stick, and when i move the mouse off it reverts to unchecked.

It is very difficult to Google for this. All attempts at QMenu checkable give answers/code for a QAction. I cannot find someone addressing a QMenu item (i.e. it has a sub-menu) where a checkbox is desired.

It works programatically though. If I hard-code

ui->menuUseThreads->menuAction()->setChecked(true);

that sets it checked. Then I can't uncheck it interactively.

All in all: is this supposed to work? If it's not then that may explain/I am wasting my time.

JonB

@J-Hilk
Still takes a lot of work to write the code for this. Remember I get no signal upon clicking the checkbox if I force it to show, so I'm going to have to write code to manage that as well as the state. Just not worth it for one checkbox.

Besides, as per this topic title, my intention was to find out whether QMenu sub-menus are intended (i.e. out of the box) to support a checkable checkbox. Since it seems they do not, plus I can't find anyone else asking this question, my idea of doing it this way seems not to be what others do, so I'll redesign.

JoeCFD

@JonB I did a quick test with Qt 6.5 on Ubuntu 22.04 and got the same result. It seems each menu has an action(menuAction()) attached to it. The checkbox looks like from this action. However, it does not do anything to its child actions.

JonB

@JoeCFD
Hey, thanks for checking! Nice to know I'm not mad. I guess this has never been supported, and I'm the only person who fancies having a checkbox against a sub-menu :)

I only need clicking the checkbox interactively to toggle its state correctly. (Not trying to do any actions.) I know that in code menuUseThreads->menuAction()->setChecked/isChecked() do work. Maybe I can slot onto menuAction()'s clicked (triggered? activated?) or whatever and change the check state with setChecked() myself?

Hopefully it will emit void QAction::triggered(bool checked = false)...?

JonB

Well, sadly it all seems like a no-go :(

When I click to try to change the sub-menu's checkbox I do not get any signal like QAction::toggled/changed/triggered from the QMenu::menuAction(). It just goes to grey and then reverts to original state (checked or unchecked, as set from code) when I move the mouse off it. That means I have no way to know the user is clicking on the checkbox to change its checked state myself, since Qt does not do this.

So my conclusion is QMenu sub-menus/menuAction()s are not intended to support having a checkbox, for right or for wrong. Hence I need to design my sub-menu alternatively....

J.Hilk

@JonB said in Is a `QMenu` item supposed to be able to be checkable?:

Hence I need to design my sub-menu alternatively....

have you considered to simply subclass QMenu and repaint your own checkbox ? might be the simplest solution

mpergand

@JonB
Have you tried setNativeMenuBar(false)

JonB

@J-Hilk

have you considered to simply subclass QMenu and repaint your own checkbox ?

...Not when I am using QT Creator to do the design work, I have no intention of learning to Promote... and don't want to write more than about one line of code for this... :)

J.Hilk

@JonB there is nothing to learn,
inside QtDesigner, click on promote select your header -> done.

JonB

@mpergand said in Is a `QMenu` item supposed to be able to be checkable?:

Have you try setNativeMenuBar(false)

Never seen that one. It says:

The currently supported platforms are macOS, and Linux desktops which use the com.canonical.dbusmenu D-Bus interface (such as Ubuntu Unity).

so I don't think it applies to me anyway. And that would be on the whole menu bar. I don't want to alter that just for the sake of one checkbox several levels down in the menu....

JonB

@J-Hilk
Still takes a lot of work to write the code for this. Remember I get no signal upon clicking the checkbox if I force it to show, so I'm going to have to write code to manage that as well as the state. Just not worth it for one checkbox.

Besides, as per this topic title, my intention was to find out whether QMenu sub-menus are intended (i.e. out of the box) to support a checkable checkbox. Since it seems they do not, plus I can't find anyone else asking this question, my idea of doing it this way seems not to be what others do, so I'll redesign.

SGaist

@JonB hi,

Something that might be worth checking on the interest mailing list.

Intuitively, I would have expected that clicking on the menu's checkbox would check all subsequent checkable actions. That menu action would need to be tri-state in any case.

Pl45m4

@JonB said in Is a `QMenu` item supposed to be able to be checkable?:

Hey, thanks for checking! Nice to know I'm not mad. I guess this has never been supported, and I'm the only person who fancies having a checkbox against a sub-menu :)

@JonB said in Is a `QMenu` item supposed to be able to be checkable?:

I can't find anyone else asking this question, my idea of doing it this way seems not to be what others do, so I'll redesign.

So fun to read that you often come up with some "weird" (not weird, but uncommon) stuff :D
Honestly I've also stumbled across this quite a while ago and figured out, that it doesn't work like you could assume how it works.
It's similar to the QMenu and QAction stuff in general. For example that you can't see QActions in your GUI. All you see is the WidgetAction which is the graphical representation of your QAction and can be customized (through subclassing QWidgetAction).

https://doc.qt.io/qt-6/qwidgetaction.html

From what I have experienced in QtDesigner, I think that it's not meant for that purpose. After adding another layer/sub-menu to an already checkable QAction, all checkboxes and current check states disappear. QMenus are not checkable in QtDesigner.
Yes, hardcoding the check sate breaks this, but as you've said above, it still doesn't work interactively, unfortunately :(

@JonB said in Is a `QMenu` item supposed to be able to be checkable?:

Still takes a lot of work to write the code for this. Remember I get no signal upon clicking the checkbox if I force it to show, so I'm going to have to write code to manage that as well as the state. Just not worth it for one checkbox.

If you manage to make it work, (maybe by using QWidgetAction), it could be quite interesting :)
... and it doesn't have to feel like bad UI/UX, which I think, is the reason why this is not possible.
As soon as you add sub-actions or -menus, your current action becomes "flat" and more like an "organisation unit", which has no other function than showing child-actions or even more menus.

SimonSchroeder

There are operating systems (not macOS) where clicking on a QMenu opens up the submenu directly instead of hovering the mouse pointer over the menu entry and waiting 50ms for the submenu to open. The few times I have used our software on macOS this got really annoying because on macOS it will just close the menu. This means that I always use this feature on Windows and Linux. How would you differentiate between a single click opening the submenu and a single click toggling the checkbox? It is not intuitive and not consistent. Hence, I would say it is bad UI design.

You could add inside your submenu an entry "Toggle all" or "All on" and "All off". Either right at the top or the bottom of the submenu.

JonB

@SimonSchroeder said in Is a `QMenu` item supposed to be able to be checkable?:

How would you differentiate between a single click opening the submenu and a single click toggling the checkbox?

Thank you, I simply had not noticed/grasped this. I had assumed the checkbox and the text for the menu/sub-menu were separate items. I had expected to click on the checkbox to alter that and on the text to invoke opening the submenu, as quite separate actions. I now realise that is not how it works, they are a single item for the purpose of clicking. So it all makes sense now.

Pl45m4

@JonB

I thought of using the checkbox not as option to fully, partly enable or disable the submenu items (tri-state), but as enabler for the current "option" in where the checkbox is in and which then has additional submenu options.
I don't know if it makes sense and probably it's still bad UI/UX and has limited use.
At least there was a point where I thought "It would be great, IF..." :)

JonB

@Pl45m4 said in Is a `QMenu` item supposed to be able to be checkable?:

I thought of using the checkbox not as option to fully, partly enable or disable the submenu items (tri-state), but as enabler for the current "option" in where the checkbox is in and which then has additional submenu options.

That is exactly what I do want it for. However @SimonSchroeder's explanation --- that the checkbox and the text are really a single thing composing the menu item --- makes me realise that menu items are not intended to distinguish click on checkbox vs click on text, they are one and the same action.