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

[Wilbert Berendsen]

Op zondag 4 januari 2009, schreef 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.

I totally agree with you (really!). Thank you for your enlightening view.

I think most times the usual KDVI way of doing things would suffice. Okular 
just calls Frescobaldi. I could implement a mechanism in Frescobaldi itself 
that sorts out the correct instance (the one that embeds the Okular part. Kate 
does that too, by exporting it's own PID in the environment).

I could also provide a "first-run" wizard with a button that writes the 
frescobaldi command in Okular's config, so that the user doesn't have to edit 
the Okular editor settings himself.

Thanks again, it seems Frescobaldi will be running along in KDE 4.2. I could 
add the LilyPond icons and the katepart indenter script that are part of 
lilypond-kde4 to KDE, then lilypond-kde4 would not be necessary anymore in KDE 
4.2

with best regards,
Wilbert Berendsen

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