After bug 1964022, titlebar buttons with adwaita look a bit off.
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox140 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
(Blocks 2 open bugs, Regressed 1 open bug)
Details
Attachments
(5 external files)
Since they still use the old GTK3 buttons.
I think the ideal thing to do would be to render the buttons on our own, but using the right icon theme and foreground color. That would even allow us to get rid of the "non-native" titlebar buttons too.
What we want is really using the window-{maximize,minimize,restore,close}-symbolic icons. moz-icon:// exposes them but only with 1x resolution. I hacked nsIconChannel to allow sending icons with 2x scale (so that they look crisp on HiDPI), but even with that there's another issue, which is that those icons should change with the color scheme of the window (kinda like context-properties).
So for the scale I can hack around it, either by hardcoding a bigger scale, or passing it in the query string and using image-set() in the front-end. But I'm guessing the foreground color bit is not that easy to hack around (at least I haven't found an easy way).
I'm assuming that if I were to make that work, I'd need some new vector-like image type (so that we can decode-per-color or so)? Or can you think of another way of making something like that work?
| Assignee | ||
Comment 1•1 year ago
|
||
This doesn't quite work because on color scheme changes they stay
frozen.
| Assignee | ||
Comment 2•1 year ago
|
||
^ is what I was trying fwiw.
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year ago
|
||
Using this for the action icon and such is harder.
| Assignee | ||
Comment 4•1 year ago
|
||
This looks better on the native theme, and on the built-in themes too.
It's a mixed improvement and regression for non-native themes:
- On one hand, we use the system icons.
- On the other, we don't use the theme fill (which usually would be
used via context-fill / context-stroke).
So over-all I think it's worth it.
| Assignee | ||
Comment 5•1 year ago
|
||
| Assignee | ||
Comment 6•1 year ago
|
||
As we don't really need them. This avoids non-webrender drawing on the
main window altogether.
Updated•1 year ago
|
| Assignee | ||
Comment 7•1 year ago
|
||
Comment 8•1 year ago
|
||
Nice to see the icon decoder gets updated, very much needed. I see that detecting text direction from file endings (ltr/rtl) is gone. Maybe it's just old school scheme and not needed anymore? And this is more of a feature request, would it not be possible to get rid of gtkiconsize as it's completely different in gtk4? If it's hardcoded upstreams in gtk3 you might as well hardcode it yourself? And get rid of gtk_icon_size_lookup in the process. But this is a huge rework that gets rid of basically everything that is already deprecated in gtk3, good work!!
| Assignee | ||
Updated•1 year ago
|
Comment 10•1 year ago
|
||
Comment 11•1 year ago
|
||
| Assignee | ||
Comment 12•1 year ago
|
||
(In reply to Jens Persson from comment #8)
Nice to see the icon decoder gets updated, very much needed. I see that detecting text direction from file endings (ltr/rtl) is gone. Maybe it's just old school scheme and not needed anymore?
Yeah we don't use any icon names ending in ltr/rtl afaict.
And this is more of a feature request, would it not be possible to get rid of gtkiconsize as it's completely different in gtk4? If it's hardcoded upstreams in gtk3 you might as well hardcode it yourself? And get rid of gtk_icon_size_lookup in the process. But this is a huge rework that gets rid of basically everything that is already deprecated in gtk3, good work!!
Let's do that in bug 1965779.
Comment 13•1 year ago
|
||
| bugherder | ||
| Assignee | ||
Updated•1 year ago
|
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
Comment 16•1 year ago
|
||
| bugherder | ||
Comment 17•1 year ago
|
||
| bugherder | ||
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Description
•