[Okular-devel] Kile and Okular with ForwardDVI

[Thomas Braun]

Hi Pino,

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

Okay so I'll add this check before calling okular and also a version check of 
okular in our "System Check" dialog. Written on my todo list.

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

Is ForwardDVI also supposed to work with PDF files? Of course we should then 
call it differently ;)
I only tried with pdfsync and not with synctex. And with pdfsync okular did 
not jump to any src reference.

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

We could try this method for KDE 4.4 but to be honest this is for kile not so 
important at the moment. We are still trying to get it in reasonable shape 
for a release.

bye,
thomas