GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-03-27T19:35:33Zhttps://gitlab.gnome.org/GNOME/gnome-calculator/-/issues/346Calculator using 145 MB RSS on launch2024-03-27T19:35:33ZSidCalculator using 145 MB RSS on launchOn launching gnome-calculator (`43.0.1`), `top` reports it as using 145 MB.
Is this expected ?On launching gnome-calculator (`43.0.1`), `top` reports it as using 145 MB.
Is this expected ?https://gitlab.gnome.org/GNOME/gnome-calculator/-/issues/372Calculator pops up currencies in programming mode when entering hex characters2024-03-27T19:16:44ZJani NikulaCalculator pops up currencies in programming mode when entering hex charactersCalculator 43.0.1. Programming mode, Hexadecimal input. Entering hex characters a-f as the first digit pops up a currency selection dialog. It's a distraction.
I believe entering currencies in hexadecimal for conversions in programming ...Calculator 43.0.1. Programming mode, Hexadecimal input. Entering hex characters a-f as the first digit pops up a currency selection dialog. It's a distraction.
I believe entering currencies in hexadecimal for conversions in programming mode is a niche that the calculator could perhaps ignore.
Personally I think a and f popping up functions is also a distraction in programming mode, but more justifiable than currencies.
Please consider removing the currency (and function) popups from the programming mode.
![Screenshot_from_2023-12-01_14-26-30](/uploads/d62a9fe900c8b4ff97d4dda60e61a43f/Screenshot_from_2023-12-01_14-26-30.png)https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/997Sidebar: Reduce visual overload and improve contrast of text in events list2024-03-27T14:53:49ZPhilipp SSidebar: Reduce visual overload and improve contrast of text in events list### Affected version
- Fedora 37
- Calendar 43.1
### Bug summary
The event list in the sidebar is visually overloaded with the entire event widget being completely colored. Event title, location, and time labels have poor contrast in ...### Affected version
- Fedora 37
- Calendar 43.1
### Bug summary
The event list in the sidebar is visually overloaded with the entire event widget being completely colored. Event title, location, and time labels have poor contrast in some cases, especially for all-day events when the calendar color is applied to the entire widget. The design in the current [calendar mockup](https://gitlab.gnome.org/Teams/Design/app-mockups/-/blob/61b4ebe09c885852ad6dcfaab94632d437a536c0/calendar/adaptive-calendar.png) does not solve this problem.
### Steps to reproduce
1. Add some time-based and some all-day events in a week.
2. Select the first week-day of that week in mini calendar to view the list of these events.
### What happened
### What did you expect to happen
The use of fully colored event widgets makes sense to visually distinguish the events in a large and complex layout like the week and month view. In the sidebar colors can be easily reduced without loosing information while significantly improving legibility.
I created a mockup basically copying Sam Hewitt's [calendar shell-widget mockup](https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/35f769c96806ececc48801a75f6ccda87274bd74/shell-widgets/shell-widgets.png) into the sidebar with the following small adjustments:
- removing the shadows used for distinction of full-day and time-based events (not necessary in my opinion but alternative indicator could be used instead)
- dark color for start time
- shadow is used for hover style instead as it is normally in lists (see green event)
I added some more events and a full-day event to the original calendar mockup for comparison with the proposed solution:
![compare](/uploads/97bd634704ac188c194fc250da608b6a/compare.png)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1204Date format should be localizable in Event Widget2024-03-27T13:08:20ZJordi MasDate format should be localizable in Event WidgetHello,
Currently the dates in Catalan in the event Widget are shown as "dilluns abril 1" when it should show "dilluns 1 d'abril"
This code https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/gui/gcal-event-widget.c?ref_type=h...Hello,
Currently the dates in Catalan in the event Widget are shown as "dilluns abril 1" when it should show "dilluns 1 d'abril"
This code https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/gui/gcal-event-widget.c?ref_type=heads#L403:
` timestamp_str = g_date_time_format (time, "%a %B %e");`
Should be translatable. Currently it assumes that dates will be "month (%B) - day (%e)" for all locales, but this order changes depending on the locale.
The easiest will be do make it translatable.
Finally, this seems to be also another problem of the same type in the Agenda View:
https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/src/gui/views/gcal-agenda-view.c?ref_type=heads#L188https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/262Redesign for the combined notifications list & calendar popover layout2024-03-27T12:53:25ZAllan DayRedesign for the combined notifications list & calendar popover layoutI've been dissatisfied with the layout of the notifications/calendar drop down for some time. Various reasons for this:
- It feels overwhelming - there a lot of content, and a lot of complexity
- It's hard to read the layout - sections ...I've been dissatisfied with the layout of the notifications/calendar drop down for some time. Various reasons for this:
- It feels overwhelming - there a lot of content, and a lot of complexity
- It's hard to read the layout - sections aren't clearly delineated, there isn't enough regularity for the eye to be able to pick up on a discernible structure
- The visual hierarchy is off in places; for example, if I select a date in the calendar, events for that date appear to the left of where I just clicked
- The calendar click targets are really tiny
- It just doesn't look beautiful
The following is a potential option for updating the layout to address these issues. However, it is just an idea and it would be good to know if there are other proposals out there. Also, it would be good to have input from a visual designer.
[Original mockup (please ignore!)](/uploads/0b0d7a5800d59642063795e48420aaf9/image.png)https://gitlab.gnome.org/GNOME/nautilus/-/issues/2197Case-sensitive option for the search functionality2024-03-27T05:25:03ZK0RRCase-sensitive option for the search functionalityJust like the renamer (pic below) is case sensitive the search should (optionally) be too.
![image](/uploads/9d1ab2ecbb107754ee16bda18e57cec2/image.png)
It would help me to check if any of my photos need to be renamed - some of them had...Just like the renamer (pic below) is case sensitive the search should (optionally) be too.
![image](/uploads/9d1ab2ecbb107754ee16bda18e57cec2/image.png)
It would help me to check if any of my photos need to be renamed - some of them had part of their names capitalized like this: somefile.PNG, otherfile.JPEG.https://gitlab.gnome.org/GNOME/gimp/-/issues/11127[Feature]Cache non-destructive effects in xcf for fast file loading2024-03-27T02:24:33ZZhafran Rama Azmi[Feature]Cache non-destructive effects in xcf for fast file loading**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
### Description of the feature
Hello, I am asking for caches of non-destructive filters to be cached within an xcf so it can be loaded fast, I am ...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
### Description of the feature
Hello, I am asking for caches of non-destructive filters to be cached within an xcf so it can be loaded fast, I am a general user so I don't have an idea in mind of how we're supposed to cache it, but I imagine resulting image can be cached?
<!-- Please describe your feature with details. Also:
- If the feature is UI-related, add screenshots, mockups or videos;
- If the feature is about some standard or API, link relevant resources;
- If you have a patch, see: https://developer.gimp.org/core/submit-patch/ -->
### Use cases
Fast loading of an xcf file within gimp.
<!-- Explain the use cases or problems to solve.
If you are unsure, you should first discuss with the community in the forums
or talk with the developers on IRC: https://www.gimp.org/discuss.html -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3297Design proposition: wider notification window for events, calendar, date, wea...2024-03-26T21:51:37ZAleks ANDRÉDesign proposition: wider notification window for events, calendar, date, weatherDebian sid, GNOME 3.38.1
### Feature summary
When using a wide screen, the actual window showing notifications, events, calendar and weather – displayed with Super+V is imho tall and could be made more wider to ease the user get every ...Debian sid, GNOME 3.38.1
### Feature summary
When using a wide screen, the actual window showing notifications, events, calendar and weather – displayed with Super+V is imho tall and could be made more wider to ease the user get every information at a glance.
### How would you like it to work
Splitting calendar+events and clocks+weather on two adjacent columns, the notification window design is not much impacted but at the same time, the contents appears more structured and the user’s eyes movement is limited.
### Relevant links, screenshots, screencasts etc.
Proposition (top) Vs. actually (bottom)
![proposition](/uploads/c03fd8be732eb6e818292f4cb4bfc314/proposition.png)
![actual](/uploads/b0901b29d3c6b63e465ab7bef3cb121b/actual.png)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3522Need an adaptive multi-columns layout (for world clocks and weather) when hei...2024-03-26T21:35:18ZJeff FortinNeed an adaptive multi-columns layout (for world clocks and weather) when height is insufficient to display elements in the notifications menuAs you can see with this screenshot, sometimes when I have a couple of calendar items showing up, in addition to my many timezones, the weather information gets cut off:
![Screenshot_from_2020-12-22_11-43-03](/uploads/fad75a4699045bea33...As you can see with this screenshot, sometimes when I have a couple of calendar items showing up, in addition to my many timezones, the weather information gets cut off:
![Screenshot_from_2020-12-22_11-43-03](/uploads/fad75a4699045bea33d19e3326ad3139/Screenshot_from_2020-12-22_11-43-03.png)
At that point, it would make sense for some of those elements to be spread across 3 columns instead of 2. I have an ultra-wide screen layout, there's plenty of available horizontal space. This would probably go well with @aday's general "going horizontal" direction for GNOME 40?
Some elements that would be great to relocate to a third column, particularly when you already have a bunch of calendar appointments (below the calendar) filling up the 2nd column already:
* World clocks / timezones cities
* Weather forecasthttps://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2318Grouped notifications2024-03-26T21:35:18ZJan NeumannGrouped notifications<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
<!--
Describe what you would like to be able to do with GNOME...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
<!--
Describe what you would like to be able to do with GNOME Shell
that you currently cannot do.
-->
Grouped notifications. Let's say you're using some sort of a messaging app that generates a lot of notifications, either when you're away or when the app is not open. This currently results in visual clutter in the notification area, which becomes full of notifications that could effectively be replaced with a single notification. In addition, this many widgets result in lag, as described in #2135.
Instead, let's automatically group all of these into a single card.
### How would you like it to work
<!--
If you can think of a way GNOME Shell might be able to do this,
let us know here.
-->
If an application had produced more than a fixed amount of notifications (about 3?), group them to a single card for that particular application, showing a list of notification summaries (again, at most 3 or 5, with the rest hidden away) and displaying all of them in their entirety only upon expand request for this single card (you click on it and it expands)
This resolves visual clutter, without ridding the user of important information.
### Relevant links, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation,
code, mockups or a similar feature in another desktop environments,
please provide them here.
-->
Examples of how this is done on different platforms (please look at screenshots available in these links):
* [Android](https://developer.android.com/training/notify-user/group)
* [iOS](https://www.guidingtech.com/ios-12-notifications-grouping-by-app-vs-automatic-difference/)
* [KDE](https://community.kde.org/images.community/e/ec/Notification_grouping.png)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6187Group/bundle/reuse previously missed transient screenshot notifications2024-03-26T21:11:14ZBen HerbstGroup/bundle/reuse previously missed transient screenshot notifications**The notifications about the screenshots should be grouped together into one notification, just like the Syncthing and Blueman ones in this screenshot.**
![grafik](/uploads/da11d67d5cac1ce7600395e9721af9e3/grafik.png)**The notifications about the screenshots should be grouped together into one notification, just like the Syncthing and Blueman ones in this screenshot.**
![grafik](/uploads/da11d67d5cac1ce7600395e9721af9e3/grafik.png)https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4393Redesign the user selection list, to make it a grid2024-03-26T21:08:50ZAllan DayRedesign the user selection list, to make it a gridOne of the parts of the login screen redesign that we never got around to implementing is a new user selection grid, which is intended to replace the existing user list.
The mockups for this [can be found here](https://gitlab.gnome.org/...One of the parts of the login screen redesign that we never got around to implementing is a new user selection grid, which is intended to replace the existing user list.
The mockups for this [can be found here](https://gitlab.gnome.org/Teams/Design/os-mockups/-/raw/master/lock-login/user-selection-grid.png). To give a flavour, this is how it looks for 3 user accounts:
![image](/uploads/4447c96023fcfc0842ff38beb0f42e03/image.png)
The new designs are much more visually engaging and attractive, and are better suited to the typical numbers of users that we see. They are also more consistent with the rest of the shell design, particularly the changes that landed in 40. As such, they will bring the shell user experience together so that it's more cohesive and integrated.https://gitlab.gnome.org/GNOME/libadwaita/-/issues/714Tab overview switcher mode doesn't allow toggling the searchbar with Ctrl+F2024-03-26T17:22:49ZJeff FortinTab overview switcher mode doesn't allow toggling the searchbar with Ctrl+FAs tested with the current Epiphany Technology Preview, if you do `Ctrl+F` from within the `Ctrl+Shift+O` overview mode, nothing happens.
I know that you can also search by just typing random strings into the ether without turning on th...As tested with the current Epiphany Technology Preview, if you do `Ctrl+F` from within the `Ctrl+Shift+O` overview mode, nothing happens.
I know that you can also search by just typing random strings into the ether without turning on the searchbar, but that's not visually discoverable nor intuitive to many users. It would be good to also allow the standard `Ctrl+F` (and maybe even `F3`, as a secondary) shortcut to also work as a way to explicitly toggle the overview's searchbar. Other apps (Nautilus, GNOME Calendar, etc.) allow this too.https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4022reorder workspaces by mouse drag-n-drop2024-03-26T03:32:45ZVasil Sudakoureorder workspaces by mouse drag-n-drop<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
The ability to drag and reorder by mouse the entire workspaces...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
The ability to drag and reorder by mouse the entire workspaces on Activities Overview / Show Applications.
<!--
Describe what you would like to be able to do with GNOME Shell
that you currently cannot do.
-->
### How would you like it to work
Click by Right/Middle button of mouse on the workspace thumbnail and move that to different place.
<!--
If you can think of a way GNOME Shell might be able to do this,
let us know here.
-->
### Relevant links, screenshots, screencasts etc.
![2021-04-01_01-37](/uploads/da9d7d35014ee47f9e616e7308356809/2021-04-01_01-37.png)
![2021-04-01_01-43](/uploads/bd09e554dc0155cda07516b02be31569/2021-04-01_01-43.png)
<!--
If you have further information, such as technical documentation,
code, mockups or a similar feature in another desktop environments,
please provide them here.
-->
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6745Use Amberol-style background treatment for MPRIS controls2024-03-26T01:31:36ZCassidy James BlaedeUse Amberol-style background treatment for MPRIS controlsThis could make the media player controls much more visually interesting without requiring an entire redesign.
Amberol for context:
![Screenshot of Amberol with a compact window](https://apps.gnome.org/assets/screenshots/io.bassi.Ambe...This could make the media player controls much more visually interesting without requiring an entire redesign.
Amberol for context:
![Screenshot of Amberol with a compact window](https://apps.gnome.org/assets/screenshots/io.bassi.Amberol/amberol-compact.png) | ![Screenshot of Amberol with a green-tinted window](https://apps.gnome.org/assets/screenshots/io.bassi.Amberol/amberol-recolor.png)
--- | ---https://gitlab.gnome.org/GNOME/gimp/-/issues/11114Animation Playback window size not in sync with canvas size2024-03-25T22:20:45ZDilipAnimation Playback window size not in sync with canvas size<!-- ⚠️ 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: 2.99.18
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Flatpak
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Ubuntu 22.04
<!--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)-->
The animation playback window is too wide when compared to the canvas
![Screenshot_from_2024-03-25_20-11-05](/uploads/0552bd196bd43607e2bca034b41bde0c/Screenshot_from_2024-03-25_20-11-05.png)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)-->
Reproduction steps:
1.
2.
3.
…
Expected result:
Expecting a window the same as canvas size
Actual result:
The playback windows is very big
### Additional information
If you have a backtrace for a crash or a warning, paste it here.https://gitlab.gnome.org/GNOME/librsvg/-/issues/1067Disable logging when fuzzing is active2024-03-25T20:17:26ZFederico Mena QuinteroDisable logging when fuzzing is activeAs part of #1018, the [hongfuzz-rs docs](https://github.com/rust-fuzz/honggfuzz-rs?tab=readme-ov-file#conditional-compilation) recommend disabling logging so the fuzzer will have fewer paths to try to reach. Logging [is done here](https...As part of #1018, the [hongfuzz-rs docs](https://github.com/rust-fuzz/honggfuzz-rs?tab=readme-ov-file#conditional-compilation) recommend disabling logging so the fuzzer will have fewer paths to try to reach. Logging [is done here](https://gitlab.gnome.org/GNOME/librsvg/-/blob/e09c63c41a103b9b32831a4c897d3bc1ce29ee26/rsvg/src/log.rs#L5-14).
CC @correctmosthttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1121Setting end time to 23h when start time is 23h should not bump end date to ne...2024-03-25T07:52:10ZJeff FortinSetting end time to 23h when start time is 23h should not bump end date to next day until you type an end time after midnightThis is a very minor corner-case scenario, but it causes problems / user inattention errors when scheduling time-based events that last "between 23h00 and 23h59" (ex: a half-hour event at 23h).
## To reproduce
1. Create an event using ...This is a very minor corner-case scenario, but it causes problems / user inattention errors when scheduling time-based events that last "between 23h00 and 23h59" (ex: a half-hour event at 23h).
## To reproduce
1. Create an event using the advanced event editor dialog
1. Toggle off "All day" to convert to a time-based event
1. Type "23" as the starting hour, leave minutes to "00"
1. Type "23" as the ending hour (before setting the minutes)
## Actual results
End date is bumped 1 day into the future
## Expected results
In the very specific case of events that start at 23:xx and end at 23:yy, we should not auto-increment the end time (and thus end date) by 1 hour; we can pretty safely assume the user meant to do a time-based event that is within the same day and that they will set the minutes end time to sometime before 23h59. It is much less likely that the user actually meant to create an event from "23h today to 23h next day".
In other situations (ex: start/end times that are any number _other_ than `23`), GNOME Calendar can safely do its usual calculations to auto-increment the end time by 1 hour after the start time.
---
This is a successor to issue #91, and kind of related (but much less messed up) to issue #1120 (12-hour time issue), and #393 (default values issue).Spaghetti SenseiSpaghetti Senseihttps://gitlab.gnome.org/GNOME/gimp/-/issues/4088Modify Histogram to show channel values less than 0.0f and greater than 1.0f2024-03-24T14:47:39ZElle StoneModify Histogram to show channel values less than 0.0f and greater than 1.0fThe much-needed option to show "out of display range" channel values in GIMP Histograms was discussed at length on IRC a long time ago. PhotoFlow has implemented such a histogram, which might serve as an example interface for GIMP. See t...The much-needed option to show "out of display range" channel values in GIMP Histograms was discussed at length on IRC a long time ago. PhotoFlow has implemented such a histogram, which might serve as an example interface for GIMP. See this pixls.us post: https://discuss.pixls.us/t/photoflow-news-and-updates/4742/402https://gitlab.gnome.org/GNOME/gimp/-/issues/3028[Feature request] Allow "Fill Window" as an option in the "Initial zoom ratio"2024-03-24T10:24:51ZNokia808[Feature request] Allow "Fill Window" as an option in the "Initial zoom ratio"Hi. Currently there are only 2 options in "Initial zoom ratio": 1:1 & "show entire image"
There are many users need to use "Fill Window" as a default initial zoom ratio & it is not conventional to set this value every time open new image...Hi. Currently there are only 2 options in "Initial zoom ratio": 1:1 & "show entire image"
There are many users need to use "Fill Window" as a default initial zoom ratio & it is not conventional to set this value every time open new image & will be more convenient to have "Fill Window" as a 3rd default initial zoom ratio.