GIMP issueshttps://gitlab.gnome.org/GNOME/gimp/-/issues2024-02-15T16:00:44Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/10136Shortcuts GUI locks user into a keypress, Gdk-CRITICAL **: gdk_window_get_win...2024-02-15T16:00:44ZMark SweeneyShortcuts GUI locks user into a keypress, Gdk-CRITICAL **: gdk_window_get_window_type: assertion 'GDK_IS_WINDOW (window)' failed### Environment/Versions
- GIMP version: 2.99.17, built from source
- Operating System: Linux
### Description of the bug
when editing a shortcut, edit->keyboard shortcuts, a critical message appears in the terminal when a shortcut is d...### Environment/Versions
- GIMP version: 2.99.17, built from source
- Operating System: Linux
### Description of the bug
when editing a shortcut, edit->keyboard shortcuts, a critical message appears in the terminal when a shortcut is double clicked to set it.
Then the user can't do anything except press a key.
Gdk-CRITICAL **: 18:23:41.335: gdk_window_get_window_type: assertion 'GDK_IS_WINDOW (window)' failed
### Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. start GIMP
2. edit->keyboard shortcuts
3. double click to set a shortcut, critical in terminal
4. complete control taken by GIMP, nothing can be done except press a key, not even OS interaction.
5. on key press, sometimes a window pops open showing the key press
Expected result: double click opens up a user input entry field, that you can type into to set the shortcut.
Actual result: no display of entry field, system locked until a key is pressed3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/11029Slider widget needs a complete revamp2024-03-18T09:10:16ZAlexandre 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/gimp/-/issues/104392.99 Recently Closed Docks shows empty submenu after reopening closed docks2024-02-29T19:37:29ZJacob Boerema2.99 Recently Closed Docks shows empty submenu after reopening closed docksWindows 10 Home 64-bit; current master, self-built.
**Reproduction**
1. Assuming you don't have any previous recently closed docks.
2. Create a new dock with at least two dockables.
3. Close this dock.
4. Notice that Window -> Recently...Windows 10 Home 64-bit; current master, self-built.
**Reproduction**
1. Assuming you don't have any previous recently closed docks.
2. Create a new dock with at least two dockables.
3. Close this dock.
4. Notice that Window -> Recently closed docks has this dock listed as the only menu item in this submenu.
5. Click this menu item to reopen the dock.
6. Check the Recently closed docks again and see that it is now an empty submenu.
**Expected**
The Recently Closed docks should be removed when there are no items left in it.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/10248Incorrect thumbnail in layers dialog2024-02-11T15:15:34ZJacob BoeremaIncorrect thumbnail in layers dialog### Environment/Versions
- GIMP version: current master
- Package: self-built using MSYS2
- Operating System: Windows 10 Home, 64-bit
### Description of the bug
This is not present in 2.99.16, only in master. Open the attached image[P...### Environment/Versions
- GIMP version: current master
- Package: self-built using MSYS2
- Operating System: Windows 10 Home, 64-bit
### Description of the bug
This is not present in 2.99.16, only in master. Open the attached image[P3-rgb-maxvalue31.xcf](/uploads/994531bb62cdcdbc95bb901ecc9ce8f7/P3-rgb-maxvalue31.xcf)
Look at the thumbnail of this image in the Layers dialog. The top-left pixel should be red, but is yellow.
Screenshot:![layers-dialog-incorrect-thumb-1](/uploads/e7461f8278055beb36ee53162b0bebca/layers-dialog-incorrect-thumb-1.png)
As a guess, it might be related to the small non-square size (3x2), in combination with having to stretch the pixel at 0,0.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/9576Tool preset menu incomplete first time its shown2024-03-12T16:11:44ZJacob BoeremaTool preset menu incomplete first time its shownWindows 11, 64-bit,self-built, up-to-date master.
Start gimp, open the triangle menu in the toolbox, open `Tool Options menu` for e.g. rectangle select.
The menu only shows the `Save Tool Preset` submenu and `Reset Tool Options` and `R...Windows 11, 64-bit,self-built, up-to-date master.
Start gimp, open the triangle menu in the toolbox, open `Tool Options menu` for e.g. rectangle select.
The menu only shows the `Save Tool Preset` submenu and `Reset Tool Options` and `Reset all Tool Options`.
Close this menu and open it again: now you also see the restore, edit, delete submenus.
Second issue is crashing accessing triangle menu after that, will open separate issue.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/5507New icon design needed for macOS 11 Big Sur2024-03-10T23:15:17ZThePotatoKing55New icon design needed for macOS 11 Big SurmacOS Big Sur introduced a new standard for app icon designs, and it doesn't seem like anyone's updated GIMP yet. I made a quick icon but I'm sure someone could make something better.
![GIMP](/uploads/e4199e17585b5aa789a6078be9f84072/GIM...macOS Big Sur introduced a new standard for app icon designs, and it doesn't seem like anyone's updated GIMP yet. I made a quick icon but I'm sure someone could make something better.
![GIMP](/uploads/e4199e17585b5aa789a6078be9f84072/GIMP.png)
[Here's a .icns version that you can add directly to the GIMP.app folder.](/uploads/cf4b6cab3d8f5f76047eed1e367842c0/GIMP.icns)3.0 RC1AryeomAryeomhttps://gitlab.gnome.org/GNOME/gimp/-/issues/10875Welcome dialog: additional customization options are very close together2024-03-18T16:23:48ZJacob BoeremaWelcome dialog: additional customization options are very close together### Environment/Versions
- GIMP version: current master self-built on Windows 10
### Description of the bug
In the welcome dialog, the two additional customizations are next to each other with not much space in between. Other language...### Environment/Versions
- GIMP version: current master self-built on Windows 10
### Description of the bug
In the welcome dialog, the two additional customizations are next to each other with not much space in between. Other languages often require more text, which is solved by moving the second option and if needed widening the dialog.
However:
- It might be easy to overlook the second option because they are so close together.
- If a translation needs a lot more space, the dialog might get wider than desirable.
Maybe we should consider another layout for these two options. One problem might be that the height is already almost as high as the height of a small 1360x768 screen.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/10715Icon for effect GUI2024-02-13T22:59:34ZJehanIcon for effect GUI@aryeom Could you upload a small icon to be used for effects, as in https://developer.gimp.org/core/specifications/layer-effects-ui/ ?
Thanks.@aryeom Could you upload a small icon to be used for effects, as in https://developer.gimp.org/core/specifications/layer-effects-ui/ ?
Thanks.3.0 RC1AryeomAryeomhttps://gitlab.gnome.org/GNOME/gimp/-/issues/9322MacOS menu integration regression after full port to GTK 32024-01-31T14:42:41ZLukas OberhuberMacOS menu integration regression after full port to GTK 3### Environment/Versions
- GIMP version: 2.99.15 gtk3 version
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> development
- Operating System: <!--[Windows? mac...### Environment/Versions
- GIMP version: 2.99.15 gtk3 version
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> development
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> macOS
<!--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)-->
MacOS menu usage has regressed from 2.99.14 post integrating the full upgrade to GTK3. See https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/837
The issues are:
1. GIMP menu does not match macOS expectations:
a. `Settings...` menu item is called `Preferences` (and smaller issue: does not have a shortcut, which should be Command+`,`)
b. `Hide GIMP`, `Hide Others` and `Show All` menu items are missing
Standard 2.99.x:
![image](/uploads/41c7f1db86acd2fb8b64039fedc7867e/image.png)
Gtk3:
![image](/uploads/f7cd3722367692bcfc94d1360371cc83/image.png)
2. File menu: the Quit item should not appear here. Also I've noticed the order of some of the items has changed from `master` version. Don't know if intentional or not.
Gtk3:
![image](/uploads/dc661db1ae32415cb22ae9cdabb9a94b/image.png)
3. Edit menu: Preferences, Keyboard Shortcuts and Input Devices should not appear here. Since you've removed Modules and Units from `GIMP` menu, makes sense for them to be here. Manage extensions is in a different place here.
Gtk3:
![image](/uploads/2c8534fb7cfe50fc61c384d1b275192a/image.png)
4. Windows and Help menus should be last two menus.
Gtk3:
![image](/uploads/36f3664244c21956826a4cf48171dc7a/image.png)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. NA
…
Expected result: See screenshots
Actual result: See screenshots3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/9219A compact welcome screen (design)2024-03-18T16:23:50ZAnik MondalA compact welcome screen (design)![welcgimp](/uploads/bd492e91ac869f088e3032b35ae493b3/welcgimp.png)![welcgimp](/uploads/bd492e91ac869f088e3032b35ae493b3/welcgimp.png)3.0 RC1AryeomAryeomhttps://gitlab.gnome.org/GNOME/gimp/-/issues/8494Confusing German message regarding embedded color profile2024-02-25T23:32:22ZUlrich WindlConfusing German message regarding embedded color profile### Environment/Versions
- GIMP version: 2.10.32
- Package: Installer from gimp.org<!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->
- Operating System: Windows<!--[Windows...### Environment/Versions
- GIMP version: 2.10.32
- Package: Installer from gimp.org<!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->
- Operating System: Windows<!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->
<!--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)-->
Probably an old-time bug, but I just noticed it:
When loading an image taken with my smartphone, German GIMP pops up a message claiming the image had an embedded color profile "linear TRC from sRGB IEC61966-2.1", manufactured by GIMP. The popup also asks whether to convert the image into the "GIMP built-in Linear sRGB".
Obviously the image made by the smartphone cannot have the GIMP color profile.
### Reproduction
Is the bug reproducible? Always<!--[Always / Randomly / Happened only once ] (write it after the > symbol)-->
Reproduction steps:
1. Open image made with smartphone (Color Space: sRGB)
2. Read popup
Expected result:
Correct embedded profile (Linotronic sRGB IEC61966-2.1) should be displayed
Actual result:
Wrong embedded profile is being displayed, probably either a translation mistake or swapped parameters.
![GIMP-color-profile](/uploads/126854ee60081f5957b621b3060479d5/GIMP-color-profile.JPG)
### Additional information
If you have a backtrace for a crash or a warning, paste it here.3.0 RC1JehanJehanhttps://gitlab.gnome.org/GNOME/gimp/-/issues/1265Review the default workspace layout (dockables, etc.).2024-02-25T23:08:04ZBugzillaReview the default workspace layout (dockables, etc.).## Submitted by Ilya Korneychuk
**[Link to original bug (#791947)](https://bugzilla.gnome.org/show_bug.cgi?id=791947)**
## Description
Created attachment 365970
The suggested default workspace
Due to the GIMP's workflow logics the ...## Submitted by Ilya Korneychuk
**[Link to original bug (#791947)](https://bugzilla.gnome.org/show_bug.cgi?id=791947)**
## Description
Created attachment 365970
The suggested default workspace
Due to the GIMP's workflow logics the Tool Options window is essencial. What about the gradients window seems to me it is used rarely however it is on the foreground in the left bottom layer. To make GIMP easier to undertand for new users I suggest to move the Tool Options window to the left bottom space and put it to the foreground. So the bottom left stack will look like this: Brushes, Palettes, Gradients, Gradient Editor, Palette Editor, Tool Presets, Tool Options.
What about the space in the top right I suggest to put the Navigation window to the foreground. By my opinion this makes the best ergonomical experience for a new user.
**Attachment 365970**, "The suggested default workspace":
![gimp-ik](/uploads/abb4ee283a6726c0a220a0b786ff66c7/gimp-ik.png)
Version: 2.9.83.0 RC1AryeomAryeomhttps://gitlab.gnome.org/GNOME/gimp/-/issues/7859Selection outline does not show up on first try with Fuzzy Select & Select by...2023-11-05T10:29:15ZJeffery SmallSelection outline does not show up on first try with Fuzzy Select & Select by Color with GIMP 2.10.30### Environment/Versions
- GIMP version: 2.10.30
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> 2.10.30-0focal2 Ubuntu package
- Operating System: <!--[Window...### Environment/Versions
- GIMP version: 2.10.30
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> 2.10.30-0focal2 Ubuntu package
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Linux Xubuntu 20.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)-->
Ever since upgrading to 2.10.30 the first selection made using Fuzzy Select or Select by Color fails to show the active selection (i.e., with marching ant outlines). The selection HAS been made, it is simply not displayed. Only after the next use of the tool does the selection display.
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> This bug is 100% reproducible.
Reproduction steps:
1. Select tool and make a selection. Nothing shows.
2. Make 2nd selection and total selection shows.
3. Tool operates properly after this point.
Expected result:
Should see selection after first mouse click.2.10.38https://gitlab.gnome.org/GNOME/gimp/-/issues/10949Selection outline not visible when using "Fuzzy Select" or "Select by Color" ...2024-03-02T20:03:54ZHorschtSelection outline not visible when using "Fuzzy Select" or "Select by Color" without a preexisting selection### Environment/Versions
- GIMP version: 2.10.36
- Package: Installer from gimp.org (direct download)
- Operating System: Windows 10 Version 22H2 (OS Build 19045.4046)
### Description of the bug
Selection outline is not visible when u...### Environment/Versions
- GIMP version: 2.10.36
- Package: Installer from gimp.org (direct download)
- Operating System: Windows 10 Version 22H2 (OS Build 19045.4046)
### Description of the bug
Selection outline is not visible when using "Fuzzy Select" or "Select by Color" when there is no prior selection. It does exist though and when switching to the pencil tool it also appears again.
### Reproduction
Always
Reproduction steps:
1. Clear selection using Select None
2. Choose the "Fuzzy Select" or "Select by Color" tool
3. Click on a color
Expected result:
Marching ants selection outline becomes visible, showing the selected area
Actual result:
Marching ants selection outline does not show up, as if the selection didn't work
### Additional information
![gimp-2.10_8BtUxoValJ](/uploads/fe60da0bffcf51eaca9eebc228d35a4f/gimp-2.10_8BtUxoValJ.mp4)https://gitlab.gnome.org/GNOME/gimp/-/issues/10710macOS Dialogue box keyboard shortcuts inconsistent2024-02-08T17:02:59ZTerramacOS Dialogue box keyboard shortcuts inconsistent<!-- ⚠️ 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.10.36
- Package: Direct Install, .dmg
- Operating System: macOS Sonoma 14.2.1
### Description
On macOS, keyboard shortcuts in the main app (e.g., copy, paste, select all, etc.) all use the Cmd key, as is expected throughout most of macOS applications. This is _not_ the case, however, with any dialogue boxes (e.g., Change _<x>_ color, any filter windows); they still expect the use of the Ctrl key for keyboard shortcuts like copy/paste.
This is also a problem in fields in dockable dialogs, such as Tool Options; you cannot select all the text in a field (e.g., the Pencil's Size property).https://gitlab.gnome.org/GNOME/gimp/-/issues/10645Pasting/opening big images resizes the Gimp in single window mode2024-03-14T12:19:02ZDaniel ManiaPasting/opening big images resizes the Gimp in single window mode### Environment/Versions
- GIMP version: 2.10.36
- Package: Installer from gimp.org
- Operating System: Windows 10 x64
### Description of the bug
When opening or pasting an image into Gimp that is bigger than the current Gimp window,...### Environment/Versions
- GIMP version: 2.10.36
- Package: Installer from gimp.org
- Operating System: Windows 10 x64
### Description of the bug
When opening or pasting an image into Gimp that is bigger than the current Gimp window, the Gimp window will resize. Depending on the position of the Gimp window the right and/or lower side of the Gimp window can be off screen. This only happens when the Gimp workspace was empty before opening/pasting.
### Reproduction
Is the bug reproducible? Always
**Reproduction steps:**
1. Open Gimp (workspace has to be empty) and make the Gimp window small
2. (Copy image data that is wider than the Gimp workspace from another application, e.g. XNview or paint.net)
3. Open or paste image into Gimp (both "Edit \> Paste" and "Edit \> Paste as New Image \[Shift+Ctrl+v\] trigger the bug)
**Expected result:**
The Gimp window size should remain unchanged and the image should be displayed according to the setting "Image Windows \> Initial zoom ratio".
**Actual result:**
The Gimp window resizes to accommodate the image. The "Initial zoom ratio" setting is bugged too. When set to "Show entire image", the image is usually zoomed out, but not enough to actually show the whole image (should this be a separate bug report?).
When the Gimp workspace is not empty (one or more images already open), opening or pasting a big image will not resize the Gimp window. In that case, Gimp behaves as expected.
It can be argued that resizing the Gimp window could be an option that can be enabled or disabled in the settings. But, under no circumstances should the Gimp window change to a size that renders parts of the window inaccessible (off screen).https://gitlab.gnome.org/GNOME/gimp/-/issues/10531White squares appearing over lines after undoing2023-12-27T13:06:39ZBonnibel RoseWhite squares appearing over lines after undoing- GIMP version: GIMP 2.10.36
- Package: GIMP 2.10.36 for Intel Direct Download
- Operating System: MacOS Sierra 10.13
TLDR: Pressure sensitivity creates issue where lines won't undo properly
I have just replaced my old WACOM tablet (Not...- GIMP version: GIMP 2.10.36
- Package: GIMP 2.10.36 for Intel Direct Download
- Operating System: MacOS Sierra 10.13
TLDR: Pressure sensitivity creates issue where lines won't undo properly
I have just replaced my old WACOM tablet (Note, I have never set up drivers for that tablet such as pressure sensitivity and what-not) with a Huion H1060P. I installed pressure sensitivity drivers for my Huion tablet and they are working perfectly fine. The issue comes in now when I draw in GIMP, after I undo a line stroke it will stay on screen for a prolonged period of time and when I draw over the line that I have undone, white squares will appear around the newly created line stroke. After doing some tests I have found out it is the pressure sensitivity, this issue does not occur when drawing with my mouse. But, why I think this is a GIMP bug is because this issue does not occur on other drawing apps and only occurs on GIMP. This app has been very loyal to me and I do not want to switch to anything else, if anyone can tell me if this issue is happening to them or is easily fixable, that would be very helpful. My friend had a similar issue happen on Photoshop and has no idea what caused it, he uses a screen tablet that is a WACOM.
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->![Screen_Shot_2023-12-26_at_3.01.57_PM](/uploads/b0622d01e3cf5919c0394cedc8eb3d02/Screen_Shot_2023-12-26_at_3.01.57_PM.png)
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. Enable pressure sensitivity on your drawing pad
2. Draw strokes
3. Undo
…
Expected result: Lines are supposed to undo immediately
Actual result: Lines do not disappear immediately, will stay on screen until I draw over them, creating white squares around it.
### Additional information
This issue may be a graphical issue on my part, maybe I'm missing a file on GIMP but I have reinstalled many times. It could also be an undo memory issue.https://gitlab.gnome.org/GNOME/gimp/-/issues/10489Color selection in Colorize dialog does not respond to new active palette sel...2023-12-18T20:51:51ZIsaac WaldronColor selection in Colorize dialog does not respond to new active palette selection<!-- ⚠️ 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.10.36
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Microsoft Store
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 11
<!--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)-->
Changing the active palette after the Colorize dialog has been opened for the first time does not update the colors on the palette tab of the dialog's color selector dialog.
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. Open an image
2. Select any color palette
3. Open the Colorize dialog using Colors > Colorize
4. Click the color swatch to open the color selection dialog
5. Activate the palette tab; note that the available colors match the selected palette
6. Close the color selection and Colorize dialogs
7. Select any other color palette
8. Repeat steps 3-5 and note that the available colors remain from the palette selected in step 2 and not the currently active palette selected in step 7
…
Expected result: Colors shown in the color selection dialog's palette tab match the currently active palette
Actual result: Colors shown in the color selection dialog's palette tab appear to be stuck on the palette first selected during a session
### Additional information
If you have a backtrace for a crash or a warning, paste it here.https://gitlab.gnome.org/GNOME/gimp/-/issues/10462Change Foreground Color HSV Value Rounding Error in calculating HTML Notation...2023-12-12T19:01:00ZCraig FedynichChange Foreground Color HSV Value Rounding Error in calculating HTML Notation Hex Value<!-- ⚠️ 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.10.36
- Package: Direct download from gimp.org, file is gimp-2.10.36-setup.exe
- Operating System: Microsoft Windows 10 Home
<!--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).-->
Updated from 2.10.34 to 2.10.36 and confirmed it's still an issue
### Description of the bug
Background: I'm dealing with a precise color code that acts as a mask for a plugin so I'm using specific colors hex values related to precise HSV values. All the mask colors use different, precise Hues (0.0, 180.0, 90.0, 270.0, 45.0, etc), but are always 50.0 Saturation and 50.0 Value.
Issue: When opening the Change Foreground Color box and entering the HSV values of H:0.0, S:50.0, V:50.0, the HTML Notation incorrectly displays the value at 804040. If you paint or fill with the color and use the color picker (or the display color picker), it shows the correct value of 7f4040. However, if you type the HTML value of 804040 into the HTML notation box, It shows the nearest HSV values of H:0.0, S:50.0, V:50.2 and correctly paints the HTML value of 804040. The color picker will correctly identify the 804040 value to repick the color.
So the brush, color picker (fill tool, etc) all have a different color than what's being displayed in Change Foreground Color. It also seems to apply to Change Background Color.
Summary: The HSV text box calculations have a rounding error that's causing HSV values to be displayed incorrectly off by 1 from their actual values in the backend of the program.
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)-->Yes.
Reproduction steps:
1. Open Change Foreground Color
2. Select HSV.
3. Enter the H value of 0 (Though others should work. I tested a few.)
4. Enter the S value of 50.0
5. Enter the V value of 50.0
6. Note the HTML notion reports the color code of 804040.
7. Ether draw with the pencil tool or use the fill bucket on a new image or empty layer.
8. Use the Color Picker tool with "Set foreground color" and "Use info window" enabled.
9. Confirm both the Color Picker info box and Change Foreground Color window report the new hex value of 7f4040
…
If steps 3-5 are instead changed to entering the HTML notion value of "804040" directly, then it works as intended.
Expected result:
Hex value of 804040 to be painted on the canvas.
Actual result:
Hex value of 7f4040 was painted on the canvas.
### Additional information
If you need a recording of my workflow, I can get one, but it seems easy to reproduce.https://gitlab.gnome.org/GNOME/gimp/-/issues/104202.10.36 layer transparency slider problem2024-03-14T00:59:45ZMichael Hans2.10.36 layer transparency slider problemin multi layer images, former versions were fixed to enable double click in transparency slider, typing the desired value, click on the next layer doing the same, and so on
happens that NOW the value typed in is not saved on layer chang...in multi layer images, former versions were fixed to enable double click in transparency slider, typing the desired value, click on the next layer doing the same, and so on
happens that NOW the value typed in is not saved on layer change anymore and an arbitrary value is set for the layer you left, seems to be the slider value for where the cursor was