Closed AzumaHazuki closed 10 months ago
I had no problems to add it to dark and Valendas, but it would work only if you opened the menu twice, see https://github.com/lxqt/lxqt-themes/pull/105#issuecomment-1895490917 and response.
Maybe @tsujan gives you the long explanation.
EDIT: I see that you're right, it doesn't work anymore at all.
No, transparency isn't possible because the widget should work without stylesheet too, but Qt styles like Fusion and Breeze don't support window translucency. Only a Qt style like Kvantum does.
Fancy Menu with translucency and KWin's blur-behind, styled by Kvantum:
Since elsewhere I'd promised to give an explanation:
If you enable translucency in the code, Fancy Menu could be made translucent by Qt's Stylesheet style but, without stylesheet and with a Qt style like Fusion, either it'll be 100% transparent or it'll have a black background, depending on whether compositing is present or not.
A widget like Main Menu is different because it's a QMenu
, and QMenu
is drawn differently by QStyle.
All in all, it's about QStyle and that we want our widget to be usable with or without stylesheets and also with or without compositing — except for @stefonarch and me, I doubt that anyone uses Fancy Menu under Wayland.
Okay then, how about this: the older Wing Menu's main window is a QMenu, so we know this can be done. Would it be a lot of work to refactor the code that generates LXQtFancyMenuWindow such that is itself a QMenu rather than whichever unstyleable derived class it is?
I had kind of assumed it was built the same way to begin with...oops.
.... rather than whichever unstyleable derived class it is?
First, it is completely stylable. Second, it isn't a derived class.
the older Wing Menu's main window is a QMenu
Wing Menu was a QMenu
having a QWidgetAction
with a default widget, while Fancy Menu is simply a widget with a Qt::Popup
flag. I don't think anyone wants to sacrifice the simplicity of the latter just to force translucency, to say nothing of the probable side effects that might result, especially under Wayland.
The thing is, this is a step backwards in flexibility and themeability compared to Wing Menu.
How much work would reimplementing this that way really be? It sounds like you're saying the entire plugin as we have it now would just need to be "wrapped in" a QMenu one level up, from the sound of it. And I don't see why it couldn't still fall back to sane defaults if none are defined in the theme -- for example, if there's no LXQtPanelMainWindow {}
block defined, grab palette(window)
, palette(base)
, and palette(text)
.
Also, what exactly would happen under Wayland? I was under the impression Qt makes it more or less seamless to code for both...
I've noticed that it isn't possible to specify transparencies, either by q*gradient or by png/svg/etc overlays, over the main window of the Fancy Menu plugin. It seems there's a permanent, solid block of #000000 underlaying it.
Would it be possible to default this to transparency/null instead? This would enable semi-transparent backgrounds; I'm currently working on a somewhat Aero-ish theme and would like to be able to do this. Thanks in advance! :)