It is confusing for the users to see the formats 1.3--1.6 in the file-open
dialog and not the 2.0 format. The exotic extensions were only used when
e.g., LyX 1.6.x exported to LyX 1.5.x format.
* disable branch-add-insert in pass thru paragraphs
* when it is not possible to input a quote inset, insert a single
ascii quote when argument to quote-insert is "single"
* handle "mathspace" dialog in Text::getStatus
* disable insertion of newline inset in pass thru paragraphs
* handle "mathdelimiter" and "mathmatrix" dialogs in GuiView::getStatus.
LFUN_BUFFER_SAVE_AS has an optional argument where an initial format can be preset
This fixes:
* The remainder of bug #3402: Open Export As dialog when attempting to export to read-only directories
* Bug #8886: 'export as' should default to the default document output format
It is always a bad idea to compare a localized string. I think the whole method Formats::getFormatFromPrettyName (which is now unused) should be ditched. This is bound to fail.
If there is a new toolbar, it will not be restored by Qt and we need to
initialize it ourselves. However, it is not so easy to find out which
toolbars are restored by Qt and which are not. For this, the setVisible
function of GuiToolbar is 'misused'. If the visibility is set, the toolbar
must have been restored by Qt and we should leave it alone.
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?
The advantage of having this in LyX is the intelligent file name handling
of included files. Implementation as discussed on the list, but ensure also
that an attempt to use locked files fails.
It is not possible to transport the different error/abort/success conditions
of a VCS checkin through a simple empty or nonempty string. Therefore it was
no wonder that the return values were used inconsistently for different VCS.
Now the log and return status are decoupled, and all VCS are handled
consistently. This is a prerequisite for proper locking detection of the
upcoming rename command.
Both cvs and svn are able to retrieve non-existing files from repository,
but this was only implemented for rcs. This is a prerequisite for the
planned move and copy VCV operations. I also improved error schecking and
used extractFromVC() also for files specified on the command line if they
do not exist (in GUI mode, it was already the case in non-GUI mode).
If the WA is the last one showing a buffer, then the buffer may either be
closed or kept hidden, or the user is asked. The behaviour is controlled
by a new preference option.
For discussion, see http://comments.gmane.org/gmane.editors.lyx.devel/142638
The stderr message "Object::disconnect: Unexpected null parameter"
often appeared when closing and opening buffers.
GuiView::on_currentWorkAreaChanged should not pass a null pointer
to Object::disconnect.
