Red Hat Bugzilla – Bug 442445
comand line option '-sourceposition' does not work correctly
Last modified: 2008-07-21 12:50:41 EDT
Description of problem:
As described in the manual of xdvi:
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
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
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
fprintf(stderr, "DEBUGING: %02x %02x %02x %02x\n",
I get DEBUGING: ffffffe8 01 00 04
I am not a professional programmer, but why printing char produces something
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:
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:
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.