[Nepomuk] [Okular-devel] Using Okular Generators as a basis for Nepomuk Indexers

Albert Astals Cid aacid at kde.org
Mon Feb 18 00:02:51 UTC 2013


El Dijous, 14 de febrer de 2013, a les 18:14:21, Vishesh Handa va escriure:
> Hey everyone

Hi

> 
> ( Please remember to cc me or the nepomuk mailing list )
> 
> As you might remember, we foolishly tried to use Okular to fetch the text
> and document metadata for 4.10. Okular, clearly isn't ready to be used in
> such a way cause its UI parts are quite integrated with the rest. Would it
> be feasible to change that?

Yes, it can be done.

> 
> In Nepomuk when we were trying to create the Okular::Document, we passed a
> null pointer for the widget.
> 
> This posed the following problems -
> 1.) Document class -
>      a.) It tries to override the cursor via QApplication - we don't have a
> QApplication
>      b.) It tries to create a QPrinter in order to determine the paper size
> 
> One very simple way to fix both of these is to not call them when you don't
> have a widget. I've attached a very simplistic patch which does that.

What's the problem in b?

> 
> 2.) Generators - All the generators use the main widget and often create
> dialogs. How do we counter this? Again, the only mechanism that I could
> think of was for Okular to tell the generators not to create any ui
> elements, and we modify all the generators to abide by that.
> 
> In the case of the PDF generator, the only UI components that I noticed was
> the password dialog. The DVI generator has this whole DVIRenderer which I'm
> not too sure of.
> 
> Anyway, it seems like it can be done with some effort.
> 
> Is this direction acceptable to the Okular team? Or should I just ignore
> all of this and write nepomuk indexers using the libraries used in the
> generators? Doing that would lead to quite a lot of code duplication, but
> it might be considerably faster since we only need the plain text and
> document metadata.

The direction is not only acceptable but wanted.

Your proposed patch is going the wrong way in my opinion though, the correct 
fix is not add ifs in the core but to move the responsability where it 
belongs, i.e. let the UI do UI stuff, be it with signals, interfaces or 
whatever way of talking between layers.

Ideally we wouldn't have any of the core nor generators linking against UI 
stuff, but it's hard :D

So how do you want to proceed?

Cheers,
  Albert


More information about the Nepomuk mailing list