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
When the selection changes, the focus must be on one of the selected items. Not
doing this was creating a very annoying behavior where you would select an item
in the tree view with the pointer first, but then when moving up/down with the
keyboard arrow, the move originated from the previously set item. This was
because the arrow move used the "cursor path", i.e. the keyboard focus, and not
the item selection as origin.
In our case, let's make sure these match (i.e. the cursor path is the path of at
least one of the selected items, which is the most expected behavior for mixed
pointer/keyboard interactions).
See code in gtk_tree_view_move_cursor_up_down() from GTK code.
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.
… with another default shortcut.
This won't happen with the standard US layout, but among all the layouts which
exist (or will exist), there is no say that the characters behing <shift>2-5
keys are not another one of our default shortcuts for other actions. We don't
want to print this case, because it is special enough that it's really not a
bug. In this case, we just ignore the transformed shortcut on the zoom action
and be done with it.
Calling gimp_resource_delete() on a data with a file which was not stored yet
would fail on missing file as reported by Lloyd in a comment in #9976. We could
just special-case the code to make the already-inexisting case acceptable on
deletion, but there are a few more issues.
In particular gimp_data_create_filename() relies on actually checking file
existence on the file system. Therefore generating the file path too early
(before any possible rename, i.e. for uniqueness or other formatting need) would
easily generate duplicate paths (which means one of the data object would be
overwritten on exit). It's better to kinda *reserve* the set file path
immediately by saving the data file.
The only drawback I could see on saving early is possible I/O slowdown if a
script were to create many data, but I actually don't think it's a valid use
case (no script should likely create enough data files that we would notice a
slowdown, i.e. likely creating hundreds of data objects at once) anyway. So
let's go with it, at least for now.
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.
It returns all the fonts (possibly more than 1) with a given name. I left the
function gimp_font_get_by_name() as a utility when one don't want to choose (or
is not able anyway, e.g. a script with minimal information), though I wondered
if we should not simplify with a single function (the new one, which is the
correct one now that it is possible to have several fonts with a given name).
It is easy to test with fonts named the same. For instance I could find 2
different fonts, both named 'Holiday'. This call in the Python console returns
both:
> Gimp.fonts_get_by_name('Holiday')
As part of this commit, I also implemented resource arrays (or subtype arrays)
as PDB arguments and return types.
… description.
- The returned value as width/height/etc. of the glyph extents (or bounding
box), not "of the font" (which doesn't mean much).
- Adding some definition for ascent and descent. This text is straight out
copied from Pango documentation comments in pango/pango-types.h.
- I don't see why we were negating the descent value. Let's keep the value sign
as defined in Pango.
- 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())
- First do not write the protocol-version (and therefore don't read it either
nor compare it to the current one). This file does not depend on the protocol
version.
- Secondly when reading an unknown identifier, simply print a message on stderr
for debugging/reference, but ignore it up to the next closing parenthese.
- Finally do not use the file-version as a terminal error as well. When we read
a shortcutsrc with the wrong version, we still try to read it as best as we
can. There might be issues, but it's better than fully dropping the whole list
of shortcuts as it's a pretty important file (people might have spent a lot of
time tweaking their shortcuts!).
Fixing:
> [809/2421] Generating libgimp/GimpUi-3.0.gir with a custom command (wrapped by meson to set env)
> libgimpwidgets/gimppropwidgets.c:37: Warning: GimpUi: multiple comment blocks documenting 'SECTION:gimppropwidgets:' identifier (already seen at gimppropwidgets.c:23).
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.
This function is not perfect and in particular doesn't seem usable with binding
because of GimpUnit being some weird mix between an enum and some kind of class.
So this will have to be fixed too. See #8900.
… 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.
I am using the same GimpDrawableChooser with an additional drawable_type
argument to only show the appropriate tab if we want to limit what can be
chosen.
None of our plug-ins actually use a GimpLayer or GimpChannel only arg so far,
but if we have some day, or if some third-party plug-ins want to have such arg,
now they quite easily can!
After testing, setting a window as transient to another from another process is
still broken on Windows and it's hard to diagnose without using Windows
directly. Since it's not just broken, but it even hangs the whole process, which
is quite a blocker issue, let's disable again the whole code on Windows.
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.
Rodrigo Lledó