- Do not only check the step width, but also the time interval between 2
progress calls. No need to run a PDB call, then update the GUI every
millisecond or so. This would just unecessarily slow down the plug-in
for updates which the user won't ever see. From my tests, 20 updates
per second is plenty enough to have the progression look fluid. No
need for much more.
- Do not warn anymore on stderr when we drop progress updates. Even if
just on the unstable builds, such warning is wrong. First because it
depends on files and machines. Typically a lot of processing could set
their progress updates relatively to layers. Yet we currently consider
that 1/256 steps are too small. So what if you have more than 256
layers? This would make the same code print a warning on big files,
and none on small files.
The second reason is that we should not encourage plug-in developers
to have limited progression updates, but the opposite (progression
info makes for good feedback), neither should we expect them to
compute the step size or the time between updates. It's a much saner
approach to have them only take care about computing relevant update
steps while our API focuses on filtering these in order to avoid
overloading the GUI.
It makes for good progression feedback, sharp GUI while not taking all
CPU time on it, all this while making it easy on plug-in developers.
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.
- don't include <gdk-pixbuf/gdk-pixbuf.h> in headers in app/
- instead, include it in many .c files instead of <glib-object.h>,
finally acknowledging the fact that app/ depends on gdk-pixbuf almost
globally
- fix up includes as if libgimpbase depended in GIO, which it soon will
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-05-04 Sven Neumann <sven@gimp.org>
* libgimp/gimpprogress.c (gimp_progress_update): print a warning
on stderr if a plug-in updates the progress too frequently.
svn path=/trunk/; revision=22402
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-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 Michael Natterer <mitch@gimp.org>
* libgimpbase/gimpbaseenums.h (enum GimpProgressCommand):
added GIMP_PROGRESS_COMMAND_PULSE.
* libgimpbase/gimpbaseenums.c
* plug-ins/pygimp/gimpenums.py
* tools/pdbgen/enums.pl: regenerated.
* app/core/gimppdbprogress.c: implement GimpProgress::pulse()
and send a PULSE command to the callback.
* libgimp/gimpprogress.c: handle PULSE by calling the set_value()
callback with a value of -1 and document that hack in the API docs.
* libgimp/gimpprogressbar.c: interpret -1 as request to pulse.
2004-08-30 Michael Natterer <mitch@gimp.org>
Brought the PDB progress into a working state. Fixes bug #6010,
addressed bugs #97266 and #135185 and unfortunately reopens bug
#150194 (will fix that later).
* libgimpbase/gimpbaseenums.h: added enum GimpProgressCommand.
* app/core/gimppdbprogress.c
* libgimp/gimpprogress.c: use the enum instead of integer
constants for the different progress commands. Cleanup.
* app/plug-in/plug-in-progress.c
* app/plug-in/plug-in-run.c
* app/plug-in/plug-in.c: switch bach to real refcouting for
plug_in->progress (reopens bug #150194) and enabled the PDB
progress code.
* plug-ins/script-fu/script-fu-scripts.c: cleaned up the
progress stuff and the script-fu interface a bit.
* plug-ins/pygimp/gimpenums.py
* plug-ins/script-fu/script-fu-constants.c
* tools/pdbgen/enums.pl: regenerated.
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.
Jehan