On Mittwoch 13 Mai 2009, Pino Toscano wrote: Hi Pino,
> > With KDE 3.5 kile used to call kdvi like > > kdvi --unique 'file:/home/kdedev/kile-projects/test.dvi#src:16 > > ./test.tex' and kdvi jumped to the source special "#src: 16./test.tex" in > > the file /home/kdedev/kile-projects/test.dvi. > > Aha. > > > With okular this method does not work anymore. > > Actually, this was not implemented so far (that's why it does not work). Thats of course a good reason. > > Have you already added forward search in okular? > > If yes, how do I have to call okular in order to get it working? > > It is not there yet. > Incidentally, we received a bug report about named destinations for PDF > documents, which we don't handle correctly. > Fixing this bug (for which I need to ask permission to add one string, > though) would basically add a -a/--anchor <name> parameter for the Okular > shell (or, if you have better names, they would be welcome), that would > allow to jump to the specified named destination. This way, you would just > need to do: $ okular some.dvi --anchor 'src:16 ./test.tex' Sounds good. An alternative name could be --source-reference/ -s but --anchor is also good. > As said, this will come as a consequence of a bugfix for PDFs, so it will > need a small addition in the DVI backend (the actual resolution of the > named destination to a viewport in the current document). I really hope to > have this in KDE 4.3. Me too. > Furthermore, there's something that I would like to improve regarding the > okularpart <-> embedders interaction with source references (ie "please > open the source file foo.xxx, at line Y and column Z). This could be useful > for Frescobaldi as well. > Currently, when the user uses Kile and wants to have source links being > opened with Kile when reading a PDF within Kile, the current way is "go to > the Okular settings and set Kile as editor" (same as with KDVI). > One of the possible idea to improve this would be having the okularpart > emitting a signal like: > void sourceReferenceRequest(QString source, int row, int column, bool& > open) this way, you could just connect to such signal of the okularpart > instance, and in case you want to handle a request of source reference, you > would set the open reference to true, and then handle it yourself. > If true, Okular would then stop there, and don't go further with the editor > invocation. > If false, Okular would go ahead just like now. > > What do you think? So if I understand you correct the idea is that the okularpart says "I have a source reference here" and all editors can then do the appropriate actions, or? This sounds good for an embedded part but I don't know if it works also good for a standalone okular. For a standalone okular kile would have to poll the dbus system for an okular application, and if it finds one, then wait for a okular signal as a standalone okular might not been opened from within kile. Or is there an easier way? And if we do it vice versa? Let okular search for kile/frescobaldi/etc. on dbus and tell them with a dbus method call sourceReferenceRequest(QString source, int row, int column, bool& open). Then the editors can decide what do do. And for all non-dbus enabled application okular still provides the "editor settings" configure options. The disadvantige here is that okular would have to have a list of applications implementing this dbus interface and this is not so nice. bye, thomas _______________________________________________ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel