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
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.
Some coding style fixes, also one warning fix, and a lot of shuffling
around to reorganize the code. Basically removing the prototype listing
at the file start is a big error. This file is huge and without a
minimum of organization, it's a huge mess to understand what's what.
Basically a class file must always start by the class_init(), then the
init(), then the various object methods (constructed() or finalize() if
any, etc.), and possibly other parent classes' implementations. These
are the entry points, it's normal to start here (not from leaf
functions!).
Then we get the public functions which are other entry points (calls
from other parts of the code). And only after, private functions such as
signal or action callbacks, and utilities at the very end.
This requires a well organized prototype listing, which works as a menu,
and prevents the implementation order to depend on call order (this gets
us completely random order and imply usually that top functions are the
less important ones, such as utilities, just how it was before this
commit).
Anyway I'm not sure why I spent time on this because we deprecated this
plug-in, but if we still want to push nice updates (like MR !519), we
should at least do it well and clean. Also it's a good first example for
plug-in rewrite in modern no-GtkAction code.
The initial attempt of this commit was to remove the `GtkAction` usage,
but grew a bit wider than that. The following happened:
* The dialog became a proper GObject, rather than being a big chunk of
static variables that were hopefully initialized before you used them.
* The dialog now uses `GAction`s to implement actions, and converted
some signal handlers to actions as well.
* The plug-in run procedure now uses `GtkApplication`. This is one hand
necessary to be able to set accelerators for actions, but on the other
hand is more future-proof, as GTK4 removes `gtk_main()`
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
This is an official way to declare these plug-ins as now
unmaintained/deprecated.
Relevant plug-ins are:
1) help-browser (Displaying the docs): nowadays every desktop machine
has a browser. Let's just use whatever is the person's default
browser.
2) web-page (Web screenshot): it looks to me like every browser has this
feature by default now (I use it all the time in Firefox to get a
full-page screenshot, never in GIMP), even on mobile, I am told. It's
nice to have it in GIMP too, but not like absolutely necessary.
On the other hand:
1. It's a hell to build, with a lot of issues. We have regular issues on
our Flatpak-s. We don't manage to build it on our CI (only locally
apparently). Also it takes a crazy amount of time (like 90% of CI
build-time would be webkit).
2. From what I gather, new versions don't work on Windows anymore. Even
MSYS2 seems to have dropped the ball and don't try anymore.
Basically we would have a feature disparity from GIMP 3.0 (most
platform but Windows). We don't know when it will be resolved (if
ever) as it's been like this for years.
Now why we are keeping the code around instead of just removing
everything is that the topic tree in the help browser is useful and
comfortable to use. Ideally we should get some equivalent to help
browsing the help efficiently in the web docs as well (so basically
menus, web search and alike?). So I am told to keep the code around at
least for now to see if we can figure something out or improve the
situation.
Except for this point, we can consider the WebkitGTK plug-ins as
deprecated from GIMP 3.0 on.
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.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
This is the minimum set of changes needed to update help-browser to the
WebKitGTK+ 2 API. Fortunately, the plug-in did not use parts of the old
API which would have been difficult to port (DOM bindings, for example),
and therefore the code translates quite well to the new API. The main
differences are:
- WebKitWebFrame is gone, most of its methods are now in WebKitWebView.
- Searching for text inside Web pages has to be done now through the
WebKitFindController object.
- Checking whether there is selected text that can be copied now goes
through WebKitEditorState.
- The WebKitWebView::title-changed signal is no more, the callback is
connected to notify::title instead.
- The load-started and load-finished pair of signals are now merged
into WebKitWebView::load-changed.
- There are no methods to zoom a WebKitWebView in and out, instead
the zoom-level property is set. The updated code ensures that the
zoom lovel stays inside the [0.1, 10.0] range.
- Page visit history now goes through WebKitBackForwardList.
The updated plug-in was successfully built in tested with WebKitGTK+
version 2.20.3.
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.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
... standard icon names and GTK+ icon names as second choice.
We should only use GIMP specific icon names as last resort, when there
is no standard or GTK+ names dedicated to the function.
This is made possible thanks to commit 3cc77b0.
s/gimp-document-recent/document-open-recent/
s/gimp-indent/format-indent-more/
s/gimp-next/go-next/
s/gimp-previous/go-previous/
s/gimp-save/document-save/
s/gimp-save-as/document-save-as/
s/gimp-revert/document-revert/
s/gimp-open/document-open/
s/gimp-document-recent/document-open-recent/
s/gimp-quit/window-close/ ou s/gimp-quit/application-exit/
s/gimp-warning/dialog-warning/
s/gimp-edit-clear/edit-clear/
s/gimp-justify-.*/gtk-justify-.*/
s/gimp-font/gtk-select-font/
s/gimp-color-palette/gtk-select-color/
s/gimp-cancel/gtk-cancel/
Warning
g_thread_init has been deprecated since version 2.32 and should not be used in newly-written code. This function is no longer necessary. The GLib threading system is automatically initialized at the start of your program.
Jehan