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

mpergand

@JonB
Have you tried setNativeMenuBar(false)

JonB

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.