The miss counter was taken away. Now the algorithm relies on the
distance between the tiles and the viewport.
Also the visibleRect() and setVisibleRect() methods were removed from
TilesManager since we now pass this information to
TilesManager::cleanupPixmapMemory()
Will make it easier to make separate apps based on the core in the future
Note this will most probably break your settings if you are not running a very up to date kdelibs (4.9 or 4.10)
so be careful on updating
REVIEW: 104947
Some requests may take a while to process in a highly zoomed region.
Since those requests are not yet finished, other requests to the same
region are likely to be made (specially if the user is scrolling fast)
and the generator will have to render the same region repeatedly.
Also when changing zoom rapidly some pixmaps can arrive at the tiles
manager when another request has already been posted. This pixmap is not
necessary anymore and should be discarded (the tiles manager will get a
new pixmap anyway).
The visible region was set in the PixmapRequest only a tiles manager was
available. Because of that the generator could check if it was supposed
to used tiles by simply checking if its normalized rect was null.
However is good to know the visible region even when a tiles manager is
not present. This way if the request is big enough to start a tiles
manager we already know the visible region and can change the
PixmapRequest accordingly.
Previously it was cleaned in FIFO order
I also moved the pixmap selection logic in a separate function, that
will be needed in the next patches.
Note: This behaviour is yet not optimal for the thumbnails panel,
because it is allowed to be at a page different than the current
viewport
Previously it was cleaned in FIFO order
I also moved the pixmap selection logic in a separate function, that
will be needed in the next patches.
Note: This behaviour is yet not optimal for the thumbnails panel,
because it is allowed to be at a page different than the current
viewport
It actually serves three purposes:
a) Make sure all the values are there (this should be always true, but doesn't hurt making sure) because if SwapFree was there but SwapTotal was not, it'd be a mess
b) add up things in order so we don't underflow, currently the code did process stuff as it came in the file, and it happens that SwapTotal appears before SwapFree in /proc/meminfo so it actually did "MemFree:" + "Buffers:" + "Cached:" - "SwapTotal:" + "SwapFree:", which can underflow if "MemFree:" + "Buffers:" + "Cached:" < "SwapTotal:"
c) Do not underflow at all, so if "MemFree:" + "Buffers:" + "Cached:" + "SwapFree:" < "SwapTotal:" we return 0 correctly not a zillion of free memory
Aurélien you might want to update gwenviews copy of this code (there's a few other bugfixes we did a while ago you didn't update either)
CCMAIL: agateau@kde.org
BUGS: 291129
The only affected generator is poppler (because it's the only one with
saving support).
Since version 0.20, Poppler can save annotations to PDF. If the user is
using an older version, this patch warns him that annotations are not
saved.
This patch makes sure that the file saved in the .okular file keeps
the original filename (and, in particular, the extension) even if the
user is re-exporting a .okular archive as .okular archive. Before this
patch, the file boundled in the .okular archive would be named like the
.okular file it was exported from (eg foo.okular instead of foo.pdf).
Note: Okular had no problems in reopening it, but advanced users
unpacking the ZIP file obtained a .okular file which is actually a
native file, and not an okular archive.
1) If the user had previously annotated the document with an old okular
version and the document contains existing annotations and no /Encrypt
(ie the case where annotation changes are no longer saved locally), make
Document::saveDocumentInfo write the original unmodified local
annotations back to XML, so that it seems that the original file was not
changed. If the user makes annotation changes, code from previous
patches already asks him to save them to a different document on close.
2) Ask "Save changes?" if the user has modified annotations in a .okular
archive.
BUG: 300197
3) Turned a "sorry" message in a "information" (with dontshowthisagain),
because now we also have the "Save changes?" prompt to inform the user.
4) Suppressed all annotation-related message boxes on document opening
This patch turns Okular into a ReadWritePart. Annotation editing is always
disabled if we're loaded as ReadOnlyPart, no matter the document type.
REVIEW: 105020
The only affected generator is poppler. Note that:
Document has /Encrypt <=iff=> SaveInterface supportsOption(SaveChanges) is false
This patch enforces the following behavior (and warns the user the first time
he edits an annotation).
- If the document has /Encrypt, warn that "Save as" is not available, but it's
possible to export as okular archive. New annotations will be automatically
saved to XML as usual.
Note that the previous patch already made all existing annotations uneditable,
because there's no way to save them.
- If the document has no /Encrypt and there are existing external annotations,
warn that changes won't be saved automatically. The user needs to "Save as" or
changes will be lost.
- If the document has no /Encrypt and there aren't existing external
annotations, don't show any warning. New annotations will be automatically saved
to XML as usual and to file if "Save as" is pressed.
Mailson Menezes
Tobias Koenig
Bogdan Cristea
Albert Astals Cid
Fabio D'Urso
Albert Astals Cid