Since 6d6a3bfce5, files are opened in a
new Shell instance and the current one is unaffected, therefore changes
to the current file do not get lost any more.
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
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
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
As a side effect, this change fixes bug 303998, that caused a crash if
the part's widget was destroyed before the part itself, because
m_findBar had already been destroyed.
BUG: 303998
FIXED-IN: 4.9.0
As a side effect, this change fixes bug 303998, that caused a crash if
the part's widget was destroyed before the part itself, because
m_findBar had already been destroyed.
BUG: 303998
FIXED-IN: 4.9.0
Fixes a bug that causes the extraction of a wrong bounding box:
If the request queue is not empty, signalPixmapRequestDone causes a new
pixmap request to be started, thus overwriting mPixmapGenerationThread's
mCalcBoundingBox before it is read by the if in the next line.
Now signalPixmapRequestDone is called after the bounding box is saved,
so that new requests are started only after all data from
mPixmapGenerationThread have been saved.
BUG: 257370
REVIEW: 105600
Fixes a bug that causes the extraction of a wrong bounding box:
If the request queue is not empty, signalPixmapRequestDone causes a new
pixmap request to be started, thus overwriting mPixmapGenerationThread's
mCalcBoundingBox before it is read by the if in the next line.
Now signalPixmapRequestDone is called after the bounding box is saved,
so that new requests are started only after all data from
mPixmapGenerationThread have been saved.
BUG: 257370
REVIEW: 105600
The call to FT_New_Face takes the address of the 'face' variable, whose type is a
typedef *something TF_Face;
The value of TF_Face (so a pointer to the properly filled font structure) s then
replaced inside the call of TF_New_Face; but when the latter function fails,
the value of 'face' is not reset and this leads to a crash in the distructor of
TeXFont_PFB.
So properly initialize TF_Face to 0, its address is valid, and the code works.
BUG: 303472
FIXED-IN: 4.8.5
(cherry picked from commit 99c4da2f9e)
The call to FT_New_Face takes the address of the 'face' variable, whose type is a
typedef *something TF_Face;
The value of TF_Face (so a pointer to the properly filled font structure) s then
replaced inside the call of TF_New_Face; but when the latter function fails,
the value of 'face' is not reset and this leads to a crash in the distructor of
TeXFont_PFB.
So properly initialize TF_Face to 0, its address is valid, and the code works.
BUG: 303472
FIXED-IN: 4.8.5
This is especially useful if resetSearch is called because of a
document switch, because a search without results in the previous
document has no relation with the new one, and therefore keeping the red
background doesn't make sense.
Instead of directly killing the search in the core, emit a signal
caught by FindBar to tell its SearchLineEdit to reset the search
operation.
In this way, SearchLineEdit can set m_changed, and next time a new
search operation will be started, instead of attempting to use the
old one.
This is especially useful if resetSearch is called because of a
document switch, because a search without results in the previous
document has no relation with the new one, and therefore keeping the red
background doesn't make sense.
Fabio D'Urso
Albert Astals Cid
Jan Binder
Sandro Mani
Tobias Koenig
Jaydeep Solanki
Yury G. Kudryashov
Script Kiddy
Albert Astals Cid
Luigi Toscano