lxqt / lxqt-panel

The LXQt desktop panel
https://lxqt-project.org
GNU Lesser General Public License v2.1
179 stars 135 forks source link

Fancy Menu - Default LXQtFancyMenuWindow to transparent instead of black [Feature request] #2018

Closed AzumaHazuki closed 5 months ago

AzumaHazuki commented 5 months ago

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! :)

stefonarch commented 5 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.

tsujan commented 5 months ago

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:

translucency

tsujan commented 5 months ago

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.

AzumaHazuki commented 5 months ago

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.

tsujan commented 5 months ago

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

AzumaHazuki commented 5 months ago

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