Lloyd Konneker (89f2af04) at 28 Mar 15:54
ScriptFu: tests of TinyScheme string-ports and string escapes
No changes except to tests.
Lloyd Konneker (996ae2c9) at 28 Mar 15:51
ScriptFu: tests of TinyScheme string-ports and string escapes
!740 added a GimpResource superclass and subclasses such as GimpBrush to libgimp. It left the GUI and plugins broken.
!771 fixed the broken GUI
This issue just says some plug-ins are still broken. Upcoming MR will fix the plugins to use the new classes and widgets related to GimpResource class.
This is part of the larger effort to replace the GUI formerly implemented by PyGimp and ScriptFu with GimpProcedureDialog, GimpProcedureConfig, and property widgets. Which still has large holes for chooser of GimpItems and widgets for plug-in, run-time defined enums.
Yes, !786 (merged) is intended to fix.
But note #9270 is related, another step of cleanup of development of GimpResource.
Is this still an issue with 2.99.18? I tested with a nightly build and could not reproduce (although maybe I don't understand the issue.)
I mark it related to the colorspace invasion, using GeglColor instead of GimpRGB, since many changes were made recently.
The "godzilla" script is a test script. It is in the repo, but should not ship with stable Gimp. I don't know any example real-world scripts that need scrolling dialogs. The original test script "Sphere" existed since ancient days. The test script is tutorial, to illustrate and test all the widgets. It uses the home-grown UI of ScriptFu. A similar test script "Sphere v3" is more recent, uses the standard plugin UI of GimpProcedureDialog, and is used to test GPD development (for example to test that defaults for Resources work, a current problem.)
I think the original issue/complaint was on Windows, where you couldn't even move the dialog's window so that you could get to the bottom of it, and the buttons were at the bottom? The original issue was contrived, Gimp's own test script and not a real world plugin.
For some GUI toolkits, the scrollbar only appears on a window/dialog when the window it is necessary (say when the window is resized smaller.) I think Gtk supports dialogs with scrollbars that appear when necessary.
I think the essential question is should GimpProcedureDialog put it's widgets in a scrollable area? My opinion is yes, for generality, but it is low priority since few plugins should need it.
To review: there is an MR that fixes this, but the MR needs work. The MR touches some of the core API dealing with plugins (not ScriptFu) so it must be of high quality and reviewed properly.
Before 3.0rc1 one of these should happen:
Thanks, I wasn't aware of #403 and Kevins opinion.
Kevin contributed much of ScriptFu, but has been relatively inactive recently. His opinion carries much weight.
Yes.
I don't think we have decided to port all scripts in the repo to new-style.
I mean to say:
Some users might have their own scripts in 2.10 that they want to use in 3.0. A few of those scripts might still work in 3.0 as an "old-style" script, without any change, when the script does not use PDB API that has changed. That is why we don't want to obsolete them now. I envision that we obsolete them in say 3.2 or even 4, after users have a period of time to adjust. Others may have different opinions.
I don't think it is a high priority to port all the scripts in the repo to new-style, since it is more important to stabilize and test the API, as Jehan has said. API stability means that after a major version change, such as 2.0 or 3.0, libgimp and PDB API should not change. We can port the plugins later, but we should not change the API later.
@brunolopesdsilv Do you mean "all" to include the ScriptFu plugins in the repo? No, ScriptFu plugins are not part of this tracking issue.
We could open another tracking issue for "port ScriptFu plugins to use GimpProcedureDialog." IMO that should not block 3.0rc1. Plugins that have not been ported to GPD still work, they are just ugly and not uniform with those that do use GPD.
Can you cite a document that describes how (open-output-string "foo") should work?
It seems that MIT, Racket, Guile don't support passing a string to open-output-string. That is, the optional string is unique to TinyScheme (or in other Schemes is the name of the port.)
From what I can understand by reading code, it seems that the passed string is used only to hold what is written, and that any writes will overwrite it starting at the first char.
And (open-output-string "foo") might fail soon if there is garbage collection, since "foo" is a string but there are no references to it after the call to open-output-string.
And (get-output-string (open-output-string "foo")) will yield EOF (and not "foo") since there was nothing written.
Thank YOU. Shouting in amazement at how much you contribute.
A new failing test case:
> (define in (open-input-string "abc"))
in
> (gc) ; force garbage collection
#t
> (read in)
h
So TS string ports are not copying the string, and the port does not keep a cell reference to the string. Which seems like a fundamental flaw, at least for imperative programs.
I think you are saying "don't use open-input-output-string".
I agree, I just wonder why TS implements it, and whether anyone uses it?
I was thinking it could be a better abstraction. If it is a pipe, where you can read from one end and write to the other end, then input and output ports are not needed as separate concepts: an output port is a pipe that you only write to, or call get-output-string on.
That is not what TS does now, just a thought for how it should/might be.
Plugin "Palette to Gradient" fails with:
Writing dirty data '/work/.home/.config/GIMP/2.99/gradients/Bgold.ggr'
Traceback (most recent call last):
File "/usr/local/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/palette-to-gradient/palette-to-gradient.py", line 91, in run
gradient = make_gradient(palette, num_segments, num_colors)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/palette-to-gradient/palette-to-gradient.py", line 50, in make_gradient
_, color_left = palette.entry_get_color(color_number)
^^^^^^^^^^^^^
TypeError: cannot unpack non-iterable Color object
Note the last line is significant, this is a Python trace in reverse order from a C trace.
and then the plugin fails to return values:
(python-fu-palette-to-gradient:547): LibGimp-WARNING **: 10:13:45.738: _gimp_procedure_run_array: no return values, shouldn't happen
Plugin python-fu-palette-to-gradient: GLib: CRITICAL: g_error_new: assertion 'domain != 0' failed
GLib (pid:547): [E]xit, show [S]tack trace or [P]roceed: (gimp-2.99:239):
Is the bug reproducible?
Reproduction steps:
…
Expected result: gradient created
Actual result: fails
Recently a signature change on gimp-palette-entry-get-color, now returning a GeglColor, was returning two values.
Also: Gradient>Save as CSS
Traceback (most recent call last):
File "/usr/local/lib/x86_64-linux-gnu/gimp/2.99/plug-ins/gradients-save-as-css/gradients-save-as-css.py", line 149, in gradient_css_save
success, lcolor, lopacity = gradient.segment_get_left_color(index)
^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: cannot unpack non-iterable Color object
and changed signature for gimp-gradient-segment-get-left-color
Lloyd Konneker (59b6c8fc) at 21 Mar 10:01
ScriptFu: fix 11077: call gimp_ui_init in every run_func
... and 3 more commits
Do you have a reference for open-input-output-string? It seems unique to TinyScheme, at least not described in MIT scheme or others. I probably won't test it since it seems not R5RS.
Also, do you have any opinion on byte operations on a string-port? It appears that you could mix byte and char operations on a string-port, but it is not documented well. And I think it should be discouraged, say undefined behavior, that we won't test.
In the repo, at plug-ins/script-fu/scripts/test/test9.scm is our existing test for byte operations on string-ports.
I agree that the failed negative test seems like a bug also.
Looking at SF's TS implementation, it appears that any #\n.... up to the next delimiter char will return \n. For example #\n or #\newfoobarzed. It is not looking for an exact match on "newline", just a match on "n".
I don't know how original TS 1.42 (without unicode) behaves.
The failed negative tests seems rather benign, not critical.