This proposes enhancing PDB gimp_display_new() to successfully return a
null display when non-interactive, and enhancing PDB gimp_display_delete
to return success even for a null display.
Most scripts (Python and Scheme) that call gimp_display_new() abort the
script when run in batch mode. The proposed changes implement null
displays. Only the behavior changes, not the signature.
Probably no scripts will need to be changed, neither scripts distributed
with Gimp nor third party scripts. (Few use other than
gimp_display_new().)
The benefit of this change is that it simplifies plugin programming.
Plugin authors can worry less about the mode. Batch programmers can use
more plugins without regard for whether they call gimp_display_new().
(About ten Scheme plugins distributed with Gimp will cease to abort when
called in batch mode. Since the plugins don't return an image except to
display it, the plugins are not useful in batch mode, but the lack of a
return value from Scheme plugins is another issue.)
One disadvantage is that the error when a display cannot be created
(because of exhaustion of system resources) cannot be detected in a
script after this change. The error when a display cannot be created
because an invalid image is passed will still abort a script.
An alternative in Python is to bracket a call to gimp_display_new() with
try:except:, but there is no such alternative in Scheme.
The null display is similar to the null Linux device. The new, flush,
and delete display PDB operations will act on a null display, without
aborting, just as on a real display.
The other PDB operations on a null display:
gimp_display_is_valid() will return False on a null display,
gimp_display_reconnect will abort a script,
gimp_display_get_window_handle() will abort a script (on invalid
argument for the display.)
A patch is attached. It includes changes in display.pdb to
gimp_display_new() and gimp_display_delete().
