As usual, these got forgotten!
Also colorxhtml is actually deeply broken by commit 89c359ce47 which removed
gimp_drawable_get_pixel() (Niels thought it was not used, whereas it was simply
harder to spot with bindings!).
This will have to be fixed eventually.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
Note that in the future, we expect this to be possible to create other brushes
with a same name. Maybe we should have a special function allowing to request
core resources (the ones installed by GIMP itself).
… being installed.
There is already most of the main code logic for this, though now plug-ins need
to be in their own subdirectories, which breaks for plug-ins/common/ and
plug-ins/python/, while I needed plug-ins in both these categories to generate
the Windows installer welcome images (file-png, and python-fu-eval in
particular).
Once again, meson was not very helpful, since all its functions still refuse to
output generated files in subdirectories, so I end up duplicating plug-in files
with a custom Python script.
This should fix the CI. It was working on my machine as GIMP was installed, but
such a build rule should work even without GIMP installed.
This will also be useful in the future when we'll want to run unit tests of
plug-ins through the finale GIMP binary itself.
This code is taken from Massimo's comment in #1786 and MR !834. It doesn't fix
a crash as this was already handled in !404, yet the missing prompt after
hitting "clear" was clearly not consistent with how one expect a clear feature
to work.
At least now, we've got a prompt back immediately after clearing.
This plug-in has a partial GUI (a FileChooser dialog is launched).
However, you could only save the active gradient rather than choosing
any of them like the 2.10 version of this plug-in.
This patch ports the original UI so you can choose both the gradient
and file in interactive mode.
It's a test plug-in which doesn't actually need an image to work, so it's
annoying that it currently requires one (making testing more cumbersome).
Also cleaning up a bit the coding style.
Also make the start checks a bit more robust to broken core code by
double-checking that the palette is valid from the start, even though getting an
invalid palette should normally not happen anymore (at least I fixed one such
case with a palette with a NULL id in my previous commit; but it looks like our
core code is not perfectly robust and we should push the code to extensive
testing).
Note that the generated widget is currently ugly (no label and terrible UX), but
this is meant to improve soon.
Simplifies chooser widgets (e.g. GimpBrushSelect) by eliminating attributes (e.g. opacity) of chosen resource.
See #8745, but this commit fixes that by first refactoring the code.
Refactors GUI widgets (e.g. GimpBrushSelectButton and GimpBrushSelect etc.)
Refactor by "Extract class" GimpResourceSelectButton from GimpBrushSelectButton etc.
This moves common code into an inherited class (formerly called GimpSelectButton)
but the subclasses still exist.
The subclasses mainly just do drawing now.
Refactor by "Extract module" GimpResourceSelect from GimpBrushSelect etc.
Moves common code into one file, generic at runtime on type of GimpResource,
that is, the new code dispatches on type i.e. switch statements.
In the future, when core is changed some of that can be deleted.
The files gimpbrushselect.[c,h] etc. are deleted.
The module adapts the API from core to the API of callbacks to libgimp.
Note that core is running the resource chooser (select) widgets remotely.
Core is still calling back over the wire via PDB with more attributes
than necessary.
The new design gets the attributes from the resource themselves,
instead of receiving them from core callback.
The libgimp side adapts by discarding unneeded attributes.
In the future, core (running choosers for plugins) can be simplified also.
Fix gimp_prop_chooser_brush_new same as other resources.
Finish changes, and clean style.
Annotations
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
Just add a no-op flush() as I think it's actually unneeded in the context of a
GtkTextView GUI. At least it doesn't cause issues with copy-pasted code or when
using external libraries using the sys.stdout.flush() interface.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
Just duplicate the blurb into the help string. I'll leave it to someone
else to write a dedicated, longer help text if needed.
Also fixing the call s/Gimp.init/GimpUi.init/.
As noted by @Ofnuts, histogram-export still expected to receive
a single layer from GIMP. The parameters have been updated to
reflect receiving multiple layers/drawables, and the active layer
is selected. The parameter was left in case multi-layer support
is added in the future.
Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
- Set the "gimp30-python" Gettext domain and bind it to the proper
locale directory as installed by GIMP.
- Localize various strings with gettext.
- Remove calls to self.set_translation_domain() in
do_query_procedures(). This is technically wrong right now but I am
going to get rid of the menu item localization for plug-ins done by
the core.
The CLI options now know which procedures are batch procedures or not.
First it means that it won't just randomly try any procedure name one
may pass and will properly output an error if you pass a non-existing
interpreter procedure.
Secondly, there is no default interpreter anymore (unless only one
interpreter exists). If you don't set an interpreter procedure with
--batch-interpreter or if you pass a wrong one, it will output the list
of available batch procedure, thus helping you understanding how to use
the --batch option.
The default for color properties (GimpRGB) is now to be editable. So
let's remove the formerly specific call for this.
Also fixing a clashing mnemonics ('c' both for '_Color' and '_Cancel').
- Fix return value in error case: s/GObject.Error/GLib.Error/ and anyway
in this form, the error should be a string. Using the easier form
procedure.new_return_values() instead.
- "file-png-load" uses a GFile now (like all load procedures).
… GimpUi.ProcedureDialog.new()
The old way is still working and acceptable as far as I am concerned.
Just switching to the recommended (by upstream) syntax to show it works
as expected and as a good example of code.
- Now using multi-drawable run() signature, but sensitive only with a
single drawable.
- width|height() calls are now get_width|height().
- PDB call to 'plug-in-sel2path' now expects a drawable array as well.
The following changes were made:
- run() signature now moved to multi-drawables.
- sensitivity mask now enables the plug-in when one or several drawables
are selected. When several, a fog layer will be created over each
selected layer.
- Mnemonics added to properties.
- Color property finally used now that our API has support for boxed
parameters with GimpRGB value type.
- Use a config object instead of ordered GimpValueArray and use the
begin|en_run() API to store values between runs.
- Add a graphical interface generated with the new GimpProcedureDialog
API.
We did port it to the new API but we are doubting it is useful at all.
It might have been, historically, when foreground extract algorithm was
first introduced, but probably not anymore, even more as the algorithm
is now implemented mostly on GEGL side anyway. So if any benchmark were
to be done, it should probably be added as GEGL tests.
Also as we are planning to update even more the API lately, it feels
really like a waste of time to also fix this plug-in while we currently
believe it to be useless.
Still we move it to the gimp-data-extras repository for being able to
easily bring it back in case we missed some use.
The Openraster plug-in calls file-png-load and
gimp-file-load-layer but didn't check if the result
was SUCCESS. Even though I haven't seen any
failures let's improve error checking by adding
a check for a correct result.
The current openraster specification only has a limited
number of layer modes. Let's improve things a little bit
by mapping both the current and legacy layer modes
to the same openraster composite-op where available.
For the other layer modes we could examine what the
closest composite-op is, or add a GIMP specific op
(which is what Krita seems to do). For now we set
all these to the openraster equivalent of NORMAL.
Let's use the non legacy layer modes when importing/exporting
openraster images. That way we are more likely to be able to
import the correct layer modes since openraster only has a
limited number of layer modes defined.
Per polls on Twitter, Reddit, Patreon and Tipeee, most people were
willing to drop this plug-in as not being relevant anymore (247 for
dropping and 63 for keeping it, so nearly 80% out of 310 participants).
So let's move it to gimp-data-extras allowing it to still have a
possible life, and who knows, maybe to even evolve.
See also corresponding commit beffc6b to gimp-data-extras repository.
This fixes#5838 which was caused by an incomplete port
of this plug-in to the new introspection API.
For now we do keep the n_drawables parameter of save_ora until
issue #5312 is fixed. Not doing this would cause saving to fail.
Since meson 0.43.0 (below our current requirement), 'symbol_prefix'
argument of gnome.generate_gir() allows an ordered list. If I prepend
'gimp_ui', it makes any gimp_ui_*() function to not start with 'ui_'.
In particular, GimpUi.ui_init() becomes GimpUi.init() which is much less
redundant.
shadow_bevel.py and sphere.py are unfinished and have been in the
"Unstable" only builds for years. This is probably not worth porting
them. Let's just delete them.
I have actually move these (as well clothify and whirlpinch removed
yesterday) to the gimp-data-extras repository so if anyone wants to
revive them, and port them to GIMP 3, they can start off from there.
Following Elad Shahar advice (cf. #4368), let's delete whirlpinch.py and
clothify.py.
The rational is that whirlpinch.py does the same thing as the existing
"plug-in-whirl-pinch" which is itself a compat plug-in to
"gegl:whirl-pinch" operation. Also the Python file has an explicit
command saying it is exactly the same algorithm, yet with no preview and
slower. Finally it was not even installed on stable build. It doesn't
look like there is any reason to keep it (it was probably a demo/test
Python plug-in).
As for clothify.py, a quick look at the short code shows it is exactly
the same algorithm as clothify.scm, with the same arguments and
installed on the same `Filters > Artistic` menu (except that the Python
version is not installed on stable builds).
So let's just keep the script-fu version as it has been the used version
until now, and there is no deprecation going on in one side or another.
So let's keep what already works.
Since the patch was initially contributed, some parts of the
introspection changed. First all GUI-related code is in a GimpUi module
now.
Also Gimp.get_pdb().run_procedure() is now using a list instead of a
GimpValueArray.
Note by reviewer (Jehan): merging this port as it was in GIMP 2.10
anyway, but is this even still needed code? This plug-in is not even
available on stable release, it looks like for-development only
benchmark, and I'm not sure if it's relevant anymore, especially in our
GEGL-fueled new world.
Please anyone who knows a bit more on the history of this plug-in and
the evolution of our gimp_drawable_foreground_extract() algorithm, feel
free to weigh in and tell us what this was for exactly and if it's still
relevant.
This is a basic port without any UI.
Invoking the plugin will just sort the entire palette based on
default parameters.
The original plugin had several broken options, which I tried to fix.
Plug-ins that work from different bindings probably want to use their
own list-type to specify arguments, rather than working with a more
cumbersome `GimpValueArray`.
This new API should make it less verbose. For example:
```
args = Gimp.ValueArray.new(5)
args.insert(0, GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE))
args.insert(1, GObject.Value(Gimp.Image, image))
args.insert(2, GObject.Value(Gimp.Drawable, mask))
args.insert(3, GObject.Value(GObject.TYPE_INT, int(time.time())))
args.insert(4, GObject.Value(GObject.TYPE_DOUBLE, turbulence))
Gimp.get_pdb().run_procedure('plug-in-plasma', args)
```
becomes
```
Gimp.get_pdb().run_procedure('plug-in-plasma', [
GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE),
GObject.Value(Gimp.Image, image),
GObject.Value(Gimp.Drawable, mask),
GObject.Value(GObject.TYPE_INT, int(time.time())),
GObject.Value(GObject.TYPE_DOUBLE, turbulence),
])
```
Reduce number of undo steps created by Spryrogimp previews.
First, by grouping them into a single undo.
The implementation adds a function for clearing the
incremental preview drawing that is being executed as an idle task,
and closing an undo group in case the preview left it open (which
would usually be the case). A second way to reduce undos is
by generating a new preview only upon mouse button release of
scales in the UI, and not while dragging the scale.
Just "Console" is enough in the context of menus with submenu hierarchy,
but when accessing directly the feature (with Action Search for
instance), a more accurate name is nicer. It avoids to have to check
what is what in the tooltip text.
Add visual tab to spyrogimp plugin for a more intuitive, visual
way of specifying the spyrograph pattern.
In addition, fix using the selection as the fixed gear, and add
option to save the pattern to a path.
Without the write permission for the owner, the `make install-plug-ins`
special target fails on Python plug-ins. And anyway I don't see a reason
why not give write permission to the owner (like all other plug-ins are
installed).
There is no reason to limit it to "xhtml" only. Even more, in all
browsers I tried, the exported page was failing to load with the '.xtml'
extension, while it loads fine when renamed as '.html'.
Only problem is that now we have 2 plug-ins able to save as html (other
is file-html-table) and the first in the procedure list (with no
explicit logics right now) will just shadow the next one. We will have
to add some generic infrastructure to allow people to choose favorite
load/export plug-ins, probably in Preferences, next to the raw plug-in
selection.
paste as brush, paste as pattern, select to new brush, select to new pattern
fill selection outline, fill path, stroke selection, distort, rounded rectangle
indexed color conversion, merge visible layers, new guide, new guide (by percent)
image properties, newsprint, fractal explorer, sample colorize, new layer
metadata editor (just a button), spyroplus (only common buttons)
It is a nearly full port. Some things would still need to be updated
(like deprecated use of GtkTable or gtk_range_set_update_policy()
removed), and other stuff need to be taken care of in GIMP API first.
But the core of the feature is there.
There are 2 TODOs to take care of here. First, there is no GUI yet for
the interactive mode which will just use the default values.
Second, the color argument is not working yet because I had issues
passing a GimpRGB as argument (ideally I should create a GimpParamRGB
with gimp_param_spec_rgb(), but since we still have the pygobject bugs
about manipulating GParamSpec data directly, I can't).
Anyway it works with default values, which is already a good first step.
:-)
Apart from porting, only code logics change is the whole
encode()/decode() code because it created a string vs bytes mess and the
zipfile API apparently didn't like to deal with bytes, even though the
docs say otherwise.
It's hard to test on my UTF-8 system, so please anyone working with
non-UTF-8 paths, we welcome reports if ORA load/save does not work
properly.
Other than this, load, save and load_thumb were all tested and working
properly so far.
So it seems that whatever is in _SCRIPTS is not in the distribution by
default (I suppose the reason is that even scripts can be generated). So
let's add the non-generated scripts to EXTRA_DIST.
1/ First I realize we were still using AM_PATH_PYTHON() and not
AM_PATH_PYTHON3().
2/ We don't need to check anymore for pygtk, pycairo, nor do we need
Python headers. Everything is now taken care of by GObject
Introspection and we have nothing else to build GIMP-side.
3/ Change --enable-python into --with-python. We don't actually build
anything now. There is no Python support to enable or disable
anymore. We simply install Python plug-ins or not. The 3 values are
"yes" (default, configure breaks if a Python 3 interpreter is not
found), "no" (Python plug-ins are not installed, not recommended) and
"force" (install Python plug-ins anyway even if an interpreter is not
found; this can be useful especially for cross-compilation since
Python is not useful at build-time anymore).
Note that --with-python=force, if an interpreter is not found, the
file `pygimp.interp` won't be installed. This is not a problem at all
if the interpreter can be found at runtime the standard way.
Otherwise packagers should add themselves a pygimp.interp file with
the known interpreter path.
Oups, I left the plug-in as Python 2. This was still a good
proof-of-concept that GIMP 3 will support as well Python 2 and Python 3
(even though Python 2 is end-of-life soon anyway).
This first version will just offset by 1 in interactive mode, by
default. The GIMP 2 version used to have a GUI, but it was not created
by the plug-in itself. I am guessing that maybe our Python wrapper used
to create GUI by default.
If so, this will have to change. Python plug-ins will be responsible of
their own GUI, just like C plug-ins.
Older palette-to-gradient used to have a palette argument. Bring it
back. The logics is that if the string is empty or None, the procedure
will use the currently selected palette. Otherwise it will try to
transform the named palette into a gradient and will fail with an error
if this palette does not exist.
Jehan