User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20071004 Iceweasel/188.8.131.52 (Debian-184.108.40.206-1)
I run a dual monitor setup (not xinerama), so I have two X displays (first is :0.0 and second is :0.1).
When I launch some applications on my second screen, the appear on my first screen instead of on the second.
I say "might appear on the wrong screen" because I can't find a nice pattern on when it will appear on the correct screen and when on the wrong one (see steps to reproduce.
This is a regression, since 4.4.0 worked correctly.
Steps to Reproduce:
- open a pdf file in thunar with evince -> appears on the wrong screen
- open a pdf file in thunar with acroread -> appears on right screen
- open evince from xfdesktop -> appears on the right screen
- open brasero from xfdesktop -> appears on the wrong screen
Sometimes the launched application appears on the correct X screen, sometimes on the wrong one (see steps to reproduce)
The application should always appear on the second X screen when launched from the second X screen.
Please contact me if I can help to debug this. I'd love to get this resolved. Not having to have to go back to a terminal to launch applications is the whole point of using xfce :-).
I should probably have mentioned that I'm running xfce on debian sid.
Created attachment 1424
patch fixing the issue in trunk
I experienced the same issue in trunk and fixed. Could you try the attached patch ?
The patch has to be applied against libxfcegui4/xfce-exec.c
With all respects, I doubt this is a *major* issue. Does your system crash, do you loose your work, is there any security risk?...
> With all respects, I doubt this is a *major* issue. Does your system crash, do
> you loose your work, is there any security risk?...
You are right, my apologies. Changing severity to normal. I'll check the patch posted above soon.
Thanks for the patch Jean-François, but it doesn't solve the issue for me.
JF, regardless, if you get the chance, could you apply it to 4.4 branch as well? Probably useful.
Created attachment 1426
applying the same code as JF's patch to thunar-vfs-exec - defective
Let me correct myself: JF's patch fixed some cases (i.e. launching brasero from the xfdesktop menu), but not others (like opening a pdf file in either xfdesktop or thunar).
I looked into the issue and the reason his patch doesn't fix all cases is because thunar-vfs-exec doesn't use libxfcegui4's xfce-exec. The attached patch fixes my problems.
Ah, excellent. Benny, ok to apply to thunar-vfs? Or if you want to do it...
Hm... the patch doesn't look right. Now gdk_spawn_on_screen() is used AND the DISPLAY variable is set manually. gdk_spawn_on_screen() should set the DISPLAY variable. So, instead of placing a new value into the sn_envp, it should simply remove the entry for DISPLAY (if any).
benny, when I try unsetting DISPLAY it doesn't work at all anymore - I get in ~/.xsession-error:
cannot open display:
Run 'evince --help' to see a full list of available command line options.
I guess I'll look at the gtk code, to see what gdk_spawn_on_screen actually does.
After reading the gtk docs (which are all too sparse on comments IMHO), it seems like gdk_spawn_on_screen should take care of it all. But since that wasn't happening, I looked into the code:
gdk_spawn_on_screen is just a simple wrapper for g_spawn_async, which installs an additional function as child_setup. The wrapper uses g_setenv to set the display to the correct value, and then calls the user's child_setup.
This wrapper child_setup is called right before the execve, so in reality the effect of g_setenv vanishes, because the execve replaces the environment with the one specified in envp, unless of course envp is null. But since xfce sets envp, it needs to include a correctly set DISPLAY.
I don't know if this should be reported as a bug to gtk or not. It might not be a bug, but a poorly documented feature, afterall ;-). But please use the patch I attached for the time being, it is necessary.
Note: I had to look through a bunch of functions to come to this conclusion, it's possible I overlooked something (and I'm by all means not particularly familiar with gtk/glib's internals).
I suggest to apply the proposed patches to xfce_4_4 for the upcoming release and then eventually improve the changes as Benedikt suggested; unless some improved patch is sent/committed in the meantime.
Created attachment 1429
Please disregard the earlier patch I posted. I didn't handle the case of envp==NULL correctly, sorry! (Difference is just one if statement to check...)
No need to change the name... just mark it obsolete when you attach the new patch.
I had time to look into gdk now, and just discovered that gdk_spawn_on_screen() calls gdk_spawn_make_environment_for_screen() to modify the DISPLAY variable in the child environment (as I would have expected it to be). So, there's no need to patch thunar-vfs, since it's done in GDK. If that doesn't work properly, try to figure out what's wrong. According to the ChangeLog, the fix in GDK is present since 2003:
(gdk_spawn_make_environment_for_screen): private function
to create an environment vector with DISPLAY set appropriately
for the screen.
I also think that this is a bug in Gdk. The xfce_exec code has been working fine since I have 2 monitors and the problem appeared after some update in my system (unfortunately I can't tell which package exactly; maybe gtk+ 2.12).
So this one is for GTK+ then.
(In reply to comment #18)
> So this one is for GTK+ then.
Did you fill a bug on GTK+'s bugzilla ?
Nope, feel free to do so. ;-)
Created attachment 1435
I just ran a test program (see attachment) and gdk_spawn_on_screen seems to work as expected. So it seems the problem is in our side.
Ehm, you did not pass an env to gdk_spawn_on_screen().
Created attachment 1436
test code (take 2)
I think I found with this new test code (including envp this time) what is going on. If I don't provide envp the DISPLAY env variable is not set and gdk_spawn_on_screen works fine; if I use environ as envp (which contains a value for the DISPLAY env variable), gdk_spawn_on_screen ignores the screen parameter and uses the value of DISPLAY.
According to GDK doc: "the child process is spawned in such an environment that on calling gdk_display_open() it would be returned a GdkDisplay with screen as the default screen". Therefore it looks like a bug in Gdk or a lack of documentation. I'm gonna fill a bug against GDK; in the meantime, as a workaround, I suggest to remove the DISPLAY variable from the envp given to gdk_spawn_on_screen in real_xfce_exec_with_envp.
Bug filled in GNOME bugzilla as #497727
> in the meantime, as a workaround, I suggest to remove the DISPLAY variable from
> the envp given to gdk_spawn_on_screen in real_xfce_exec_with_envp.
Are you sure that that will work? I think I tried that since benny suggested it, and the child ended up having an environment where DISPLAY was not set at all.
(In reply to comment #25)
> Are you sure that that will work? I think I tried that since benny suggested
> it, and the child ended up having an environment where DISPLAY was not set at
Is it really a problem ?
(In reply to comment #26)
> (In reply to comment #25)
> > Are you sure that that will work? I think I tried that since benny suggested
> > it, and the child ended up having an environment where DISPLAY was not set at
> > all.
> Is it really a problem ?
It is if it's an app that wants to access X...
(In reply to comment #27)
> It is if it's an app that wants to access X...
Then the technique used to fix trunk is the most usable: overwriting the DISPLAY env variable with the destination screen name
(In reply to comment #28)
> Then the technique used to fix trunk is the most usable: overwriting the
> DISPLAY env variable with the destination screen name
I agree, at least until this gets fixed upstream...
Fixed with revision 26393.
2007-11-28 Benedikt Meurer <email@example.com>
Make sure to pass the correct $DISPLAY value to processes
spawned by Thunar and xfdesktop. Bug #3667.
*** Bug 3699 has been marked as a duplicate of this bug. ***
JF, did this get applied to 4.4 branch yet? I think I want to re-roll the libxfcegui4 4.4.2 package with this fix in it.
(In reply to comment #32)
> JF, did this get applied to 4.4 branch yet? I think I want to re-roll the
> libxfcegui4 4.4.2 package with this fix in it.
Yes it has been applied with revision 26366