Cassidy James Blaede

Notifications are not for ongoing progress, that's what dock progress bars generally are for. I think our normal expectation here is that we'd show the progress in-window in Files, closing...

@danrabbit do we want to pursue this before release?

@JoseExposito this looks so good! It works well on most hardware here though setting the delay to 200ms seems to be more reliable in masking the transition on my i3...

@marbetschar so in that case, the delay is not high enough and so you're seeing the GTK change slip through the animation. Try making the above suggested change and see...

@JoseExposito yep, I understand how the delay works, but mentioning accepting input is a good point. However, even on relatively good hardware I'm not seeing consistent GTK transitions in any...

As a note for my testing scenario, I'm using a page with this GitHub PR in Web, a Files window, and the System Settings → Desktop → Appearance pane. The...

Just another stream of consciousness comment: shipping with a longer delay to start, then investigating and fixing any delays possible in the GTK transition itself, and then shortening the delay...

So poking at this further, the GSetting to disable animations doesn't seem to apply to CSS animations in the stylesheet. Forcing it in the stylesheet/app's custom CSS (e.g. with `*...

@Exalm what GSetting, then? Because setting the org.gnome.desktop.interface one doesn't change anything in Handy or Gtk.CSS animations for me here.

@JoseExposito hm, I'm not sure if something changed underneath this branch, but now in its current state I get a pretty reliably weird transition: https://user-images.githubusercontent.com/611168/138942748-32937a78-bdbe-4137-a19f-f2343d60c5b2.mp4