Perhaps a simple way to fix this would be to add a new configuration option that would specify that the custom command would be launched from the GUI program (gdmlogin and gdmgreeter) directly rather than by the daemon.  This would cause the custom command to be launched as the GDM user and should allow GUI programs to be launched okay.  Perhaps a new key like

CustomCommandRunAsGdmUser=true|false

Note related bug #451400

Do I get it right: if a custom command would be called from gdm, it would inherit the environment of gdm, which is a graphical environment and therefore applications with a gui would work. As the custom commands are currently called from a daemon, they don't inherit a graphical environment and consequently applications that require a gui don't work. So the problem is the inherited environment!? 

I have read that custom commands were primarily intended for local use, and not remote use. 

If the change to make custom commands run as gdm user is trivial (I have no clue whether it really is), that might be a temporary solution. But I wonder whether it would not be useful to introduce a new "class" of commands that could be used to start any kind of applications localy and remotely. 

You should say "if a custom command would be called from gdmlogin/gdmgreeter, it would inherit the environment of gdm.  More specifically since the greeter program has access to write to the Xserver, programs started by it also have such authorization.

The root daemon could set up an environment and since it has authority to read Xauth files and such, it could obtain a connection to the Xserver to run programs this way.  However, I think launching such commands from the greeter is a little easier to code and less error prone.  I think this also better lends itself to ensuring that all GUI programs are running under the same environment (shell, etc.).

Custom Commands show up in the Actions menu currently because their initial use was to create commands similar to the ones found in the Actions menu.  Perhaps some people want to create custom commands that really belong in a different menu?  If so, then perhaps we need to figure out how to further extend the way custom commands are defined to allow more configurability?  The fact that the Actions menu doesn't show up on XDMCP displays means that custom commands currently only are visible to non-remote users.  If people want custom commands on remote terminals, we have to figure out a way to enhance this code to support that, I'd think.

One idea might be to define such custom commands in the gdmgreeter .xml theme file.  This would restrict this feature to gdmgreeter (not gdmlogin), but it might be a clean place to specify that additional programs be launched along with the greeter.  Though since people download themes from public websites, we probably don't want to allow arbitrary commands.  But perhaps keywords that refer to custom commands that are in the GDM configuration files?  This way the administrator needs to set up the custom command for the theme to actually start working with this feature, which is probably good.  People/distros should make a conscious decision about what commands they allow here.

If you take my approach suggested above, then hacking gui/greeter/greeter_parser.c so that you can specify programs to run by specifying the custom command number, and then making the greeter run that program shouldn't be too hard to figure out.  Much of the code that already exists shows how to do the tag/element parsing and there are plenty of places in GDM where it launches other programs via g_spawn_async or whatnot.

I'd say we'd need to be able to launch programs in two ways.  

1) All the time.
2) When a button is pressed.

So I'd say there are two places greeter_parser should be updated.  Probably there needs to be a new tag where you can specify a list of custom commands to run all the time with the greeter, and the button tag needs a new element to specify custom command for #2.  For prototyping purposes you might just solve #2 initially.

Once you got that working, then we'd probably need to add a new configuration option to specify that a custom command is not intended to be displayed in the Actions menu, but is instead managed by adding the right stuff to the xml file and is made available in the greeter that way instead.

This is just a suggestion of how I think it could work.  Others with ideas please discuss.  Lukasz?

I think it would be okay for a feature like this to be gdmgreeter specific.  This approach gives theme writers a lot of control over how the GDM layout looks and how the additional custom tools are presented.

Also note that if such a feature were added, it would probably deprecate BackgroundProgram, since this would be a more powerful way to run additional programs at GUI time.

Let me know if you need any help.

Thanks for taking the time to report this bug.
However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use.

By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME.
Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.