https://bugs.kde.org/show_bug.cgi?id=453167
Paul McAuley <k...@paulmcauley.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |k...@paulmcauley.com
--- Comment #8 from Paul McAuley <k...@paulmcauley.com> ---
Created attachment 149642
--> https://bugs.kde.org/attachment.cgi?id=149642&action=edit
kirigami(?) apps with a fake pop-up window using the "window-close-symbolic"
icon. On mouse hover the "window-close" icon then appears.
(In reply to Eduardo Alvarado from comment #1)
> This would also affect the close icon in notifications.
The close icon in notifications uses "window-close", not
"window-close-symbolic".
I have been investigating this for my 3rd party icons, and the only
applications I have found so far which use "window-close-symbolic" are (I
think) kirigami-based ones which have a fake pop-up window. See the attached
screenshot. When you hover the close button with the mouse in these fake pop-up
windows, they then show the "window-close" icon.
(In reply to Nate Graham from comment #7)
> Indeed, `window-close-symbolic` is circled.
>
> If we change that to just be an uncircled X, I wonder if it could have any
> other consequences...
An uncircled X would need to be larger than the current icon to match the other
symbolic GTK CSD window icons. In the case of the kirigami(?) examples I
mentioned above this would cause problems with the mouse-over of "window-close"
being smaller. Either you could change the (also circled but red)
"window-close" icon to be larger as well to match, or get the kirigami(?) apps
to draw their own mouse-over highlight like GTK rather than using an icon.
Overall, I like that Adwaita GTK now uses the "symbolic" icons for windows and
I now use Adwaita GTK rather than Breeze GTK for that reason. It partially
solves the regression in Wayland in bug 437082, and allows third party icon
themes to now have at least some consistency.
--
You are receiving this mail because:
You are watching all bug changes.
