This seems to be required with KPluginFactory and Qt5 since without it
KPluginFactory::create<Okular::Generator>() always returns null.
For some reason this requires a complete rebuild before generatorstest
passes.
REVIEW: 123466
This requires a generator to have a
MyGenerator(QObject *parent, const QVariantList &args)
constructor in order to be successfully loaded.
The OKULAR_EXPORT_PLUGIN macro was adapted, and the generators to provide it the about data; the protected Generator::setAboutData() is no more needed.
Remove the 'lib' prefix from plugins, unneeded now.
CCMAIL: okular-devel@kde.org
svn path=/trunk/KDE/kdegraphics/okular/; revision=744169
as it uses the yetToBeAnnounced freedesktop libspectre project. I'm actually adding libspectre sources for the kde4.0.x
timeframe as libspectre won't be released/packaged on time for 4.0 but will remove it for 4.1 and onwards.
libspectre is a shared project between okular and evince *hooraay* that aims to unify the developing of a layer on top of libgs
That closes my work on making ps *work* on okular for KDE 4.0, any reported problem will be of course investigated
Thanks for reading up to here :-D
svn path=/trunk/KDE/kdegraphics/okular/; revision=732860
*** Note this is not a complete port, most of the generators use the
printFiles method which Qt 4.3 does not support, these have simply
been commented out until we find a solution. At least it removes
the dependency so we can remove from kdelibs.
svn path=/trunk/KDE/kdegraphics/okular/; revision=725660
Added a non-virtual closeDocument() in the base Generator class: this way, particular closing routines can be implemented in the "low level" of a generator.
Apart the renaming, the logic of doCloseDocument() remains the same.
CCMAIL: okular-devel@kde.org
svn path=/trunk/KDE/kdegraphics/okular/; revision=723046
- We don't use libqgs anymore but libgs directly
- We don't use an out of process executable anymore to talk to libqgs
Using libgs is a bit cumbersome (only one gs instance per process)
and almost no other gs viewer does it, but if you look at kghostview code
it's full of X black magic, so going the libgs path feels better
for my sanity and for portability
svn path=/trunk/KDE/kdegraphics/okular/; revision=671156
* add full API docs
* renamed getMetaData -> metaData
* removed supportsRotation in Document and Generator
* moved Permission and SearchDirection enums into separated header core/global.h
svn path=/trunk/playground/graphics/okular/; revision=619183
Add a protected method to get the document, and hide the real document pointer as private, so the generators can't redefine it.
svn path=/trunk/playground/graphics/okular/; revision=598025
* Moved all implementations to generator.cpp
* Added 'const' where it make sense
* Adapted all generators (except gs)
svn path=/trunk/playground/graphics/okular/; revision=597525
Instead of telling the generators to do the work themselves (that was usually destraoying the ld pages and creating the new ones), now we just rotate the page objects deleting only their "mutable" contents.
This way, generators can just return true in their supportRotation() to make okular rotate the pages for them for free. Of course they still have to generate the page pixmaps according to the given page rotation.
Now, there's a new rotationChanged() function in the Generator API so generator that needs it can be norified about the document rotation changing.
CCMAIL: developers@okular.org
svn path=/trunk/playground/graphics/okular/; revision=593632
Now every generator has to implement this one and put (if necessary) all the code for cleaning up all the stuff related to the currently open document.
For now the return value it is not read, but generators as strongly suggested to return tru o false, whether all the operations in there went fine.
svn path=/trunk/playground/graphics/okular/; revision=562210
- more const'ness in signals
- no need to redeclare the signals in the generators, as they are already in Generator
svn path=/branches/work/kde4/playground/graphics/okular/; revision=549941
- 1. editor-like text selection, and I do mean it, its not pseudo-editor
(like the ones acroread and kviewshell have) it doesnt intersect the
selection area with words under it, no, it does a lot more, including
work on cursors and searching for the text area closest to the given
cursor
- 2. rotation support, change the orientation of the documents if
you need too :)
- 3. the kfaxview backend works beautifully, porting kviewshell backends
is damn easy ! djvu and dvi will be next!
- 4. Hardware Blending of selection rectangles! We now use XRender
instead of KImageEffect, makes a damn faster blend!
- 5. Overview mode - as seen in Kviewshell, but quite a bit extended,
the kviewshell is only one state, while we support it in both
continous and non-continous form
- BTW. I coded all those features myself, (apart from kfaxview backend library)
it is an impressive bit right? but oKular cant be run by only one person,
join in on the fun! i can introduce you into the code just mail niedakh@gmail.com
svn path=/trunk/playground/graphics/oKular/kpdf/; revision=509871
1. GSGenerator (generator ghostview, need renaming)
Implements the Generator class, handles PixmapRequest transmission and starts other objects.
2. InternalDocument
Holds information stored in document's DSC and the information set by the user:
Page Format, BoundingBoxes, etc, some code taken from kghostview
3. GSInterpreterLib, the synchronous pixmap generator
4. GSInterpreterCMD, asynchronous pixmap generator that communciates with the kpdflibgsasynchelper application
svn path=/trunk/playground/graphics/oKular/kpdf/; revision=445276
Martin T. H. Sandsmark
Montel Laurent
Alex Richardson
Albert Astals Cid
Pino Toscano
Albert Astals Cid
John Layt
Tobias Koenig
Piotr Szymanski