We had 2 flags to indicate that a PDB argument could be nullable:
null_ok and none_ok. That was a huge mixup and the PDB generation code
was using sometimes one, sometimes the other. Let's settle for only
none_ok.
This fixes a bunch of annotations.
While setting a plug-in as transient usually worked, it was failing in
cases the plug-in's progress bar was not initialized (i.e. if
progress_init() was not called before setting the dialog transient).
This commit stores the calling display, core side too (libgimp side, the
plug-in already had the calling display ID information), and we use this
when a GimpProgress has not been created yet.
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.
Fix the dependency by making the stamp an actual (yet empty/no-op)
header file which is included by all generated source file. This way, we
ensure that meson rebuild .o files when the .pdb sources are changed.
This is the second solution proposed by eli-schwartz here:
https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080053413
Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
Same for returned value though it seems we have no function with none_ok
as return value. At least we have the rule in the generation script for
when this will happen.
No need of is_id_arg() anymore in pdb/lib.pl. Let's reuse the {id}
value. Also I had to add an additional trick for GimpDisplay which we
will now generate as such in libgimp PDB files, but still need to show
as GimpObject on app/pdb/.
As previously, only the new classes and the PDB generation for a first
step.
So a value array can now we created like this:
array = gimp_value_array_new_from_types (&error_msg,
G_TYPE_STRING, "foo",
G_TYPE_INT, 23,
G_TYPE_NONE);
Change PDB generation to use this, which makes for much nicer code in
the libgimp wrappers, and only set arrays separately instead of all
values.
This reverts commit 833666d462.
The _pdb files are an implementation detail and we do not want
separate doc sections for them, the conflicts need so be resolved in
another way.
Otherwise we get a few duplicate sections since some of the non-PDB
files are named similarly.
Fix this GObject introspection warning and other similar warnings:
> libgimp/gimp_pdb.c:28: Warning: Gimp: multiple comment blocks
> documenting 'SECTION:gimp:' identifier (already seen at gimp.c:129).
All foo_pdb.c functions in libgimp regenerated. I have reviewed this a
dozen times, but please have a look, there might well be glitches and
our public API is sortof important...
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2007-07-25 Sven Neumann <sven@gimp.org>
* tools/pdbgen/pdb/progress.pdb: added new procedure gimp-progress-end.
* app/pdb/progress_cmds.c
* app/pdb/internal_procs.c
* libgimp/gimpprogress_pdb.[ch]: regenerated.
* plug-ins/print/print.[ch]
* plug-ins/print/print-settings.[ch]: end the progress and save
the settings from the "end-print" handler. The plug-in then
appears finished but keeps running in the background until it has
finished the print operation.
svn path=/trunk/; revision=22994
2006-03-26 Michael Natterer <mitch@gimp.org>
* tools/pdbgen/lib.pl: removed support for arg->implicit_fill.
* tools/pdbgen/pdb/progress.pdb (progress_init): remove it without
replacement, the generated function on the libgimp side is
internal anyway.
* libgimp/gimpprogress_pdb.[ch] (_gimp_progress_init): rgenerated
with a display_ID parameter.
* libgimp/gimpprogress.c (gimp_progress_init): pass
gimp_default_display() to _gimp_progress_init().
2006-02-20 Sven Neumann <sven@gimp.org>
* tools/pdbgen/pdb/progress.pdb
* libgimp/gimpprogress.[ch]: applied slightly modified patch from
Stephane Chauveau. Wraps the gimp_progress_update() PDB call so
that redundant progress updates are suppressed in libgimp. This
gives a noticeable speedup for all plug-ins that update the
progress too often (bug #331470).
* libgimp/gimpprogress_pdb.[ch]: regenerated.
2005-09-29 Michael Natterer <mitch@gimp.org>
* tools/pdbgen/pdb/progress.pdb: removed the "wrap" from
gimp_progress_set_text() so it shows up as libgimp function again.
* libgimp/gimpprogress_pdb.[ch]: regenerated.
* libgimp/gimpprogress.[ch]: changed the old
gimp_progress_set_text() to gimp_progress_set_text_printf() and
added gimp_progress_init_printf(). (did this because the method of
calling init(NULL) followed by set_text("foo") caused popup
progress windows to be resized after they were shown).
* libgimp/gimp.def: changed accordingly.
* plug-ins/*/*.c: use gimp_progress_init_printf() instead of
init(NULL) plus set_text(foo) and changed users of set_text() to
use set_text_printf().
2005-09-09 Michael Natterer <mitch@gimp.org>
Added parent window API to the GimpProgress interface and to
the libgimp progress stuff. Might look strange, but does
the right thing in almost all cases (image window, file dialog,
script-fu dialog etc). Fixes bug #62988.
* app/core/gimpprogress.[ch]: added GimpProgress::get_window()
which should return a toplevel window ID if the progress is in a
window that wants to be the transient parent of plug-in dialogs.
* app/widgets/gimpwidgets-utils.[ch] (gimp_window_get_native): new
function which returns the window handle of a GtkWindow's GdkWindow.
* app/widgets/gimpfiledialog.c: implement ::get_window().
* app/display/gimpdisplay.[ch]: ditto. Removed window handle API.
* app/gui/gui-vtable.c: changed accordingly.
* libgimpbase/gimpbaseenums.[ch] (enum GimpProgressCommand):
added GIMP_PROGRESS_COMMAND_GET_WINDOW.
* app/plug-in/plug-in-progress.[ch] (plug_in_progress_get_window):
new function. Also renamed some functions to match the
GimpProgress interface, and not the legacy PDB procedure names.
* tools/pdbgen/pdb/progress.pdb
* app/core/gimppdbprogress.c: implement get_window() on both
sides of the wire, keeping backward compatibility (hopefully).
* libgimp/gimpprogress.[ch]: deprecated gimp_progress_install()
and added gimp_progress_install_vtable() which takes a vtable with
padding to be extensible. Added get_window() vtable entry and
dispatch it accordingly. Also added pulse() which was implemented
in a hackish way before. Everything is of course backward
compatible.
* libgimp/gimpprogressbar.c: inmplement the get_window() stuff
so a plug-in dialog containing a progress can be the transient
parent of another dialog in another plug-in.
* libgimp/gimpui.[ch] (gimp_ui_get_progress_window): new function
which returns a foreign GdkWindow of this plug-ins progress
window.
Renamed gimp_window_set_transient_for_default_display() to
gimp_window_set_transient() and make it use the progress' window
handle instead of the display's (which is the right thing to do in
almost all cases).
* libgimp/gimp.def
* libgimp/gimpui.def: add the new functions.
* tools/pdbgen/enums.pl
* app/pdb/internal_procs.c
* app/pdb/progress_cmds.c
* libgimp/gimpprogress_pdb.[ch]: regenerated.
* libgimp/gimpexport.c
* plug-ins/*/*.c: follow API change.
2005-08-03 Michael Natterer <mitch@gimp.org>
Changed naming scheme for PDB procedure names from
random_crap_that_traditionally_has_underscores to
enforced-canonical-identifiers. I'm pretty sure some things are
broken after this commit. More changes to come...
* libgimpbase/gimpbase.def
* libgimpbase/gimputils.[ch]: added gimp_canonicalize_identifier().
* app/pdb/procedural_db.[ch] (struct ProcRecord): added
"gchar *original_name" to keep a procedure's original name as
reigstered by plug-ins (compat cruft).
(procedural_db_init_procs): canonicalized list of deprecated
procedures.
* app/plug-in/plug-in-proc-def.c (plug_in_proc_def_free): free
original_name.
* app/plug-in/plug-in-message.c: canonicalize procedure names
which are received over the wire.
* app/plug-in/plug-in-rc.c: serialize the original_name and create
the canonicalized name on-the-fly when deserializing.
* app/plug-in/plug-in-run.c: pass the original_name to plug-ins
when running them because they strcmp() the passed procedure name.
* app/plug-in/plug-ins.c (plug_ins_add_to_db): pass
canonical procedure names to procedural_db_execute().
(plug_ins_file_proc_compare): special-case "gimp-xcf", not "gimp_xcf".
* app/xcf/xcf.c: changed static XCF procedures accordingly.
* tools/pdbgen/app.pl
* tools/pdbgen/lib.pl: do some trivial substitutions to generate
canonicalized names in app/, and C identifiers with underscores in
libgimp/.
* tools/pdbgen/pdb/brushes.pdb
* tools/pdbgen/pdb/fileops.pdb
* tools/pdbgen/pdb/gradients.pdb
* tools/pdbgen/pdb/image.pdb
* tools/pdbgen/pdb/palettes.pdb
* tools/pdbgen/pdb/patterns.pdb
* tools/pdbgen/pdb/plug_in.pdb
* tools/pdbgen/pdb/procedural_db.pdb
* tools/pdbgen/pdb/text_tool.pdb
* tools/pdbgen/pdb/transform_tools.pdb: canonicaloized procedure
names in calls to std_pdb_deprecated() and in procedure names in
generated C code.
* app/pdb/*_cmds.c
* libgimp/*_pdb.c: regenerated.
2005-02-13 Sven Neumann <sven@gimp.org>
* app/core/gimpprogress.c (gimp_progress_start): accept an empty
string.
* app/plug-in/plug-in-progress.c: if NULL is passed as message to
plug_in_progress_start(), set an empty string on the progress.
* tools/pdbgen/pdb/progress.pdb:
* libgimp/gimpprogress.[ch]: wrap the new gimp_progress_set_text()
PDP function with a function that accepts printf-like arguments.
* libgimp/gimpprogress_pdb.[ch]: regenerated.
* lots of plug-ins, most of them file plug-ins:
use gimp_progress_init(NULL) followed by gimp_progress_set_text()
to initialize the progress using the new API instead of constructing
a temporary string.
2005-02-12 Sven Neumann <sven@gimp.org>
* app/core/gimpprogress.[ch]: added GimpProgress::pulse.
* app/display/gimpdisplay.c
* app/display/gimpstatusbar.c
* app/widgets/gimpfiledialog.c
* app/widgets/gimpprogressbox.c
* app/widgets/gimpprogressdialog.c
* app/widgets/gimpthumbbox.c: implement it in the classes that
implement the GimpProgress interface.
* app/plug-in/plug-in-progress.[ch]: allow plug-ins to pulse their
progress.
* tools/pdbgen/pdb/progress.pdb: added a procedure for the new
functionality.
* app/pdb/internal_procs.c
* app/pdb/progress_cmds.c
* libgimp/gimpprogress_pdb.[ch]: regenerated.
* libgimp/gimp.def: updated.
2004-08-29 Michael Natterer <mitch@gimp.org>
Added an API to allow plug-ins to embed the progress for the
actions they trigger into their own GUI (attention: half-done and
broken code ahead...)
* app/core/Makefile.am
* app/core/core-types.h
* app/core/gimppdbprogress.[ch]: new object implementing dispatching
progress calls to a temporary PDB procedure in a plug-in.
* app/Makefile.am: force to link gimppdbprogress.o, bah!
* app/plug-in/plug-in-progress.[ch]: added API to install,
uninstall and cancel a PDB progress for this plug-in, but disabled
the implementation because it doesn't work yet.
* tools/pdbgen/pdb/progress.pdb: added pdb wrappers for the new
install, uninstall and cancel functions.
* libgimp/Makefile.am
* libgimp/gimp.h
* libgimp/gimpprogress.[ch]: added an API around the PDB progress
stuff.
* app/pdb/internal_procs.c
* app/pdb/progress_cmds.c
* libgimp/gimpprogress_pdb.[ch]: regenerated.
* plug-ins/script-fu/script-fu-scripts.c: use the new API to show
the progress in the script-fu dialog.
2004-08-27 Michael Natterer <mitch@gimp.org>
Moved the gimp_progress_init() and gimp_progress_update() PDB
functions to their own group because they don't belong to the
"Plug-In" namespace and will soon get more functions.
* tools/pdbgen/pdb/plug_in.pdb: removed the progress stuff...
* tools/pdbgen/pdb/progress.pdb: ...and added it here.
* tools/pdbgen/Makefile.am
* tools/pdbgen/groups.pl
* app/pdb/Makefile.am
* libgimp/Makefile.am: changed accordingly.
* libgimp/gimpprogress_pdb.[ch]: new generated files.
* app/pdb/internal_procs.c
* app/pdb/plug_in_cmds.c
* libgimp/gimp_pdb.h
* libgimp/gimpplugin_pdb.[ch]: regenerated.
