gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2023-11-22T15:35:21Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/6219Deprecate the search path for ~/.themes in GTK3/4, remove in GTK52023-11-22T15:35:21ZDallas StrouseDeprecate the search path for ~/.themes in GTK3/4, remove in GTK5`~/.themes` is a legacy path and should no longer be supported. It might be a problem to remove the search path in the middle of GTK4 (and backport patches to GTK2 and GTK3), so let's deprecate them and remove them when the time for GTK5...`~/.themes` is a legacy path and should no longer be supported. It might be a problem to remove the search path in the middle of GTK4 (and backport patches to GTK2 and GTK3), so let's deprecate them and remove them when the time for GTK5 comes.
Required to remove the search path for `~/.themes` in KDE: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3585#note_816672https://gitlab.gnome.org/GNOME/gtk/-/issues/6186HighContrastInverse theme uses faint blue for highlighting, which doesn't sta...2023-11-02T09:23:12ZnteodosioHighContrastInverse theme uses faint blue for highlighting, which doesn't stand out against the dark background<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
As `$HOME/.config/gtk-*.0/settings.ini`:
```
[Settings]
gtk-theme-name...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
As `$HOME/.config/gtk-*.0/settings.ini`:
```
[Settings]
gtk-theme-name=HighContrastInverse
```
Maybe `gsettings set org.gnome.desktop.interface gtk-theme HighContrastInverse` is the right way to do that, no idea, either way works here.
Now start any GTK application of your choice, e.g. `gnome-power-statistics`.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example
*written in C* that exhibits the issue.
-->
## Current behavior
Low contrast between selections (#0F3B71) and background (#2D2D2D).
As selection I mean for example the selected row in the tree, the selected tab, a selected string in a text field etc.
While we are at it, borders are also kinda faint for my liking for a high contrast theme, but that will be more debatable.
## Expected outcome
High contrast between selections and background. Make selections #0000FF?
## Version information
libgtk-3-0/mantic,now 3.24.38-5ubuntu1
libgtk-4-1/mantic,now 4.12.2+ds-1ubuntu1
Ubuntu 23.10
## Additional information
![disks](/uploads/3e0f12fb21ec054f0c799365eac63024/disks.png)
"ds" text selection is barely visible:
![disks2](/uploads/f245b9ecf87af2e1ffec83ea70c20960/disks2.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/6035Gtk3-demo does not Highlight the Item under the mouse cursor in Dark mode2023-09-17T14:06:04ZДилян Палаузовgit-dpa@aegee.orgGtk3-demo does not Highlight the Item under the mouse cursor in Dark modeIn Light desktop mode in gtk3-demo on the left pane the item below the mouse pointer is highlighted. In Dark desktop mode it is not highlighted. This is stated at https://gitlab.gnome.org/GNOME/evolution/-/issues/2473, after I wrote tha...In Light desktop mode in gtk3-demo on the left pane the item below the mouse pointer is highlighted. In Dark desktop mode it is not highlighted. This is stated at https://gitlab.gnome.org/GNOME/evolution/-/issues/2473, after I wrote that Evolution does not emphasize the items in tree view in Dark mode. The explanation in the mentioned ticket is that this distinction is probably done on purpose. On my computer gtk3-demo does not emphasize the item below the selected cursor in Light and Dark mode in gtk3-demo on the left pane.
* Please highlight in gtk3-demo the item under the mouse/touchpad cursor both in Dark and Light desktop modehttps://gitlab.gnome.org/GNOME/gtk/-/issues/6021ColumnView header has extra border2023-08-15T13:50:49ZLukas K.ColumnView header has extra border<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
Open the list view settings example from gtk4-demo and zoom in using t...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
Open the list view settings example from gtk4-demo and zoom in using the inspector
## Current behavior
![image](/uploads/a1df93cec1aebc13af2fc6d9c1d5e6b3/image.png)
The ColumnView headers have a border on the left edge (next to name).
## Expected outcome
There should be no border to avoid double borders.
## Version information
4.10.5 from Arch Linux repos, running on swayhttps://gitlab.gnome.org/GNOME/gtk/-/issues/5434Hide progress level in progress bar until it can form a circle2022-12-21T04:20:34ZKdwkHide progress level in progress bar until it can form a circle# Problem
Currently, progress bar with very low progress levels looks like this:
![Screenshot_from_2022-10-30_11-48-32](/uploads/e4de0d4e15ea221eb0f51e436ada0148/Screenshot_from_2022-10-30_11-48-32.png)
This isn't ideal because the pro...# Problem
Currently, progress bar with very low progress levels looks like this:
![Screenshot_from_2022-10-30_11-48-32](/uploads/e4de0d4e15ea221eb0f51e436ada0148/Screenshot_from_2022-10-30_11-48-32.png)
This isn't ideal because the progress bars lose the rounded corners.
# Proposal
Originally, I proposed to make the corners rounded anyway, but was told it is not feasible.
I wonder if it is possible to instead show the progress level as 0 below a certain threshold such that the progress level does not show until the rounded corners of the progress bar form a circle.https://gitlab.gnome.org/GNOME/gtk/-/issues/5212ugly green rectangles during dnd2022-09-27T14:16:06ZBenjamin Otteugly green rectangles during dndI get these ugly green rectangles in the middle of the widget during dnd:
![image](/uploads/539ae561012564ef4aceadfc9f6a6748/image.png)
That seems wrong?I get these ugly green rectangles in the middle of the widget during dnd:
![image](/uploads/539ae561012564ef4aceadfc9f6a6748/image.png)
That seems wrong?https://gitlab.gnome.org/GNOME/gtk/-/issues/5007clean up the icon theme situation2023-04-27T15:54:42ZMatthias Clasenclean up the icon theme situationIcon themes are no longer a thing, and our api should reflect the changed practices around icon use.
Goals for GTK5 could be:
1. Have an "image format" for icons
2. Have GtkImage/GtkPicture just treat icons like any other paintable
3. ...Icon themes are no longer a thing, and our api should reflect the changed practices around icon use.
Goals for GTK5 could be:
1. Have an "image format" for icons
2. Have GtkImage/GtkPicture just treat icons like any other paintable
3. Have a tool for app devs to create those images and include them as resources
4. Drop GtkIconThemehttps://gitlab.gnome.org/GNOME/gtk/-/issues/4919Buttons in PopoverMenu are background color2022-05-17T08:19:30ZJan WillemButtons in PopoverMenu are background color<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce t...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
bug
-->
1. The default (light) theme is used
2. You place a MenuButton inside a ListBox
3. Inside the PopoverMenu is a custom item which is a button
4. The button has the property has-frame=False
5. The button has an icon
6. You select the ListBoxRow where the MenuButton is located
7. Open the PopoverMenu and now the button appears to be invisble
Here is an application that demonstrates the issue:
[demo.py](/uploads/89889d437f4e4e211558f225cda0df2b/demo.py)
Sorry for not providing an example in C, I can't write it. But I hope some Python helps.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example
*written in C* that exhibits the issue.
-->
## Current behavior
When the popover is show the button has the color value which is equal to the background color. This means you cannot see the button. The buttons appears when you hover over it. This only happens when the button has the property has-frame=False and the MenuButton for the popover is placed in a ListBox.
<!--
Please describe the current behaviour
-->
## Expected outcome
The color of icon in the button is not dependent on whether has-frame is true or false.
<!--
Please describe the expected outcome
-->
## Version information
- Gtk 4.6.3
- Fedora 36
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
## Additional information
Note: no custom theme is used.
![Screenshot_from_2022-05-13_13-42-57](/uploads/df9cc16932eb88eb0ee2b282a9373ee6/Screenshot_from_2022-05-13_13-42-57.png)
Here the first ListBoxRow is selected and the first button is visible.
![Screenshot_from_2022-05-13_13-43-19](/uploads/eebcd9283a9cb0a7e97b6632ffaec351/Screenshot_from_2022-05-13_13-43-19.png)
Here the seccond ListBoxRow is selected and the first button is not visible due to the color being the same as the background.
I first raised the issue on https://discourse.gnome.org/t/button-only-visible-on-hover/9827 and Sebastian pointed out that https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/theme/Default/_common.scss#L621 could be related.https://gitlab.gnome.org/GNOME/gtk/-/issues/4816Rounded corners on inline-toolbar when it is not the last child2022-04-04T23:01:18ZPhilip ChimentoRounded corners on inline-toolbar when it is not the last childA GtkToolbar with the `.inline-toolbar` style class has rounded corners on the bottom, which look jarring when it is not the last-child of its container.
This issue occurs only with GTK 3 (`.inline-toolbar` does not exist in GTK 4).
##...A GtkToolbar with the `.inline-toolbar` style class has rounded corners on the bottom, which look jarring when it is not the last-child of its container.
This issue occurs only with GTK 3 (`.inline-toolbar` does not exist in GTK 4).
## Steps to reproduce
Code to illustrate the issue:
```c
#include <gtk/gtk.h>
int main(int argc, char** argv) {
gtk_init(&argc, &argv);
GtkWidget *tool = gtk_toolbar_new();
GtkStyleContext *style = gtk_widget_get_style_context(tool);
gtk_style_context_add_class(style, GTK_STYLE_CLASS_INLINE_TOOLBAR);
gtk_toolbar_insert(GTK_TOOLBAR(tool), gtk_tool_button_new(NULL, "The toolbar"), 0);
GtkWidget *box = gtk_box_new(GTK_ORIENTATION_VERTICAL, 6);
gtk_container_add(GTK_CONTAINER(box), gtk_label_new("The top label"));
gtk_container_add(GTK_CONTAINER(box), tool);
gtk_container_add(GTK_CONTAINER(box), gtk_label_new("The bottom label"));
GtkWidget *win = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_container_add(GTK_CONTAINER(win), box);
gtk_widget_show_all(win);
g_signal_connect(win, "destroy", gtk_main_quit, NULL);
gtk_main();
return 0;
}
```
## Current behavior
Here's a screenshot showing the rounded corners on the bottom of the toolbar:
![Screenshot_from_2022-04-04_15-55-58](/uploads/735eb1206b3cb3f6a5f24aeca0ab0f0f/Screenshot_from_2022-04-04_15-55-58.png)
## Expected outcome
When the toolbar is not the last child of its container, I'd expect it to look more like this:
![Screenshot_from_2022-04-04_15-56-29](/uploads/4dc115791b0756255ce6c6c62a65d2bc/Screenshot_from_2022-04-04_15-56-29.png)
## Version information
- GTK 3.24.31
- Fedora Linux 35.20220113.0 (Silverblue)
## Additional information
If a merge request for this would be welcome, I'd be happy to do it myself. I think I know how to fix it.https://gitlab.gnome.org/GNOME/gtk/-/issues/4473GtkScale needs better minimum sizes2021-12-01T16:18:15ZBenjamin OtteGtkScale needs better minimum sizesScreenshot is from gnome-control-center's sound panel (GTK3, but should apply to GTK4 as well):
![image](/uploads/657a9127406c583b82fb89f23643432b/image.png)
I don't think this is a suitable minimum size for any kind of scale.
This sh...Screenshot is from gnome-control-center's sound panel (GTK3, but should apply to GTK4 as well):
![image](/uploads/657a9127406c583b82fb89f23643432b/image.png)
I don't think this is a suitable minimum size for any kind of scale.
This should probably be fixed in the theme by setting a reasonable `min-width`/`min-height` respectively?https://gitlab.gnome.org/GNOME/gtk/-/issues/4238GtkPopoverMenu: Popovers with one item have odd spacing2022-01-10T05:18:02ZChristopher DavisGtkPopoverMenu: Popovers with one item have odd spacing<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
bug
-->
1. Use a popovermenu with only one item
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example
*written in C* that exhibits the issue.
-->
## Current behavior
<!--
Please describe the current behaviour
-->
When using popover menus with only one item, the popover seems to have additional space allocated where it doesn't need to.
This occurs on both the Default theme and Adwaita.
## Expected outcome
<!--
Please describe the expected outcome
-->
Popovers shouldn't have that extra space at the bottom.
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
Using GTK4 from the development branch, running from `org.gnome.Platform//master`
## Additional information
<!--
- Screenshots or screen recordings are useful for visual errors
- Attaching a screenshot or a video without explaining the current
behavior and the actions necessary to reproduce the bug will lead
to the bug being closed
- Please report any warning or message printed on the terminal
-->
![image](/uploads/447cb4ccbcfa76b72631750c70d24a9d/image.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/3935Add style class for "designer" on toplevels in Default theme2022-09-23T15:37:54ZChristian HergertAdd style class for "designer" on toplevels in Default themeFor designer work, we have a design requirement that is the rendering process in another container than the host UI process. That means we may be running a different variant of the active theme, or a completely different theme.
Trimming...For designer work, we have a design requirement that is the rendering process in another container than the host UI process. That means we may be running a different variant of the active theme, or a completely different theme.
Trimming off the shadow or getting snapshots with or without the shadow is rather cumbersome.
It would be nice if we could instead add a new CSS class on GtkNative objects inflated with GtkBuilder which would denote a "shadowless" variant of the toplevels (while still retaining box-shadow which are used for borders).
For example, just using `window.csd { box-shadow: none; margin: 0px; }` in as a custom CSS provider isn't suitable because we'd lose the border from the Default theme.
A quick proposal may be to simply add `gtk-designer` css class to toplevels and match on that in Default.css to not include the drop shadow variant.
https://gitlab.gnome.org/chergert/drafting already cooks the XML pretty heavily when sending it to the GtkBuilder in the copilot process, adding a new CSS style is rather trivial.https://gitlab.gnome.org/GNOME/gtk/-/issues/3612destructive-action button in infobar not styled2021-01-23T15:55:27ZKolja Lampedestructive-action button in infobar not styled<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
bug
-->
1. Settings
2. Users
3. Try to delete a fingerprint
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example
*written in C* that exhibits the issue.
-->
## Current behavior
<!--
Please describe the current behaviour
-->
![image](/uploads/482016ac8250024e472d7dcf4aa2f3c2/image.png)
`destructive-info` in an infobar using Adwaita doesn't get styled.
## Expected outcome
<!--
Please describe the expected outcome
-->
`destructive-info` in an infobar using Adwaita should get styled.
Or it shouldn't be used in those circumstances I guess?
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
Using Manjaro with Gnome 3.38.3
## Additional information
<!--
- Screenshots or screen recordings are useful for visual errors
- Attaching a screenshot or a video without explaining the current
behavior and the actions necessary to reproduce the bug will lead
to the bug being closed
- Please report any warning or message printed on the terminal
-->
![image](/uploads/dd845e9525e8ab1db046167266d4869a/image.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/3586Consider removing the gtk-theme-name setting2023-11-22T15:35:22ZMatthias ClasenConsider removing the gtk-theme-name settingWe want to leave theme selection to platform libraries.
We need a replacement api that those libraries can use to tell GTK about the stylesheet to load.We want to leave theme selection to platform libraries.
We need a replacement api that those libraries can use to tell GTK about the stylesheet to load.https://gitlab.gnome.org/GNOME/gtk/-/issues/3584Remove the prefer-dark setting2022-10-12T13:19:55ZMatthias ClasenRemove the prefer-dark settingWe are planning to move to a setup where theme selection is controlled by platform libraries such as libgranite and libadwaita, and we want to stop doing anything more than directly mapping from theme name to css file (or not even that, ...We are planning to move to a setup where theme selection is controlled by platform libraries such as libgranite and libadwaita, and we want to stop doing anything more than directly mapping from theme name to css file (or not even that, we'll see).https://gitlab.gnome.org/GNOME/gtk/-/issues/3510Accessibility concerns about hidden focus2021-04-03T11:01:03ZAlex ARNAUDAccessibility concerns about hidden focusHello,
Steps to reproduce:
1) Open gtk4-demo
Result with gtk4-demo:
Look at the theme applied on "GTK Demo" on the top of the left pane.
Result with gtk3-demo (expected behavior):
The theme is well applied on "GTK Demo"
Note:
On gtk4...Hello,
Steps to reproduce:
1) Open gtk4-demo
Result with gtk4-demo:
Look at the theme applied on "GTK Demo" on the top of the left pane.
Result with gtk3-demo (expected behavior):
The theme is well applied on "GTK Demo"
Note:
On gtk4-demo pressing down arrow then up arrow makes the theme working again.
Thanks in advance.https://gitlab.gnome.org/GNOME/gtk/-/issues/1185change active frame (column or pane2019-12-11T13:48:15ZWolfchange active frame (column or paneIt took years to find out that with F6 I can change the active column in most programmes.
Examples: In nautilus, I can switch between the left and the right column, in evolution (classical view) I can cycle through the three parts of the...It took years to find out that with F6 I can change the active column in most programmes.
Examples: In nautilus, I can switch between the left and the right column, in evolution (classical view) I can cycle through the three parts of the window - post boxes column left / message list top right / message body bottom right.
This is a good feature - by why is it activated by F6??? - This is really an unhandy key and not suitable for such a regularly used feature. And I cannot even change it (maybe someone else can and tell me how?). The TAB key (and Shift-TAB for the reverse direction) would be nice - such it's done in Mac OS.
And the other thing:
No highlighting is given for the active frame. MacOS does so, and it's really essential for efficient keyboard navigation. I still miss it after many years now on GNOME.
Cheers,
Wolfhttps://gitlab.gnome.org/GNOME/gtk/-/issues/1176Keyboard shortcut windows design updates2022-04-12T05:50:02ZAllan DayKeyboard shortcut windows design updatesThe keyboard shortcut windows haven't had much in the way of updates since they were first introduced, and there are some rough aspects which could be improved. These include:
- Paging feels awkward and is more work than scrolling
- It'...The keyboard shortcut windows haven't had much in the way of updates since they were first introduced, and there are some rough aspects which could be improved. These include:
- Paging feels awkward and is more work than scrolling
- It's hard to read the shortcuts, due to the text size of the shortcuts, all the spacing between each key, and the superfluous "+" characters
[These mockups](https://gitlab.gnome.org/Community/Design/os-mockups/raw/master/keyboard-shortcuts/keyboard-shortcuts.png) indicate how these issues could be resolved. Changes:
- Removes paging in favour of scrolling
- Removes the "+" characters
- Moves the keys after the shortcut labels
- Uses the standard text size for key labels
- Reduces the amount of padding around the key labels, particularly horizontal padding
@bertob and @jimmac might be able to advise further.https://gitlab.gnome.org/GNOME/gtk/-/issues/116gtk_widget_clear_path called too late, causing incorrect style after class re...2024-02-14T15:50:56ZDaniel Colascionegtk_widget_clear_path called too late, causing incorrect style after class removal## Steps to reproduce
1. Make a container that overrides get_path_for_child
2. Add a child
3. Define a class style that changes the widget's appearance
4. Set the class
5. Observe the widget appearance changes to reflect new behavior
6....## Steps to reproduce
1. Make a container that overrides get_path_for_child
2. Add a child
3. Define a class style that changes the widget's appearance
4. Set the class
5. Observe the widget appearance changes to reflect new behavior
6. Remove the class
## Current behavior
6a. Widget appearance does not change immediately; may change after style transition, inspector close, etc.
## Expected outcome
6b. Widget appearance changes immediately to reflect removal of CSS class
# Version information
3.22.24; code inspection indicates problem is still present in GTK4 master
# Additional information
Widgets cache their paths via the "gtk-widget-path" quark and this cached path isn't invalidated immediately when the CSS style changes. Instead, we forget this path only in response to the style-changed CSS node signal, which is sent only after lazy style recomputation. The first style recomputation after a style change uses the old path! The problem isn't apparent when adding _adding_ a style class: the CSS selector matching code checks for classes on both the widget node itself and on the path entry for the widget. But after we remove a CSSS class, the removed CSS class is still present on the old cached GtkWidgetPath, so the CSS selector matching gets a false-positive match and fails to update the visual appearance of the widget to reflect the removed style.https://gitlab.gnome.org/GNOME/gtk/-/issues/100Make CSD window shadows available on KDE2019-11-28T19:08:59ZPavilufMake CSD window shadows available on KDEHello,
On KDE (KWin) there is no shadows for CSD windows. KWin provides an API for CSD applications to add shadows.
So can it be possible to make CSD window shadows available on KDE please ?
https://bugs.kde.org/show_bug.cgi?id=391917
...Hello,
On KDE (KWin) there is no shadows for CSD windows. KWin provides an API for CSD applications to add shadows.
So can it be possible to make CSD window shadows available on KDE please ?
https://bugs.kde.org/show_bug.cgi?id=391917
Thanks !