[Okular-devel] handle 'point and click' events (textedit-URIs)

[Wilbert Berendsen]

Hi Pino,
many thanks  for your concise reply!

Op vrijdag 2 januari 2009, schreef Pino Toscano:
> Hi,
>
> thanks for pointing out the issue, and for using Okular of course :)
>
> > But if there is no way for a parent application (that embeds Okular) to
> > be called when the user clicks a textedit:// link, my nice Frescobaldi
> > editor will stop working in KDE 4.2 and I couldn't do anything about it.
> > :-(
>
> Luckly we have some days before KDE 4.2, so the we can find a solution.
>
> > I certainly can live with textedit:/ handling inside Okular, but then we
> > should arrange a way for applications to override the default handling
> > (open a configured editor). That could be done via an environment
> > variable,
>
> I personally find the idea of using a envvar quite "raw" and not that much
> user friendly (aren't we both developing nice comfortable GUIs for our
> users? ;) ).

Yes! :-)

(But all this would be invisible: The app that embeds Okular would set the 
envvar, so the user never ever has to configure that var him/herself, it would 
just be a way for okular to know if some parent app that embeds Okular really 
wants to get the textedit events.)

> Okular in KDE 4.2 provides a way to configure the editor to be launched
> for "sources", ie when working with DVI files with inverse search
> hyperlinks. Using this configuration, the user can also setup Okular for
> DVI integration within Kile. The interaction way used for Kile is to run it
> telling it to go at a specified line of a source file (something like `kile
> --line 10 thefile.dvi`).
> IMHO, this way could also be applied for Frescobaldi. Although, from what I
> see from the Frescobaldi' sources, it allows multiple instances of it,

Yes: Frescobaldi allows multiple instances (although it by default reuses the 
running one). But the embedded (inprocess) Okular always communicates via 
ktexteditservice with the correct one, because Frescobaldi exports an 
environment variable that is read by ktexteditservice. ktexteditservice then 
direcly calls the specified Dbus object to open the textedit url.

This could be moved to Okular. (See the comments in ktexteditservice.cpp)[1].
This works very quickly and it never bothers apps that do not know or want 
another way of interacting with Okular, because they do not set that env var.

It would be nice if the user can just run Frescobaldi and have Okular 
interacting with frescobaldi (or any other parent app) without asking the user 
to change Okular's own settings first to make point-and-click links work.

> unlike Kile. A second problem (that could be solved with an hidden
> configuration, at least for KDE 4.2) is that it should be possible to
> configure the editor for different file types (eg "frescobaldi --line %l
> %f" for
> application/x-lilypond, "kile ..." for "application/dvi", etc).
> This would have the advantage that the user could just configure the editor
> for lilypond files once, and forget about it :)
>
> What do you think?

We could do the following:
- user clicks on textedit link in Okular
- some parent app that embeds us, wants our event?
	(via special envvar that app sets?)
  - yes: pass the textedit url to the parent app, via a DBus call (quickest)
         or just by running the app with the url as argument. Done.
  - no:
    - find out the source file mimetype (from extension)
    - find out preferred editor for that mimetype via KService OR users choice
       inside Okular
    - figure out the way to call that editor (based on list of editors pref.
          in a config file)
    - call that editor,
    - no suitable application found? Then possible pass the whole url to KRun.

[1] http://lilykde.googlecode.com/svn/trunk/lilypond-kde4/ktexteditservice.cpp

<musing>
Another possiblity would be leaving all special handling outside of okular and 
make a ktexteditservice part of KDE with a nice settings gui where the user 
can override the default behaviour, like currently in OKular. This has 2 
drawbacks btw:
- each time the user clicks an url the startup notification fires for a while 
(until appstarted() is called in ktexteditservice)
- each clicked url is recorded in last opened documents.

So after all it's maybe better to keep the textedit handling inside Okular. 
:-)
</musing>

with many regards and thanks again for your reply.
Wilbert Berendsen

-- 
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
        -- Mahatma Gandhi