summaryrefslogtreecommitdiff
path: root/include/svx/svddrag.hxx
AgeCommit message (Collapse)Author
2017-09-08clean up SdrDragStatNoel Grandin
- 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>
2017-09-08svx: Make SdrDragStatUserData's dtor pure virtualTakeshi Abe
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>
2017-03-31tdf#82580 tools: rename Rectangle to tools::RectangleMiklos Vajna
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>
2016-04-25tdf#99452 svx: fix undo of table row edge dragMiklos Vajna
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>
2016-03-01loplugin:unuseddefaultparam in svx (part2)Noel Grandin
Change-Id: I99e3d6137ec17e3fc782253c85e5fa4f1da4cec4
2016-01-11svx: SdrDragStat::GetPointAnz() -> GetPointCount()Miklos Vajna
Change-Id: Ib8728408a81c655c36b46a8483970c38e9a40bc4
2015-11-10loplugin:nullptr (automatic rewrite)Stephan Bergmann
Change-Id: I71682f28c6a54d33da6b0c971f34d0a705ff04f5
2015-07-16loplugin:unusedmethods svxNoel Grandin
Change-Id: I92158457b3ffaaf7c84c6f4c87708d766c8c9f61 Reviewed-on: https://gerrit.libreoffice.org/17117 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2015-04-23loplugin:staticmethodsNoel Grandin
Change-Id: I6207b475127099872c6f3764331006688129b673
2014-12-07Forward-declare MarkedUndoAction.Kohei Yoshida
Change-Id: I1c36077cada47bacfb8436cf3fb659e47d02da60
2014-10-23Fraction: Revert "fdo#81356: convert Fraction to boost::rational<long> - wip"Jan Holesovsky
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
2014-10-23Fraction: Revert "fdo#84854 it seems long is not enough on 32 bit"Jan Holesovsky
This reverts commit 582ef22d3e8e30ffd58f092d37ffda30bd07bd9e. Conflicts: svx/source/svdraw/svdedtv1.cxx svx/source/svdraw/svdibrow.cxx sw/source/filter/ww1/w1filter.cxx Change-Id: I80abc7abdeddc267eaabc9f8ab49611bb3f8ae83
2014-10-16fdo#84854 it seems long is not enough on 32 bitDavid Tardon
Fraction used BigInt internally for computations, rational does nothing like that. Change-Id: I3e9b25074f979bc291208f7c6362c3c40eb77ff5
2014-10-09fdo#81356: convert Fraction to boost::rational<long> - wipJuan Picca
* 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>
2014-03-19Remove unused fieldsTor Lillqvist
Change-Id: Ia7d3b7e319f2a568120add15ef05915a98fe6696
2014-03-19Drop unused "reserve" fieldsTor Lillqvist
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
2014-01-28bool improvementsStephan Bergmann
Change-Id: Ic32faa81bfbb66a9d8632fb3db187e33c31188ed
2013-11-09fdo#65108 inter-module includes <> include/svxNorbert Thiebaud
Change-Id: I5335182ea16695c77c2855b34c98220aea2befa1
2013-10-23fixincludeguards.sh: include/svxThomas Arnhold
Change-Id: I2c280be12f36c1538e922286745aabc62482423d
2013-08-06Translate German comments, fix some WSPhilipp Weissenbacher
Conflicts: include/svx/unoapi.hxx Change-Id: Icd0adbe98727a83fae3822863f7c6395f7474882
2013-04-23execute move of global headersBjoern Michaelsen
see https://gerrit.libreoffice.org/#/c/3367/ and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a