gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2023-07-09T16:10:07Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/2380Remove performance destroying wildcards2023-07-09T16:10:07ZMatthias ClasenRemove performance destroying wildcardsI spent a few days tracking down why every single style in widget-factory gets recreated when I move the mouse in or out of the window.
The answer is
```
*:disabled { }
*:link { }
```
These wildcards make it so that every widget think...I spent a few days tracking down why every single style in widget-factory gets recreated when I move the mouse in or out of the window.
The answer is
```
*:disabled { }
*:link { }
```
These wildcards make it so that every widget thinks it needs to rebuild its style when the state of a parent widget changes.
Removing just these two rules makes GTK do a lot less work on state changes.
I would suggest to replace '*' here with lists of names for the places we actually want to be affected by this.Jakub SteinerJakub Steinerhttps://gitlab.gnome.org/GNOME/gtk/-/issues/3145Listbox in rounded frame has first+last row focus indicator cut off2023-04-21T07:36:03ZTimm BäderListbox in rounded frame has first+last row focus indicator cut offFor obvious reasons, the keyboard focus indicator on listbox rows inside a `GtkFrame` now look silly when for the first and last row:
![Screenshot_from_2020-09-10_06-59-16](/uploads/38ea08f0e28b56ebc000b9708df201c8/Screenshot_from_2020-...For obvious reasons, the keyboard focus indicator on listbox rows inside a `GtkFrame` now look silly when for the first and last row:
![Screenshot_from_2020-09-10_06-59-16](/uploads/38ea08f0e28b56ebc000b9708df201c8/Screenshot_from_2020-09-10_06-59-16.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/3826Styling for inline toolbar is broken when a separator is used2023-03-25T14:27:49ZBugzillaStyling for inline toolbar is broken when a separator is used## Submitted by David Zeuthen
**[Link to original bug (#684325)](https://bugzilla.gnome.org/show_bug.cgi?id=684325)**
## Description
Screenshot says it all. See attached.
Version: 3.22.x## Submitted by David Zeuthen
**[Link to original bug (#684325)](https://bugzilla.gnome.org/show_bug.cgi?id=684325)**
## Description
Screenshot says it all. See attached.
Version: 3.22.xhttps://gitlab.gnome.org/GNOME/gtk/-/issues/2143Vertical inline toolbars styling of linked buttons is broken2022-09-23T16:46:34ZJeff FortinVertical inline toolbars styling of linked buttons is brokenReopened from https://bugzilla.gnome.org/show_bug.cgi?id=738474 and summarized (that one had a couple of comments):
As the screenshot below demonstrates, inline toolbars have an incorrect style when oriented vertically, particularly whe...Reopened from https://bugzilla.gnome.org/show_bug.cgi?id=738474 and summarized (that one had a couple of comments):
As the screenshot below demonstrates, inline toolbars have an incorrect style when oriented vertically, particularly when using linked buttons (you can also notice the problem in widget-factory if you add "inline-toolbar" to Style Classes for the vertical GtkToolbar on the 3rd page):
![pitivi_vertical_inline_toolbar_styling_bug](/uploads/255bc63aeeddfb413d189d2c18d9b9a5/pitivi_vertical_inline_toolbar_styling_bug.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/1586Adwaita: Add "selected but not focused" styles2021-11-02T07:49:05ZTimm BäderAdwaita: Add "selected but not focused" stylesSometimes it's confusing if multiple lists or treeviews contain a selected row, but only one of them will react to key navigation input.
One example of this is the filechooser. Starting a file chooser dialog shows a nicely highlighted b...Sometimes it's confusing if multiple lists or treeviews contain a selected row, but only one of them will react to key navigation input.
One example of this is the filechooser. Starting a file chooser dialog shows a nicely highlighted blue "Recent" row in the sidebar, but pressing e.g. the arrow down key will NOT change the selected row in the sidebar, but instead in the treeview.
It would be nice it if was clear where the keyboard input is going to go in such situations.https://gitlab.gnome.org/GNOME/gtk/-/issues/3509Reconsider style for GtkMessageDialog messages2021-10-03T11:33:29ZMichael CatanzaroReconsider style for GtkMessageDialog messagesGTK 4 message dialogs seem a little... overexuberant. As a reminder, message dialogs show (a) message text, and (b) secondary text. In GTK 4, Adwaita seems to think of the message text as if it is a title, but it's not a title: it's just...GTK 4 message dialogs seem a little... overexuberant. As a reminder, message dialogs show (a) message text, and (b) secondary text. In GTK 4, Adwaita seems to think of the message text as if it is a title, but it's not a title: it's just a message. The secondary text is optional.
Some example screenshots from GTK 4 Chess:
![Screenshot_from_2020-12-23_21-36-16](/uploads/9fb3cd18353a2455089220e29544c214/Screenshot_from_2020-12-23_21-36-16.png)
![Screenshot_from_2020-12-23_21-36-08](/uploads/3575e399a9680f7bfdac0770897a41fe/Screenshot_from_2020-12-23_21-36-08.png)
![Screenshot_from_2020-12-23_21-36-38](/uploads/0c75d343e9987f10e03eb91677ac6fcd/Screenshot_from_2020-12-23_21-36-38.png)
Seems a bit much, right? Almost like shouting at the user?
Here are equivalent screenshots from GTK 3 Chess, where Adwaita uses a much more traditional style for the message text:
![Screenshot_from_2020-12-23_21-40-30](/uploads/1694c3c1839ddaf2566acd8b4732595c/Screenshot_from_2020-12-23_21-40-30.png)
![Screenshot_from_2020-12-23_21-40-20](/uploads/eb82c5761c5bbe089605031279532f6d/Screenshot_from_2020-12-23_21-40-20.png)
![Screenshot_from_2020-12-23_21-40-53](/uploads/28e665df20a70a38a1a6b59f66b6856f/Screenshot_from_2020-12-23_21-40-53.png)
Note that in GTK 3, the message text is styled as a title only if there is secondary text, and the style is not nearly so aggressive.https://gitlab.gnome.org/GNOME/gtk/-/issues/2173Cannot have .circular and .suggested-action at the same time2021-09-06T14:34:48ZLuca Bacciluca.bacci@outlook.comCannot have .circular and .suggested-action at the same timeFrom this stackoverflow question: https://stackoverflow.com/questions/58154264/how-to-create-a-suggested-rounded-button-in-gtk-rs
I have tried to add the two style classes .circular and .suggested-action to a button using Glade. They wo...From this stackoverflow question: https://stackoverflow.com/questions/58154264/how-to-create-a-suggested-rounded-button-in-gtk-rs
I have tried to add the two style classes .circular and .suggested-action to a button using Glade. They work together only when the button is in the pressed state (:active), but not in the normal case when the button is unpressed.
Test UI xml: [button_circular_and_suggested_action.ui](/uploads/4132ef88b94f71a0f144c56d64d99390/button_circular_and_suggested_action.ui)
`gtk-builder-tool preview button_circular_and_suggested_action.ui`https://gitlab.gnome.org/GNOME/gtk/-/issues/3413GtkStackSidebar's first row has glitchy press state in widget factory2021-05-04T02:05:40ZAlice MikhaylenkoGtkStackSidebar's first row has glitchy press state in widget factory![Screenshot_from_2020-11-30_15-39-10](/uploads/c4d9426b0a5b3644f781daee11346d3c/Screenshot_from_2020-11-30_15-39-10.png)
This is a weird one, I wasn't able to reproduce it anywhere else. But in any case, it looks like a leftover of the...![Screenshot_from_2020-11-30_15-39-10](/uploads/c4d9426b0a5b3644f781daee11346d3c/Screenshot_from_2020-11-30_15-39-10.png)
This is a weird one, I wasn't able to reproduce it anywhere else. But in any case, it looks like a leftover of the old style.
@jimmachttps://gitlab.gnome.org/GNOME/gtk/-/issues/2096New checkboxes and radio buttons are used in menus in some states2021-04-19T13:29:18ZAlice MikhaylenkoNew checkboxes and radio buttons are used in menus in some states![checkbox](/uploads/ce7a0816e51e009a14a11df28840db66/checkbox.png)
New checkbox style is used when checkbox is checked and not hovered.
Additionally, the "normal" non-menu style seems used when non-checked checkbox is hovered.
Not pi...![checkbox](/uploads/ce7a0816e51e009a14a11df28840db66/checkbox.png)
New checkbox style is used when checkbox is checked and not hovered.
Additionally, the "normal" non-menu style seems used when non-checked checkbox is hovered.
Not pictured, but the same thing happens with radios.
@jimmachttps://gitlab.gnome.org/GNOME/gtk/-/issues/3476Round all window corners2021-04-05T19:29:27ZTobias BernardRound all window cornersOpening a new issue to track this after it was reverted because it triggered rendering bugs https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2921
When those issues are resolved we should un-revert that change and once again round all...Opening a new issue to track this after it was reverted because it triggered rendering bugs https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2921
When those issues are resolved we should un-revert that change and once again round all window corners.
cc @exalm @jimmachttps://gitlab.gnome.org/GNOME/gtk/-/issues/3082improve entry completion styling2021-04-03T01:00:56ZChristian Hergertimprove entry completion stylingRight now, the entry completion styling is fairly minimal to get things ported across to GTK 4. While working on other completion stuff for GtkSourceView, I took a quick look at how we might improve things a bit.
The tricky part still i...Right now, the entry completion styling is fairly minimal to get things ported across to GTK 4. While working on other completion stuff for GtkSourceView, I took a quick look at how we might improve things a bit.
The tricky part still is that we'd have to try to tweak the popover sizing in gtkentrycompletion.c to handle the margins (for shadows).
Curious on thoughts @aday @bertob @jimmac.
![Screenshot_from_2020-08-22_15-47-46](/uploads/28e3350ecc0ca9fc253f8e178f994130/Screenshot_from_2020-08-22_15-47-46.png)
This gets things looking a bit more like Firefox's completion bar which is one of the better examples I've seen.
```css
entry.has-completion {
border-bottom-left-radius: 0px;
border-bottom-right-radius: 0px;
border-bottom: none;
border-color: @theme_selected_bg_color;
outline: none;
box-shadow: 0 0 3px @borders;
}
entry popover.entry-completion contents {
border-top-left-radius: 0px;
border-top-right-radius: 0px;
border-bottom-right-radius: 9px;
border-bottom-left-radius: 9px;
border: 1px solid @theme_selected_bg_color;
border-top: none;
}
entry popover.entry-completion frame {
border: none;
}
```https://gitlab.gnome.org/GNOME/gtk/-/issues/2372Arrow button style class2021-04-03T01:00:27ZRicardo Silva VelosoArrow button style classA common pattern of a smaller linked button which opens a popover/menu. Having this in Adwaita will bring consistency.
![Captura_de_tela_de_2020-01-13_14-31-35](/uploads/172a480709e4babbe8ad6acf9ce33d16/Captura_de_tela_de_2020-01-13_14-...A common pattern of a smaller linked button which opens a popover/menu. Having this in Adwaita will bring consistency.
![Captura_de_tela_de_2020-01-13_14-31-35](/uploads/172a480709e4babbe8ad6acf9ce33d16/Captura_de_tela_de_2020-01-13_14-31-35.png)
Pattern found in:
* Nautilus (view mode)
* Builder (run button)
* Glade (open button, normal size)
* Gedit (open button, normal size)
* LibreOffice and others non-GTK apps
Similar to #1273.https://gitlab.gnome.org/GNOME/gtk/-/issues/3033Links in selected labels are barely visible2021-04-03T00:59:42ZMohammed SadiqLinks in selected labels are barely visibleLinks in selected labels are barely visible
![image](/uploads/813e0bc08ea0eb6ab3ef055620908e9d/image.png)
This is an issue in Gtk3 tooLinks in selected labels are barely visible
![image](/uploads/813e0bc08ea0eb6ab3ef055620908e9d/image.png)
This is an issue in Gtk3 toohttps://gitlab.gnome.org/GNOME/gtk/-/issues/1707vertical inline toolbars styling is broken2021-04-03T00:59:08ZAlexandru Băluțalexandru.balut@gmail.comvertical inline toolbars styling is brokenThis has been reported already at: https://bugzilla.gnome.org/show_bug.cgi?id=738474
![inline-314](/uploads/fc208bc588e7237287bb30bc55f39008/inline-314.png)
You can notice the problem also in widget-factory if you add "inline-toolbar" ...This has been reported already at: https://bugzilla.gnome.org/show_bug.cgi?id=738474
![inline-314](/uploads/fc208bc588e7237287bb30bc55f39008/inline-314.png)
You can notice the problem also in widget-factory if you add "inline-toolbar" to Style Classes for the vertical GtkToolbar on the 3rd page.https://gitlab.gnome.org/GNOME/gtk/-/issues/1606[Adwaita] Mouse-over/hover for non-focused windows2021-04-03T00:58:39ZGhost User[Adwaita] Mouse-over/hover for non-focused windowsCurrently Adwaita does not have any mouse-over / hover effect for most widgets that are in non-focused windows (ie. those that are not the current window). This gives the impression that any mouse-click would just raise the window, and n...Currently Adwaita does not have any mouse-over / hover effect for most widgets that are in non-focused windows (ie. those that are not the current window). This gives the impression that any mouse-click would just raise the window, and not active the widget under the mouse. However, this is not correct. If you click on a button in a non-focused window, the window is raised and the button is clicked.
Can Adwaita be updated to provide some feedback upon mouse-over / hover in this case? Even if it is very subtle. Alternatively, perhaps the click should not be passed on and the window only raised (made active)?https://gitlab.gnome.org/GNOME/gtk/-/issues/1611[Adwaita] No 'default' button indicator2021-04-03T00:58:08ZGhost User[Adwaita] No 'default' button indicatorWith dialogs, etc, there is no indication as to what is the 'default' button - i.e. the button that is activated with the return/enter key. At start there is a focus rect, but this can be 'tabbed' away.
In the following screenshot, whic...With dialogs, etc, there is no indication as to what is the 'default' button - i.e. the button that is activated with the return/enter key. At start there is a focus rect, but this can be 'tabbed' away.
In the following screenshot, which is the default button?
![Screenshot_from_2019-01-19_20-50-16](/uploads/c2200645a4d79c2d6b9ff08cf6e03f67/Screenshot_from_2019-01-19_20-50-16.png)
Steps to reproduce:
1. Start GEdit
2. Type some text
3. Close GEdit
4. Dialog appears - Save As... has focus
5. Press tab key
6. Save As... no longer has focus, so no focus/selection ring
7. Press Return
8. Save As... button is pressed, and save dialog appears
Most desktops (KDE, Windows, macOS) indicate the 'default' button somehow - different colour, border, etc. The default button can be different to the widget that currently has focus - as can be seen by the screenshot above, because one of those does receive the return/enter key.
Perhaps a bold font should be used to indicate the default?
This is basically the same issue as the Yaru theme had - see https://github.com/ubuntu/yaru/issues/306https://gitlab.gnome.org/GNOME/gtk/-/issues/2324Too much margin left of close button2021-04-03T00:57:37ZTobias BernardToo much margin left of close buttonThe spacing left of the close button looks a bit off, I think we should reduce it a bit.
We probably want it to be bigger than the margin on the right side to indicate that window controls are special. On the other hand, maybe we should...The spacing left of the close button looks a bit off, I think we should reduce it a bit.
We probably want it to be bigger than the margin on the right side to indicate that window controls are special. On the other hand, maybe we should re-evaluate whether that's even necessary since the close button is circular now (and doesn't have a border).
![Screenshot_from_2019-12-22_20-49-26](/uploads/66e725bbcecbba42307fdf7e14e94360/Screenshot_from_2019-12-22_20-49-26.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/2651HighContrast: on Caja the currently selected folder is no longer visible as s...2021-04-03T00:56:44ZAlex ARNAUDHighContrast: on Caja the currently selected folder is no longer visible as selectedHello,
Environment:
* Debian Testing with GTK 3.24.18
* Caja 1.24.0
I'm not sure this is a regression caused by #1450 or by a Caja change.
Steps to reproduce:
1. Open Caja (here in icon view, should be the default)
2. Look at the curr...Hello,
Environment:
* Debian Testing with GTK 3.24.18
* Caja 1.24.0
I'm not sure this is a regression caused by #1450 or by a Caja change.
Steps to reproduce:
1. Open Caja (here in icon view, should be the default)
2. Look at the current folder on the top (between the left and right arrows)
Result with Caja 1.20 / GTK 3.24.5:
![Caja_current_folderr_1.20_GTK_3.24.5](/uploads/61d72b2eee2b7dbb3496b0fe987f5b58/Caja_current_folderr_1.20_GTK_3.24.5.png)
Result with Caja 1.24 / GTK 3.24.18:
![Caja_current_folder_1.24_GTK_3.24.18](/uploads/58bfeb8f8cb9db0df5c0f51247dea531/Caja_current_folder_1.24_GTK_3.24.18.png)
Best regards.https://gitlab.gnome.org/GNOME/gtk/-/issues/3759Adwaita: stick to gradients for backdrop2021-04-03T00:55:18ZMatthias ClasenAdwaita: stick to gradients for backdropI noticed that we do a lot of pixel-level cross-fades between gradients and solid colors when switching to backdrop.
If we keep the gradients (and just give it the same color on both ends), we'll hit a much more efficient transition
pat...I noticed that we do a lot of pixel-level cross-fades between gradients and solid colors when switching to backdrop.
If we keep the gradients (and just give it the same color on both ends), we'll hit a much more efficient transition
path that will avoid any offscreen rendering.https://gitlab.gnome.org/GNOME/gtk/-/issues/406Styling for inline toolbar is broken when a separator is used2021-04-03T00:54:52ZBugzillaStyling for inline toolbar is broken when a separator is used## Submitted by David Zeuthen
**[Link to original bug (#684325)](https://bugzilla.gnome.org/show_bug.cgi?id=684325)**
## Description
Screenshot says it all. See attached.
Version: 3.22.x## Submitted by David Zeuthen
**[Link to original bug (#684325)](https://bugzilla.gnome.org/show_bug.cgi?id=684325)**
## Description
Screenshot says it all. See attached.
Version: 3.22.x