Description of problem: As described in the manual of xdvi: "-sourceposition: .... In addition, when run with this argument (and the -nofork option is not given, which see), xdvi will always return immediately: if it finds another instance of xdvi already showing dvi_file, then it will cause that instance to raise its window and move to the given place in the dvi file; otherwise it will start up its own instance in the background......" This worked in F8, but now, everytime a new window is opened, which is very annoying. The option '-unique' has the same problem. Version-Release number of selected component (if applicable): rpm -q xdvik xdvik-22.84.13-17.fc9.x86_64 How reproducible: always Steps to Reproduce: 1.xdvi -unique somedvifile.dvi 2.xdvi -unique somedvifile.dvi 3.two windows are opened instead of one.
I cannot reproduce it on my x386 box, with -unique it reloads in the same window.
Created attachment 302412 [details] output of two xdvi -unique -debug client,src commands
I can reproduce it always. I attached to the bug output of two successive xdvi commands with some debugging enabled. Maybe it helps.
I tried the same, and upon inspection of the logs, it seems that the issue is in x_util.c:1142: CLIENT: Checking window ffffffffffffffe9 x_util.c:1152: CLIENT: Window ffffffffffffffe9: doesn't exist any more, deleting x_util.c:284: CLIENT: No "xdvi windows" property found (during the first run). I attach my logs for a case that works.
Created attachment 302419 [details] output of working xdvi -unique -debug client,src commands
Maybe you could launch xwininfo and click on the first xdvi window, look at the window id and report back the comparison with x_util.c:1142: CLIENT: Checking window ffffffffffffffe9.
Created attachment 302424 [details] output of xwininfo for the first xdvi window As you see, the window id looks quite normal. It is not ffffffffffffe9
Um. Struggling to reproduce this locally. I am wondering if this could be a window manager bug - Jiri, what WM are you using?
metacity-2.22.0-2.fc9.x86_64. I do not believe it is metacity, since xwininfo works, but I am really no expert. To be sure that it is not related my personal configuration, I have created a new user on current rawhide. The problem is completely reproducible also by this new user (with standard gnome desktop)
I was trying to play with the code. What I do not understand is the following. If I add on the begining of the function get_window_id in x_utils.c the following line fprintf(stderr, "DEBUGING: %02x %02x %02x %02x\n", window_p[0],window_p[1],window_p[2],window_p[3]); I get DEBUGING: ffffffe8 01 00 04 I am not a professional programmer, but why printing char produces something like ffffffe8.
Created attachment 302722 [details] patch correcting the problem This (very unprofessional) patch makes my problem disappear. The window id is non longer fffffffffe9 and, what is more important, -unique switch works.
Hm, ok, thanks for digging a little deeper with this - I'll have a careful look over the weekend.
Have done a build with Jiri's patch applied: http://koji.fedoraproject.org/koji/taskinfo?taskID=585170 Please test that (assuming it completes successfully). I'll push an update for F-9 if this fix is good.
The above build works for me. Thanks a lot.
xdvik-22.84.13-19.fc9 has been submitted as an update for Fedora 9
xdvik-22.84.13-19.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xdvik'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3710
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
xdvik-22.84.13-19.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.