GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-03-29T04:25:12Zhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3035Thumbnails are not prioritized when changing tabs2024-03-29T04:25:12ZKhalid Abu ShawaribThumbnails are not prioritized when changing tabs# Affected version
- Nightly flatpak: Yes
# Steps to reproduce
1. Open a big directory with a lot of thumbnails
2. Open another directory with thumbnails in another tab without scrolling or changing the window size.
# Current behaviour...# Affected version
- Nightly flatpak: Yes
# Steps to reproduce
1. Open a big directory with a lot of thumbnails
2. Open another directory with thumbnails in another tab without scrolling or changing the window size.
# Current behaviour
The newly opened directory doesn't get thumbnailed.
# Expected behaviour
<!-- Describe the expected behaviour. -->
The newly opened directory should get thumbnailed.
# Additional information
![Screencast_from_2023-07-23_22-24-59](/uploads/323c5c27663c833d758e92e6bf018149/Screencast_from_2023-07-23_22-24-59.webm)
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6847Design proposal: improve discoverability of mouse toggle in Screenshot/Screen...2024-03-11T14:16:21Zdarkblaze69Design proposal: improve discoverability of mouse toggle in Screenshot/ScreencastFor a long time I thought there was no option for pointer recording in gnome-shell screen(shot|cast) tool because my eyes interpret that toggle as an actual pointer.
Only recently by accident I've discovered that it is actually an optio...For a long time I thought there was no option for pointer recording in gnome-shell screen(shot|cast) tool because my eyes interpret that toggle as an actual pointer.
Only recently by accident I've discovered that it is actually an option toggle.
Probably it would be better to redesign it to more easily distinguish between the actual pointer, e.g. in the form of a button or another symbol like we have in "Mouse & Touchpad" panel.
![Screenshot_from_2023-07-23_02-29-09](/uploads/f0acaaf042aa1f0bb43d43b97e03692a/Screenshot_from_2023-07-23_02-29-09.png)
this symbol could work better:
![Screenshot_from_2023-07-23_02-31-27](/uploads/c4659c178a17569fe159ee2131d093cf/Screenshot_from_2023-07-23_02-31-27.png)https://gitlab.gnome.org/GNOME/gimp/-/issues/9784An Idea for a Simple (ish) Way to Implement Better Shape Tools in GIMP2024-02-29T10:03:52ZMichael DaviesAn Idea for a Simple (ish) Way to Implement Better Shape Tools in GIMP**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> All
### Description of the feature
The current workflow for creating shapes in GIMP is through the selection tools. For example, you grab the Ell...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> All
### Description of the feature
The current workflow for creating shapes in GIMP is through the selection tools. For example, you grab the Ellipse select tool, then click and drag your mouse on the canvas and release to create a circle selection. Then, you go to the "Paths" dialogue and convert the selection to a path. From there, you can scale the path up or down, or stroke or fill the path. Of course, you can also scale the selection up or down and fill the selection.
What if the shape select tools (ellipse select and rectangle select) were tweaked slightly to accommodate the option to immediately draw a shape using a path instead of a selection? For example, the user clicks a radio button labeled "Draw Selection" or "Draw Path," and if the "Draw Path" option is selected, it displays additional options for interacting with the path (see attached photo below).
Perhaps this is me being naïve because I'm not a developer, but one implementation of this could be that you somehow script it so that when a person draws the shape with the selection area, the selection is automatically converted to a path upon release of the mouse (as if the user clicked "Selection to Path," but without them needing to click anything). Or, the path could be drawn upon hitting the enter key, thus allowing the user to adjust the area first before finalizing the drawing of the shape (and telling GIMP when to execute drawing the path).
![Draw_Path_or_Draw_Selection_Shape_Selection_Tools](/uploads/ebc8d61200c10912240d733c17cb98a5/Draw_Path_or_Draw_Selection_Shape_Selection_Tools.jpg)
**Another option**, which is more simple, is to have a "Selection to Path" button directly inside the Tool Options for both shape selection tools (see other attached photo). That way the user doesn't have to navigate to a new dialogue and find the small button that performs this feature (in the paths dialogue). It would essentially be a shortcut key for the action.
![Selection_to_Path_shortcut](/uploads/999f46e094780a307ac8b487ce0550e6/Selection_to_Path_shortcut.jpg)
<!-- Please describe your feature with details.
Add screenshots, design images or other files which would help for
understanding the feature or for implementation.
Also add links when needed, for instance for implementation standards
or other relevant resources.-->
### Use cases
<!-- If not obvious, explain the use cases or problems to solve. -->These features would make it easier to draw shapes as svg paths, and fill and stroke these paths for quicker shape creation.https://gitlab.gnome.org/GNOME/gimp/-/issues/9761Making it possible to keep Gimp 2.10 and Gimp 2.99 GEGL plugins seperate2023-07-19T01:20:38ZLinuxBeaverMaking it possible to keep Gimp 2.10 and Gimp 2.99 GEGL plugins seperateGEGL Plugins all go in the same special directory ` /home/(USERNAME)/.local/share/gegl-0.4/plug-ins` and both 2.10 and 2.99 have access to them. Due to this issue I made https://gitlab.gnome.org/GNOME/gimp/-/issues/9760 I was wondering i...GEGL Plugins all go in the same special directory ` /home/(USERNAME)/.local/share/gegl-0.4/plug-ins` and both 2.10 and 2.99 have access to them. Due to this issue I made https://gitlab.gnome.org/GNOME/gimp/-/issues/9760 I was wondering if we could make it where GEGL Plugins for 2.99 could be in the normal plugins folder or not be noticed by 2.10.
I know flatpak isolates them, but if there was a more practical way to do this that would be cool.https://gitlab.gnome.org/GNOME/epiphany/-/issues/2131Shortcut to show URL in existing or new tab2023-07-13T22:23:54ZDevon McCulloughShortcut to show URL in existing or new tabPureOS 10.0 "byzantium" Epiphany 40.2 WebKitGTK 2.40.1
When I type at bash
bash$ epiphany webkit.org
bash$ epiphany webkit.org
I get two tabs at the same URL - stupid but they all do it.
How do I show a URL which is already o...PureOS 10.0 "byzantium" Epiphany 40.2 WebKitGTK 2.40.1
When I type at bash
bash$ epiphany webkit.org
bash$ epiphany webkit.org
I get two tabs at the same URL - stupid but they all do it.
How do I show a URL which is already on an existing tab
and only create a new tab when no such tab exists?
Peace
--Devon
P.S. This is to make OS-level keyboard shortcuts to URLs,
using an already open browser and tab when possible.
Searched online, groveled C code, no luck yet.https://gitlab.gnome.org/GNOME/epiphany/-/issues/2129Locale-specific adblock lists2023-07-21T00:19:23ZtwoLocale-specific adblock listsin uBlock origin, "RU AdList" which contains ad blocks for russian, ukrainian, uzbek and kazakh is enabled by default because my system language is ukrainian. but in Epiphany only EasyList is enabled by default. it would be nice to have ...in uBlock origin, "RU AdList" which contains ad blocks for russian, ukrainian, uzbek and kazakh is enabled by default because my system language is ukrainian. but in Epiphany only EasyList is enabled by default. it would be nice to have locale specific lists by default here too, and a gui for configuring themhttps://gitlab.gnome.org/GNOME/libmks/-/issues/8Chardev support2023-07-18T14:00:53ZBilal Elmoussaouibil.elmoussaoui@gmail.comChardev supportSimilar to graphical consoles, QEMU also has text based ones. This would imply using vte and should probably be optional at build time. A WIP implementation can be found at https://gitlab.gnome.org/bilelmoussaoui/libmks/-/commit/3033533e...Similar to graphical consoles, QEMU also has text based ones. This would imply using vte and should probably be optional at build time. A WIP implementation can be found at https://gitlab.gnome.org/bilelmoussaoui/libmks/-/commit/3033533e15ac19611ae433038fc59e05068b32f5 for anyone wanting to finish the last remaining bits.https://gitlab.gnome.org/GNOME/libmks/-/issues/7Clipboard support2023-07-12T16:24:25ZBilal Elmoussaouibil.elmoussaoui@gmail.comClipboard supportCurrently we lack support for the clipboard interface. The implementation could use a custom GdkContentProvider.Currently we lack support for the clipboard interface. The implementation could use a custom GdkContentProvider.https://gitlab.gnome.org/GNOME/gimp/-/issues/97342.99.16 contrast stops too hard2023-07-12T19:52:34ZMichael Hans2.99.16 contrast stops too hardin Colors/Brightness-Contrast
contrast stops are still way too hard, the old 2.10 stepping was ok
1. image no additional contrast
![SS_domingo_contrast0_DSC08787](/uploads/954082ae7f4261867cf6a77267e19b86/SS_domingo_contrast0_DSC08787.j...in Colors/Brightness-Contrast
contrast stops are still way too hard, the old 2.10 stepping was ok
1. image no additional contrast
![SS_domingo_contrast0_DSC08787](/uploads/954082ae7f4261867cf6a77267e19b86/SS_domingo_contrast0_DSC08787.jpg)
2. image with contrast +1
![SS_domingo_contrast1_DSC08787](/uploads/a854ca054dcbeb6308ec0b925d68732e/SS_domingo_contrast1_DSC08787.jpg)
3. image with contrast +2
![SS_domingo_contrast2_DSC08787](/uploads/45b63245abc861c00a38ef64fb506b61/SS_domingo_contrast2_DSC08787.jpg)https://gitlab.gnome.org/GNOME/gimp/-/issues/9729Add introspect capabilities of the Scheme implementation using SRFI 0 COND-EX...2024-03-22T17:44:02ZAlSchemistAdd introspect capabilities of the Scheme implementation using SRFI 0 COND-EXPAND### Environment/Versions
- GIMP version: **2.10**.34, **2.99**.15 dev beta, all
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> `flatpak install --user https:/...### Environment/Versions
- GIMP version: **2.10**.34, **2.99**.15 dev beta, all
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> `flatpak install --user https://dl.flathub.org/build-repo/32984/org.gimp.GIMP.flatpakref`
- Script-Fu init on Ubuntu 22: `~/.local/share/flatpak/app/org.gimp.GIMP/x86_64/beta/25dd33d02a45117189f7de74cb17ad71e555e1ca25c59ec7f6d4afb1bdc9f309/files/share/gimp/2.99/scripts/script-fu.init`
- Script-Fu init on Windows 10: `C:\Program Files\GIMP 2\share\gimp\2.0\scripts\script-fu.init`
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> **Win**dows 10, WSL 2 **Ubu**ntu 22.04.2 LTS, All
<!--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).-->
<!--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)--> **Always**
### Description of the bug
#### Positive tests in _legacy_ TS 1.42
Firstly, the conditional-compilation-like SRFI registry `*features*` is displayed:
```scheme
(srfi-0 tinyscheme)
```
Pay attentation to the **order** of features.
![ts-tst-pos](/uploads/3f0c4b25c99e006cfc2f5ffb9f4b6346/ts-tst-pos.png)
Figure 1: `cond-expand` works in TinyScheme 1.42
Like Script-Fu, TS 1.42 has two features:
1. srfi-0;
2. tinyscheme.
Symbolically, the _order_ of features could be interpreted:
1. TS _only_ supports the zero-based **S**cheme **R**equests **f**or **I**mplementation [`srfi-0`](https://srfi.schemers.org/srfi-0/srfi-0.html).
2. There will be not any other SRFI after the core engine `tinyscheme`.
The expected message "Script-Fu implements both TS and Srfi-0" is well displayed.
Since Srfi-38 is not in the SRFI registry `*features*`, the message "Srfi-38 is not supported." works.
#### Negative tests fail
![ts-tst-neg](/uploads/d6730ebc683c97c9c07eef1b258a3a94/ts-tst-neg.png)
Figure 2: TinyScheme 1.42 fails
Handling [`else`](https://sourceforge.net/p/tinyscheme/patches/15/) in `cond-expand` has been discussed in 2014-03-12 and updated in 2020-09-28 for the milestone TS 1.**43**.
![Win10-Script-Fu2-10-34-tst-neg](/uploads/b6957dc1b4a70efee54819804d07cfb5/Win10-Script-Fu2-10-34-tst-neg.png)
Figure 3: Script-Fu fails in Windows 10 Gimp 2.10.34
Hereafter enclosed are the cases where both TS and Script-Fu return unexpected #t or fail with the wrong message.
<details><summary>Click to expand</summary>
```scheme
(cond-expand (srfi-38 "srfi-38 is supported.") (else "srfi-38 is supported!"))
```
Expected result: `"srfi-38 is not supported!"`
Actual result: `#t`
___
```scheme
(cond-expand (srfi-38 "srfi-38 is supported."))
```
Expected result: `#f`
Actual result: `#t`
___
```scheme
(cond-expand)
```
Expected result: `Error: 0000. Unfulfilled cond-expand. `
Actual result: `#t`
___
```scheme
(cond-expand (else))
```
Expected result: `()`
Actual result: `#t`
___
```scheme
(cond-expand (else "srfi-38 is not supported!") (srfi-38 "unreachable"))
```
Expected result: `Error: 0001. cond-expand else clause is not the final one. `
Actual result: `#t`
___
```scheme
(cond-expand ((not) "unreachable"))
```
Expected result: `Error: 0002. cond-expand: 'not' takes 1 argument `
Actual result: `Error: cdr: argument 1 must be: pair `
___
```scheme
(cond-expand ((boolFnc prm) "unreachable"))
```
Expected result: `Error: 0003. cond-expand: unknown boolean operator boolFnc `
Actual result: `Error: cond-expand : unknown operator boolFnc `
No space before `:`.
</details>
___
### Implementation
#### Legacy
`Srfi-0` is at the _end_ of [script-fu.init](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/plug-ins/script-fu/scripts/script-fu.init#L681-714)
<details><summary>Click to expand</summary>
```scheme
;; SRFI-0
;; COND-EXPAND
;; Implemented as a macro
(define *features* '(srfi-0 tinyscheme))
(define-macro (cond-expand . cond-action-list)
(cond-expand-runtime cond-action-list))
(define (cond-expand-runtime cond-action-list)
(if (null? cond-action-list)
#t
(if (cond-eval (caar cond-action-list))
`(begin ,@(cdar cond-action-list))
(cond-expand-runtime (cdr cond-action-list)))))
(define (cond-eval-and cond-list)
(foldr (lambda (x y) (and (cond-eval x) (cond-eval y))) #t cond-list))
(define (cond-eval-or cond-list)
(foldr (lambda (x y) (or (cond-eval x) (cond-eval y))) #f cond-list))
(define (cond-eval condition)
(cond
((symbol? condition)
(if (member condition *features*) #t #f))
((eq? condition #t) #t)
((eq? condition #f) #f)
(else (case (car condition)
((and) (cond-eval-and (cdr condition)))
((or) (cond-eval-or (cdr condition)))
((not) (if (not (null? (cddr condition)))
(error "cond-expand : 'not' takes 1 argument")
(not (cond-eval (cadr condition)))))
(else (error "cond-expand : unknown operator" (car condition)))))))
```
The `error` message has two characteristics that will be fixed:
1. The separator between `cond-expand` and `:` is the French _froggy_ space ` ` that does not exist in international English;
2. The function `error` generates a fatal error that stops regression tests before the end of the campaign.
So the legacy:
```scheme
(error "cond-expand : 'not' takes 1 argument")
```
could be improved by:
```scheme
(throw "0002. cond-expand: 'not' takes 1 argument")
```
Replacing `(error "...")` with `(throw "...")` allows the campaign of regression test to continue to the next tests.
An expected error is a **positive** result by the regression test if the expected message matches the result of the execution.
</details>
___
#### Fix 1srfi-000-cond-expand.scm 1.0
[1srfi-000-cond-expand.scm](/uploads/32f9393824f41b3d110bddf05376574c/1srfi-000-cond-expand.scm)
Note that the source code does not end by `EOL` = `CR LF` in Windows or `LF` in Linux. This will discussed _later_.
In the Scrip-Fu console, run:
```scheme
*features*
```
Will improve the differences between TS and Scrip-Fu:
```scheme
(tinyscheme unicode gimp-pdb srfi-0)
```
Contrary to Script-Fu, the _legacy_ TS does not support **Unicode** and cannot access to the Gimp **P**rocedural **D**ata**B**ase.
Into the bargain, ending by `srfi-0` before the closing parenthesis keeps open the hypothesis that more SRFI could be added inside Script-Fu in the future.
___
#### Script-Fu coding style
The legacy [coding style for the C language](https://developer.gimp.org/core/coding_style/) is applied in the original `script-fu.init`.
At the end of a `define`, this could lead to the "**L**ots of **I**nsipid, **S**tupid **P**arentheses" syndrom.
Two spaces for each indendation is not enough.
![Pretty-Print](/uploads/7353f85029660d32e0a075b7b8dc9f4e/Pretty-Print.png)
Figure 4: Sript-Fu legacy vs modern coding style
`pp` standing for Pretty Print beautifies the legacy coding style.
![Npp-balanced-par](/uploads/0a7d14b2f6aa7a95753295f67d385c00/Npp-balanced-par.png)
Figure 5: Script-Fu cross balanced parenthesis in Win10 Notepad++
The modern coding style has:
1. Four spaces by indentation. Split in more smaller `define` if the indendation is too large;
2. Cross balanced parenthesis if the parenthesed expression cannot be closed on the _same_ line;
3. The smiley `;-` separator between two `define`.
Each `define` must have --at least-- one line of comment.
Above this minimal comment are one or more regression tests.
___
#### Script-Fu re-test regression test
![Win10-Script-Fu2-10-34-tst-pos](/uploads/03d5be133e436cd6cffe7e2133297bcf/Win10-Script-Fu2-10-34-tst-pos.png)
Figure 6: Sript-Fu re-test regression test on Win10
The international end-user does not wish long waffles in English comments but examples with the calling parameters and the expected result.
The following comment starting with `; (` is a running sample of the function `fnc` with two parameters
```scheme
; (fnc prm1 prm2)
; expected result
```
After the call of `fnc`, the next line is the expected result followed by an empty line.
[`re-test`](https://gitlab.gnome.org/GNOME/gimp/-/issues/9660#note_1787158) runs a campaign of regression test. The call is in the header of the source file .scm:
```scheme
;; (re-test "1srfi-000-cond-expand.scm") SUCCESSFULLY ran 22 tests in 461 ms 165 µs
```
The double semi-colon `;;` avoids to call _recursively_ a campaign of test during the _same_ campaign of test since the time of execution could change.
___
#### Script-Fu integration
![Folder-Gimp-Share](/uploads/07a0756dab766834e354625cbd0f8757/Folder-Gimp-Share.png)
Figure 7: Sript-Fu integration for Windows
Loading the source file`1srfi-000-cond-expand.scm` always generates the **positive** result `#t`:
```scheme
; THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
;-
#t
```
The missing final EOL `CR LF` on Windows or `LF` in Linux will be discussed in a future report.
___
#### srfi-0 cond-expand in Ubuntu 22
![Ubu-Script-Fu2-99-15-tst-pos](/uploads/83509002cb07b31113ce1b64e633ea40/Ubu-Script-Fu2-99-15-tst-pos.png)
Figure 8: Manual campaign of tests in Ubu22 Gimp dev beta 2.99.153.0.2https://gitlab.gnome.org/GNOME/gimp/-/issues/9727Single left clicking the tool slider should set the slider position and start...2024-03-23T18:50:51ZMark SweeneySingle left clicking the tool slider should set the slider position and start the slider drag### Environment/Versions
- GIMP version: 2.99.16, Flatpak
- Operating System: Linux
### Description of the bug
Single left clicking the tool sliders and opacity sliders should just set the
slider position and enable dragging.
At the m...### Environment/Versions
- GIMP version: 2.99.16, Flatpak
- Operating System: Linux
### Description of the bug
Single left clicking the tool sliders and opacity sliders should just set the
slider position and enable dragging.
At the moment, if you happen to left click the right end of the slider, the numerical input is activated in a buggy way.
### Reproduction
Is the bug reproducible? Yes
Reproduction steps:
1. Left Click the number end of a slider
2. Number entry gets focus
3. Slider not draggable
Expected result: Slider active and draggable
Actual result: Number input
### Additional information
Right click, or middle click, or double left click, to highlight all the numbers so that entering 50 would set the slider to 50%, pressing return or clicking elsewhere to finish.https://gitlab.gnome.org/GNOME/baobab/-/issues/105Nicer path bar2023-11-25T05:03:36ZTobias BernardNicer path barThe path bar with the border and backgrounds on each item looks a bit old, I'd update it to match the new design in Nautilus:
![image](/uploads/a830ff6b3eaa55e962b440a6d548f2ae/image.png)
![image](/uploads/b7cc174869fd434cf52f4e8e1aef3...The path bar with the border and backgrounds on each item looks a bit old, I'd update it to match the new design in Nautilus:
![image](/uploads/a830ff6b3eaa55e962b440a6d548f2ae/image.png)
![image](/uploads/b7cc174869fd434cf52f4e8e1aef307e/image.png)https://gitlab.gnome.org/GNOME/gnome-calculator/-/issues/339Currency search fails for accented characters2023-07-11T13:44:01Zjrom99Currency search fails for accented charactersCalculator version 44.0
## Steps to reproduce
1. Set locale to Brazilian portuguese
2. Open calculator
3. Switch to financial mode
4. Search for a currency that has an accented character ("dólar" for "dólar americano")
5. Search again ...Calculator version 44.0
## Steps to reproduce
1. Set locale to Brazilian portuguese
2. Open calculator
3. Switch to financial mode
4. Search for a currency that has an accented character ("dólar" for "dólar americano")
5. Search again without the accented character ("dolar" for "dólar americano")
## Expected outcome
Step 4 and 5 have the same outcome, i.e. both should display all currencies that have the word "dólar".
## Observed outcome
Step 5 fails after the character "l" is typed.
## Relevant screencast
![Gravação_de_tela_de_2023-07-08_23-11-51](/uploads/712d657baca92e37f5cff1ff8a2ec04f/Gravação_de_tela_de_2023-07-08_23-11-51.webm)https://gitlab.gnome.org/GNOME/gimp/-/issues/97172.99.14 alignment tool problem with layers marking2024-03-01T13:16:55ZMichael Hans2.99.14 alignment tool problem with layers markingwhen the layer is smaller than the image, other layers or canvas, the alignment tool selects a layer as big as the image, positioning the 4 dots on the image corners and not on the layer's corners, quite confusing, but after figuring tha...when the layer is smaller than the image, other layers or canvas, the alignment tool selects a layer as big as the image, positioning the 4 dots on the image corners and not on the layer's corners, quite confusing, but after figuring that out the alignment itself works then properlyhttps://gitlab.gnome.org/GNOME/gimp/-/issues/9715Add a way to set the toolbox icon size independently from from the size of al...2023-12-20T09:23:22ZMark SweeneyAdd a way to set the toolbox icon size independently from from the size of all other icons**Operating System:** All
### Description of the feature
The separation of Toolbox icon scaling from all other icon scaling.
In _Preferences->Themes_ there is an override icon sizes scale bar.
Could there be the same kind of bar in...**Operating System:** All
### Description of the feature
The separation of Toolbox icon scaling from all other icon scaling.
In _Preferences->Themes_ there is an override icon sizes scale bar.
Could there be the same kind of bar in Preferences->Toolbox please.
This bar would apply only to the Toolbox icons.
### Use cases
Toolbox icons look great at "Huge" on a 4k display, other icons look better and allow more layer stack visibility on smaller settings.https://gitlab.gnome.org/GNOME/gimp/-/issues/97142.99 PDB API enhance: shorter, object-oriented signatures i.e. not pass array...2024-01-27T10:17:19ZLloyd Konnekerkonnekerl@gmail.com2.99 PDB API enhance: shorter, object-oriented signatures i.e. not pass array length
# Summary
This enhancement makes the *PDB* API signatures shorter, for args that are arrays:
eliminates args for length of arrays.
Arrays know their own length so you don't need to pass the length.
Similarly, don't return a length ar...
# Summary
This enhancement makes the *PDB* API signatures shorter, for args that are arrays:
eliminates args for length of arrays.
Arrays know their own length so you don't need to pass the length.
Similarly, don't return a length arg for arrays.
Most callers don't need a length arg,
since in a caller's language you can iterate over arrays without the length.
If callers need the length, an array has a length method.
The enhancement is PDB API breaking.
Now is a good time, for Gimp 3 which breaks the API for other reasons.
*The C language libgimp API is unchanged.*
The accompanying draft MR demonstrates all aspects. If there is consensus for this enhancement, the MR needs finish and testing.
# Examples
This walks through the visible changes to the PDB API, and other things.
## Example: gimp-edit-copy, an Internal PDB procedure taking an array
### PDB signature
Use the PDB Browser to see this.
Now:
```
boolean gimp-edit-copy (int, GimpObjectArray)
```
Enhanced:
```
boolean gimp-edit-copy (GimpObjectArray)
```
This is the essential point, the signature is short and natural.
### Generated libgimp code
Many methods in libgimp are wrappers around calls to the PDB.
Diff libgimp/gimpedit-pdb.c with master
Here you see that the signature is unchanged, both now and enhanced:
```
gimp_edit_copy (int, GimpItem **)
```
That is, libgimp still has a C API, having a separate length arg.
But note that the wrapped call to the PDB is suitably changed:
```
args = gimp_value_array_new_from_types (NULL,
>>>>>>>>>>>>>> the int length arg is not passed
GIMP_TYPE_OBJECT_ARRAY, NULL,
G_TYPE_NONE);
```
### Generated app code
The generated code in app are "invoker functions",
that implement a call to the PDB in terms of calls to core functions.
Diff app/pdb/edit-cmds.c with master
Now:
```
num_drawables = g_value_get_int (gimp_value_array_index (args, 0));
```
The length of the array is passed into the invoker function, in an element of the GValueArray passed in a call the a PDB procedure.
Enhanced:
```
num_drawables = gimp_value_get_array_length (gimp_value_array_index (args, 0))
```
Here, array length "num_drawables" is gotten from the passed array object,
and not directly from a separate element of the GValueArray.
The num_drawables is needed to iterate over calls to core.
## Example: gimp-get-images, a Internal PDB procedure returning an array.
Similar, use the PDB Browser and see the similar files, just for the function gimp-get-images:
pdb/groups/image.pdb
app/pdb/gimpimage-cmds.c
libgimp/gimpimage-pdb.c
## Example: PDB procedures taking/returning array of primitives.
The previous examples were PDB procedures using array of Gimp objects (images, layers, etc.)
The enhancement also works for PDB procedures using arrays of:
primitives (GimpInt32Array and GimpFloatArray)
colors (GimpRGBArray)
An example is the method gimp-plug-ins-query, returning an array of int32.
Note that these arrays of primitives(?) already do not need a separate length arg:
strings (GStrv)
bytes (GBytes)
## Example: PDB plugin procedures that are "ImageProcedure"
The enhancement also changes the signature of Plugin PDB procedures of type GimpImageProcedure,
aka "filters":
Now:
```
foo (GimpRunMode, GimpImage, gint, GimpObjectArray, ...)
```
Enhanced:
```
foo (GimpRunMode, GimpImage, GimpObjectArray, ...)
```
In the accompanying draft MR, only the Python/GIR plugin foggify.py is changed.
Browse its signature and try Filters>Decor>Fog.
Note that the signature of the "run function" of the plugin is an anomaly:
```
def foggify(procedure, run_mode, image, n_drawables, drawables, args, data):
```
It still takes a length arg. This might be a bug in PyGObject, the binding from C to Python. The "run function" is a callback from C.
# Changes
This walks through changes to Gimp code to implement the enhancement.
See the MR.
## To the code generator
Some crux changes are in /pdb i.e. the source for the pdbgen tool.
The pdbgen tool generates code for Internal PDB procedures.
Diff pdbgen.pl, app.pl, and lib.pl.
There are many more changes in the MR, but they are in generated source.
That is, in the generated /app/pdb/foo-cmds.c and /libgimp/gimpfoo-pdb.c files.
The changes to pdbgen are hard to understand because pdbgen is:
- written in Perl
- a non-trivial code generator.
We can document the changes with comments such as:
```
Don't emit code for a length arg when the next arg is an array.
Use state variables to save an int arg
and optionally emit it after we look at the next arg.
```
## To the PDB language.
The pdb/groups/foo.pdb files are in a small language, say "pdb language." Its a mix of Perl and templates, but it is a language.
*The pdb language is unchanged.*
Authors of Internal PDB procedures must still declare the length arg associated with an array arg. You still declare the C API:
```
@inargs = (
{ name => 'drawables', type => 'itemarray',
desc => 'Drawables to copy from',
no_validate => 1,
array => { name => 'num_drawables',
type => '1 <= int32',
desc => "The number of drawables to save" } },
);
```
## To ScriptFu
### To ScriptFu scripts calling the PDB
Many will need changes, to eliminate passing length args.
### To ScriptFu itself
ScriptFu will need small changes in its argument marshalling code,
for arrays of primitives and colors.
(only int32_array is implemented in the draft MR.)
### To signatures of ScriptFu scripts
Most existing scripts take just one drawable (deprecated.)
Newer scripts, taking multi-layers, will need signatures that omit
the array length arg.
Scripts using the v3 script-fu-register-filter method
(which automatically declares the Drawables array argument)
are exempt from changes to their signature.
## To core code for invoking plugins
The code that creates the prefix of args (image, drawables) to a GimpImageProcedure is changed. See /app/actions/procedure-commands.c
The method gimp_value_get_array_length() is added. See /libgimp/gimpparamspec.c.
The Gimp array types are changed so type GimpObjectArray derives from GimpArray,
by containing the same fields in the same order, as GLib commonly does.
See /libgimp/gimpparamspec.h, the GimpArray struct.
## To plugins calling Internal procedure in the PDB
### C language callers
No change: C language callers call the libgimp C API which is unchanged.
### GIR bound-language callers
Most bound language plugins need no changes, since they use the introspected libgimp C API, which does not change.
Note that binding changes the *appearance in the bound language*
of an introspected libgimp call passing an array.
That is, a binding should already hide the passing of a length arg.
For more discussion, see below "Impact on Python authors"
## To plugins calling other plugin procedures in the PDB
This case is the same for C and GIR bound-languages.
ScriptFu is not GIR bound.
Plugin PDB procedures are not bound to languages such as Python using GIR.
Only Internal PDB procedures are wrapped by libgimp and thus available through introspection.
A C or bound-language plugin calling another plugin in the PDB must chunk
an array into a GValue in a GimpValueArray, and then call run_procedure().
Using for example Python:
```
gvalue = args_gimp_value_array.get_index (2)
Gimp.Value.take_int32_array( gvalue, list )
Gimp.get_pdb().run_procedure ( args_gimp_value_array )
```
Note that the C signature is:
```
gimp_value_take_int32_array (GValue, gint32*, gsize)
```
but since it is annotated for GIR, PyGObject binds the Python "list"
argument to the "gint32*, gsize" arguments in a call.
Note that the Python code need *NOT* put a length argument into the GimpValueArray, because of this enhancement.
See #7369, which is about C language plugins.
The code related to #7369 is:
```
GimpDrawable *drawable_array[2] = ...foo... ; /* a static C array. */
GimpObjectArray *drawables =
gimp_object_array_new (
GIMP_TYPE_DRAWABLE, /* contained type. */
drawable_array, /* C array. */
2, /* length */
TRUE); /* is_static. */
retvals = gimp_pdb_run_procedure (
gimp_get_pdb (),
"proc-name",
GIMP_TYPE_RUN_MODE, GIMP_RUN_NONINTERACTIVE,
GIMP_TYPE_IMAGE, image,
/* No length argument. */
GIMP_TYPE_OBJECT_ARRAY, drawables,
G_TYPE_NONE);
```
# Impact on plugin authors
This discusses the extent of changes to *plugins*
necessitated by this change to the PDB API.
*This enhancement has the most impact on plugin signatures,
since most take a drawable array.
Only a few Internal PDB signatures take or receive arrays.*
The draft MR makes a few representative changes to plugin
but needs a separate commit to fix the rest of impacted existing plugins.
## Impact on ScriptFu script authors
ScriptFu binds to the PDB.
Thus this enhancement impacts ScriptFu scripts.
Many scripts will need small code deletions,
to eliminate length arg in calls to the PDB.
Few ScriptFu scripts take arrays and need changes
to their declared signature.
Most older scripts take a single Drawable.
Newer scripts using standalone interpreter and script-fu-register-filter
need not change.
## Impact on Python and other bound language authors of plugins
This enhancement does not change the way Python plugins call Gimp.
They most often call the libgimp API, which hides a call to the PDB.
This enhancement does not change the libgimp API.
*But PDB API documents are easier to read* for Python script authors.
Since the Python binding hides the passing of a container's length to the libgimp API,
*the signature of a PDB procedure is closer
to the signature in Python than the signature
documented in the libgimp reference.*
For example, the current signature in the API ref:
```
gboolean
gimp_edit_copy (
gint num_drawables,
const GimpItem** drawables
)
```
But the Python signature is something like:
```
Gimp.Edit.copy( list )
```
In other words, Python authors may prefer the PDB Browser as a reference,
versus the libgimp API reference,
since the signatures are nearer to what they will use, after this enhancement.
They won't have to mentally translate.
# Related
This issue is derived from #5919
which is the same but two years old.
This new issue:
1. rewords and fills out the explanation.
2. submits an MR instead of a patch, so you can easily see and test the differences.
3. the issue discusses, and the MR demonstrates, more aspects: receiving arrays, arrays of primitives, changes to plugin signatures, etc.
The original patch just demonstrated passing arrays.
This issue is related in goals to !921 and !389. There is some discussion in those issues about passing C arrays versus array objects.
# Development steps
The draft MR mostly implements this enhancement.
After consensus, the MR needs more work, testing, and review.
1. Fix a few more bindings in ScriptFu (float_array and color_array.)
2. Fix plugins that call the changed PDB API:
a. ScriptFu plugins
b. A few C plugins that call other plugins in the PDB (e.g. PluginBrowser)
c. Any bound-language plugins that take or return arrays
(other than GimpImageProcedure's Drawables array.)3.0https://gitlab.gnome.org/GNOME/gimp/-/issues/9713Debug window should have a titlebar2023-07-07T21:27:09ZAkkana PeckDebug window should have a titlebar(Minor UI issue) Closing a window, I got a Debug window with the stack trace. But unlike all other GIMP windows, this one doesn't have a titlebar, so it can't be moved unless you happen to have a key bound to move in your window manager ...(Minor UI issue) Closing a window, I got a Debug window with the stack trace. But unlike all other GIMP windows, this one doesn't have a titlebar, so it can't be moved unless you happen to have a key bound to move in your window manager (and know what that key is). The window should conform to what the other windows do, which means it should have a titlebar.https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2560Network IP Settings: Allow to set Subnet mask through CIDR shortcode2023-10-17T00:07:50ZMara LaskerNetwork IP Settings: Allow to set Subnet mask through CIDR shortcodeWhen debugging networks, DHCP servers etc one needs to often setup the Ip config manually.
I don't know how many times i have typed out 255.255.255.0 . It would be nice if I could just enter the CIDR code, for example /24.When debugging networks, DHCP servers etc one needs to often setup the Ip config manually.
I don't know how many times i have typed out 255.255.255.0 . It would be nice if I could just enter the CIDR code, for example /24.https://gitlab.gnome.org/GNOME/gimp/-/issues/9691GeoTiff file opens only in b/w and not in grayscale (due to tags not being read)2024-03-09T00:53:17ZTobiasGeoTiff file opens only in b/w and not in grayscale (due to tags not being read)This GeoTiff file opens only in b/w and not in grayscale.
[GCG2016.tif](/uploads/6dc931926e372b0be83058b214dbe709/GCG2016.tif)
This is how the file lookes in IrfanView:
![grafik](/uploads/72e9c79d02ceb1f815db3833e6bd360f/grafik.png)
A...This GeoTiff file opens only in b/w and not in grayscale.
[GCG2016.tif](/uploads/6dc931926e372b0be83058b214dbe709/GCG2016.tif)
This is how the file lookes in IrfanView:
![grafik](/uploads/72e9c79d02ceb1f815db3833e6bd360f/grafik.png)
And this is the file in GIMP 2.99.14:
![grafik](/uploads/fba1237cc8e5580312dec0dc8c48d56d/grafik.png)https://gitlab.gnome.org/GNOME/gimp/-/issues/9688Selection with handles: moving using keyboard only possible when mouse pointe...2024-02-26T15:40:04ZJacob BoeremaSelection with handles: moving using keyboard only possible when mouse pointer is inside selectionOS: Windows 10 Home, 64-bits.
GIMP: both 2.10.34 and current master.
When making a rectangular or oval selection, the keyboard keys Alt+Ctrl(+Shift) can be used to move the selection. There is however an, in my eyes, counterintuitiv...OS: Windows 10 Home, 64-bits.
GIMP: both 2.10.34 and current master.
When making a rectangular or oval selection, the keyboard keys Alt+Ctrl(+Shift) can be used to move the selection. There is however an, in my eyes, counterintuitive difference between showing the selection with adjustment handles, and just the selection outline.
- When we show only the selection outline (happens when clicking inside the selection), the mentioned keys can be used to move the selection, no matter where the mouse cursor is. To me, this seems to be the most logical.
- However, when the selection adjustment handles are visible, the movement keys only work if the mouse pointer is inside the selection (except when inside the corner areas, which will change the selection size). I don't know if there are technical reasons for this, but from a user point of view, it would be better to also allow movement when the mouse is outside the selection.