The tabular-features LFUN was merged with "inset-modify tabular" when
simplifying the tabular dialog at b5049e7. This choice later indirectly caused a
few regressions (#7308, #9794).
I reintroduce tabular-feature to allow more flexibility for user
commands, whereas "inset-modify tabular" is now reserved for the tabular
dialog. In particular, inset-modify tabular is no longer caught by math grid
insets. The name tabular-feature is kept to avoid renaming icons.
Known issues:
* After successfully applying a tabular command, the cursor is truncated to the
table.
* Note that the tabular dialog still has similar issues that are inherited from
the achitecture of the dialog menu. For instance the pref change can be
mis-dispatched to an inset inside a cell and cause an error, for instance:
Lexer.cpp (934): Missing 'Note'-tag in InsetNote::string2params. Got
tabular instead. Line: 0
Maybe the inset-modify LFUN should be modified to treat commands coming from
the wrong dialog (by checking the type) as unknown and undispatched so that
the parent can get it. In that case a non AtPoint variant of inset-modify
could be reintroduced in order to generalise tabular-feature. See:
http://mid.gmane.org/n4rdk1$efj$1@ger.gmane.org
This was made visible by aab1b145a5, since xhtml export for
lib/doc/Additional.lyx caused an exception. However, the cause for this was
already present earlier: All attempts to output a std::string to an
odocstream resulted in trying to change the encoding of the stream instead,
since there is no operator<<(odocstream &, std::string) defined, and an
implicit conversion to SetEnc happened instead.
This is fixed by making the SetEnc constructor explicit and adjusting all
code parts that did not compile anymore after that. The parts of the code
that did use the wrong output operator were the std::string version of
htmlize() from output_xhtml.cpp and all changed parts in the other .cpp files.
I also removed the std::string versions of html::htmlize() and
html::cleanAttr(), since it was difficult to see which encodings were used
with these. Now we are always explcit when using html::cleanAttr() and
html::htmlize().
Use the function support:truncateWithEllipsis() to shorten a docstring with
... at the end. Actually we use U+2026 HORIZONTAL ELLIPSIS instead of "..." when
automatically shortening strings. This is to be consistent with Qt's own
truncation and is much nicer on the screen.
This includes the bugs #9575 and #9572 regarding broken text elision in the
outliner.
Known issues (non-regressions):
* TocBackend::updateItem() should be rewritten to update all TOCs. (#8386)
* "..." should be replaced with … everywhere else on the interface (including
translation strings).
* We should prefer to rely on QFontMetrics::elidedText() to truncate strings
with an ellipsis whenever possible, or an equivalent for the buffer view
dependent on the font metrics. See the warning in src/support/lstrings.h.
This makes the defaults of Inset::inheritFont() and Inset::resetFontEdit()
compatible. There is no user visible change except for the Chunk inset which
does not produce invalid LaTeX after editing operations anymore.
This is the safe version for 2.1.0, for later there are still open questions:
- All insets with ResetsFont true should be audited: Is this really needed,
or do they show similar editing problems as the Chunk inset?
- Does inheritFont() need to be customizable in the layout file as well?
- Is resetFontEdit() != !inheritFont() needed at all?
I did not use change tracking for the docs, since I updated all existing
translations.
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?
* now hasSettings only means... that the inset has a settings dialog
* and clickable means that something should happen with left-clicking on the inset
Some inset behaviours are changed:
* (V)Space insets are not clickable anymore (the settings dialog is still accessible via context menu and Edit menu)
* TOC inset is now shown as active
* FloatList inset is shown as active and clicking on it opens the relevant part of the TOC dialog
This could be a candidate for branch (2.0.4)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40755 a592a061-630c-0410-9148-cb99ea01b6c8
preparatory to fixing #7080. Note that mathed uses the same routine, but
for a completely different purpose, so I did not rename it there. I have
seen no difference in behavior after testing, e.g., opening and
exporting Math.lyx, and also re-saving it and looking at the diff.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38109 a592a061-630c-0410-9148-cb99ea01b6c8
that also makes sure it doesn't do more work than it needs to do, by
limiting the size to 40 characters. Previously, InsetBranch::addToToc()
would have added a string representing the entire contents of the
branch! It's hard to imagine that having to recalculate that sort of
thing doesn't cause some problems with speed, especially in documents
with lots of notes and branches and such.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36974 a592a061-630c-0410-9148-cb99ea01b6c8
The issue is that RenderGraphics calls updateFrontend() even if within a CutAndPaste stask.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36699 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
In r33495, "LFUN_TABULAR_FEATURE" was replaced by "LFUN_INSET_MODIFY tabular". However, the status of LFUN_INSET_MODIFY is always enabled while a lot of insets are not allowed to change the number of columns etc.
There we need to disable the "LFUN_INSET_MODIFY tabular" status.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34613 a592a061-630c-0410-9148-cb99ea01b6c8
This is also in preparation of a decent fix for bug #3900.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34347 a592a061-630c-0410-9148-cb99ea01b6c8
- proper message passing for all tabular features
- properly define which feature needs an argument
* replace LFUN_TABULAR_FEATURE with LFUN_INSET_MODIFY
- The math tables are also affected. In the future a common base class
between math and text table will solve this inconsistency.
- There is a hack in GuiApplication in order to not rename the toolbar
icons. This will have to be cleaned up with a general icon naming for
LFUN_INSET_MODIFY... to be discussed.
* Tabular Dialog:
- big cleanup, lots and lots of bug fixing here
- migrated to InsetParamsWidget
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33495 a592a061-630c-0410-9148-cb99ea01b6c8
a lot of simplification is possible. Except some instability period...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33389 a592a061-630c-0410-9148-cb99ea01b6c8
For a displayed equation, the height is artificially increased by a displayMargin() in InsetMathHull::metrics if it is a displayed equation and there is a preview.
This extra height is not covered by the preview image and what one can see is the background as drawn by the MathHull inset. The color of this background should be either Color_mathbg or Color_background depending on whether the preview is shown or not.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32560 a592a061-630c-0410-9148-cb99ea01b6c8
accepting changes in a clipboard copy (CutAndPaste.cpp), we set the buffer
of insets (and we reset them later).
Doing this makes sense because we know this is the only operation on these
out-of-document paragraphs that will require access to a buffer.
Also, this commit gets rid of one explicit test against ERT_CODE and
LISTING_CODE.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@30623 a592a061-630c-0410-9148-cb99ea01b6c8
