[Okular-devel] Kile and Okular with ForwardDVI
pino at kde.org
Sun May 17 22:19:19 CEST 2009
> > > 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 you can see from the other email, actually chose a KDVI-lime behaviour, so
it should not be a too radical change for you.
Unfortunately (and I did not find any workaround to the issue) you won't be
able to execute:
$ okular 'file.dvi#src:100 file.text'
with Okular <= 0.8 (KDE 4.2), as it KCmdLineArgs (for what I don't understand
whether it is a wanted behaviour or not) encodes the # as part of the
filename, thus trying to open 'file.dvi%23src:100 file.text' (which of course
would not exist).
You should do a detection of the Okular version (from `okular --version`), and
do not provide any destination if <= 0.8.5.
> > 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.
Done this as well (which, FYI, what the easiest part of the work needed).
> > 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.
The okular shell would just not even connect that signal, ignoring the
proposed editor action and letting the Document doing its job as configured.
> 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?
Hm right, I was thinking more about the embedding case, but much about the
Doing this via D-Bus would complicate things a bit, as a signal could be
caugth by (and have a reply from) more than one application.
> 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.
Yes, it is easier for the okularpart guarantee some signal than all the apps
doing the same job. This way, apps can even radically change internally, and
this would not affect the okularpart at all.
Just a though about it, nothing essential anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/okular-devel/attachments/20090517/7f3bbd3c/attachment.sig
More information about the Okular-devel