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 357059 - Edit > Paste As > Script Errors...
Edit > Paste As > Script Errors...
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Script-Fu
git master
Other All
: Normal minor
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-09-21 14:28 UTC by jbaker
Modified: 2007-05-06 04:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use (catch ...) to catch the exception (5.20 KB, patch)
2007-03-18 18:28 UTC, Michael Natterer
none Details | Review
Patch to fix this bug, but not the catch issue. (4.83 KB, text/plain)
2007-05-05 21:15 UTC, Simon Budig
  Details

Description jbaker 2006-09-21 14:28:46 UTC
Please describe the problem:
The Edit > Paste As > Menu items are active when clipboard is empty causing script errors...


Steps to reproduce:
1. Start Gimp - Do not add anything to clipboard
2. New Image
3. Edit > Paste As > New Image, New Brush, or New Pattern...
4 Click Ok to save...


Actual results:
New Image does nothing
New Brush or New Pattern = Script error...

Expected results:
Menu items should be inactive if clipboard is empty...

Does this happen every time?
yes

Other information:
Comment 1 Sven Neumann 2006-09-22 08:20:27 UTC
We can't make menu items insensitive because we don't know if the clipboard contains image data that could be pasted and there's no way we could find out (except for polling but that is not an option).

Not sure how this would best be solved. Perhaps we should port the scripts to Python where we could catch the exception. Or we could try to export the functionality of gimp_clipboard_has_buffer() to the PDB. The scripts could then check if there is image data to paste and abort instead of running into an error. This would not work 100% reliably because the clipboard content might have vanished between the check and the actual call to gimp-edit-paste but that would be quite unlikely.

The "Paste as New Image" functionality in the core should probably push an informative message to the status bar telling the user why nothing was pasted. If we would provide a PDB API for this, the scripts could do this as well.
 
Comment 2 Kevin Cozens 2006-09-22 16:16:43 UTC
The script versions of "Paste As" could be updated to catch the error when the call to the GIMP paste function fails. There is no way for the script to know if it failed because the clipboard is empty or because it contained non-image data.

What would be a good message to display to the user when "Paste As" fails?
Comment 3 Michael Natterer 2006-09-22 16:44:59 UTC
Addresses this problem for internal functions:

2006-09-22  Michael Natterer  <mitch@gimp.org>

	* app/display/gimpstatusbar.[ch]: changed all message setting
	functions to use printf-style argument lists. Added new API to
	show a temporary message that stays on top regardless of any other
	message activity and disappears after 3 seconds.

	* app/actions/edit-commands.c: show a statusbar message when
	pasting fails because the clipboard contains no image data. Pop a
	dialog when "Paste as New" fails. Addresses bug #357059 for
	internal functions.

	* app/display/gimpdisplayshell-title.c
	* app/gui/gui.c
	* app/tools/gimptool.c: changed accordingly.
Comment 4 Michael Natterer 2007-03-18 18:28:07 UTC
Created attachment 84835 [details] [review]
Use (catch ...) to catch the exception

I don't know what I'm doing wrong, but with this patch the
scripts still fail. They do catch the exception and show the
message, but then the entire script still fails.

Kevin, can you look at this please?
Comment 5 Kevin Cozens 2007-03-18 20:44:45 UTC
The patch looks good. The reason you feel the entire script still fails is due to the "Procedural database execution" error message it still spits out. This is due to the marshall_proc_db_call() routine in the scheme-wrapper.c file spitting out its own message when it detects that a call to a GIMP PDB function failed. You are getting two messages for the one problem. This is behaviour inherited from the days of the SIOD based Script-Fu plug-in.

The error handling mechanism should be changed. Calls to GIMP PDB functions which fail should result in an error message being placed in a buffer. An error code should be returned to the Scheme interpreter which should then decide what to do about the error. The default behaviour would be to display the error message placed earlier in the message buffer.
Comment 6 Sven Neumann 2007-05-04 07:51:51 UTC
Kevin, can you please look at this issue and decide how it should be handled. It is important that this is fixed for the 2.4 release.
Comment 7 Simon Budig 2007-05-05 21:14:20 UTC
I propose having gimp-edit-paste-as-new return 0 on a non-existing clipboard and handle that case in the scripts. This fixes this report, but does not adress the catch issue in script-fu.

Patch is attached.
Comment 8 Simon Budig 2007-05-05 21:15:26 UTC
Created attachment 87626 [details]
Patch to fix this bug, but not the catch issue.
Comment 9 Simon Budig 2007-05-06 04:44:51 UTC
Fixed in CVS, does not adress the wrongly output message in a catch. I will have a look at this. If we want to track this in bugzilla, this should go into a new bug.

2007-05-06  Simon Budig  <simon@gimp.org>

        * tools/pdbgen/pdb/edit.pdb: make gimp-edit-paste-as-new not fail
        at an empty clipboard, but return -1 as image id.

        * app/pdb/edit_cmds.c
        * libgimp/gimpedit_pdb.c: regenerated.

        * plug-ins/script-fu/scripts/paste-as-brush.scm
        * plug-ins/script-fu/scripts/paste-as-pattern.scm: Changed
        accordingly, fixes bug #357059.

        * modules/controller_linux_input.c: changed some axis names to make
        more sense.