also reported here:
https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/290935

and here:

https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/157708

Since this does work if DISPLAY is set correctly, it is not a gnome-terminal bug.
You already recognised this ("It seems to be cause by a bug in gnome-panel.") so why did you file this against gnome-terminal ?

Possibly the panel launchers aren't setting the DISPLAY variable correctly.

Please specify the exact version of gnome-panel you use.

Moving -> gnome-panel for further triage.

Using gnome-panel:

GNOME gnome-panel 2.26.0

It also happens when a link is on the desktop, so not sure if it is only in the panel.
If you need any more info, please ask.
Using Ubuntu 9.04 by the way.

I can confirm this, additionally,

It is not limited to gnome-terminal but all panel items:

menu items and panel launchers, exceptions see below

some notification area items, e.g. volume control: left click on icon - slider on wrong screen, right click on icon and select open volume control - opens on correct screen.

some panel applets, although some behave correctly e.g. system monitor applet will open the system monitor application on the correct screen when using its menu.

The run application dialogue sets the DISPLAY variable correctly so applications launched from it open on the correct screen.

Menu Items/Panel Launchers that use a script to launch i.e. a shell is invoked first have the DISPLAY variable set correctly so open on the correct screen.

Another oddity which might help in tracking down this problem:

on the second screen (DISPLAY=:0.1) right click on a panel launcher,
select properties,
- properties dialogue opens on wrong screen (DISPLAY=:0.0)
leave properties dialogue open on wrong screen,
right click on the same panel launcher, select properties again,
- dialogue closes on wrong screen and opens on correct screen (DISPLAY=:0.1)
((much weirdness))

You do not need to export DISPLAY=:0.1 in gnome-terminal as the original reporter suggested, if you have gnome-terminal (via run dialogue) open on any screen the DISPLAY variable is correct.

Ubuntu 9.04 - gnome-panel 2.26.0

This did not happen with the previous versions of gnome-panel

I confirm this as well, happened to me with a new install of Ubuntu 9.04; 8.04 and 8.10 were working fine.

I have a thread as well on the Ubuntu forum:
http://ubuntuforums.org/showthread.php?t=1137206

Notice that some applications like Firefox and Open Office open on the correct screen.

I confirm the errors reported by Gavin and Davidux. I updated my system from Ubuntu 8.10 to Ubuntu 9.04 (gnome-panel 2.26.0).

But the problem is not limited to the gnome-panel. When I right-click on the desktop of screen1 and create a new directory/document the object will be put on screen1. So far so good, but if you right-click on the desktop of screen1 and create a new "starter" the object will be put on screen0.

I have exactly the same issue: everything opened on screen 1 displays on screen 0 (but firefox and openoffice, maybe others) in jaunty (gnome 2.26.1).
Alt-F2 + <command> displays it in the right place, though.

I had the same problem (but *only* for nautilus file manager) in intrepid (gnome 2.24.sthg), so this is definitely a regression IMHO

