FileName::tempName() created a new temp file name by using qt to create a
temporary file with a unique name, and then deleting that file and returning
the name. This was unsafe, since other processes or even other threads of the
running LyX could create files with the same name between deletion and then
using the temp name.
This is fixed by using the TempFile class instead. As a side effect, a few
cases where the temp files were not deleted after usage were fixed as well.
The only place that is still unsafe is createTmpDir().
for possible thread conflicts, of the sort Georg resolved at
6a30211f. I have made static variables const where possible,
and marked cases that looked potentially problematic with the
comment:
// FIXME THREAD
Many of these definitely are vulnerable to concurrent access, such
as the static variables declared at the start of output_latex.cpp.
Suppose, e.g., we were outputting latex and also displaying the
source of a different document.
I'd appreciate it if others could grep for "FIXME THREAD" and see
if some of these are harmless, or what.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
* some functionality is in new modules now
new header locations and library names: QtConcurrent and QtWidgets
* method setResizeMode is renamed to setSectionResizeMode
* deprecated QAbstractItemModel::reset() is dropped now
* platform specific code like QApplication::syncX() is not common anymore
* QString::fromAscii() is dropped now
* some QDesktopServices methods has been moved to QStandardPaths
When there is a single document open, the tabbar gets hidden. The only and selected tab is still visible though as a break in the line delining the tabwidget. To fix this we paint the tabwidget ourselves and remove the presence of the hidden tab.
If no mask is supplied or the mask is attached to the end of the filename, we end up with unexpected names like
<system-temp-dir>\lyx_tmpdir.qHp780.vcr780_<mask>
instead of a temporary file in the lyx temporary directory like
<system-temp-dir>\lyx_tmpdir.qHp780\<mask>.vcr780.
This option is set to true by default as this is the most widespread use case.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40515 a592a061-630c-0410-9148-cb99ea01b6c8
I also added 2 FIXME where we should not call GuiView directly.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39948 a592a061-630c-0410-9148-cb99ea01b6c8
(Sorry for not waiting for you, I wanted to enter freeze ASAP.)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38317 a592a061-630c-0410-9148-cb99ea01b6c8
Two things have been fixed here:
1) the selection should not be cleared when the user right clicks a math inset that is part of the selection,
2) the type of context menu should be determined at mouse-press, because that is the moment when the cursor is set. However, we should do it after setting the cursor, because setting the cursor might change the selection status and this influences the choice for the type of context menu.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37961 a592a061-630c-0410-9148-cb99ea01b6c8
This should have been done by qt, but we can override qt by adapting the style on the windows platform.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37678 a592a061-630c-0410-9148-cb99ea01b6c8
This was a similar problem as for bug #5796 in r30807. There I made sure that the position that is used for the context menu is set at mousepress. That was because also the cursor was set at mousepress and we want to get the context menu at the place where the mousebutton was pressed, and not where the mousebutton was released.
However, in this case, the position of the context menu is stored on mousepress, but we don't take into account that the cursor might move afterwards due to the DEPM.
So, the solution is not to save the position of the mouseclick, but to save the name of the context menu we requested.
PS. Perhaps we could save the cursor position, but this seems to work too.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37669 a592a061-630c-0410-9148-cb99ea01b6c8
Now, when hovering the tabs, the full paths are shown as a tooltip.
see r37084.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37101 a592a061-630c-0410-9148-cb99ea01b6c8
Now, when hovering the tabs, the longer name is shown as a tooltip.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37084 a592a061-630c-0410-9148-cb99ea01b6c8
