bootchk had the case in commit 6781a35668. I again had it with gfig. I think it
just makes sense to init GEGL, especially as the errors are not that explicit
and that the plug-in code may not even call GEGL code directly (so it makes it
harder to guess).
After the recent port.
* contrast-retinex: Initialize format & src_buffer to NULL
* curve-bend and map-object: Remove no longer needed functions
* file-load-gif: Fix C++ style comment
Resolves#10119.
If the user sets the "Image Spacing" and "Hole Width" values
to 0, the hole creation code gets stuck in an infinite loop.
This patch adds a check to the allocation code for the hole
to make sure both its dimensions are greater than 0. If not,
then the hole is not created in the first place.
If the GIF has a value other than 0 or 49 in its PixelAspectRatio
header, then we now use it to set the non-square pixel resolution.
For reference, GIFs calculate this value like so:
PAR = (Value + 15) / (float) 64.
- Fonctions were renamed: s/gimp_text_fontname/gimp_text_font/ and
s/gimp_text_get_extents_fontname/gimp_text_get_extents_font/
- The size_type arguments were removed. Even in 2.10, this argument was marked
as "dead" and ignored. It was only kept for API compatibility.
- The font name (string) was replaced by a GimpFont argument.
gimp_text_font() is easily tested in the Python console with:
> Gimp.text_font(Gimp.list_images()[0], None, 10, 40, "Hello World!", 1.0, True, 100, Gimp.context_get_font())
And gimp_text_get_extents_font() with:
> Gimp.text_get_extents_font("Hello World!", 100, Gimp.context_get_font())
Hardcoded colors don't work well with theme customization (on a dark theme in
particular, it was bad).
Anyway built-in units are already grayed-out and non-editable. I don't think
further styling is needed.
… function gimp_font_get_pango_font_description().
Also updating file-pdf-save which is the only plug-in using these right now.
Note that I am not fully happy with the new function
gimp_font_get_pango_font_description() because I experienced some weird behavior
in file-pdf-save which is that some fonts were wrong if this is called after
pango_cairo_font_map_set_resolution().
But let's say this is a first step looking for improvements.
...and to GimpProcedureDialog.
Also resolves#25 by adding the missing PDB parameters to the GUI.
Note that there are a few remaining tasks:
* The config values are being copied to mapvals.
Eventually the rest of the code needs to be updated
to directly use the config.
* The material tab uses icons from the Lighting plug-in. They didn't show up before the port; this needs to be fixed.
* The drawable buttons are huge compared to the original plug-in. The styling needs to be looked at.
Converted to GimpProcedureDialog as well, and changed the
string argument for the combobox to GimpChoice.
Some widgets are still standalone and could be further improved
to work with GimpProcedureDialog.
A new aux parameter for upper/lower border area was added so this could be generated
as part of the GUI.
I received warnings about serializing the FloatArray and GBytes parameters, so I did not integrate
the existing variables with GimpProcedureConfig in this current version.
The only missing feature is that we don't constrain the various argument
drawables to RGB/grayscale or to the same dimension as the input drawable. This
could actually be quite easily implemented, either through a set of constraint
flags, or a more flexible callback function (similar to the API of
gimp_drawable_combo_box_new()). It could either be implemented on the argument
level (which has the advantage of letting libgimp handle argument sanity of
plug-in developers, even in non-interactive calls, with generic error messages)
or within the new GimpDrawableChooser API.
I was actually implementing this when I realized that this plug-in works fine
even with images of different dimensions. As for the format, GEGL handles format
conversion automatically. There is absolutely no reason to limit ourselves.
So let's drop this feature for now, because we should not over-engineer. If it
turns out useful and we get requests, we can always create later either a
specialized arg macro GIMP_PROC_ARG_CONSTRAINED_DRAWABLE() or a method to
specialize the widget with gimp_drawable_chooser_new_constrained() for
instance).
A few minor code style issues were also fixed.
Note that there's only one procedure parameter (Preset name),
but it's not retained between runs.
I want to ask about this before making a full conversion to
GimpProcedureDialog widgets.
This name was really irking me because it's not a button (anymore? Maybe it used
to be just a button). Depending on the specific widget, it will have several
sub-widgets, including a label. And it can theoretically even be something else
than a button.
So let's just rename these widgets with the more generic "chooser" name.
- Increase the default size to 40x40 and multiply it by the current window scale
factor to have decent preview size.
- Make the brush preview always square with a GtkAspectFrame: even though
brushes are not necessarily square, this is a much more obvious size rather
than letting GTK choose a random allocation size which ends up very weird
looking.
- Scale down the brush to the biggest possible dimensions which fit the square
preview area (if the brush native size is already smaller, I don't scale up
though) while keeping aspect ratio: previous implementation was really weird,
as we were only seeing a tiny corner of much brushes as we weren't scaling
them down. Obviously I use new gimp_brush_get_buffer|mask() functions for
this as it supports scaling.
- Implement drawing color brushes too: the previous implementation was only
drawing the brush mask, which was absolutely not what would be expected for
such brushes.
- Add a white background behind color brushes with transparency.
- Simplify and clean up the code.
One of the consequences of this new implementation is obviously that it's
mandatory to call gegl_init() when using this widget.
- Move the property widget functions for GimpResource properties into a new
libgimp/gimppropwidgets.[ch] file. This mirrors the files
libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types.
- Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new().
- gimp_prop_chooser_factory() doesn't need to be public.
- Add a label to GimpResourceSelectButton, make so that the
gimp_prop_chooser_*_new() functions set the property nick to this label and
add this label to the size group in GimpProcedureDialog.
- Removing useless or redundant code.
- Simplifying various logics.
- Using GimpResource directly in temporary PDB procedures, not resource names.
- Better cleanup of the core resource chooser when the plug-in dialog quits (we
need it to ask core to close also any visible resource chooser dialog).
- Replace the "Close" button by more common OK/Cancel. In particular, the
GimpPdbDialog now properly keeps track of the initial object and when hitting
"Cancel" (or Escape key), this initial object is set back.
- Clean up some of the comments, especially when the code is self explanatory.
There is still much more to clean and improve, but it's a first welcome step.
One instance of `(GIMP_VALUES_GET_INT (args, 0)` was missed during the initial conversion.
This caused a compiler error. The value is now retrieved from the GimpProcedureConfig
object.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
...and to GimpProcedureDialog.
selection-to-path-dialog.c was also removed as the code can now be contained
within selection-to-path.c thanks to the new API.
The various information (width, height, image type and number of layers) are
those of the full image, not of the thumbnail. Make it clear in the docs of
GimpRunThumbnailFunc.
Additionally:
- file-xmc was returning the proper information but variables were wrongly
named, which was confusing.
- Fix file-ico thumbnail proc which was returning the thumbnail width/height.
- In file-darktable, initialize width/height to 0 so that we just don't show any
size when we don't get the information. It's better not to show anything than
completely wrong information (the thumbnail target size).
We were choosing the bigger icon in the ICNS list. Instead let's choose the
bigger icon within the target size bounding box. In case there is no smaller (or
equal size) icon, we falls back to the smallest bigger icon.
Also make sure we set width and height to the full image size, as this is used
as information on the full image (not the thumbnail).
SVG is a vector format which is easy to render exactly within the size×size
bounding box. Let's make sure we do so.
This makes for much sharper SVG thumbnails (and also possibly faster thumbnail
render).
… than a GimpValueArray.
Similar to other GimpProcedure, move to using a config object. A difference is
that thumbnail procedures are always run non-interactively.
Also fixing WMF load thumbnail procedure: the dimension computation was wrong
when the image was wider than tall.
Also the palette argument is now a proper GFile argument (not a string).
There is also a palette argument for the export procedure, but it's currently
unused. A palette storing function will need to be implemented.
Some bit of additional logic cleanup was done.
Again, I am losing a tiny bit of UI, in particular the ratio fields, but also
the update of the size label (this was kinda broken anyway, as it updated only
when updating some fields, not others).
Also moving the default resolution to 300 PPI.
Last but not least, I transformed the "paths" int argument to a GimpChoice
argument.
The new dialog is not fully on-par with the old one. We lost the X and Y ratio
fields as well as the ability to constrain dimensions to each other. This should
be improved when we'll get proper automatically generated widgets for dimension
arguments.
Also fixes some spelling issues and removes a warning about an
uninitialized variable.
Currently the only argument is for non-interactive mode, so
the dialogue isn't ported to GimpProcedureDialog yet.
The dialog itself is ported to GimpProcedureDialog. However, the
width and height require another API that allows for size entries with
multiple fields before it can be considered finished.
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.
I was hoping to redesign further but the whole logic of animated brush creation
is made so complicated that I think it would require a whole more complex GUI
with visual hints. So anyway I stopped at basic redesign and port to the new
dialog generation code.
It still makes the code much simpler and a bit more powerful (also less bugs
hopefully). I have also reviewed the procedure arguments, removing redundant
ones (display-cols and display-rows are just computed from cell-width and
cell-height) and adding some aux arguments instead to simplify dynamic GUI code.
It's the basic stupid port, though this dialog is so bad that I think I'm going
for a second stage with a basic redesign of this GUI while also moving to
GimpSaveProcedureDialog. To be continued.
The arg "num-images" is clearly redundant as the "images" array already has this
information. Moreover it is bug-prone, for instance running 'Repeat "Filmstrip"'
would crash the plug-in which was defaulting to NULL "images" and 1 "num-images"
(without any GimpItem serialization ability yet).
Of course, we could just fix this, but better remove the redundant arg and all
possibilities of future similar bugs.
Also I now display a proper error message when running without input images
which says: "\"Filmstrip\" cannot be run without any input images"
The dialog itself is ported to GimpProcedureDialog, but the original
plug-in only had one config parameter (Number of Tiles).
Some of the other options might make sense as config parameters
such as the horizontal/vertical toggles and opacity.
I needed a few more GimpProcedureDialog widgets, which I now have. The only part
still not generated in this plug-in is the image selection. This is hundreds of
lines less!
It now has arguments for every usable setting (except "keep-height" which is an
aux arg because it is simulated with a 0 "film-height" in non-interactive mode).
Also the film-height/keep-height default in interactive mode is now much better.
I override the film-height default and set it to be the image's height. This
makes for a much better default at all time.
The "Reset" button in Advanced section is not useful anymore since we now have
the generic "Reset" (to Initial/Factory) of GimpProcedureDialog, though it
actually doesn't work right for the time being, as it fails serializing
GimpFont.
It would be worth porting when GimpDrawableComboBox widgets can be used as
GimpProcedureDialog generated widgets. Or even better, if the GimpPickableButton
were ported to libgimp to be used by plug-ins (since it's actually a lot more
usable).
I didn't port to GimpProcedureDialog because we'd need first a GimpSizeEntry
generatable widget, which can map to several properties (here for instance 3
width properties).
… working with a GimpProcedureConfig.
These are the easiest ones to port as most of the work was already done (mostly
just some now useless calls to remove).
Also in gimp_procedure_config_begin_run(), make sure we sync the arguments with
the config object first thing, even in interactive and with-last-vals case
(where the args may be further overridden). This was especially important for
Script-fu scripts as the image and drawable were not provided separately, so we
need to make sure that the config file has the right values.
A lot less lines for the same functionalities!
This includes improvements too:
* "include-pointer" as new PDB argument;
* settings storage thanks to GimpProcedureDialog;
* it should hopefully work better in non-interactive (though it's untested).
The macOS and Windows screenshots are untested after this change, though they
should still work the same. Please report if there is any problem!
Resolves#10069
Currently, the DDS header information for the width, height, and bytes per scan line
are read in and assumed to be correct. As these values are used for memory allocation
and reading, it would be good to verify they do not exceed the file size.
This patch adds a condition after the header is read in to verify those values. If they exceed
the file size (mins an offset), the file is not read in and an error message is shown.
Also refactoring: extract two functions
Add test case scripts/test/register-fail
Catches more registration errors.
Any errors not caught at least will not crash.
Remains to be ported to 2.10, but only a few lines, without the refactoring.
Resolves#10072.
The current PSP palette loading code does not check if
the file's palette entry count value is below the limit
(G_MAXUNIT32 / 4 due to each color being 4 bytes long).
This patch adds this check and stops loading if the count
is larger than GIMP currently supports.
Resolves#10071.
When reading RLE compressed data, a buffer was allocated to 127 bytes.
However, it can potentially be used to read 128 bytes, leading to a
off-by-one vulnerability. This patch allocates 128 bytes to the buffer
to prevent this from occurring.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
This commit and the ones prior are simple refactoring,
with no intended functional changes.
In anticipation of enhancements 9608 and 8404
which make returned values more scheme like.
Also makes code more readable.
For characters outside ASCII:
1. repr is wrong in REPL
2. sharp constant #\<codepoint> fails to evaluate
3. sharp constant hex #\x<hexdigits> accepts invalid UTF-8 codepoints
4. a call to error with such a character eats the output string
Also, changed the repr of ASCII control characters (was #\x7)
to their unicode repr (now a box glyph with hex)
Test framework and tests in Scheme, and portable.
Work in progress. Expect commits for more tests.
Testing framework is stable, more or less.
Add more tests
Add tests layer and layerMask.
test Item methods
More tests, selection
Test memory, vector in TS.
More tests char functions
sharp expr tests
Jehan