Bug 62100

Since the desktop file doesn't use any KDE specific tags and it works from KDE, I think 
this is a gnome bug. 

I investigated this a bit - according to strace, gnome is running the command
"display" fine, but then "display" exits for some reason - no error message
given. Here is the end of the strace:

22924 open("/tmp/magicfu3JAt", O_RDONLY|O_LARGEFILE) = 4
22924 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
22924 mmap2(NULL, 0, PROT_READ, MAP_PRIVATE, 4, 0) = 0
22924 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
22924 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
22924 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x401d9000
22924 read(4, "", 4096)                 = 0
22924 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
22924 close(4)                          = 0
22924 munmap(0x401d9000, 4096)          = 0
22924 rmdir("/tmp/magicfu3JAt")         = -1 ENOTDIR (Not a directory)
22924 unlink("/tmp/magicfu3JAt")        = 0
22924 _exit(1)                          = ?

Any ideas?

This is VERY odd, since it runs when started in any other way. Is there 
anything odd gnome does before starting an application, like clearing the 
environment or killing stdin/stdout/stderr completely? 
 
This seems to happen in something executed by display; At least with a quick 
grep, I can't find anything that would cause this strace snippet in 
ImageMagick itself.

I figured it out - "display" exits if it gets EOF on stdin. 
Try "display < /dev/null". I think the panel is correct to set
up stdin this this way (it opens /dev/null on stdin).

*** Bug 62162 has been marked as a duplicate of this bug. ***

Hmm... display will accept images streams on standard input for and display
them. According to the man page, you are supposed to specify the file as "-" for
this to happen, but experiment shows that it does this even if you don't.

One fix is to change the command to 
/usr/X11R6/bin/display SOMEFILE.png 
perhaps we could use
/usr/share/doc/ImageMagick-5.4.3.11/images/magick.png
or perhaps we could use a custom image.

This fix works for me at least.

*** Bug 55950 has been marked as a duplicate of this bug. ***

*** Bug 63136 has been marked as a duplicate of this bug. ***

Why work around it with weird hacks, it's probably just a simple bug where it
gets confused by an immediate EOF on stdin... it's just not handling stdin
correctly.

In utilities/display.c, when display is checking for command line arguments and
finds that no images are specified on the command line, it does the following:

        if (!isatty(STDIN_FILENO))
          option=(char *) "-";
        else
          option=(char *) "logo:Untitled";

So for non-tty terminals, it tries to read an image from standard out.  This
behavior is contrary to what the man page says, but I expect that  there are
some scripts out there that rely on it.  You could simply change this to

        option=(char *) "logo:Untitled";

which would conform to the behavior described in the man page but may break some
(arguably ill-written) scripts, or you could change the Gnome launcher command
to "display logo:Untitled", which would not break anything.

...or you could check for an eof on stdin before automatically assuming it is an
image stream.

s/standard out/standard in/ 
:-o

since this bug does not seem to be resolved,
I suggest to issue an update to ImageMagick package which would remove the gnome
menu entry of ImageMagick.

that would solve all the problems.

having a non-working default menu entry in the GNOME main menu gives a very bad
reputation  to RedHat Linux distribution.

Created attachment 58304 [details]
patch for the ImageMagick-5.4.3.11-1 spec file to fix this problem

*** Bug 66458 has been marked as a duplicate of this bug. ***

*** Bug 65860 has been marked as a duplicate of this bug. ***

this bug is still present in Limbo

Yes, it is present Limbo public beta 1, but the latest ImageMagick rpm
(ImageMagick-5.4.7-3 -- not in Limbo public beta 1) does fix this problem.