search

PapirusDevelopmentTeam / arc-kde

Arc KDE customization
https://git.io/arc-kde
GNU General Public License v3.0
904 stars 53 forks source link

Opaque menu border in Neon with Qt 5.9 #42

Closed abhnvkmr closed 7 years ago

abhnvkmr commented 7 years ago

i had installed Arc-KDE and Kvantum from papirus PPA. Yesterday Qt 5.9 was pushed to Neon User edition and now the menu borders look like this

screenshot_20170620_175848

varlesh commented 7 years ago

Thx for report, it's reproduced on other kvantum themes?

varlesh commented 7 years ago

I'm now try Arc Dark Transparent with Qt 5.7 and Qt 5.9 (with update) on Live KDE Neon and not confirm this: screenshot_20170620_194628 screenshot_20170620_195804

Try remove temp files on ~/.cache directory and relogin?

abhnvkmr commented 7 years ago

Still happening with other Kvantum themes. I also cleared .cache sans non-KDE folders.

Still I am fairly sure that it is a configuration issue because it's not happening for new users. Only for users that existed before I upgraded to 5.9.

varlesh commented 7 years ago

Sometime i see this bug too, but only for desktop menu right click > Add Panel. But it's not reproduced always - now all fine showing... Also i'm use version 0.10.4, try this: https://github.com/tsujan/Kvantum/releases/download/V0.10.4/kvantum_0.10.4-ubuntuLTS_amd64.deb This happened only for desktop widget menu for you or for another menus too (apps, other widgets and etc)? @tsujan you have ideas?

varlesh commented 7 years ago

Also notice, for right click > add panel not used shadows. For example, theme KvAmbiance: screenshot_20170621_115035

varlesh commented 7 years ago

@tsujan i reproduce this bug (it's happened not always): image

tsujan commented 7 years ago

I can't reproduce this but I recompiled Kvantum as soon as Qt was upgraded to 5.9 on my system. So, I recommend a recompilation against Qt 5.9.

tsujan commented 7 years ago

There's also another possibility. Lack of shadow usually means lack of compositing when a menu is created for the first time. The plasma may be started a few milliseconds before the compositor. Can you see the issue with applications that aren't related to Plasma?

varlesh commented 7 years ago

No, for me it's happened for only desktop widget > add panel menu sometime. I try recompile kvantum with new packages from Neon PPA

tsujan commented 7 years ago

OK, if it only happens with Plasma, it should be about the startup order, as I mentioned above. However, recompilation against 5.9 is a good idea.

If you see those shadowless menus in any app NOT related to Plasma, please tell me!

varlesh commented 7 years ago

I'm now use your package 0.10.4 from release and this happened randomly. I think you right with:

Lack of shadow usually means lack of compositing when a menu is created for the first time. The plasma may be started a few milliseconds before the compositor.

See, now all fine and shadows too: image Maybe need add sleep option some seconds for start?

varlesh commented 7 years ago

@abhinavk Please test with new git version (compiled with Neon PPA's): https://launchpad.net/~varlesh-l/+archive/ubuntu/test/+build/12783385/+files/kvantum_0.10.4ubuntu16.04_amd64.deb

varlesh commented 7 years ago

oops, sorry... for launchpad not available add repos from neon, because packages hosted on another server. Compiled with Qt 5.5 (from ubuntu ppa)

varlesh commented 7 years ago

You right @tsujan , because when i change engine kvantum > breeze > kvantum. All looks fine. @abhinavk Try this

abhnvkmr commented 7 years ago

I installed the .deb and it now looks fine.

tsujan commented 7 years ago

@varlesh I logged into KDE again and, at last, saw it:

plasma1

This is not about compositing; the submenu is composited but has no shadow.

Kvantum includes a workaround for some rare cases, where a stylesheet containing "padding" is applied to a menu. In such cases, Kvantum removes the shadow because, most probably, the stylesheet would interfere with the shadow size and would make it ugly. Such cases are caused by mistakes in the app code.

However, I'm confused by the randomness: If there's a stylesheet, it should be always there.

varlesh commented 7 years ago

See dev comment, it's happened because plasma started a few milliseconds before the compositor. Temporary solution - reenable kvantum engine.

varlesh commented 7 years ago

This is not about compositing; the submenu is composited but has no shadow. Kvantum includes a workaround for some rare cases, where a stylesheet containing "padding" is applied to a menu. In such cases, Kvantum removes the shadow because, most probably, the stylesheet would interfere with the shadow size and would make it ugly. Such cases are caused by mistakes in the app coding. However, I'm confused by the randomness: If there's a stylesheet, it should be always there.

But see my previous screen , border with shadows https://github.com/PapirusDevelopmentTeam/arc-kde/issues/42#issuecomment-310053472 It's very strange

tsujan commented 7 years ago

Yes, your test confirms the compositing hypothesis rather than the above one: in my screenshot, the menu is composited because compositing is present but it got its shadow size before compositing was enabled. Plasma has its weird bugs....

tsujan commented 7 years ago

Actually, the workaround I mentioned above is only for context menus of line-edits. Therefore, the compositing being started too late is the best explanation of this case :)

varlesh commented 7 years ago

Ok, @tsujan thx for help. Closed. PS: KDE bugs infinitely :)

tsujan commented 7 years ago

because when i change engine kvantum > breeze > kvantum. All looks fine.

You're completely right. I did the same thing and everything is OK:

plasma2