[Okular-devel] Kile and Okular with ForwardDVI

[Pino Toscano]

Hello again,

> > > 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.

Scratch that.
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?

Yes, exactly.

> 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 
standalone usage.
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.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/okular-devel/attachments/20090517/7f3bbd3c/attachment.sig