Version: (using KDE 4.0.2) Installed from: Debian testing/unstable Packages KDVI has a configuration section called "DVI Specials". Many LaTeX users use this together with the srcltx latex-package to be able to click in DVI files with the middle mouse button so that e.g. kile or kate then will jump to the correct position in the LaTeX source file. If okular will completely replace kdvi, then I'm hoping this functionality will not disappear. Best regards, Torquil Sørensen
Are you referring to the inverse search? Mostly it's there (core library speaking), what it needs are the following: a) a good way to trigger them easily (right now you can with Shift+Left Mouse Button, but you have to be quite precise in clicking in the points) b) possibly a UI to configure the editor (right now the default is Kate, but optionally configurable to be any editor) (Changing the component to 'general' as the DVI backend already provides all the data.)
b) is implemented with okular from KDE4.2 RC, but I could not figure out a way to trigger the inverse search.
This bug is really bad. You can view files in a gazillion different programs, but kdvi was the only functional dvi previewer with inverse search.
> but I could not figure out a way to trigger the inverse search. Shift+left mouse button click. Although you still have to be precise.
I have tried shift-clicking everywhere - from the top of the page, line by line, from left to right - nothing. What exactly do you need to click?
As I'm working with LaTeX quite a lot I really need this feature. So far I can fallback on kdvi, but it's not very convenient.
I tried Shift+LMB, too, but without success. I use opensuse KDE4.2 packages. I'd really like to see this feature working in okular. Or even better, inverse search from PDF documents (e.g. pdfsync). Any testing help needed? Just let me know what to do...
It would be great to have this working as in kdvi - it's a real regression from 3.5 and a real shame. I have tried Shift-LMB, LMB-Shift in 4.2, many other combinations, everywhere on the page, but cannot get this to work at all. If accuracy is required, maybe a solution could be to display the points (maybe with a small circle) so that the user knows where to click? I am happy to assist with testing too, if needed.
I even offer a help in implementation. However, my free time is very limited. Is there some small part where I might help out?
Hi, I had a look at the source code (branch 4.2) and have some questions if I understood it correctly. - kdegraphics/okular/generators/dvi/dviRenderer.cpp: Does parseReference(...) get called on inverse search? Because here I could not find any place where it get called. - Judging from the comment in dviRenderer.cpp:621 the format is supposed to be src:1111Filename which at least on my system is wrong. Here it is "src:1111 Filename" where Filename ends with .tex (and before Filename is a space). I have here TexLive2007 on debian lenny and latex called with -src-specials. - Where is Shift + LMB set for inverse search in the sourcecode? I could not find that. Thanks a lot, Thomas (member of kile dev team)
(In reply to comment #10) > - kdegraphics/okular/generators/dvi/dviRenderer.cpp: > Does parseReference(...) get called on inverse search? > Because here I could not find any place where it get called. > > - Judging from the comment in dviRenderer.cpp:621 the format is supposed > to be src:1111Filename [...] That code is not used anymore. It's a leftover of the kviewshell infrastructure (the dvi generator was adapted from the kdvi code). Anyway, in the kdvi code it is used only by the jumpToReference method (dcop interface) which takes an encoded string (as explained in the comment) as input. > - Where is Shift + LMB set for inverse search in the sourcecode? I could not > find that. See PageView::contentsMouseReleaseEvent (ui/pageview.cpp, line 1820 and following lines).
(In reply to comment #11) > > - Where is Shift + LMB set for inverse search in the sourcecode? I could not > > find that. > See PageView::contentsMouseReleaseEvent (ui/pageview.cpp, line 1820 and > following lines). Thanks for the pointer. I tracked the problem down to SourceRefObjectRect::contains(...) in area.cpp. And adding some debug output I realized that I never got the situation that I clicked inside the sourceObject. Although I used 400% zoom and really tried hard. What should the calculation in the return statement of SourceRefObjectRect::contains(...) do?
Ok, now the inverse search should require less precision and thus be actually usable. The fixes have been backported to KDE 4.2.2. I consider the problem mostly solved (thus closing this bug), so for further issues please open a new report.
*** Bug 185134 has been marked as a duplicate of this bug. ***
Thanks a lot Pino. I just tried it and it works like a charm now.