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

[Pino Toscano]

Hi,

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

I personally find the envvar system quite fragile in itself, that's why I 
would not like to use it.

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

Your ktexteditservice is at the same time too generic ("textedit://" is quite 
generic as protocol, and could potentially conflicting with anything else as 
generic as it; thus not your specific "fault") and too specific (the D-Bus 
call it does is quite taylored). I would prefer to avoid that.

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

I don't see it as problem. Kile users do that since years with KDVI, and it's 
a one-time-and-forget configuration; Frescobaldi users could do that as well.
That can be described in the documentation, FAQ, whatever.

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

I would prefer to run some application, mostly because from an user POV it 
would be coherent with the current possibilities (both behaviour and GUI 
configuration). The only issue here is knowing the specific target 
application among the possibly open ones.

And if there's really need to, there are quite more elegant ways to commnicate 
back and forth with a KPart than with an envvar, like:
a) passing data to the arguments of the kpart (see the QVariantList parameter 
when loading a KDE service)
b) invoking slots on the part (see QMetaObject::invokeMethod()) and listening 
to signals of the part (the usual connect()); in both the cases you don't 
even need to cast to the specific kpart you are using, as the kpart's meta 
object is what matters.

-- 
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/20090104/783bea65/attachment.sig