After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 97266 - add gimp_progress_bar_hide and gimp_progress_bar_show pdb functions
add gimp_progress_bar_hide and gimp_progress_bar_show pdb functions
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Plugins
git master
Other All
: Normal enhancement
: Future
Assigned To: Nathan Summers
Nathan Summers
Depends on:
Blocks: 6010 96815
 
 
Reported: 2002-10-30 23:18 UTC by Nathan Summers
Modified: 2005-01-19 00:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nathan Summers 2002-10-30 23:18:49 UTC
The constant popping up and closing progress bar windows that show up when 
certain scripts are run can be irritating and in some cases may be a 
bottleneck.  A simple fix is to have hide and show functions that 
determine whether to pop a progress bar window up.  A count is used so 
that multiple calls to hide require an equal number of calls to show 
before the windows are shown again.

Rockwalrus
Comment 1 Manish Singh 2002-11-16 21:49:22 UTC
A better fix would be to keep a small progress/status window around
for the entire duration of the script, It's important to give user
feedback. This involves more core changes though.
Comment 2 Raphaël Quinet 2002-11-17 12:08:14 UTC
I agree.  Hiding the progress bar(s) would be a bad idea.  There
should be at least one progress bar visible somewhere.  I don't think
that it would be easy to have one bar that moves linearly for the
entire duration of the script, because most of the time the script
does not know if one of the function calls will last several orders
of magnitude longer than the other ones.  I don't mind having a
progress bar that is reset for every new fucntion call that is made
by the script.  Maybe there could be two progress bars, like in the
window that is displayed when the GIMP starts: the top one would be
controlled by the script and the bottom one would show the progress
of each function call.  I suggest to close this as WONTFIX and to
open a new bug report with the better solution.
Comment 3 Nathan Summers 2002-11-18 20:15:30 UTC
Interesting idea, but it's not scalable. Here at work we have an 
extension that calls a script that calls another script for part of 
its work, and of course that script calls plug-ins. Of course, the 
two scripts could be merged into one unmaintable mess (and we would 
have to have two copies for when we need the second script without 
the first), but that would still leave three levels on the call 
stack. In our situation, supressing the progress bar completely would 
be quite desirable, but I can see in general how it would be good to 
have some progress bar of some sort up, even if the plug-in's 
progress bar is rather useless.

It seems like we really need to have a stack in the plug-in api (I 
seem to recall that there already is something like that, but I think 
it works in the /inverse/ of what is the desired functionality.  I 
don't have access to the code right now to check.)  The progress bar 
on the _bottom_ of the plug-in stack would be the one displayed.  It 
would be nice if the progress bar could be an arbitrary widget in an 
extension's window.

It would be nice if the progress stack would have a signal propagated 
up whenever a lower-level progress bar changed (so that it could 
update its progress accordingly.) Practically, however, the 
disadvantages (wild superfluous IPC, complications in plug-in code) 
would probably outweigh any advantages.)
Comment 4 Michael Natterer 2004-08-10 18:48:50 UTC
2004-08-10  Michael Natterer  <mitch@gimp.org>

	Redid the whole internal progress stuff: don't pass around
	progress_callback and progress_data; instead, provide a
	pointer to a GimpProgressInterface which can be implemented
	by a variety of backends.

	Addresses (but not yet fixes) bugs #6010, #97266 and #135185.

	* app/display/Makefile.am
	* app/display/gimpprogress.[ch]: removed the old progress hack.

	* app/core/Makefile.am
	* app/core/core-types.h
	* app/core/gimpprogress.[ch]: implement GimpProgressInterface.

	* app/widgets/Makefile.am
	* app/widgets/widgets-types.h
	* app/widgets/gimpprogressdialog.[ch]: the standalone progress
	dialog as widget implementing GimpProgressInterface.

	* app/display/gimpdisplay.c
	* app/display/gimpstatusbar.[ch]
	* app/widgets/gimpfiledialog.[ch]
	* app/widgets/gimpthumbbox.[ch]: added GimpProgressInterface
	implementation to these classes.

	* app/core/gimp-gui.[ch]
	* app/gui/gui-vtable.c: replaced the old progress vtable entries
	by two new to create and destroy a GimpProgressDialog in case
	no other progress is available.

	* app/pdb/procedural_db.[ch]
	* app/plug-in/plug-in-run.[ch]
	* tools/pdbgen/app.pl: pass a GimpProgress to all PDB wrappers and
	all plug-ins.

	* app/plug-in/plug-in.[ch]
	* app/plug-in/plug-ins.c
	* app/plug-in/plug-in-message.c
	* app/plug-in/plug-in-progress.c: handle the case there the
	plug-in was crated with a progress as well as the case where it
	wasn't.

	* app/app_procs.c
	* app/batch.c
	* app/xcf/xcf.c
	* app/file/file-open.[ch]
	* app/file/file-save.[ch]
	* app/widgets/gimphelp.c
	* app/widgets/gimpbrushselect.c
	* app/widgets/gimpfontselect.c
	* app/widgets/gimpgradientselect.c
	* app/widgets/gimppaletteselect.c
	* app/widgets/gimppatternselect.c: changed accordingly.

	* app/core/gimpimagefile.[ch]
	* app/display/gimpdisplayshell-dnd.c
	* app/gui/file-open-dialog.c
	* app/gui/file-open-location-dialog.c
	* app/gui/file-save-dialog.c
	* app/widgets/gimplayertreeview.c
	* app/widgets/gimptoolbox-dnd.c: pass a GimpProgress to all file
	related functions. Embed the progress in the file dialog where
	possible.

	* app/core/gimpdrawable-blend.[ch]
	* app/core/gimpdrawable-transform.[ch]
	* app/core/gimpimage-convert.[ch]
	* app/core/gimpimage-flip.[ch]
	* app/core/gimpimage-resize.[ch]
	* app/core/gimpimage-rotate.[ch]
	* app/core/gimpimage-scale.[ch]
	* app/core/gimpitem-linked.[ch]
	* app/core/gimpitem.[ch]
	* app/core/gimpchannel.c
	* app/core/gimpdrawable.c
	* app/core/gimplayer.c
	* app/core/gimpselection.c
	* app/vectors/gimpvectors.c: replaced callback/data by GimpProgress.

	* app/tools/gimpblendtool.c
	* app/tools/gimptransformtool.c
	* app/gui/convert-dialog.c
	* app/actions/documents-commands.c
	* app/actions/file-commands.c
	* app/actions/image-commands.c
	* app/actions/layers-commands.c
	* app/actions/plug-in-commands.c
	* app/actions/vectors-commands.c
	* tools/pdbgen/pdb/convert.pdb
	* tools/pdbgen/pdb/edit.pdb
	* tools/pdbgen/pdb/image.pdb
	* tools/pdbgen/pdb/layer.pdb: changed callers accordingly.

	* app/pdb/*_cmds.c: regenerated.
Comment 5 Michael Natterer 2004-08-30 14:59:43 UTC
Can we consider this as FIXED now?

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.