Whenever the scrollbar value changes we request a new pixmap so we
always have an up to date viewport.
Unfortunately that can lead to unnecessary calls when zooming. That's
because the zoom event changes the value of each scrollbar but not all
at once. Instead one scrollbar value is changed after the other (leading
to two requests).
The problem here is that when the first request is made just one of the
scrollbars have its updated value while the other still carries the old
one. Previously that wasn't a big deal but now we depend on the correct
scrollbar values to get the visible viewport and thus request only the
visible tiles (and its whereabouts).
Without that change we're making requests to tiles that are not actually
visible and this only gets worse as the zoom level gets higher.
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.
Call m_part->closeUrl with promptToSave=false in the Shell dtor, so that
the save changes prompt is not shown again (it's already shown because
of Shell::queryClose)
Call m_part->closeUrl with promptToSave=false in the Shell dtor, so that
the save changes prompt is not shown again (it's already shown because
of Shell::queryClose)
Stop being too smart for own our good, try to merge open and openRecent actions in just one action
confuses the hell out of people, so let's KISS and just make open recent be open recent
BUGS: 302358
BUGS: 251335
FIXED-IN: 4.10.0
With this commit Okular will show a so called poster image for PDF documents
containing movie annotations. The image will be a screenshot of the first frame
of the video.
BUGS: 301603
REVIEW: 105890
FIXED-IN: 4.10.0
The splitting was only executed after the pixmap arrived the tiles
manager. That was bad and likely to lead to an unnecessary rendering in
the case of a big tile that would be split after all.
This also fixes a bug where some tiles weren't updated.
Otherwise we end up in a busy loop on part deletion if there are pending requests
Should not happen but if this fixes it don't see the need to lose time investigating
why given the number of todo things
Otherwise we end up in a busy loop on part deletion if there are pending requests
Should not happen but if this fixes it don't see the need to lose time investigating
why given the number of todo things
Most of the positioning calculations were taking into account the 'crop'
argument (which is a NormalizedRect) to execute some translations.
If not using tiles the value of crop were always the normalized bounding
box of the page, relative to the page itself. So translating by it is
essentially a noop.
When using tiles this argument represents the normalized viewport,
relative to the page. Although useful for the tiles manager, translating
by 'crop' is not necessary for any of those operations.
Since the review pane has different requirements than the page view, this
change introduces a mode parameter to the AnnotationPopup ctor.
REVIEW: 106045
Provide the actions for all annotations in the RMB menu, if multiple
annotations are located on top of each other.
BUGS: 300942
REVIEW: 106035
FIXED-IN: 4.10.0
The machinery in KParts/QObject is already doing it and this way we don't get the
KXMLGUIClient::~KXMLGUIClient: 0x15637528 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
warning
I'm not sure if calling this a kdelibs bug yet or not though :D
BUGS: 261538
FIXED-IN: 4.9.1
The machinery in KParts/QObject is already doing it and this way we don't get the
KXMLGUIClient::~KXMLGUIClient: 0x15637528 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
warning
I'm not sure if calling this a kdelibs bug yet or not though :D
BUGS: 261538
FIXED-IN: 4.9.1
