Resolves#10530.
In GTK2, setting a window's scrollbar policy to GTK_POLICY_NEVER
hid the scrollbars. In GTK3, this also makes the window automatically
resize to fit the contents. Since ImageMap displays the full drawable
with no scaling, this caused the plug-in window to be very large for large
layers.
GTK_POLICY_EXTERNAL in GTK3 works the same as the GTK2 version of
GTK_POLICY_NEVER, so using it instead fixes the problem.
The default width and height magic numbers were also replaced with
constants.
Resolves#10611.
In GTK3, GtkRadioButtons are set using the "active" property
rather than selected, so the callback needed to check the
GTK_STATE_FLAG_ACTIVE flag instead of GTK_STATE_FLAG_SELECTED
when changing grid types.
The code was also reformatted to match current coding style.
The grid state was not correctly updated when changed from within the
grid settings dialog.
Instead of using g_simple_action_set_enabled we need to use
g_simple_action_set_state, since we don't want to change whether the
action is enabled or disabled, but the checked/unchecked state.
This completes commit 685c8bde99 where the http:// scheme was automatically
transformed into https:// in some cases, in particular while typing (when
pasting for instance, it was still possible to add an http URL). So let's block
"toggled" signal handlers when the URL is explicitely edited to prevent this
annoying issue.
(cherry picked from commit b991f8b361)
The targets were just being left floating, and the pre-generated in-tree
source were always used instead
When bison/flex are found, ensure we actually dep on their output - thus
actually running the targets - and only use the in-tree copies as a
fallback
This adds "https://" as a valid website prefix in the ImageMap URL edit
field, in addition to http://.
It also restores the prefix change that 2.10 had when you switched URL
types. It also fixes code formatting in affected areas.
Additionally, the ImageMap-specific icons weren't showing up due to the
filenames not matching the references strings ("imap-polygon" but
the filename was "imagemap-polygon.png"). This patch fixes that by
renaming the strings to match file name.
Partial code style fixes were made as well; a lot more are needed.
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
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
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.
As explained in previous commits, the _peek_ call is advantageous
because:
- It is less bug-prone as we don't have to handle freeing the string. In
all the cases I changed, I even spotted at least 2 cases where we were
leaking a string (in file-mng, `temp_file_name` is never freed; and we
were also leaking in an error case of gfig).
- As a consequence of the previous point: simpler code with less lines.
- In local file cases, the _peek_ variant does not even need to allocate
an additional string.
- In other case, if we query several times the path, it is allocated
once and cached so it stays efficient.
- When possible, working on the GFile rather than on a path string may
be more robust. For instance I changed one g_unlink() into a
g_file_delete(). Actually most reading/writing should be done with the
GIO API when possible, but I didn't want to change too much code
logics on this commit.
The gimp_drawable_type() is an issue though as gimp_drawable_get_type()
is already defined as a common GObject API.
Though I'm actually wondering if GimpImageType is well called. Rather
than Type, shouldn't we go with ColorModel?
sed -i 's/\<gimp_drawable_bpp\>/gimp_drawable_get_bpp/g' "$@"
sed -i 's/\<gimp_drawable_width\>/gimp_drawable_get_width/g' "$@"
sed -i 's/\<gimp_drawable_height\>/gimp_drawable_get_height/g' "$@"
sed -i 's/\<gimp_drawable_offsets\>/gimp_drawable_get_offsets/g' "$@"
s/gimp_image_base_type/gimp_image_get_base_type/
s/gimp_image_width/gimp_image_get_width/
s/gimp_image_height/gimp_image_get_height/
Sorry plug-in developers, more porting work! But really this seems like
the right thing to do in order not to get stuck with inconsistent naming
for many more years to come.
This gives a big cleanup in the meson.build files of the plug-ins.
It's also quite a bit more maintainable, since anything that changes in
libgimp's dependencies, linkage, ... doesn't have to be copy-pasted into
each plug-in.
This fixes:
> warning: source file 'images/imagemap-icon-images.c' is in a subdirectory,
> but option 'subdir-objects' is disabled
And similar warnings.
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
It was agreed that we should write "plug-in" consistently. Only possibly
user-visible strings were updated.
Thanks to scootergrisen for a first patch which could not make it
after changing decision on the canonical writing.
Alx Sa