GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2023-08-16T21:57:14Zhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/25Wrong labels in settings dialog2023-08-16T21:57:14ZCédric BellegardeWrong labels in settings dialogSince GNOME 3.26, sections label are not bold (as in any other GNOME apps).
This make setting dialog hard to read...
Example:
nautilus 3.26:
![nautilus](/uploads/2db6ddfca12fdd2399ee8fb5e38743ab/nautilus.png)
gedit 3.26:
![gedit](/uplo...Since GNOME 3.26, sections label are not bold (as in any other GNOME apps).
This make setting dialog hard to read...
Example:
nautilus 3.26:
![nautilus](/uploads/2db6ddfca12fdd2399ee8fb5e38743ab/nautilus.png)
gedit 3.26:
![gedit](/uploads/02d69ba3b3a70ede3969a33177f91938/gedit.png)3.26.1https://gitlab.gnome.org/GNOME/gnome-music/-/issues/132Console spam on startup related to Spotify API calls2018-01-12T11:02:41ZRobert MunteanuConsole spam on startup related to Spotify API callsWhen starting up gnome music I get many such messages in the console:
```
(gnome-music:15295): Grilo-WARNING **: [lua-library] grl-lua-library.c:508: Can't fetch element 1 (URL: https://api.spotify.com/v1/search?q=album:Kings%20Of%20Met...When starting up gnome music I get many such messages in the console:
```
(gnome-music:15295): Grilo-WARNING **: [lua-library] grl-lua-library.c:508: Can't fetch element 1 (URL: https://api.spotify.com/v1/search?q=album:Kings%20Of%20Metal+artist:Manowar&type=album&limit=1): 'Authentication required: Unauthorized'
```
Running on openSUSE Tumbleweed x86_64
* python3-3.6.4-1.1.x86_64
* gnome-shell-3.26.2-1.2.x86_64
* gnome-music-3.26.1-1.2.x86_64
* grilo-plugins-0.3.5-3.1.x86_643.26.2Marinus Schraalmschraal@gnome.orgMarinus Schraalmschraal@gnome.orghttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/228Add a --quit commandline argument2018-01-11T02:33:27ZMohammed SadiqAdd a --quit commandline argumentClicking the close button in gnome-calendar don't always close all the instances of the application. It would be nice if a `--quit` command line argument is added that would actually close the application if open.
This is implemented i...Clicking the close button in gnome-calendar don't always close all the instances of the application. It would be nice if a `--quit` command line argument is added that would actually close the application if open.
This is implemented in applications like `gnome-todo`, `nautilus`, etc.
## How to reproduce
1. Open gnome-shell search
2. Type in "Calendar"
3. Open gnome-calendar
4. Close it using close button
The window is closed, but an instance of gnome-calendar is still running as a gapplication-service, which I think was run by gnome-shell search provider.
## Development Tasks
* [x] Add `--quit` commandline argument that quits the running instance of the application
## QA Tasks
* [x] `--quit` quits the running application3.27.3Akbar HashmiAkbar Hashmihttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/221Add <Ctrl>+f shortcut to toggle search bar2023-07-25T00:52:38ZGeorge Willian CondomittiAdd <Ctrl>+f shortcut to toggle search barAlthough search bar is shown as user starts typing it seems to make sense to also have Ctrl+f shortcut as it's the default behaviour for searching on most GNOME apps.
## Development Tasks
* [x] Implement the `<Ctrl>F` action
## QA Ta...Although search bar is shown as user starts typing it seems to make sense to also have Ctrl+f shortcut as it's the default behaviour for searching on most GNOME apps.
## Development Tasks
* [x] Implement the `<Ctrl>F` action
## QA Tasks
* [x] Pressing `<Ctrl>F` toggles the search bar
* [x] No regressions were introduced3.27.3George Willian CondomittiGeorge Willian Condomittihttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/41stack_visible_child_name_changed assumes all calendar sources are HTTPS and u...2019-12-30T13:10:54ZGeorges Basile Stavracas Netostack_visible_child_name_changed assumes all calendar sources are HTTPS and use standard portsThe URI is constructed with no regard for port numbers nor protocol. For example, a server on port 8080 will have a broken link. A server on http will be incorrectly displayed as https. Should query the calendar source to see what securi...The URI is constructed with no regard for port numbers nor protocol. For example, a server on port 8080 will have a broken link. A server on http will be incorrectly displayed as https. Should query the calendar source to see what security method is specified ("none" or "tls").
**[Link to original bug (#762692)](https://bugzilla.gnome.org/show_bug.cgi?id=762692)**
## Development Tasks
* [x] Use `libsoup` to handle URLs
## QA Tasks
* [ ] URLs have the proper ports
* [ ] No regressions were introduced3.27.3Günther WagnerGünther Wagnerhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/230Month popover is always on top2023-02-11T04:08:24Zalex285Month popover is always on topReproduce Always
1. Open Calendar on Month View
2. Add some events on the same day to trigger the popover
3. Press "New Event"
Outcome: The "Event" Widget opens behind the Month Popover as you can see from the screenshot. The focus is ...Reproduce Always
1. Open Calendar on Month View
2. Add some events on the same day to trigger the popover
3. Press "New Event"
Outcome: The "Event" Widget opens behind the Month Popover as you can see from the screenshot. The focus is on Event Widget, and we cannot close the popover
![calendar-bug](/uploads/bba45977f51957ec35931023a7125dbb/calendar-bug.png)
actually all windows open bellow that popover, it is like a floating. Tested on Xorg, perhaps it works as it should on Wayland, but i cant try it now3.27.3Georges Basile Stavracas NetoGeorges Basile Stavracas Netohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/227add a topWindow class with the app's reversed domain name2017-12-12T07:56:52Zalex285add a topWindow class with the app's reversed domain namethis is a small style addition after some discussion i had with @feaneron and @chergert
each GTK app could use the reversed domain name (as in Flathub) to add a unique topWindow class, so a theme can extend some styles per app if that ...this is a small style addition after some discussion i had with @feaneron and @chergert
each GTK app could use the reversed domain name (as in Flathub) to add a unique topWindow class, so a theme can extend some styles per app if that is necessary, without need to upstream the changes on the projects. besides not all projects accept upstream 3rd party styles
aside the above, this also can help to remove the complexity of themes in general, including Adwaita that tries to address many widgets hierarchies, and make possible to write a proper structured Sass ..someday!
some examples
```
Calendar: "org-gnome-Calendar"
Todo: "org-gnome-Todo"
Builder: "org-gnome-Builder"
Tilix: "com-gexperts-Tilix"
```
Note that the className can be either capitalized or not, depending the name is used in Flathub
![calendar-class](/uploads/23da6410fb6da0337bbff4ff79f85aa2/calendar-class.png)
i will submit patches in a little bit
## Development Tasks
* [x] Add the `org-gnome-Calendar` CSS class to the main window
## QA Tasks
* [x] Main window has the `org-gnome-Calendar` CSS class in the GTK Inspector
* [x] No regressions were introduced3.27.3alex285alex285https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/211Month view is hard to read2018-04-10T00:38:26ZGeorges Basile Stavracas NetoMonth view is hard to readCreated attachment 362894
mockup
I currently find the month view quite difficult to read. It feels like a real effort to interpret the information that's being displayed - it takes work to scan the events and it's difficult to different...Created attachment 362894
mockup
I currently find the month view quite difficult to read. It feels like a real effort to interpret the information that's being displayed - it takes work to scan the events and it's difficult to differentiate between different types of event.
I think there are various reasons for this:
* The default calendar colours are hard to differentiate from one another.
* For me the date is in the wrong position - when I read a calendar I expect the date to come first, as that frames the rest of the information in each tile.
* Within each event, the name of each event doesn't always come first, which makes it hard to quickly read down the list and identify each one. This kind of inconsistency creates additional cognitive overhead.
* The brackets around the times are additional visual noise which you have to process out.
* Everything is very squashed.
I'm attaching a proposal which, to my eyes, makes the tiles much easier to read. It includes the following changes:
* Move the date to the top left of the tile and make it bigger.
* Change the default colours to be brighter and easier to differentiate.
* Increase the height of each event.
* Move the times to the right, so the event name is always the first bit of text.
**Attachment 362894**, "mockup":
![month-tile](/uploads/476957c3a0cf4b8d340e0bf7c8edd3b4/month-tile.png)
**[Link to original bug (#789855)](https://bugzilla.gnome.org/show_bug.cgi?id=789855)**
## Design Tasks
* [x] Define a new layout for the Month view
* [x] Update the visual of events
## Development Tasks
* [x] Implement the new Month view layout
* [x] Implement the new event visual
## QA Tasks
* [x] [Month view] Day numbers are at top of the cell
* [x] [Month view] Overflow label is in the bottom position
* [x] [Month view] Overflow button is hidden until overflow happens
* [x] [Month view] Single day, timed events have a 16px colored rounded rectangle
* [ ] [Month view] Multiday or all day events maintained the previous block layout
* [ ] [Week view] Single day timed events look like a block with a vertical layout
* [ ] No regressions were introduced3.27.3Georges Basile Stavracas NetoGeorges Basile Stavracas Netohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/168Events created in month or year view are created with incorrect time and miss...2023-02-06T22:00:45ZGeorges Basile Stavracas NetoEvents created in month or year view are created with incorrect time and missing timezoneThis is a regression introduced in the upgrade from Fedora 25 to Fedora 26. All events I create in Calendar are now displayed with a start time five hours later in GNOME Shell. For example, if I create an event in Calendar for 7:30 AM, t...This is a regression introduced in the upgrade from Fedora 25 to Fedora 26. All events I create in Calendar are now displayed with a start time five hours later in GNOME Shell. For example, if I create an event in Calendar for 7:30 AM, the event start time displayed in GNOME Shell is 12:30 PM. That's a five hour difference. My timezone is UTC -5, so surely the problem is related to timezone.
* GNOME Calendar 3.24.3
* GNOME Shell 3.24.2
* evolution-data-server 3.24.3
Let me know if there's anything useful I can provide as it's 100% reproducible for me... I'm surprised it doesn't happen for everyone.
**[Link to original bug (#785094)](https://bugzilla.gnome.org/show_bug.cgi?id=785094)**
## Development Tasks
* [x] Investigate why events created in Month and Year views have the wrong timezone
## QA Tasks
* [x] Create an event from Month view, the event has a timezone
* [x] Create an event from Year view, the event has a timezone
* [x] No regressions were introduced3.27.3Michael CatanzaroMichael Catanzarohttps://gitlab.gnome.org/GNOME/nautilus/-/issues/252libnautilus-extensions API broken without warning2018-02-13T05:37:21ZBastien Noceralibnautilus-extensions API broken without warningCommit 7e2605c681d065e6b0a3d779c30b892932597991 made changes that broke a number of modules. For example, nautilus-ideviceinfo:
```
In file included from /home/hadess/Projects/jhbuild/nautilus-ideviceinfo/src/nautilus-ideviceinfo.c:33:0:...Commit 7e2605c681d065e6b0a3d779c30b892932597991 made changes that broke a number of modules. For example, nautilus-ideviceinfo:
```
In file included from /home/hadess/Projects/jhbuild/nautilus-ideviceinfo/src/nautilus-ideviceinfo.c:33:0:
/home/hadess/Projects/gnome-install/include/nautilus/libnautilus-extension/nautilus-property-page-provider.h:34:2: warning: #warning "Only <nautilus-extension.h> should be included directly." [-Wcpp]
#warning "Only <nautilus-extension.h> should be included directly."
^~~~~~~
In file included from /home/hadess/Projects/jhbuild/nautilus-ideviceinfo/src/nautilus-ideviceinfo.c:34:0:
/home/hadess/Projects/gnome-install/include/nautilus/libnautilus-extension/nautilus-location-widget-provider.h:35:2: warning: #warning "Only <nautilus-extension.h> should be included directly." [-Wcpp]
#warning "Only <nautilus-extension.h> should be included directly."
^~~~~~~
/home/hadess/Projects/jhbuild/nautilus-ideviceinfo/src/nautilus-ideviceinfo.c:46:8: error: unknown type name ‘NautilusPropertyPage’
static NautilusPropertyPage *ideviceinfo_property_page_new(NautilusPropertyPageProvider *provider, const char *uuid, const char *mount_path)
^~~~~~~~~~~~~~~~~~~~
/home/hadess/Projects/jhbuild/nautilus-ideviceinfo/src/nautilus-ideviceinfo.c: In function ‘ideviceinfo_property_page_new’:
/home/hadess/Projects/jhbuild/nautilus-ideviceinfo/src/nautilus-ideviceinfo.c:48:2: error: unknown type name ‘NautilusPropertyPage’; did you mean ‘NautilusPropertyPageProvider’?
NautilusPropertyPage *ret;
^~~~~~~~~~~~~~~~~~~~
NautilusPropertyPageProvider
```
nautilus-property-page-provider.h added a guard warning, but removed existing includes, meaning those warnings were really transformed into errors:
https://gitlab.gnome.org/GNOME/nautilus/commit/7e2605c681d065e6b0a3d779c30b892932597991#83edc341335872e0f8dcb82ce581a7d55c049f52
The existing/legacy includes should have been left inside the guard to not break existing extensions.
See also recent commits to gnome-user-share.3.27.90https://gitlab.gnome.org/GNOME/gnome-music/-/issues/142Clicking on cancel button from selection bar crashes gnome music2018-02-23T23:06:35ZJean FelderClicking on cancel button from selection bar crashes gnome musicSteps to reproduce:
1. from any view (except playlistsview) select multiple items
2. click on "Cancel" button
3. gnome music crashes with the following message:
> line 163, in _on_cancel_button_clicked
> self._view.set_selection_mode...Steps to reproduce:
1. from any view (except playlistsview) select multiple items
2. click on "Cancel" button
3. gnome music crashes with the following message:
> line 163, in _on_cancel_button_clicked
> self._view.set_selection_mode(False)
> AttributeError: 'TreeView' object has no attribute 'set_selection_mode'
This comes from `playlistsview`: `self._view` from `playlistsview` is now a `TreeView`. This object does not have a `set_selection_mode` method.3.27.90https://gitlab.gnome.org/GNOME/gnome-tweaks/-/issues/117Reword Touchpad Click Method section2018-03-26T14:35:54ZJeremy BichaReword Touchpad Click Method sectionExplanation
-----------
In GNOME 3.27.90, the GNOME [default](https://git.gnome.org/browse/gsettings-desktop-schemas/commit/?id=77ff1d9) mouse click emulation on touchpads will change from 'default' to 'fingers'. 'default' apparently dep...Explanation
-----------
In GNOME 3.27.90, the GNOME [default](https://git.gnome.org/browse/gsettings-desktop-schemas/commit/?id=77ff1d9) mouse click emulation on touchpads will change from 'default' to 'fingers'. 'default' apparently depends on a hard-coded list of hardware to try to do 'fingers' on Mac hardware and 'areas' on Windows hardware (?).
This setting was already in Tweaks (see the first screenshot below) but isn't explained very well so I am using this bug to propose an improvement (the next two screenshots). The setting is at the bottom of the _Keyboard & Mouse_ page.
In my proposed patch, there is no check mark if 'default' is set since it's harder to know which method is in use and it would be confusing to add a 'default' choice here.
Current Touchpad Click Method Section
--------------------------------------
![gnome-tweaks-click-method-3-27-4](/uploads/fff0f2f924d5114d8c8925ff0245b9d2/gnome-tweaks-click-method-3-27-4.png)
Proposed Rework
---------------
This makes the _Keyboard & Mouse_ page long enough to scroll. Before the scroll:
![gnome-tweaks-click-method-1](/uploads/e3f0b4842ec2457630c9afb0ab20c38f/gnome-tweaks-click-method-1.png)
After scrolling down:
![gnome-tweaks-click-method-2](/uploads/b0043d1797c13fa0062944e1a14bbce4/gnome-tweaks-click-method-2.png)3.27.90https://gitlab.gnome.org/GNOME/gnome-tweaks/-/issues/91Too small window size when unmaximized2018-08-24T12:19:16ZBugzillaToo small window size when unmaximized## Submitted by Alexander Mikhaylenko `@exalm`
**[Link to original bug (#782255)](https://bugzilla.gnome.org/show_bug.cgi?id=782255)**
## Description
Created attachment 351250
Unmaximized GNOME Tweak Tool
If Tweak Tool starts maxim...## Submitted by Alexander Mikhaylenko `@exalm`
**[Link to original bug (#782255)](https://bugzilla.gnome.org/show_bug.cgi?id=782255)**
## Description
Created attachment 351250
Unmaximized GNOME Tweak Tool
If Tweak Tool starts maximized on screens with height < 800px, then the window size is not set, resulting in a way too small window when unmaximized. See screenshot.
**Attachment 351250**, "Unmaximized GNOME Tweak Tool":
![Снимок_экрана_от_2017-05-06_13-54-53](/uploads/335e75b5ace526bdc91e1ef9d8cd2d9e/Снимок_экрана_от_2017-05-06_13-54-53.png)3.27.90https://gitlab.gnome.org/GNOME/gnome-music/-/issues/127playlists are not displayed2018-01-27T21:37:54ZBugzillaplaylists are not displayed## Submitted by Dariusz Deoniziak `@darekdeoniziak`
**[Link to original bug (#789640)](https://bugzilla.gnome.org/show_bug.cgi?id=789640)**
## Description
Created attachment 362513
screenshot of an issue
This screenshot shows the i...## Submitted by Dariusz Deoniziak `@darekdeoniziak`
**[Link to original bug (#789640)](https://bugzilla.gnome.org/show_bug.cgi?id=789640)**
## Description
Created attachment 362513
screenshot of an issue
This screenshot shows the issue: https://i.imgur.com/XS8sUEC.png
Playlists do not display. Sometimes just empty side panel shows up without labels.
Steps to reproduce:
1. First run of gnome-music (after killing it)
2. No matter where I go in the app, after going to playlists the panel is gone (or empty)
3. Close app (without killing it)
4. Run app again and go to playlists, all is fine.
5. Kill app, cycle repeats
No errors are displayed when I run gnome music from terminal. Actually I got bunch of errors, but regarding spotify authorization, which I believe is not related?
**Attachment 362513**, "screenshot of an issue":
![music](/uploads/90f160235ae4ce3a9cf7e558f53179f0/music.png)3.27.90https://gitlab.gnome.org/GNOME/gnome-music/-/issues/46Crashed when trying to play music over UPnP2018-01-28T14:25:02ZBugzillaCrashed when trying to play music over UPnP## Submitted by Andreas Nilsson
**[Link to original bug (#758704)](https://bugzilla.gnome.org/show_bug.cgi?id=758704)**
## Description
This is the output I get at the terminal:
process 27340: arguments to dbus_message_iter_append_b...## Submitted by Andreas Nilsson
**[Link to original bug (#758704)](https://bugzilla.gnome.org/show_bug.cgi?id=758704)**
## Description
This is the output I get at the terminal:
process 27340: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_check_is_valid_path (*string_p)" failed in file ../../dbus/dbus-message.c line 2717.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)
Before that I get a million of these:
(gnome-music:27340): Gtk-WARNING **: State 0 for GdTaggedEntry 0x55b8bfb264f0 doesn't match state 128 set via gtk_style_context_set_state ()
But I think that's unrelated.3.27.90https://gitlab.gnome.org/GNOME/gnome-music/-/issues/2Fix deprecated accelerator call2018-01-16T21:02:32ZMarinus Schraalmschraal@gnome.orgFix deprecated accelerator callFix the following deprecated gtk call:
```
gnomemusic/window.py:72: DeprecationWarning: Gtk.Application.add_accelerator is deprecated
app.add_accelerator('<Primary>a', 'win.selectAll', None)
```Fix the following deprecated gtk call:
```
gnomemusic/window.py:72: DeprecationWarning: Gtk.Application.add_accelerator is deprecated
app.add_accelerator('<Primary>a', 'win.selectAll', None)
```3.27.90https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/235noon is displayed as "12 AM"2018-01-11T10:46:54ZAdam Dinglenoon is displayed as "12 AM"I'm running gnome-calendar built from master on Ubuntu 17.10.
In a locale with 12-hour (AM/PM) time, gnome-calendar displays noon as "12 AM". That should be "12 PM".I'm running gnome-calendar built from master on Ubuntu 17.10.
In a locale with 12-hour (AM/PM) time, gnome-calendar displays noon as "12 AM". That should be "12 PM".3.27.90Adam DingleAdam Dinglehttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/229Add weather forecast to GNOME Calendar2018-03-24T13:50:11ZGeorges Basile Stavracas NetoAdd weather forecast to GNOME CalendarGNOME Calendar needs opt-in weather forecast, with support for custom locations
## Development Tasks
* [x] Introduce weather forecast through `libgweather`
* [x] Introduce automatic location detection through `geocode-glib`
* [x] I...GNOME Calendar needs opt-in weather forecast, with support for custom locations
## Development Tasks
* [x] Introduce weather forecast through `libgweather`
* [x] Introduce automatic location detection through `geocode-glib`
* [x] Implement weather update scheduler
* [x] Implement network detector
## QA Tasks
* [x] Week, Month & Year view show weather forecasts for the next 3 days
* [x] Setting a custom location correctly updates the weather information
* [x] Weather reacts to network availability
* [x] No regressions were introduced3.27.90Florian BroschFlorian Broschhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/107Keyboard shortcuts window is too big2018-03-24T18:49:09ZDebarshi Rayrishi.is@lostca.seKeyboard shortcuts window is too bigNautilus' keyboard shortcuts window is too big to fit on a 1366x768 laptop screen.Nautilus' keyboard shortcuts window is too big to fit on a 1366x768 laptop screen.3.27.90https://gitlab.gnome.org/GNOME/nautilus/-/issues/65Search options for "Full text" and "File name" are preserved only for that se...2018-07-22T10:53:01ZCarlos SorianoSearch options for "Full text" and "File name" are preserved only for that searchWith no way to have the setting permanent. This kinda defeats the point as I don't expect people to be changing the option they prefer every time.
Also, it goes against the latest efforts avoiding temporary settings in the views and per...With no way to have the setting permanent. This kinda defeats the point as I don't expect people to be changing the option they prefer every time.
Also, it goes against the latest efforts avoiding temporary settings in the views and permanent settings in the preferences dialog, which was causing reports with confused users. In the last years we have moved all settings to permanent, and would be useful to rethink this one too.3.27.90