GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-03-18T01:29:58Zhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3361When creating a new file from a template using the meatballs menu, the view i...2024-03-18T01:29:58ZJeff FortinWhen creating a new file from a template using the meatballs menu, the view is not focused, keyboard shortcuts cannot be usedWith version 46 / nightly:
1. Ensure you have some files in your `XDG_TEMPLATES_HOME` directory (i.e. `~/Templates`)
2. In any folder in listview, click the meatballs (…) menu in the location bar at the top
3. Click `New Document >` and...With version 46 / nightly:
1. Ensure you have some files in your `XDG_TEMPLATES_HOME` directory (i.e. `~/Templates`)
2. In any folder in listview, click the meatballs (…) menu in the location bar at the top
3. Click `New Document >` and select one of your template files
Result: the file gets created in the view, and is "apparently" selected in blue, but the view does not get the focus, so:
* You cannot rename directly with `F2` (but ideally it should prompt you directly to rename, #524)
* You cannot use the Up/Down arrow keys to navigate
* You cannot delete it directly with `Delete`, or `Ctrl+X` to cut it
* There is no clear way to get the focus there with the keyboard, without clicking
I wonder if this bug could also be an explanation for #2887 ?
However, this bug does not affect version 45.2.1, only version 46. It affects both the list view and the grid view.https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7472Accessibility: Locate pointer doesn't work when Reduce animations is turned on2024-03-11T05:34:29Z雪 女王Accessibility: Locate pointer doesn't work when Reduce animations is turned on<!--
Please read https://gitlab.gnome.org/GNOME/gnome-shell/-/tree/main#reporting-bugs
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and ...<!--
Please read https://gitlab.gnome.org/GNOME/gnome-shell/-/tree/main#reporting-bugs
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Shell version (see https://release.gnome.org/calendar/
for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
* Does this issue happen without extensions (please follow instructions below)
To properly disable extensions you can use gnome-extensions-app and then restart
your session. Disabling extensions without a restart is not sufficient to rule
out extensions as cause of a bug. If an issue can only be reproduced with a
certain extension, please file a bug report against that extension first.
-->
* Using latest ArchLinux
* On Gnome 45.4
* Using Wayland
* Extensions likely aren't to blame
### Bug summary
In the accessibility settings, when Reduce animations and Locate pointer are both enabled, Locate pointer will not work. Nothing happens when pressing the LCTRL key.
### Steps to reproduce
1. Enable "Reduce animations"
2. Enable "Locate pointer"
3. Press LCTRL
### What happened
Nothing
### What did you expect to happen
Something shows up to indicate the pointer's location.
### Note
I expect this to be because the locate pointer feature is an animation, and the reduced aniamtions settings makes that animation last 0 frames, as this is a common issue I encounter when using reduced motion accross many systems.
I think overriding the reduced animations on that feature so that the animation plays would be acceptable, though I can't speak for all users of that feature
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2950"Add a picture" does not check whether the selected picture(s) already are am...2024-03-10T23:37:33ZJeff Fortin"Add a picture" does not check whether the selected picture(s) already are among the wallpapers library, creates duplicates1. Add a couple of wallpapers to Settings' Appearance panel, with the "Add a picture" button
2. Click the "Add a picture" button again, and select one (or multiple) wallpaper(s), with some wallpapers that already have been added
Result:...1. Add a couple of wallpapers to Settings' Appearance panel, with the "Add a picture" button
2. Click the "Add a picture" button again, and select one (or multiple) wallpaper(s), with some wallpapers that already have been added
Result: duplicate entries are added to Settings' favorite wallpapers grid
Expected result:
* Do not add wallpapers that were already added
* If adding only one wallpaper, and that wallpaper would be a duplicate, select (apply) that wallpaper directly (as if the user had clicked it).https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1192When selecting a dates cells range from Sunday to Monday, quick-add popover o...2024-03-09T20:41:28ZJeff FortinWhen selecting a dates cells range from Sunday to Monday, quick-add popover only says "next Sunday" or "Tomorrow"As found by @theevilskeleton, in versions 45-46+, if you select both the upcoming Sunday and Monday, the label in the quick-add popover is incorrect.
Some examples:
| When testing some days prior | When tested on a Saturday (Sat is bl...As found by @theevilskeleton, in versions 45-46+, if you select both the upcoming Sunday and Monday, the label in the quick-add popover is incorrect.
Some examples:
| When testing some days prior | When tested on a Saturday (Sat is blue, but not actually selected) | When testing on a Monday |
| - | - | - |
| ![image](/uploads/5117dead4ea90388c85c8c382412f675/image.png) | ![image](/uploads/3796436fd498ed49916c30ac0db5a6fb/image.png) | ![foo](/uploads/04a49f6d19be4b4d0f73cb456fafadec/foo.jpg) |
This is most likely the same causes as #1066.
---
Hints:
* This bug is maybe not a regression from the infinite timeline month view branch, but probably emanates from the heuristic of "when is it the current week?" from the Week View that we now depend on since bug #1063.
* Will also have to take #160 into account once that lands (ideally, fix 160 first!)https://gitlab.gnome.org/GNOME/gimp/-/issues/11029Slider widget needs a complete revamp2024-03-28T02:15:37ZAlexandre ProkoudineSlider widget needs a complete revampCurrently, the slider/spinbox widget in 2.99 (any revision, tested on Ubuntu Linux) has multiple issues:
- [ ] Dragging or clicking to set a value automatically enables the numeric input mode which steals the focus. This is covered by #...Currently, the slider/spinbox widget in 2.99 (any revision, tested on Ubuntu Linux) has multiple issues:
- [ ] Dragging or clicking to set a value automatically enables the numeric input mode which steals the focus. This is covered by #9727.
- [ ] Once the numeric input mode is enabled, you cannot click and drag to correct the value if the position is behind the numeric input field, you have to click elsewhere, then drag the slider to a diferent position behind the numeric input field.
- [ ] Clicking on +/- buttons makes the numeric input field steal the focus again. This is covered by #9786.
- [ ] Plugins don't get the same functionality, e.g. you cannot reset a value of a specific parameter, only the entire state of the GEGL op behind it.
- [ ] In the worst case scenario, which is, like, most sliders for brush-based tools, you get to see a row of 4 (four!) buttons next to the slider: +/-/reset/weird-lock-with-a-tooltip-that-explains-nothing. You could learn from Blender here:
![image](/uploads/d3cc482c12ac27c86154644ed5db8347/image.png)
You get the same functionality (+/- increment, key modifiers with different increment steps for dragging, label inside the slider, numeric input via double-click, resetting via context menu, a locking button) _and_ much cleaner UI.
I'm sorry, but the current state of affairs is a disaster _and_ a regression from 2.10. I've seen @pixelmixer's attempt to address this by making the lock button optional, personally I do not think this is the way to go.3.0 RC1https://gitlab.gnome.org/GNOME/nautilus/-/issues/3360"Search Everywhere" button in remote locations takes me to local Tracker-back...2024-03-13T10:40:00ZJeff Fortin"Search Everywhere" button in remote locations takes me to local Tracker-backed search results, instead of offering temporary recursive searchWith the 46 / nightly version:
1. Make sure recursive search is disabled for remote locations in the preferences (default setting)
2. Open some `sftp://some_host/some_folder` location
3. Type-to-search something that is not present in t...With the 46 / nightly version:
1. Make sure recursive search is disabled for remote locations in the preferences (default setting)
2. Open some `sftp://some_host/some_folder` location
3. Type-to-search something that is not present in the directory you're looking at, but somewhere in its sub-directories
## Actual result
You are presented with this GUI:
![image](/uploads/e00eb87e7387a69fa2a258a05188ff65/image.png)
…but clicking "Search Everywhere" transforms your remote search query into a local Global Search query, which is a completely different context. Redirecting you to totally unrelated local search results is a bug, in my view.
## Expected result
I think it would make more sense to make the "Search Everywhere" button a "Search in Subfolders" button, with some sort of explanatory warning label above it that it might be slow.
Also as part of #3308 I would like the infobar to also allow temporarily recursive-searching a network location, even if there already are search results within the root folder.
What do you think @aday?https://gitlab.gnome.org/GNOME/seahorse/-/issues/380Change Passphrase button on SSH Key Properties page does nothing2024-03-11T09:14:13ZMichael CatanzaroChange Passphrase button on SSH Key Properties page does nothingUsing seahorse 43.0 from flathub, when I click the Change Passphrase button on the SSH key properties page, nothing happens. No command line warnings are printed.Using seahorse 43.0 from flathub, when I click the Change Passphrase button on the SSH key properties page, nothing happens. No command line warnings are printed.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3355Unable to undo action when deleting latest file of a folder2024-03-09T10:02:21ZAlessandro BonoUnable to undo action when deleting latest file of a folder# Affected Version
- Version: NautilusDevel
- Distribution: Flatpak
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Create a folder `test`
2. Enter inside ...# Affected Version
- Version: NautilusDevel
- Distribution: Flatpak
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Create a folder `test`
2. Enter inside folder `test`
3. Create a folder `test1` inside the folder `test`
4. Move to trash folder `test1`
5. Click the `Undo` button in the Toast
# Expected Behavior
The folder `test1` gets moved back from the trash.
# Actual Behavior
Nothing happens and the view keeps being empty.https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/306MS365 has wrong example line2024-03-26T16:42:04ZJan-Michael BrummerMS365 has wrong example lineLatest changes to UI added an example line, but this is wrong for MS365 as now URLs can be used at all. MS365 request a unique ID string.
CC: @adayLatest changes to UI added an example line, but this is wrong for MS365 as now URLs can be used at all. MS365 request a unique ID string.
CC: @adayhttps://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/102Papers constantly tries re-rendering while resizing the window, leading to 5-...2024-03-23T05:19:15ZJeff FortinPapers constantly tries re-rendering while resizing the window, leading to 5-10x longer render timesThis is like #98 and #100, combined, on steroids.
1. Open this [magical vector map](https://www.stm.info/sites/default/files/media/Stminfo/images/plan_reseau.pdf)* in Papers. Have a stopwatch and CPU usage monitor handy on the side
2. O...This is like #98 and #100, combined, on steroids.
1. Open this [magical vector map](https://www.stm.info/sites/default/files/media/Stminfo/images/plan_reseau.pdf)* in Papers. Have a stopwatch and CPU usage monitor handy on the side
2. Once Paper settles and finishes doing the initial rendering, slowly resize the window (whether to a big size filling the screen, or the other way around, to a small size)
3. Start the stopwatch and monitor your CPU usage
Result: as seen in [this demonstration video](https://youtu.be/SxW5zqxGQro)…
* Papers will take 35-40 seconds to render that map if you dragged-resized the window, instead of 13-17 seconds if you were to hit Ctrl+R (which is already slower than it should be, as per #98) without resizing involved
* Evince is not affected: once you release the drag (finish resizing the window), it _always_ takes exactly a maximum of 4 to 5 seconds to render that PDF, no matter the size and how often/slowly you resize the Evince window.
---
*: You can also test with the sample from [this poppler issue](https://gitlab.freedesktop.org/poppler/poppler/-/issues/1456), as both are extremely useful to make performance problems visible in Papers.https://gitlab.gnome.org/GNOME/gimp/-/issues/11021Text antialiasing is broken since color invasion (probably due to cairo)2024-03-09T15:12:36ZBruno LopesText antialiasing is broken since color invasion (probably due to cairo)### Environment/Versions
- GIMP version: 2.99.19 (d3e37fa) | 2.99.18
- Package: CI crossbuild | Flatpak
- Operating System: Windows 11 | Debian Bookworm
### Description of the bug
Since the latest changes regarding color invasion (?) ...### Environment/Versions
- GIMP version: 2.99.19 (d3e37fa) | 2.99.18
- Package: CI crossbuild | Flatpak
- Operating System: Windows 11 | Debian Bookworm
### Description of the bug
Since the latest changes regarding color invasion (?) the texts rendering became quite awful with a dark borderline.
![image](/uploads/bc21eb2e44d0450619e84a17016d9bc0/image.png)
![image](/uploads/4ec1854c6d981e9f70ff8fb95cefa8be/image.png)
This is "solved" disabling antialiasing but the text become rough.
### Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Create a image with a medium to light shade as background
2. Type some white text
…
Expected result: Alpha channel from antialiasing is kept
Actual result: Seems that alpha channel is gone so the antiliasing don't work weel
### Additional information
Nope.3.0 RC1https://gitlab.gnome.org/GNOME/nautilus/-/issues/3352The "Detailed" Date and Time doesn't follow Locale2024-03-17T21:00:26ZMattias BengtssonThe "Detailed" Date and Time doesn't follow Locale# Affected Version
- Version: GNOME nautilus 46.beta
- Distribution: Fedora Workstation 40 Prerelease
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Ch...# Affected Version
- Version: GNOME nautilus 46.beta
- Distribution: Fedora Workstation 40 Prerelease
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Choose "English (United States)" Language with "Sverige" Formats in GNOME Settings
![Screenshot_from_2024-03-07_19-00-50](/uploads/7a5aa1e0782b27dd83019af65a04a312/Screenshot_from_2024-03-07_19-00-50.png)
2. Choose "Detailed" Date and Time Format in Nautilus
3. Observe that the time format follows US Locale for date (but Swedish 24H format over US AM/PM).
# Expected Behavior
I would expect the date to be formatted using Swedish Locale (2024-03-07 19:03) instead of US Locale (03/07/2024 19:03).
# Actual Behavior
The time format follows US Locale for date (but Swedish 24H format over US AM/PM for the time portion :) ).
![Screenshot_from_2024-03-07_18-47-59](/uploads/1c72b41d0be9e3f1b954a88234317688/Screenshot_from_2024-03-07_18-47-59.png)
# Additional info
I haven't done anything in terms of setting the locale environment variables outside of GNOME. But just to make sure, this is the output of `locale`:
```
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=sv_SE.UTF-8
LC_TIME=sv_SE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=sv_SE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=sv_SE.UTF-8
LC_NAME="en_US.UTF-8"
LC_ADDRESS=sv_SE.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_MEASUREMENT=sv_SE.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
```https://gitlab.gnome.org/GNOME/gnome-builder/-/issues/2170Ellipsized runtime name in comborow in the project's configuration makes it i...2024-03-07T00:26:06ZJeff FortinEllipsized runtime name in comborow in the project's configuration makes it impossible to know what runtime I'm onHi there!
This label here is ellipsized, and combined with the fact that the related popover menu widget does not show a visual indicaiton of what is actually selected, makes it impossible for me to know / confirm that I am on the maste...Hi there!
This label here is ellipsized, and combined with the fact that the related popover menu widget does not show a visual indicaiton of what is actually selected, makes it impossible for me to know / confirm that I am on the master/nightly version of the SDK for any given project's configuration:
![Screenshot_from_2024-03-06_19-16-27](/uploads/ae7ffdc950312d9b18c5ff0085d4b6a8/Screenshot_from_2024-03-06_19-16-27.png)
I've been meaning to report this for a while; I'm currently running version 45.0, but I think I've experienced this problem on every version before.
My font scaling setting is set to 1.00, so it's presumably not "Large Text" accessibility causing this.https://gitlab.gnome.org/GNOME/gimp/-/issues/11014RTL: "Next" and "Previous" buttons in Tip of the day points towards each other2024-03-07T14:21:55ZAnders JonssonRTL: "Next" and "Previous" buttons in Tip of the day points towards each other<!-- ⚠️ IMPORTANT: READ ME! ⚠️
This is the default template for bug reports.
For feature requests or performance issues, please switch instead to the appropriate template in the "Choose a template" list.
It is important that you fill al...<!-- ⚠️ IMPORTANT: READ ME! ⚠️
This is the default template for bug reports.
For feature requests or performance issues, please switch instead to the appropriate template in the "Choose a template" list.
It is important that you fill all the fields of the template.
-->
### Environment/Versions
- GIMP version: GIMP_2_99_18-119-ga905208873
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Flatpak and compiled from source
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Linux
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
Found when trying to reproduce #11007.
Opening Tip of the day in an RTL language gives the `Next` and `Previous` buttons in swapped order which is to be expected. However, since the arrows haven't changed direction, they now point at each other. Common use seems to be mirroring arrows for right-to-left languages.
![GIMP-tips_arabic-arrows](/uploads/32f79c97b4fc3ede740aed1d112cac62/GIMP-tips_arabic-arrows.png)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. Open tip of the day with an RTL locale. I tested LANG=ar_SA.utf8
Expected result: Next and Previous buttons to not point at each other.
Actual result: Buttons are pointing at each other.https://gitlab.gnome.org/GNOME/gimp/-/issues/11007Tip of the day: Next and Previous tips buttons seem swapped2024-03-09T17:15:18ZSabri ÜnalTip of the day: Next and Previous tips buttons seem swapped### Environment/Versions
- GIMP version: 2.99.19 / commit 9750c77
- Package: flatpak from gnome-nightly
- Operating System: Penguin
### Description of the bug
Next and Previous tips button seem replaced amid no code change for 16 year...### Environment/Versions
- GIMP version: 2.99.19 / commit 9750c77
- Package: flatpak from gnome-nightly
- Operating System: Penguin
### Description of the bug
Next and Previous tips button seem replaced amid no code change for 16 years!
![Ekran_Görüntüsü_-_2024-03-06_07-01-30](/uploads/222e56e0162d7f10b0f8df02d524f5b0/Ekran_Görüntüsü_-_2024-03-06_07-01-30.png)
### Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Open Tips of the day dialog
…
Expected result: Previous tip > Next Tip
Actual result: Next Tip > Previous Tiphttps://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/94When searchbar's searchentry has an existing query but is deselected, Ctrl+F ...2024-03-07T05:08:24ZJeff FortinWhen searchbar's searchentry has an existing query but is deselected, Ctrl+F should refocus and select-all instead of clearing the search1. `Ctrl+F`
2. Type something
3. Click somewhere in the document; the search query (and its results highlights) remains active. This is correct.
4. `Ctrl+F` again to refocus the searchentry
Result: search entry contents get cleared, sea...1. `Ctrl+F`
2. Type something
3. Click somewhere in the document; the search query (and its results highlights) remains active. This is correct.
4. `Ctrl+F` again to refocus the searchentry
Result: search entry contents get cleared, search query gets lost/reset.
This should not be done because:
* You are throwing away user data that the user has spent time constructing (the search query)
* The user was expecting to be able to replace or edit the search query, just like in other apps (web browsers, file managers, etc.; barring bugs like #86)
* You are throwing away the significant amount of CPU work that was done to search through the document, and are forcing the search to happen from scratch again, so it's a performance issue.
This is the same UX & performance design philosophy as https://gitlab.gnome.org/GNOME/nautilus/-/issues/2819https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/90Document's Ctrl+Left / Ctrl+Right (rotation) keyboard shortcuts interfere wit...2024-03-26T19:58:27ZJeff FortinDocument's Ctrl+Left / Ctrl+Right (rotation) keyboard shortcuts interfere with SearchBar's standard text cursor shortcuts to move to the previous/next wordIn editable text entry fields, like the SearchEntry, `Ctrl+Left` and `Ctrl+Right` are standard shortcuts for being able to move the text cursor between words within the entry widget. However, Papers currently lets the same shortcuts from...In editable text entry fields, like the SearchEntry, `Ctrl+Left` and `Ctrl+Right` are standard shortcuts for being able to move the text cursor between words within the entry widget. However, Papers currently lets the same shortcuts from the document canvas (to rotate counterclockwise/clockwise) interfere with that, so instead of moving the text cursor within the SearchEntry, the document unexpectedly gets rotated and the cursor does not move.https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/84Document's `Ctrl+A` Select All shortcut interferes with searchbar's searchent...2024-03-26T19:58:27ZJeff FortinDocument's `Ctrl+A` Select All shortcut interferes with searchbar's searchentry widget1. `Ctrl+F`
2. Type some gibberish
3. Change your mind, hit `Ctrl+A` to select all the contents of the searchbar to replace them
Result: instead of selecting all text in the search entry, all the text in the document is selected / highl...1. `Ctrl+F`
2. Type some gibberish
3. Change your mind, hit `Ctrl+A` to select all the contents of the searchbar to replace them
Result: instead of selecting all text in the search entry, all the text in the document is selected / highlighted in blue.https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/83Page Up / Page Down shortcut skips pages2024-03-05T17:55:31ZJeff FortinPage Up / Page Down shortcut skips pagesTesting with the nightly flatpak version, pressing `PgUp` / `PgDown` on the keyboard, even after clicking/selecting something in the main contents view (to be sure the sidebar thumbnails are not the thing that have focus), PgUp/Down skip...Testing with the nightly flatpak version, pressing `PgUp` / `PgDown` on the keyboard, even after clicking/selecting something in the main contents view (to be sure the sidebar thumbnails are not the thing that have focus), PgUp/Down skips pages (especially the ones in the "middle" of the sidebar) instead of always going up/down 1 page at a time.
Demonstration video:
![Screencast_from_2024-03-05_00-03-40](/uploads/973193c9fe7eb7c65354cc3d57dd7aab/Screencast_from_2024-03-05_00-03-40.webm){width=75%}https://gitlab.gnome.org/GNOME/nautilus/-/issues/3348Trash: when auto empty trash is enabled, Nautilus can't open the trash settin...2024-03-25T10:56:00ZAutomeris naranjaTrash: when auto empty trash is enabled, Nautilus can't open the trash settings section of GNOME Settings## Affected version
- nautilus-45.2.1-1.fc39.x86_64 (can't test nightly flatpak because of https://gitlab.gnome.org/GNOME/nautilus/-/issues/3343)
## Steps to reproduce
1. Go to GNOME Settings > Privacy > File History & Trash
2. Enable "...## Affected version
- nautilus-45.2.1-1.fc39.x86_64 (can't test nightly flatpak because of https://gitlab.gnome.org/GNOME/nautilus/-/issues/3343)
## Steps to reproduce
1. Go to GNOME Settings > Privacy > File History & Trash
2. Enable "Automatically Delete Trash Content"
3. Open Nautilus and go to the Trash view
4. Click in the "Settings" button from the "Items in trash older than..." banner
## Seen behavior
The File History & Trash section of Settings won't appear.
This is broken since GNOME 45, which introduced the new Privacy panel (https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1819) with subpages. In GNOME 46, https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2038 / https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2288 added the possibility to open panel subpages, but ~~it seems that only the System panel is currently supported~~ the Privacy panel is yet to be supported.