Disable fade animation

MouseFan · 2019-07-06 10:39:39

When i switch between programs it is very annoying. I was looking for a solution in Google but could not find anything. I would like to turn off any animation, including fading.

Video for example vimple.co/66fddf69118347a4850fe800bce89f70

MountainDewManiac · 2019-07-06 12:22:27

Fade animation? I wasn't aware that Xfwm offered that.

Are you using a third-party compositor?

Regards,
MDM

ToZ · 2019-07-06 12:53:19

It's not fading per se, it's both the default GTK3 focus dimming that happens with the toolkit (see https://developer.gnome.org/gtk3/stable … rview.html for a discussion about GTK3 widget states) and xfwm4 theme configurations.

There are two types of "fading" that are happening there.

GTK3 toolkit "fading" - this is the fading that happens within the window (minus the window titlebar). You can affect these by overriding the default "backdrop" state of widgets via something like:
```
*:backdrop {
        -gtk-icon-effect: none;
        color: #000000;
}
```
...change "#000000" to the foreground colour of the elements to match your current focused foreground colour. Note that I also prevent any icons from dimming by setting the "-gtk-icon-effect" parameter.
.
The second is the titlebar dimming. This is done by xfwm4 and the theme that is selected. Have a read through the xfwm4 theme howto to get a better understanding of how xfwm4 themes work. Basically, there are different active and inactive elements in the theme that create the "fade" effect. You'll need to change those (or just copy all active elements to their corresponding inactive elements).

MountainDewManiac · 2019-07-06 20:15:22

Seems like every time I visit this forum, I read more threads from Xfce users wanting to know how to disable - or fix - another facet of this GTK garbage. Why is it that the Xfce developers are wasting spending so much time trying to switch everything over to it, again? They're tired of working on the Xfce project and figure that, once they've convinced the last of us to go with a different DE, they can stop, since at that point no one will be likely to notice?

Regards,
MDM

Last edited by MountainDewManiac (2019-07-06 20:15:54)

ToZ · 2019-07-06 23:37:20

I can't seem to recall if this widget behaviour was the same in GTK2. Maybe its something that's been around for a while. Anyways, GTK3 Xfce is just around the corner.

oldhwman · 2019-10-07 12:24:12

Hi everyone,

Apologies for reviving this old topic -- I was wondering if the great hive mind of the Internet had any new input on this. I'm happy to bring some of my own.

I haven't tried bisecting this, but I suspect this behaviour was recently(-ish) introduced by adding support for the _NET_WM_STATE_FOCUSED property. Gnome needs that because, now that they're using header bars, there's no way to show which application has focus except by dimming that application's window. Until recently, XFWM didn't export that property, so themes using the :backdrop selector didn't work properly.

GTK2 themes (thankfully) don't support that, and a bunch of other window managers don't support it, either, which is why it's been hidden so far.

Now, my questions are:

1. Is anyone aware of a way to turn that damn thing off without editing the theme? Perhaps some obscure X11 hack that I definitely no longer remember from back when messing with XF86Config was a thing, which would just drop (or force the values of) some properties from a set of windows?

2. If not, is there any interest in introducing such an option? I'd be happy to provide a patch but I'm not sure what the right way to implement this would be -- there's a very good reason why dimming is supported (i.e. headerbar apps!), and a patch that just breaks headerbar applications is just as bad as a patch that breaks non-headerbar applications. Besides, I'm not an XFCE user anymore (due to this whole GTK3 thing, I'm not a GTK user anymore so I switched to other things after the 4.12 release) and I don't really trust myself to come up with an idiomatic solution.

The back story to my question is that there's some old code of mine still running back at my alma mater. Now that their old LTS distro got upgraded, and I did the nice thing and port my old code to GTK3, the few people there not using KDE (and the old GTK2 code of my app) are going nuts. As soon as they switch to their LaTeX or LibreOffice document window, the application window containing simulation results goes dim (and pretty hard to read) -- and it's pretty annoying regardless of what applications are involved, since the whole screen starts blinking like a Christmas tree in reverse as soon as you start switching between windows. It's not too obvious on a tiny laptop screen, but these folks are using 27" monitors with 5-6 windows open at once.

I can't just tell my users to edit their theme -- their theme is Adwaita and these are 60 year-old engineers of the non-computer kind who don't know CSS and don't know or care what a theme is. I also don't want to port the GUI to Qt and tell them to use something else, either, I'd much rather fix the thing that they're using today. I could tell them to keep using the GTK2 version of my application but the other ones would still exhibit this behaviour, and I wish I could be more helpful than that...

Last edited by oldhwman (2019-10-07 12:49:50)

ToZ · 2019-10-07 18:39:31

@oldhwman, hello and welcome.

Not sure how much to add, but in case you haven't seen these yet:
- https://bugzilla.xfce.org/show_bug.cgi?id=11067 - the commit that added support for _NET_WM_STATE_FOCUSED
- https://gitlab.gnome.org/GNOME/gtk/issues/777 - gnome bug report discussion about the backdrop issue.

When I look at the Adwaita theme on my system, GTK3.24.12, the backdrop differences are minimal (in the sense that I can still quite easily see the content of the non-focused windows). Are you using the built-in Adwaita theme or a packaged version of the Adwaita theme (if the later, it may no longer be relevant for the version of GTK3 you are currently running)?

As for suggestions, feel free to create a bug report to see what the developer will say.

oldhwman · 2019-10-07 20:40:22

Hey @ToZ -- it's good to be here! Thanks!

(Come to think of it, I'm sure I had an account here but it's been so many years I don't even remember the username...)

I'm reasonably sure this is the built-in Adwaita theme, but I'll check. The saturation difference isn't extreme (it's worth with other teams but I'm not going down that path...) but it's definitely there and I can see how someone could be bothered by it. It's not hard to read for you and me, on quality monitors, but for older folks on bad monitors... I've seen it, and it's not too pretty.

I've done some further digging and I think I'll settle for providing them with a package of a hacked-up Adwaita for now. It seems like the path of least resistance. If there's any interest in the community here, I can look into a real fix that everyone can benefit from.

Sorry if I was a bit grumpy about this -- I get bitter every time I have to touch GTK code nowadays. Didn't mean to take it out on you folks sad .

ToZ · 2019-10-07 23:32:07

No worries, we're pretty easy going around here.

The hacked Adwaita may be the best way to go forward. I searched for a while to see if I could find a good GTK3 theme that didn't have ":backdrop" statements, but the searches were fruitless. Even if there was one, you'd have to find some way to get everyone to change the theme. Hacking Adwaita may just be the best way forward. At one point I was thinking maybe it would be possible to create a system-wide GTK hack, but I was wrong with my assumption that /etc/gtk-3.0.gtk.css could be used. You can only use the user-based ~/.config/gtk-3.0/gtk.css file.

If you do get a working non-backdrop Adwaita theme working, post it back here. Others may find it useful.

oldhwman · 2019-12-18 10:05:53

So, uh, this turned out to be a lot more work than I'd hoped and I want to invent a time machine so that I can travel back to 2007 and kick myself for using GTK.

I tried to hack up Adwaita and I was actually successful but the amount of effort there isn't exactly realistic. It's a lot of CSS, way more than I'm comfortable maintaining, and the changelogs are daunting. I can hack this particular Adwaita release, corresponding to this particular GTK version and Gnome release, but it will definitely require ongoing maintenance and I simply don't understand GTK theming well enough to jump on this ship.

I also experimented with using another window manager for XFCE. Openbox incidentally doesn't set the STATE_FOCUSED property. It seems to work well but XFCE is the one piece of software that I actually trust in all this. Hacking up its innards looks counterproductive.

Eventually, I pored through xfce-look.org and found a theme (ClassicLooks) that doesn't use this feature. My users seem happy with it, so I'm happy. If this breaks again, I'll rewrite the UI using Qt.

Fixing this problem with C++ isn't my idea of elegance but I don't see another way. There are quite a few of bug reports about this, at every level of the tech stack, from the GTK bug tracker to Ubuntu's. Unfortunately, everyone either deflects (it's not us, it's the WM setting this property; it's not us, we have to set that property -- this is controlled by the theme) or insists this is a feature. So taking this upstream looks unproductive, especially since Gnome is heavily invested in it (there's no other choice for Gnome, since Gnome applications no longer have titlebars -- windows need to have different backdrops, otherwise you can't tell which one's the active window).

Aravisian · 2019-12-18 15:57:35

I use backdrop in a slightly different way when doing one of my ludicrous attempts at making a gtk3 theme. That being said, I can tell you: Simply removing backdrop options from a themes css will do nothing about the backdrop problem.
It's the engine.
Gnomes gtk3 engine is the shambles -which may seem odd on the surface because it works (and has been working for a long time) for webpages, Mozilla and everything else that uses cascading style sheets to stretch or render images. Yet, Gnomes is lousy at images.
And... I am sadly confident that I know exactly why.
Strong Image Rendering encourages individual expression in theming and Gnome Does Not Want That. At all.
Which is why gtk css is quite good if you want a background with a linear gradient and why it shows how apps can be developed in a more lazy fashion (You can make a button any size you want since just having a linear gradient means it will have a stretchy background instead of a distorted image.)
The problem is definitely not the Window Manager.
And no, it is not the themers.

alcornoqui · 2019-12-18 22:06:42

oldhwman wrote:

Hi everyone,
Apologies for reviving this old topic

You're very welcome to revive a topic in this way, thanks to all for the interesting discussion!

oldhwman · 2019-12-19 10:04:48

I... don't really want to go on a Gnome bashing session here. I don't use it enough and (barring this re-encounter with GTK) I don't write nearly enough software using its technology to comment. I understand why this feature was added and I'm pretty sure it's a good idea in some cases.

I'm pretty disappointed about what's happening simply because this is a problem that really can't be properly resolved anywhere except upstream. I can whip something up for my application but I can guarantee that all it would achieve is break compatibility somewhere else. It's not something that can be easily solved downstream because the breakage occurs at the interface between toolkit, theme and application code. Upstream response has been... let's just call it less than sympathetic.

That's all I want to say because I don't want to invite the anti-Gnome trolls.

Aravisian wrote:

And no, it is not the themers.

Yeah, this is something I do want to vent about.

A lot of people treat theming (and application overrides) very poorly, like it's something we do just to piss off upstream developers. I'm sure there are plenty of things that we could do better but this black-and-white attitude is extremely short-sighted. I don't want to second-guess the toolkit but if I have to choose between making my users happy and keeping toolkit developers happy, I'm always going to pick my users. They are literally the reason why I'm writing a program in the first place. I can always pick another toolkit if I have to, but I can't pick other users.

What happens after that is up to us, toolkit and app developers. We can either work out something that works on both ends, and I for one am more than willing to compromise, because second-guessing the toolkit is rarely good for me in the long run. Or we can summon our inner 13 year-olds, ignore each other and write passive-agressive blog posts about how what everyone else is doing is Entirely Wrong. Which, for some reason, has become very popular in the open source community lately and I swear to god it's more obnoxious and annoying than being at a dinner party with five Microsoft MVPs.

Aravisian · 2019-12-20 02:17:54

oldhwman wrote:

Yeah, this is something I do want to vent about.

This one thread has managed to touch on several topics I would like to vent about- including thread necromancy.
The benefits of Thread Necromancy are numerous and strong and the cons are slight and small. Yet, in net-culture, it has become customary to -rudely- chastize people who revive a thread on topic in order to contribute -on topic- to that discussion with new information, new questions - keeping it organized and tight.
The con includes that a thread can get long with off hand comments, like this one. But that is slight (Sometimes entertaining) and the pros outweigh it far often than not.
Please allow me to second the opinion made by alcornoqui. IMO, thread revival is often very helpful. I can make a long list as to why.

oldhwman wrote:

That's all I want to say because I don't want to invite the anti-Gnome trolls.

There is a big difference between trolling and voicing valid and legitimate concerns about a product. We cannot always choose silence (and you have not chosen silence, only reticence) for fear of being labeled a "troll" by someone that misuses the word to pander to their own convenience.

oldhwman wrote:

I don't want to second-guess the toolkit but if I have to choose between making my users happy and keeping toolkit developers happy, I'm always going to pick my users. They are literally the reason why I'm writing a program in the first place. I can always pick another toolkit if I have to, but I can't pick other users.

NAILED IT!

Xfce Forum

Sub domains

#1 2019-07-06 10:39:39

Disable fade animation

#2 2019-07-06 12:22:27

Re: Disable fade animation

#3 2019-07-06 12:53:19

Re: Disable fade animation

#4 2019-07-06 20:15:22

Re: Disable fade animation

#5 2019-07-06 23:37:20

Re: Disable fade animation

#6 2019-10-07 12:24:12

Re: Disable fade animation

#7 2019-10-07 18:39:31

Re: Disable fade animation

#8 2019-10-07 20:40:22

Re: Disable fade animation

#9 2019-10-07 23:32:07

Re: Disable fade animation

#10 2019-12-18 10:05:53

Re: Disable fade animation

#11 2019-12-18 15:57:35

Re: Disable fade animation

#12 2019-12-18 22:06:42

Re: Disable fade animation

#13 2019-12-19 10:04:48

Re: Disable fade animation

#14 2019-12-20 02:17:54

Re: Disable fade animation

Board footer