Sounds like we need to fix that icon. We'll do that in the breeze-icons repo.
Hmm, I'm not sure about this. edit-undo isn't really that semantically incorrect since restoring a trashed item can be considered a form of undo. Also from a practical perspective, the edit-undo icon is far more meaningful than this restoration icon, whose meaning is not at all clear.
Great, thanks. Now please fix the commit message to be a statement in the imperative mood (i.e. "do something to that other thing"). See https://chris.beams.io/posts/git-commit/#seven-rules
Sat, Jan 19
Does this screenshot actually show the place where the icon is used? ;-)
Did you test by running QT_SCALE_FACTOR=2 gwenview with this patch? :)
Wed, Jan 9
Some of these gesture recognizers would be very helpful in other KDE programs as well (Okular is what I have in mind). Can they be moved to some central place where both Gwenview and Okular can use them?
Mon, Jan 7
Sun, Jan 6
I agree, unless the XDG spec evolves, it is becoming more and more useless anyway.
Sat, Jan 5
arc does something very strange when I try to apply this patch:
Fri, Jan 4
So, anyone brave enough to accept?
Yes, this is necessary to successfully build on Gentoo as well.
Thu, Jan 3
I can't comment whether this is the desired way to do it, but it does fix the build with exiv2 0.27, on openSUSE at least. (with D17872 in)
Without it, the compilation fails due to errors:
error: exception handling disabled, use -fexceptions to enable
Wed, Jan 2
Tue, Jan 1
Mon, Dec 31
I am inclined to accept this. It's a nice enhancement that seems to work fine in my testing, and while it doesn't strictly speaking follow the letter of the XDG spec, I don't think there's any sense letting the perfect being the enemy of the good here. We all know how that game would end: tons of wrangling in the FDO world and no official support for 512px thumbnails for years while we wait. I say let's do this now.
Intuitively this patch makes sense and is certainly "technically correct", but feedback we had in plasma with the wallpaper was that a fullscreen transition is quite a bit separate to the setting you'd use for small widget effects. 100ms for altering a few pixels of a shadow is a much slower in pixels per second than 100ms to slide something across the whole screen.
For now this should probably look at the setting in the Widget Style, but it would be nice to unify these at tome point to a single "Animation Speed" control that affects both apps and Plasma.
I know that KWin has its own animation setting, exposed in the Compositor KCM. Is that the one that sets the animation speed in the Plasma Integration plugin?
Sun, Dec 30
fix test build