El Diumenge, 29 d'abril de 2012, a les 15:29:22, Bogdan Cristea va escriure:
> On Sunday 29 April 2012 15:19:24 Albert Astals Cid wrote:
> > Yes, as i said the okularcore library is not designed for use in other
> > frontends, and yes, this are shortcomings i already knew of. Do you plan
> > workin
On Sunday 29 April 2012 15:33:00 Pino Toscano wrote:
> This has always been the case: Document does not asks for pixmaps on its
> own, but it does on behalf of PixmapRequest's sent by the observers.
> When a pixmap for a page is available, Document notifies the observers
> about that and they wil
Hi,
other than what Albert wrote, also:
Alle sabato 28 aprile 2012, Bogdan Cristea ha scritto:
> Same problem for the observers: I need to add a custom observer in
> order to check if the page has a pixmap
>
> if(false == page->hasPixmap(MY_OBSERVER_ID, -1, -1))
>
> and to make pixmap requests
On Sunday 29 April 2012 15:19:24 Albert Astals Cid wrote:
> Yes, as i said the okularcore library is not designed for use in other
> frontends, and yes, this are shortcomings i already knew of. Do you plan
> working on fixing them?
Yes, I am interested in fixing this problem. I am developing an
El Dissabte, 28 d'abril de 2012, a les 22:19:06, Bogdan Cristea va escriure:
> Hi
Hi
> The latest sources for okular contain a call to Settings::instance() method
> in Part constructor which seems to be mandatory even when using only okular
> core library. Please ensure a better separation of ok
Hi
The latest sources for okular contain a call to Settings::instance() method in
Part constructor which seems to be mandatory even when using only okular core
library. Please ensure a better separation of okular core library from the
frontend.
Below is the code snipped I use:
Settings::insta
