One of the things that I and many others hate about Windows is its context menus’ inconsistency. In Plasma, this generally isn’t much of a problem, if one at all, but there is a glaring discrepancy between QtWidgets-based apps’ and QML-based apps’.
Although I can note that QML menus have more padding and don’t feature animations unlike their standard counterparts, the most notable difference is that they can be screenshotted when using Active Window in spectacle.
There must be a reason for this, right? I’d be glad if someone could tell me, because at least then I’d feel slightly less bugged by it. Thanks.
Honestly, why do you care? The inability to screenshot menus is generally something that people are annoyed by. And here we have menus that can be screenshotted and you’re saying it bugs you? Life’s too short, man.
If you’re looking for a technical explanation, because because under the hood, QtWidgets menus are implemented as separate windows, while QtQuick menus are drawn by their parent window.
So is there no technical way for them to be identical, then? Surely, even if QtWidgets context menus are managed by the WM differently, they should be able to share the same content and use the same animations?
My knowledge of QML is that QtWidgets Q(Gui)Applications can consume it just fine, so I’m surprised that the two types of context menus have been so independently developed.
I might be autistic or just any other kind of annoying, I don’t know. I just care about consistency. I thought pointing this out might have helped, had it been overlooked… If you look online, it’s a significant point of contention for Windows and macOS users, so I was sure that we wouldn’t want to replicate it.
Caring about inconsistency is good. But then I would suggest that you phrase it that way instead of asking leading questions that feel a little bit like, “Why is your refrigerator white?” The answer is obvious (because you or someone else bought a white refrigerator) and doesn’t matter; what’s more interesting is the discussion of the decision-making process that resulted in that outcome, and potential trade-offs that were made in the process.
By directly asking the actual question you want answered: “Can Kirigami menus be made visually consistent with menus in non-Kirigami apps, and if so, how do we get there?”
That indeed was to be my follow-up. However, my phrasal of the question was inferior, so thanks. Because that that topic has already been briefly discussed here, would a separate topic to discuss that be considered duplicate?
Given that this is a decision made by the Qt toolkit, the place to change this would be through a Qt issue and patch getting accepted by their maintainers.
The way we get there is by having our qqc2-desktop-style theme use KQuickStyleItem to render menu items from the QStyle, rather than having its own implementation. This is what it already does for things like buttons and scrollbars, but it doesn’t do that for menus.
I’m not sure why this hasn’t already been done, but I have to assume that it’s not simple to do, or else it probably would have already happened. If it is, then hopefully it will be done soon.
Thanks lots for the explanation. Is there a bug for this? Would it be fine to make one, @ngraham?
That definitely seems like a bug. I’m not asking you to search, since I reckon I can probably get to grips with their bug tracker, but do you know of a bug for that too, @carl?
Life’s too short, man. 
