Fancy Menu - Default LXQtFancyMenuWindow to transparent instead of black [Feature request] about lxqt-panel HOT 6 CLOSED

I had no problems to add it to dark and Valendas, but it would work only if you opened the menu twice, see lxqt/lxqt-themes#105 (comment) and response.

Maybe @tsujan gives you the long explanation.

EDIT: I see that you're right, it doesn't work anymore at all.

from lxqt-panel.

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:

from lxqt-panel.

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.

from lxqt-panel.

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.

from lxqt-panel.

.... 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.

from lxqt-panel.

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...

from lxqt-panel.