Open gianlucapettinello opened 10 years ago
If by "have transparency" you mean having an ARGB visual ("true transparency" of the application), and by "is GTK+ 3" you mean those with ARGB visual (with client-side decoration, for example), then yes, this is a known issue, and I'm not aware of a perfect solution. Simply use --fade-exclude argb
if you don't need fading on those windows. The problem most likely occurred because of some design decisions of Fluxbox, together with some deep logic in X, but the exact reason remains unknown -- perhaps I will have more time tracing it after my exam. There's no indication that the issue has anything to do with "GTK+ 3 closing too quickly". You may contact Fluxbox developers or switch to a WM that does not have the problem (fvwm, for example), as well.
Should I have misunderstood your meaning (i.e. your problem is not only happening on ARGB windows), you could try changing --backend
or load the fallback settings (compton --config /dev/null
).
And we are glad that you are enjoying compton. :-)
Thanks for the very quick reply. Yes I meant what you said. I will give a try with fvwm and probably contact Fluxbox developers Thanks again
Eeeh, if what you need is just a workaround, then the --fade-exclude argb
one might be easier... Fvwm is a pretty confusing WM. :-)
Yes I tried fvwm.... well it is IT masochism :) I'm wondering if you can create a fade exclude for opening, closing, minimizing and restoring. This way I can exclude fading of argb only for closing action. Do you think it is feasible clearly after your exam? Thanks
Yes I tried fvwm.... well it is IT masochism :)
Lol, yep, that's what it is, although I found the WM more flexible than any other ones once I got used to it.
I'm wondering if you can create a fade exclude for opening, closing, minimizing and restoring. This way I can exclude fading of argb only for closing action. Do you think it is feasible clearly after your exam?
Possible, but not worthwhile. I don't understand why simply --fade-exclude
those windows would be unbearable... I'm considering adding a special switch to stop fading out destroyed ARGB windows.
That would be great. Waiting for the switch!
@gianlucapettinello:
The workaround was implemented as --no-fading-destroyed-argb
in 81c677f (richardgv-dev
). Could you please test if it works?
@richardgv Just tried now. Works perfectly. Thanks a lot! If one day you decide to implement the fading without white rectangle you become my myth
Just tried now. Works perfectly. Thanks a lot!
Great!
If one day you decide to implement the fading without white rectangle you become my myth
Huh? I thought you already know that this is not our fault. Anyway, might look into what is triggering this in Openbox when I have some extra time.
Sorry, I wish to keep this open to remind me that I need to look into the Openbox issue...
Ok no problem. Very happy you are fighting against this issue. Thanks
I just want to bump this and mention that this happens with i3 and compton v0.1_beta2.5 (Arch community as of today). The --no-fading-destroyed-argb does nothing.
I think it was already mentioned in the past. I've nvidia and fluxbox. OpenGL backend, fading enabled When I close a window which has transparency or is gtk3, a white rectangle appears and then fades away. I slowed down the effect and this white rectangle appears immediately. I read in the previous posts that it is due to the fact that gtk3 apps close too quickly. Is it possible to find a workaround. Apart from that I say that it is marvelous. I changed to compton after years of compiz and I find it so "classic" meaning well balanced Thanks Gianluca