(In reply to comment #7)
> I have exactly the same issue: everything opened on screen 1 displays on screen
> 0 (but firefox and openoffice, maybe others) in jaunty (gnome 2.26.1).
> Alt-F2 + <command> displays it in the right place, though.
> 
> I had the same problem (but *only* for nautilus file manager) in intrepid
> (gnome 2.24.sthg), so this is definitely a regression IMHO
> 

And, BTW, I use no desktop effects at all. I'm also using NVIDIA driver v180.

This is happening on amd64 upgrade from 8.10 to 9.04.

Is there any work-around for this, it really hampers my work?

You can use the run application dialog "Alt+F2" to start an application on screen1. It is annoying but works.

Just a thought: This could also be a gnome-session-manager bug.  It all depends on where gnome applications get their display information from when launched from the gnome panel.

Someone (I'm not volunteering (yet)) can probably produce a hacked version of gnome-terminal that would dump some debug information to a file about exactly which GTK call this bad terminal information is coming from.  However, I'm unwilling up upgrade to Ubuntu 9.04 on my main machine to do the test run because this bug is a show-stopper, so someone else would have to run the code to get the real debug output.

Thanks for the suggestion Hagen but it doesn't work...

http://bugzilla.gnome.org/show_bug.cgi?id=581765

I wonder why this bug seems to be full of "me too"s and whatnot and no real analysis by any gnome developers.

Is this happening on all gnome 2.26 based distros or is it isloated to Ubuntu?

(In reply to comment #10)
> Is there any work-around for this, it really hampers my work?
> 

From fooman on Ubuntu forums:

------

if you cannot get to a terminal on that screen, try installing "nautilus-open-terminal"...that will give you the ability to right-click on the secondary screen's desktop (or anywhere in nautilus) and choose "open in terminal" from the context menu.

to install it....open a terminal on the main screen and run this command:

Code:

sudo apt-get install nautilus-open-terminal

after it installs, log-out and back in again. when you get back to the desktops, you should be able to right-click on screen 2, choose "open in terminal" and open the app from there...it should then open on screen 2.

hope that helps.

-------

I tested it and it works...

Davidux

Works!

Thanx--

 

(In reply to comment #15)
> (In reply to comment #10)
<...>
> 
> if you cannot get to a terminal on that screen, try installing
> "nautilus-open-terminal"...that will give you the ability to right-click on the
> secondary screen's desktop (or anywhere in nautilus) and choose "open in
> terminal" from the context menu.
> 
> to install it....open a terminal on the main screen and run this command:
> 
> Code:
> 
> sudo apt-get install nautilus-open-terminal
> 
> after it installs, log-out and back in again. when you get back to the
> desktops, you should be able to right-click on screen 2, choose "open in
> terminal" and open the app from there...it should then open on screen 2.
> 
The problem of course is that nautilus opens on screen 1... so...

(In reply to comment #17)
> (In reply to comment #15)
> > (In reply to comment #10)
> <...>
> > 
> > if you cannot get to a terminal on that screen, try installing
> > "nautilus-open-terminal"...that will give you the ability to right-click on the
> > secondary screen's desktop (or anywhere in nautilus) and choose "open in
> > terminal" from the context menu.
> > 
> > to install it....open a terminal on the main screen and run this command:
> > 
> > Code:
> > 
> > sudo apt-get install nautilus-open-terminal
> > 
> > after it installs, log-out and back in again. when you get back to the
> > desktops, you should be able to right-click on screen 2, choose "open in
> > terminal" and open the app from there...it should then open on screen 2.
> > 
> The problem of course is that nautilus opens on screen 1... so...
> 

of course, but you can still right click on the second screen desktop and open there a terminal to launch the other programs; in any case this is only a quick fix, i hope that the gnome people will correct this bug soon

(In reply to comment #14)
> I wonder why this bug seems to be full of "me too"s and whatnot and no real
> analysis by any gnome developers.
> 
I hope this bug is looked at.  Just another note that may help pin point the issue in gnome panel or session mgmt:  When I open a remote desktop connection to ":0.1", it displays a cascading loop of my desktop on ":0.0".  I really need this working since I use VNC to access my second screen which is in a remote location.

Possible duplicate http://bugzilla.gnome.org/show_bug.cgi?id=581502

Is anything going to be done about this?

In Ubuntu, I got someone to get me info on the actual call made from gnome-panel.  This looks like a glib2.0 bug.  I have appended my comment to the Ubuntu board below:


Actually, this helps a lot.

What this tells us is that this is actually a bug in glib2.0 function g_app_info_launch_uris().

The bug occurs when this is launched with a context including a screen with gdk_screen_make_display_name(screen)=":0.1" but the parent process has DISPLAY=":0.0"

Here is a snippet of the relevent code sequence in gnome-panel:

...
        gdk_app_launch_context_set_screen (context, screen);
        gdk_app_launch_context_set_timestamp (context, timestamp);

        local_error = NULL;
        retval = g_app_info_launch_uris (appinfo, uris,
                                         (GAppLaunchContext *) context,
...

Created attachment 135573 [details] [review]
Fix to glib is_env() function.

The problem is that the DISPLAY environment variable is not getting replaced correctly.  This fixes the compare function that is not finding the old value.

Someone please change the product to glib, as the problem is not in gnome-panel.  See my attached patch.

Thank you.

Just thought I'd note that 3 individuals on the Ubuntu defect that feeds this have noted that the patch fixes their problem.

I'd sure love to help move things along, but I don't know how beyond providing a working patch.

Thanks!



It might help to change the title to something that looks like glib, such as:

g_app_info_launch_uris() fails to replace the DISPLAY environment variable correctly.

You will have to explain your patch a little better than 'naughty equals usage'
What are the strings that are passed into is_env that cause this to fails ?

I'd be happy to explain the patch.  The comment is just on why I added an equals checker where one wasn't really needed.

is_env is supposed to compare two strings, looking for a match.  Here is how it is used:

The first string (a) is a line in an environment, such as:
DISPLAY=:0

The second string (b) is a name for an environment variable, such as:
DISPLAY

The original patch would loop and return true if all of the characters *including* a trailing equals matched.  This would work if (b) was of the format: "DISPLAY=" but that didn't match the usage.  I decided to let usage win, as the changes required to other code would be more ugly.

Here is a detailed analysis of the changes.  All of my newer comments are enclosed in /*:...*/

   while (*a == *b)
   {
/*: Return false if string b has an '=' in it.  If string b contains an equals then the format of string b (based on usage) is bad.  Returning FALSE seems safer.  However this change could be removed, see below.*/
-    if (*a == 0 || *b == 0)
+    if (*a == 0 || *b == 0 || *b == '=') /* cover naughty equals usage. */
       return FALSE;
/*: The existing code returns TRUE if the first '=' character in string b matches the '=' in string a.  The correct trailing character in string b based on usage is 0.  It might be safe to leave this as-is and remove the change above, but the function is not used that way.*/
-
-    if (*a == '=')
-      return TRUE;

     a++;
     b++;
   }
/*: THIS IS THE IMPORTANT CHANGE: The correct final state based on usage is for the '=' in string a to match the 0 at the end of string b.  This will fall-thru and return FALSE if string b and the variable name portion of string a are of different lengths.*/
+  if (*a == '=' && *b == 0)
+    return TRUE;
+


I hope this explains the reason for each of the changes.

Thanks!

How can I check if this patch works?
I cannot derive from this information what code to patch where.
Is there a simple howto anywhere?
I'd be happy to test this.

Thanks for your efforts and especially Greg, thanks for the patch.
I hope it will be put upstream soon.

I tested the patch in Jaunty i386, and it worked for me.

(In reply to comment #28)
> How can I check if this patch works?
> I cannot derive from this information what code to patch where.
> Is there a simple howto anywhere?
> I'd be happy to test this.
> 
> Thanks for your efforts and especially Greg, thanks for the patch.
> I hope it will be put upstream soon.
> 

I don't know which distribution you're using, but to test it, you've basically to
download the source codeof glib2 (+ potential dependencies), apply the patch, recompile, create a package and update the system with the new package.

You could also compile the glib2.0 and replace the system's libgio shared lib with the newly compiled one (of course, take backups before...).

Definitely is a problem in Fedora 11. The patch does fix the issue.

In Fedora to apply the patch run the following as root:

yum install rpmdevtools gamin-devel
yumdownloader --source glib2
rpm -Uvh glib2-2.20.1-1.fc11.src.rpm
rpmbuild -bi rpmbuild/SPECS/glib2.spec
cd ~/rpmbuild/BUILD/glib-2.20.1
patch -i /path/to/the_patch.patch          # enter "gio/gdesktopappinfo.c"
make install

I got mixed results with this patch, some app opened in the correct screen and some did not.

Ubuntu 8.10 amd64.

Fixed differently in git master.

(In reply to comment #32)
> I got mixed results with this patch, some app opened in the correct screen and
> some did not.
> 
> Ubuntu 8.10 amd64.
> 

Should be 9.04 amd64

(In reply to comment #33)
> Fixed differently in git master.

I looked at the fix.

While I generally agree with your new methodology, I think your "unsetenv" calls in child_setup should be removed.  If the calling program calls with a context not including a screen, we should fail gracefully and display on whatever the DISPLAY environment variable was already set to.  As written the launched app will crash because DISPLAY environment variable is not set.

Here are my recommended changes:

static void
child_setup (gpointer user_data)
{
  ChildSetupData *data = user_data;

  if (data->display)
    g_setenv ("DISPLAY", data->display, TRUE);
-  else
-    g_unsetenv ("DISPLAY");

  if (data->sn_id)
    g_setenv ("DESKTOP_STARTUP_ID", data->sn_id, TRUE);
-  else
-    g_unsetenv ("DESKTOP_STARTUP_ID");
}

For a final result of:
static void
child_setup (gpointer user_data)
{
  ChildSetupData *data = user_data;

  if (data->display)
    g_setenv ("DISPLAY", data->display, TRUE);

  if (data->sn_id)
    g_setenv ("DESKTOP_STARTUP_ID", data->sn_id, TRUE);
}


NOTE: I'm less sure about DESKTOP_STARTUP_ID, but DISPLAY definitely should not be cleared in the environment if not set in the calling context.

I was just trying to keep the existing behaviour of replace_env_var (ie clearing it if NULL is passed as the value). 

But now that you mention it, I missed the fact that replace_env_var was not even called for NULL...

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

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

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

Thanks to midnightflash and keepitsimpleengr, here are some pretty nice instructions to get it fixed for Ubuntu 9.04/

Thanks TJ for patching and anyone who helped.

https://answers.launchpad.net/ubuntu/+source/glib2.0/+question/77380

It worked for me, thank you all for your support!

(In reply to comment #35)
> 
> I looked at the fix.
> 
> While I generally agree with your new methodology, I think your "unsetenv"
> calls in child_setup should be removed.  If the calling program calls with a
> context not including a screen, we should fail gracefully and display on
> whatever the DISPLAY environment variable was already set to.  As written the
> launched app will crash because DISPLAY environment variable is not set.

I think this is what is making evolution fail to open attachments in X apps.

> Here are my recommended changes:
> 
> static void
> child_setup (gpointer user_data)
> {
>   ChildSetupData *data = user_data;
> 
>   if (data->display)
>     g_setenv ("DISPLAY", data->display, TRUE);
> -  else
> -    g_unsetenv ("DISPLAY");
> 
>   if (data->sn_id)
>     g_setenv ("DESKTOP_STARTUP_ID", data->sn_id, TRUE);
> -  else
> -    g_unsetenv ("DESKTOP_STARTUP_ID");
> }

Did this ever land in glib or will the next release of many distros now be broken where evolution wants to spawn other applications that require a $DISPLAY set?

(In reply to comment #41)
> 
> Did this ever land in glib or will the next release of many distros now be
> broken where evolution wants to spawn other applications that require a
> $DISPLAY set?

To answer my own question, it seems it did according to http://git.gnome.org./cgit/glib/tree/gio/gdesktopappinfo.c#n851

I wish I knew how to find the specific commit from the above reference.  Oh well.

I confirm that the update worked for me.

I find that after the update occurs the following behavior:

Applications like Chromium, Opera and others (NOT Firefox) appears that use "gnome-open" to open the downloaded files and launch links as "mailto:".
Failure occurs and the files and applications are not opened by the system.

Case 1:
1.- Launch Opera or Chromium.
2.- Download a file.
3.- Try open the file with the download manager.
3.- Nothing happens.

Case 2:
1.- Launch Opera or Chromium.
2.- Click on a link with "mailto:"
3.- Nothing happens.

If I run the applications (Chromium or Opera) in a terminal I can view the following error when I try to open a pdf file:
 (acroread:5958): Gtk-WARNING **: " cannot open display:    "

It is the same error as if I launch in a terminal "gnome-open":

 user@computer :~$ gnome-open anyfile.pdf
 user@computer :~$ (acroread:5958): Gtk-WARNING **: cannot open display:

Could be confirmed if the same applies to you.