AMS align environment should have some spacing between odd and even columns.
Add a new virtual method displayColSpace() to InsetMathGrid, InsetMathHull and
InsetMathSplit.
A longstanding problem... (related: #1861)
The columns in AMS math environments have a fixed alignment (colAlign() in
InsetMathGrid.cpp). We set this alignment for display (Georg's
displayColAlign()) in InsetMathHull and InsetMathSplit. This is done according
to tests and documentation for the various environments.
There is also some mechanical code factoring via colAlign().
Finally, I disable setting the horizontal alignment in InsetMathSplit, which has
no impact on the LaTeX output, and has no longer any impact on the screen. (As
for vertical alignment I discovered that it was in fact customisable for
\aligned & friends! I hope that the more faithful interface will let other
users discover that too.)
The offending code appears to have been introduced a long time ago. My
understanding is that it is no longer relevant. Notably, it only appears on copy
and not on cut, which tells us that: 1) it should be safe to remove it, 2) we
should remove it for consistency.
TocModels::reset() in GuiView::structureChanged() collapses the TocWidget, and
therefore requires an update right after, which was missing.
In fact, profiling TocWidget::updateView() shows that delaying the update is
good only for fast keypresses (essentially movement). It costs 5% of a
char-forward operation in a document with approx. 100 table of contents
items. The update optimisation has been rewritten to take this data into
account.
This also fixes#9826: Outline disclosure of subsection content disappears one
second after doubleclicking content item.
As discussed on the list some time ago. cmake produces .po files already in
native line endings. Only autotools on mingw might produce wrong line endings
now, but I am pretty sure that nobody updates .po files using autotools on mingw.
cmake sorts the input files for lyx_pot.py internally, but autotools use a
shell pattern like *.ui on the command line, so the order may be different
on different machines. It is more robust not to require any sorting from the
caller, so lyx_pot.py sorts now internally.
While a one paragraph large collapsable inset (containing for example a tabular) could be very wide and trigger horizontal scrolling, the code that makes collapsable insets wide when they contain several paragraphs would actually make them narrower in this case.
Typical example is a wide tabular and a caption in a table float, where horizontal scrolling would not trigger.
(cherry picked from commit a879bc2575)
In some cases, the insets may change height or width without changing
the other apsects of the row.
Fixes bug #6991 and #10182.
(cherry picked from commit 508518ad95)
this would require another font package with several MB size for only one single word -> not worth it for the Tutorial. The other language versions of the Tutorial do already not use true small caps.
It is wrong to assume that direction is left-to-right when no indication exist.
Add a new enum with values LtR, RtL and Auto to be used as argument of
the private text() methods. When direction is Auto, let Qt decide how
the string shall be layed out.
This is reimplementation of 51ee267c. A direct cherry-pick was not possible.
Fixes bug #10169.
The computation of the width of the button was wrong. If <--> stands
for TEXT_TO_INSET_OFFSET/2 spacing, and if `[]' marks the button's
limits, then the intent is
<-->[<-->button text<-->]<-->
Therefore the physical grey rectangle width is
width - Inset::TEXT_TO_INSET_OFFSET
With this change, the spacing on the right of the button is not larger
than the left one.
Fixes bug #10147.
(cherry picked from commit 516d5d29dc)
There is already a spacing of 2 pixels on each side of a button (e.g.
collapsed inset). There is no need to add one extra pixel for command
insets.
Fixes part of bug #10149.
(cherry picked from commit 68149e380d)
When the box has a special width, one should not consider that as a fixed width. Otherwise, due to implementation quirks, the width will be set on screen as 1 inch.
A better solution would be to actually set the width by taking in account the contents width, height ans total height. This is not very difficult, but I do not know whether it would workout well in the work area.
Fixes bug #10048.
