Age | Commit message (Collapse) | Author |
|
- some light formatting in the header file
- change aPnts from std::vector<Point*> to std::vector<Point>, no point
in dynamically allocating a small value class
- rename aPnts -> mvPnts
- use std::unique_ptr for userdata
- rename pUser to mpUserData
- change some methods protected->private, since nothing external is
using them
Change-Id: I7a3f4c30c60ae1be3713f460fe65de95bed2f124
Reviewed-on: https://gerrit.libreoffice.org/42102
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to clarify that it is an abstract base class, and to avoid memleak
when deleting derived instance as pUser in SdrDragStat::Clear().
Change-Id: I39670841fda1ea3c45698585ce50aec944e0d4ab
Reviewed-on: https://gerrit.libreoffice.org/42097
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
The problem as seen by the user: if you have a table of 2 rows and 1 column,
and the separator line is dragged upwards by the mouse, then undo doesn't
restore the original situation.
Two items are created on the undo stack: sd::UndoGeoObject and
sdr::table::TableRowUndo. Let's say the table height is 8000 mm100 and the two
cell heights are 4000 and 4000. If the user resizes the first cell, so that its
height is 2000, then the new table height will be 6000. The problem is that
when undo is executed, first sd::UndoGeoObject resizes the table, distributing
the newly available 2000 between the existing rows, and then
sdr::table::TableRowUndo sets the row height of the first row: the height of
the second cell will be larger than expected. Fix the problem by not doing a
relayout during sd::UndoGeoObject, but doing a relayout after
sdr::table::TableRowUndo in this case.
This is done by:
1) Adding a new SdrDragStat::mbEndDragChangesLayout, so that
SdrTableObj::applySpecialDrag() can inform SdrDragObjOwn::EndSdrDrag() that
TableRowUndo will do the layout instead of UndoGeoObject. (This is done only in
case a row edge is dragged, as otherwise it's not guaranteed that a
TableRowUndo will follow the UndoGeoObject on the undo stack.)
2) Adding a new SdrUndoGeoObj::mbSkipChangeLayout, so that
SdrTableObj::applySpecialDrag() can let SdrUndoGeoObj::Undo() not do the
layout.
3) Adding a sdr::table::SdrTableObjImpl::mbSkipChangeLayout, so that
SdrUndoGeoObj::Undo() can let SdrTableObj::NbcSetLogicRect() not do the layout.
4) Marking the table model as modified in TableRowUndo::setData(), so it does
the layout at the end of the undo group.
Change-Id: I8adde3cdad5741e6fcb420e333ce336e18c77cf1
Reviewed-on: https://gerrit.libreoffice.org/24363
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I99e3d6137ec17e3fc782253c85e5fa4f1da4cec4
|
|
Change-Id: Ib8728408a81c655c36b46a8483970c38e9a40bc4
|
|
Change-Id: I71682f28c6a54d33da6b0c971f34d0a705ff04f5
|
|
Change-Id: I92158457b3ffaaf7c84c6f4c87708d766c8c9f61
Reviewed-on: https://gerrit.libreoffice.org/17117
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I6207b475127099872c6f3764331006688129b673
|
|
Change-Id: I1c36077cada47bacfb8436cf3fb659e47d02da60
|
|
This reverts commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba.
Conflicts:
cui/source/tabpages/transfrm.cxx
svx/source/svdraw/svdedtv1.cxx
svx/source/svdraw/svdibrow.cxx
sw/source/filter/ww1/w1filter.cxx
tools/source/generic/rational.cxx
Change-Id: I4849916f5f277a4afef0e279b0135c76b36b9d15
|
|
This reverts commit 582ef22d3e8e30ffd58f092d37ffda30bd07bd9e.
Conflicts:
svx/source/svdraw/svdedtv1.cxx
svx/source/svdraw/svdibrow.cxx
sw/source/filter/ww1/w1filter.cxx
Change-Id: I80abc7abdeddc267eaabc9f8ab49611bb3f8ae83
|
|
Fraction used BigInt internally for computations, rational does nothing
like that.
Change-Id: I3e9b25074f979bc291208f7c6362c3c40eb77ff5
|
|
* Added rational util functions used by Fraction class not
available in the boost::rational class.
* Replaced usage of Fraction by boost::rational<long>
* Removed code that relies on:
1. fraction.IsValid() -- rational only allow valid values, ie
denominator() != 0
2. rational.denominator() == 0 -- always false
3. rational.denominator() < 0 -- always false but implementation
detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
* Simplified code that relies on:
1. rational.denominator() != 0 -- always true
* BUGS EXIST because Fraction allows the creation of invalid values but
boost::rational throws the exception boost::bad_rational
Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
Reviewed-on: https://gerrit.libreoffice.org/11551
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: Ia7d3b7e319f2a568120add15ef05915a98fe6696
|
|
Probably a relic from the past, when people tried to avoid changing public
headers incompatibly to avoid causing recompilations for their
colleagues... We are long past such concerns. The talk about "extensions" in
the comment is most likely obsolete.
Change-Id: If90ca02685bf82ed529becb715b4c614287fdc57
|
|
Change-Id: Ic32faa81bfbb66a9d8632fb3db187e33c31188ed
|
|
Change-Id: I5335182ea16695c77c2855b34c98220aea2befa1
|
|
Change-Id: I2c280be12f36c1538e922286745aabc62482423d
|
|
Conflicts:
include/svx/unoapi.hxx
Change-Id: Icd0adbe98727a83fae3822863f7c6395f7474882
|
|
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
|