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().
the minibuffer. As the comments explain, this leaves a different
bug, but (a) it isn't a crash and (b) it probably won't affect
many users, if *any* users.
In [19024f72\lyxgit] this line was removed. Later this caused that floats were converted to strings using ','s instead of '.'s. Readding this line fixes this.
Get the default language by a mix of QLocale and LyXRC::gui_language
Known limitations:
* encoding is supposed to be UTF-8 (the charset parameter is checked);
* context is not handled (implemented differently in LyX);
* plural forms not implemented (not used for now in LyX);.
* tThe byte endianness of the machine on which the .mo file have been
built is expected to be the same as the one of the machine where this
code is run.
LyX uses QTemporaryFile to create a unique temporary directory. This
temporary directory will consist of two random characters and the process
identifier (PID).
Currently, the two random characters are often the same because Qt's
random generator was not seeded. If there are a lot of lyx temporary
directories accumulated, the chance of failing to find a unique temporary
directory is (N/100)%.
The temporary directories can be left behind if either LyX crashes, or
when a file in the temporary directory is opened in another viewer when
LyX closes. This can be a pdf that is viewed in a reader that disallows
the file to be removed while viewing it.
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
Most images are generated by development/tools/generate_symbols_images.py, but
some were drawn manually. Now there is no image missing from the ones the
script can generate.
These are all generated by development/tools/generate_symbols_images.py, the
only manual adjustments were renamings due to case sensitive file systems on
windows.
buffer-forall only takes one parameter now, which is the LFUN to
dispatch on all non-hidden buffers. A hidden buffer is defined as being
internally open in LyX, but not visible in any window (view).
Thanks, JMarc.
In order to interact with native osx applications, AppleScript support is a plus.
Here is a patch that makes LyX respond to a simple command (run) and that allows to communicate with LyX as with the LyX client.
Example of use:
tell application "LyX" to run "server-get-filename" with argument ""'
returns
message:/Users/bpiwowar/newfile1.lyx, code:0
with a message and the error code
The goal here is to get rid of the old code that modified variables
LANGUAGE and LC_ALL, therefore creating the problems mentionned
in the ticket.
In the new system, there is no explicit "GUI" message handler, that
needs to be reset at each language change. Instead, getGuiMessages
calls getMessages with the correct parameter. This allows to simplify
greatly the code and to remove a lot of old cruft.
The idea is to record undo at the place where the document is modified:
1/ in Buffer::updateBuffer, add a recordUndo, with the caveat that a
const_cast has to be used (because updateBuffer is const but
modifies the document, go figure).
2/ in GuiApplication::dispatch, add an extra undo group that
encompasses the updateBuffer call. Some other undo groups may be
redundant now, but it is not a problem since they do not cost
anything.
In this version, the idea is to record undo at the place where the document is modified, which is definitely cleaner.
1/ in Buffer::updateBuffer, add a recordUndo, with the caveat that a
const_cast has to be used
2/ in GuiApplication::dispatch, add an extra undo group that
encompasses the updateBuffer call. Some other undo groups may be
redundant now, but it is not a problem since they do not cost
anything.
Both bugs above were due to a missing screen update. This patch
updates the current view after dispatching a lyxserver command
and thus solves both.
The patch is quite strightforward and the only difficulty was due
to the fact that the lyxserver needs the result of the dispatched
command. Now, GuiApplication::dispatch(FuncRequest const &) does
right this, but does not return the result, while
GuiApplication::dispatch(FuncRequest const &, DispatchResult &)
is called by the former but does not return the result. So, I
split the first one, isolating the code performing the update,
such that the second one can also update the current view when
the caller is the lyx server. When the action is initiated by
anything different from the lyx server, the behavior is unchanged.
Of course this will only work if output_changes was true when creating the
.tex file.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40139 a592a061-630c-0410-9148-cb99ea01b6c8
This was an attempt to fix#2743 without re-working the InsetBibitem
mess. It didn't work, so we have to do that.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38702 a592a061-630c-0410-9148-cb99ea01b6c8
through the rc setting \icon_set. Preferences dialog will follow shortly.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38038 a592a061-630c-0410-9148-cb99ea01b6c8
Actually, this was an oversight in r33226. There is no need to touch the physical cursor in this method.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37310 a592a061-630c-0410-9148-cb99ea01b6c8
rc2rc project. (Was there a bug number for that? I can't find it, if
there was.)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37247 a592a061-630c-0410-9148-cb99ea01b6c8
preparatory to prefs2prefs conversion here, which will be the last piece
of that work.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37235 a592a061-630c-0410-9148-cb99ea01b6c8
Unfortunately the commandline export of InsetInfo is still broken for MENU_INFO.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37134 a592a061-630c-0410-9148-cb99ea01b6c8
- In GuiApplication::dispatch, do not call markDirty() for lfuns that are not ReadOnly
- In Undo::Private::recordUndo, call markDirty(). The indicator of dirtyness is now the existence of an undo element.
- In lyxfind, remove several markDirty calls that are not needed anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36772 a592a061-630c-0410-9148-cb99ea01b6c8
* create math inset
* enter macro name \ww
* press left arrow to re-enter the macro name inset, add a third 'w'.
* when leaving the inset is is updated through notifyCursorLeaves, but no undo group is active
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36596 a592a061-630c-0410-9148-cb99ea01b6c8
GuiView::loadDocument also already calls setBuffer(), so this is not needed everytime too.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35917 a592a061-630c-0410-9148-cb99ea01b6c8
- move a comment back from to GuiApplication to GuiView.cpp, so we have the comment in the place where we decide to process the func request asynchronously;
- rename dispatchDelayed to processFuncRequestAsync to have the same terminology as in the other processFuncRequest* methods;
- introduce a new function processFuncRequest to complete the set of processFuncRequest* methods. It is strange that for the normal processFuncRequest one should suddenly use lyx::dispatch. Besides, I think it is good that the whole GUI will dispatch funcRequests through GuiApplication::processFuncRequest from now on;
- use the slotProcessFuncRequestQueue to relay to processFuncRequestQueue;
- properly camelBump addToFuncRequestQueue;
- group the implementation of the processFuncRequest* functions;
- document the side-effect of processFuncRequestAsync.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35784 a592a061-630c-0410-9148-cb99ea01b6c8
Make it possible to suppress messages stored in DispatchResult objects.
BUG: 6417
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35662 a592a061-630c-0410-9148-cb99ea01b6c8
What is missing is some feedback on what colors are
set from the system (they should be disabled in the
color list).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35096 a592a061-630c-0410-9148-cb99ea01b6c8
I am not sure that there is something else that we can get from QPalette. Maybe
cursor color, if someone tells me how to get it.
Only tested on mac. I can revert if this causes problems on linux or windows.
I have to check too that it still works in non-gui mode.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35060 a592a061-630c-0410-9148-cb99ea01b6c8
DispatchResult to store a flag that tells us whether we need a buffer
update or not.
So: If you find a missing one, go to an appropriate place in the
dispatch and call cur.forceBufferUpdate() or, if you don't have a cursor
but do have a DispatchResult, call dr.forceBufferUpdate().
There is one remaining call I could not move, in
TextMetrics::redoParagraph. But this looks like an emergency call when
the macro context has not been set. There are also a couple calls that
are connected with buffer creation that I commented out, since the same
call is done again almost immediately. But I'm not positive about those.
Now the nice thing would be to do the same for updateMacros().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34826 a592a061-630c-0410-9148-cb99ea01b6c8
Solution: don't use boost::bind for msvc10 (could also be extended to several GCC versions)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34257 a592a061-630c-0410-9148-cb99ea01b6c8
* I didn't like the fact that the heart of the dispatch/status machinery is in the default clause of a long switch statement. Now, it is clear that we enter the app in getStatus, which then asks the GuiApplication itself, the GuiView, the current BufferView, the current Buffer, the document BufferView, the document Buffer,
* Shouldn't we let BufferView call the Buffer getStatus() functions ?,
* This also makes sure that if a command is not handled, it is turned off. Before r34164 this was caused by the default clause in BufferView,
* Now it is prevented that if the document BufferView is the same as the current BufferView, that the getStatus() functions are called twice,
* A warning can be outputted if the LFUN is not handled.
PS I want to do the same for the dispatch function.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34165 a592a061-630c-0410-9148-cb99ea01b6c8
