Age | Commit message (Collapse) | Author |
|
in bar charts, instead of leaving an empty place
at the zero data point.
Note: This is an initial workaround for the
interoperability problem. We need a new LibreOffice
chart option or setting to support both ways of data
visualization.
Change-Id: I5c04a265ffe1392f659097054ab11a23374e88b7
Reviewed-on: https://gerrit.libreoffice.org/65269
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I8ee0ccbbc596a4edd0da50e8bbcf573afc9bb53b
Reviewed-on: https://gerrit.libreoffice.org/65665
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
Change-Id: Ia44cbd763d06948fcf7f7633d0ee0b1aaeeda84a
Reviewed-on: https://gerrit.libreoffice.org/65664
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
Change-Id: Ibb25b79c1ec394eb04d40c5419e5cdffc17829f0
Reviewed-on: https://gerrit.libreoffice.org/65651
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
See thread starting at
https://lists.freedesktop.org/archives/libreoffice/2018-December/081589.html
Regression from commit 7263d223ddf42cc39d10a501159c7b04ef48df96.
That change has made unit tests DPI-aware; and then some tests started
failing on systems with resolutions other than 96 DPI.
It has been suggested that the proper fix would be to do for Windows
what commit ada20402efa81273e03e46cbedc21f25b9daeeac did for macOS.
Another approach would be to fix all the tests to be DPI-aware.
I cannot do the first mentioned fix; so I have fixed testFDO74215 test
in sw_ooxmlexport4; and added DPI checks to the other failing tests in
chart2_xshape and sc_subsequent_filters_test to skip testing when using
non-default DPI. This is not ideal, of course, and conditionally skipped
tests need to be re-enabled unconditionally once a proper fix arrives.
Change-Id: I5c92cfe93ae65f53a8a180fcaec49231df377b8a
Reviewed-on: https://gerrit.libreoffice.org/65595
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Idee9984b91c992e4a782332f031b546774fc1568
Reviewed-on: https://gerrit.libreoffice.org/65387
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ibe5c344a45b96cd92591ce721c24009a646313d5
|
|
The MS Office UI allows values only in range of [-90,90].
Because of this, we should reflect the angle if the Textrotation
is between 90 and 270 degree. Also we have to recalculated the
the Textrotation between 270 and 360 degree, because the OOXML
counts clockwise.
Change-Id: I2fbd53d93ab2e8ea4e26840fd056de20b337daa3
Reviewed-on: https://gerrit.libreoffice.org/65194
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With this patch the text break is allowed for column chart
X axis if the text is rotated with 0, 90 or 270 degree.
(The MS Office only allowed the text break of X axis
text when the rotation is 0, 90, or 270 degree.)
Change-Id: I0914f6208d5a5c0c864dc0227032ef858b044445
Reviewed-on: https://gerrit.libreoffice.org/65165
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Modify the chart data label rendering in case of Column/Bar chart
only if the datapoint value is 0. This patch fix in case of NEAR_ORIGIN
and CENTER DataLabelPlacement.
Change-Id: Ia9857b5ac0cc5feaf2e1fd08e98c9f8534e5af04
Reviewed-on: https://gerrit.libreoffice.org/65082
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Cleaned directories are:
accessibility, drawinglayer, itemsetwrapper, main, sidebar
Change-Id: I612eae9dec636d57a3a3a00102d74b964da5b54c
Reviewed-on: https://gerrit.libreoffice.org/64307
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ib380d6cbb1d858877cb14263cdc6beff6f0b97af
Reviewed-on: https://gerrit.libreoffice.org/65068
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
fixing a memory leak in chart2
Change-Id: Idddb6a46b1bde5c1a11148c03bbdaac20ac78e13
Reviewed-on: https://gerrit.libreoffice.org/65031
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2914579b935a7e7556264222293d043618555b91
Reviewed-on: https://gerrit.libreoffice.org/64997
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ie87d27dd2c385a63349e0b322fd067ba03d2d152
Reviewed-on: https://gerrit.libreoffice.org/64479
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I8dc57b73218277c4bc9df693578dcb25f5ebbe0a
Reviewed-on: https://gerrit.libreoffice.org/64855
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
which benefits LOOL since we can delay creating the image until
we know the dpi setting of the display we are going to write to.
Achieved by
perl -pi -w -e "s/\bImage\s*\(\s*BitmapEx\s*\((\w+)\s*\)\s*\)/Image\(\1\)/g" $( git grep -lw "BitmapEx" )
followed by
git grep -nP '\bImage\s*\(\s*BitmapEx\s*\('
followed by commenting out the BitmapEx(OUString) constructor and seeing
what needed adjusting.
Change-Id: I3224e11937d720fa484b0d659d25673a9e809267
Reviewed-on: https://gerrit.libreoffice.org/64760
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
...after 7ffdd830d5fb52f2ca25aa80277d22ea6d89970b
"HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true now"
Change-Id: I54e5ff4e036a6bb3e5774d1c0524158aae18e937
Reviewed-on: https://gerrit.libreoffice.org/64800
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Respecting the axis direction in case of
normal/stacked/percent stacked Bar chart and
the legend names will be in the right order.
Change-Id: If782393a33e48dae32f919d137e1d1148a85b0b0
Reviewed-on: https://gerrit.libreoffice.org/64632
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I4a9025e317dbd93fb45e676f266c555c72f4d18b
Reviewed-on: https://gerrit.libreoffice.org/64614
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
No UI and no ODF or OOXML support yet.
Change-Id: I839c195e9c42f074838ff6592331f7cdd13b6cd2
Reviewed-on: https://gerrit.libreoffice.org/64583
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I9fb8366634b31230b732dd38a98f800075529714
Reviewed-on: https://gerrit.libreoffice.org/64510
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
if we want to hide the text direction widget, we should hide
the rest of the elements too. For now show them all.
Change-Id: Icb2ef69c50eb2335170dda9bfcfcb947ce4d6d19
Reviewed-on: https://gerrit.libreoffice.org/64551
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I98cdda7e384dce35f02d20d5b98b61168d34f786
Reviewed-on: https://gerrit.libreoffice.org/64552
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
The failing call stack:
ucrtbased.dll!issue_debug_notification(const wchar_t * const message)
Line 28
at minkernel\crts\ucrt\src\appcrt\internal\report_runtime_error.cpp(28)
ucrtbased.dll!__acrt_report_runtime_error(const wchar_t * message) Line 154
at minkernel\crts\ucrt\src\appcrt\internal\report_runtime_error.cpp(154)
ucrtbased.dll!abort() Line 61
at minkernel\crts\ucrt\src\appcrt\startup\abort.cpp(61)
ucrtbased.dll!common_assert_to_stderr<wchar_t>(const wchar_t * const
expression, const wchar_t * const file_name, const unsigned int
line_number) Line 187
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(187)
ucrtbased.dll!common_assert<wchar_t>(const wchar_t * const expression,
const wchar_t * const file_name, const unsigned int line_number, void *
const return_address) Line 420
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(420)
ucrtbased.dll!_wassert(const wchar_t * expression, const wchar_t *
file_name, unsigned int line_number) Line 444
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(444)
vcllo.dll!ImplDbgTestSolarMutex() Line 46
at c:\lo\src\core\vcl\source\app\dbggui.cxx(46)
tllo.dll!DbgTestSolarMutex() Line 78
at c:\lo\src\core\tools\source\debug\debug.cxx(78)
vcllo.dll!OpenGLSalBitmap::Create(const Size & rSize, unsigned short
nBits, const BitmapPalette & rBitmapPalette) Line 164
at c:\lo\src\core\vcl\opengl\salbmp.cxx(164)
vcllo.dll!Bitmap::Bitmap(const Size & rSizePixel, unsigned short
nBitCount, const BitmapPalette * pPal) Line 108
at c:\lo\src\core\vcl\source\bitmap\bitmap.cxx(108)
vcllo.dll!o3tl::make_unique<Bitmap,Size &,unsigned short &>(Size &
<args_0>, unsigned short & <args_1>) Line 29
at c:\lo\src\core\include\o3tl\make_unique.hxx(29)
vcllo.dll!vcl::PNGReaderImpl::ImplReadHeader(const Size &
rPreviewSizeHint) Line 665
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(665)
vcllo.dll!vcl::PNGReaderImpl::GetBitmapEx(const Size & rPreviewSizeHint)
Line 342
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(342)
vcllo.dll!vcl::PNGReader::Read(const Size & i_rPreviewSizeHint) Line 1732
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(1732)
vcllo.dll!GraphicFilter::ImportGraphic(Graphic & rGraphic, const
rtl::OUString & rPath, SvStream & rIStream, unsigned short nFormat,
unsigned short * pDeterminedFormat, GraphicFilterImportFlags
nImportFlags,
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> *
pFilterData, const WmfExternal * pExtHeader) Line 1813
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(1813)
vcllo.dll!GraphicFilter::ImportGraphic(Graphic & rGraphic, const
rtl::OUString & rPath, SvStream & rIStream, unsigned short nFormat,
unsigned short * pDeterminedFormat, GraphicFilterImportFlags
nImportFlags, const WmfExternal * pExtHeader) Line 1281
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(1281)
vcllo.dll!GraphicFilter::FilterCallback(ConvertData & rData) Line 2509
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(2509)
vcllo.dll!GraphicFilter::LinkStubFilterCallback(void * instance,
ConvertData & data) Line 2481
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(2481)
sofficeapp.dll!Link<ConvertData &,bool>::Call(ConvertData & data) Line 84
at c:\lo\src\core\include\tools\link.hxx(84)
sofficeapp.dll!desktop::Desktop::ImplInitFilterHdl(desktop::Desktop *
__formal, ConvertData & rData) Line 1752
at c:\lo\src\core\desktop\source\app\app.cxx(1752)
sofficeapp.dll!desktop::Desktop::LinkStubImplInitFilterHdl(void *
instance, ConvertData & data) Line 1749
at c:\lo\src\core\desktop\source\app\app.cxx(1749)
vcllo.dll!Link<ConvertData &,bool>::Call(ConvertData & data) Line 84
at c:\lo\src\core\include\tools\link.hxx(84)
vcllo.dll!GraphicConverter::Import(SvStream & rIStm, Graphic & rGraphic,
ConvertDataFormat nFormat) Line 44
at c:\lo\src\core\vcl\source\gdi\cvtgrf.cxx(44)
chartcorelo.dll!chart::ChartModel::impl_loadGraphics(const
com::sun::star::uno::Reference<com::sun::star::embed::XStorage> &
xStorage) Line 621
at c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(621)
chartcorelo.dll!chart::ChartModel::impl_load(const
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> &
rMediaDescriptor, const
com::sun::star::uno::Reference<com::sun::star::embed::XStorage> &
xStorage) Line 576
at c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(576)
chartcorelo.dll!chart::ChartModel::load(const
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> &
rMediaDescriptor) Line 543
at c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(543)
chartcontrollerlo.dll!chart::ChartFrameLoader::load(const
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> &
rMediaDescriptor, const
com::sun::star::uno::Reference<com::sun::star::frame::XFrame> & xFrame)
Line 170
at c:\lo\src\core\chart2\source\controller\main\chartframeloader.cxx(170)
fwklo.dll!framework::LoadEnv::impl_loadContent() Line 1149
at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(1149)
fwklo.dll!framework::LoadEnv::startLoading() Line 383
at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(383)
fwklo.dll!framework::LoadEnv::loadComponentFromURL(const
com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader>
& xLoader, const
com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> &
xContext, const rtl::OUString & sURL, const rtl::OUString & sTarget,
long nSearchFlags, const
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> &
lArgs) Line 170
at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(170)
fwklo.dll!framework::Desktop::loadComponentFromURL(const rtl::OUString &
sURL, const rtl::OUString & sTargetFrameName, long nSearchFlags, const
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> &
lArguments) Line 619
at c:\lo\src\core\framework\source\services\desktop.cxx(619)
mscx_uno.dll!`anonymous
namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy *
pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot,
_typelib_TypeDescriptionReference * pReturnTypeRef, long nParams,
_typelib_MethodParameter * pParams, void * pUnoReturn, void * *
pUnoArgs, _uno_Any * * ppUnoExc) Line 214
at c:\lo\src\core\bridges\source\cpp_uno\msvc_win32_x86-64\uno2cpp.cxx(214)
mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const
_typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs,
_uno_Any * * ppException) Line 429
at c:\lo\src\core\bridges\source\cpp_uno\msvc_win32_x86-64\uno2cpp.cxx(429)
binaryurplo.dll!binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny
* returnValue,
std::vector<binaryurp::BinaryAny,std::allocator<binaryurp::BinaryAny> >
* outArguments) Line 239
at c:\lo\src\core\binaryurp\source\incomingrequest.cxx(239)
binaryurplo.dll!binaryurp::IncomingRequest::execute() Line 79
at c:\lo\src\core\binaryurp\source\incomingrequest.cxx(79)
binaryurplo.dll!request(void * pThreadSpecificData) Line 83
at c:\lo\src\core\binaryurp\source\reader.cxx(83)
cppu3.dll!cppu_threadpool::JobQueue::enter(__int64 nDisposeId, bool
bReturnWhenNoJob) Line 108
at c:\lo\src\core\cppu\source\threadpool\jobqueue.cxx(108)
cppu3.dll!cppu_threadpool::ORequestThread::run() Line 170
at c:\lo\src\core\cppu\source\threadpool\thread.cxx(170)
cppu3.dll!threadFunc(void * param) Line 186
at c:\lo\src\core\include\osl\thread.hxx(186)
sal3.dll!oslWorkerWrapperFunction(void * pData) Line 58
at c:\lo\src\core\sal\osl\w32\thread.cxx(58)
ucrtbased.dll!invoke_thread_procedure(unsigned int(*)(void *) procedure,
void * const context) Line 92
at minkernel\crts\ucrt\src\appcrt\startup\thread.cpp(92)
ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void
* const parameter) Line 115
at minkernel\crts\ucrt\src\appcrt\startup\thread.cpp(115)
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
Change-Id: Ia22ebb2361192c30549b0f01ac0b709295e1dbdc
Reviewed-on: https://gerrit.libreoffice.org/63700
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Each of the Column and Line Chart creates it's own x and y Axes.
So now the LineChart Exporter Method uses the same Axes as the BarChart.
Thanks for the help:
- Balazs Varga
- Adam Kovacs
Change-Id: Ie763cf831c2ce63ef204d1fdcbff634e7ca8fad5
Reviewed-on: https://gerrit.libreoffice.org/64146
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: If990d5f8cb2eca7fa6ffd21f2f8db17ba4385df6
Reviewed-on: https://gerrit.libreoffice.org/64319
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Many places in chart2 use NaN to mean no available value. Not propagating
NaN through the helper disables all this functionality.
Change-Id: I37f966007b5b7cc16778c5c6903710fbd144631b
Reviewed-on: https://gerrit.libreoffice.org/64266
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
The NaN value forces the scaling of the axis to be based on years
and introduces gaps in the rendering.
Change-Id: I78219be289d76edb53b5672209e1c031ab62def9
Reviewed-on: https://gerrit.libreoffice.org/64267
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: If1b2e04872eb0dd6725802c1709a9085f4cd8c91
Reviewed-on: https://gerrit.libreoffice.org/64141
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I5464504ae9ee411221c2cb2ff6f27b7b7e131326
Reviewed-on: https://gerrit.libreoffice.org/64201
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I4d3eb8aa354043d3ff57b4996db7b28ad25e0262
Reviewed-on: https://gerrit.libreoffice.org/64072
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I41a053f63db6bced24dd6586e2c347d286339c29
Reviewed-on: https://gerrit.libreoffice.org/64071
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This change solves the non-linear World-To-View trans-
formation that calc uses due to it's screen rendering
as good as currently possible (AFAIK).
Calcv view is layouted on pixel base (due to better
homogen distances and full pixel lines between cells),
but this leads to having a non-linear transformation
between discrete units (pixels, view) and model coordinates
(World). In principle, each cell has it's own (so called)
ViewTransformation -> the position on screen depends on
the mappings of all cells top/left from it. This is
obvioulsly non-linear and can sometimes be seen by
producing 'offset' errors when many cells (small and thin)
are shown in low zoom stages.
No better solution for this comes to mind easily. The
extremes are - on the one hand AntiAliasing the whole
calc edit view and accept 'unsharp/AAed' lines - on the
other hand what we have now.
Maybe a future solution could find a mapping that gets
close to linear mapping for the full view. On the long
run this state is hard to keep correct. Even with this
extended solution the mapping of SdrObjects spawning
mutiple cells is assumed 'linear' in that area - which
is in reality currently not the case (!)
Note: This is only true for the screen visualization,
print and/or PDF export do not do that pixel-based
layouting.
Note2: This mechanism is general in DrawingLayer (look
for '.*GridOffset.*'. If it is deactivated by providing
no offsets, the result is the unchanged, linear mapping.
First step: Add interfaces to get a possible GridOffset
at ViewObjectContact. There it belongs, we have a view-
dependent offset per object and view. Add mechanisms to
create on-demand and reach back to the view (aka calc's
derivation of it).
Second step: Implement the on-demand creation, adapt to
use it in ViewObjectContact::getPrimitive2DSequence, add
stuff to reset on zoom change, disable temporarily old
mechanism -> paint already works. Need to adapt the
places from old mechanism where the GridOffset was used,
but no longer the geometry creations.
Third step: Isolated and disabled old mechanism (by
already removing SetGridOffset). Marked all places that
possibly need change with '//Z' tag. Main work now will
be to adapt in the SdrView implementations in svx to know
about having a SdrObject-dependent ViewTransformation
at all (currently not known, was hard-coded at some places
from the old code, ViewTransformation set as MapMode at
a target OutputDevice, not member at SdrView at all...).
Fourth step: Adapt the Handles and OverlayObjects to
use an evtl. existing GridOffset. The mechanism is that
the SdrHdl(s) can be seen as 'Model-Objects', these get
converted to OverlayObjects in the ::CreateB2dIAObject()
implementations, for all SdrMarkView and SdrPageView,
so this is the place where the ObjectContact is known
(the SdrPageWindow *is* a ObjectContact) and the view-
dependent GridOffset can be calculated per SdrObject.
I modified OverlayObject to be able to work with a
set Offset that embeds the created visualization using
this additionally.
Handles get now correctly set and have a working HitTest
(due to that already using the primitives). Some inter-
action stuff already working, some will need more
adaption. We simply have no concept for this stuff...
Refactored to not get dependencies to SdrObject in
ObjectContact.
Fifth Step: Make HitTest work by adding the View-And-
Object dependent GridOffset in the View when HitTest
is triggered. This is in SdrMarkView::CheckSingleSdrObjectHit
where pObj->GetCurrentBoundRect() is used that gets the
view-independent form. To make HitTest work, add a possible
GridOffset.
Since this will be necessary more often in SdrView hierarchy,
added a tooling method (getPossibleGridOffsetForSdrObject)
at that level after checking that at that level will be
reachable at all potential spots.
Inside that method the correct ObjectContact will be identified
and the object-specific offset requested there.
Sixth Step: Adaptions and started some cleanups. Still some
adaptions needed:
- After creation of new object, need to relocate from
used GridOffset setting to WorldCoordinates
- Interactions, e.g. start with dragging handles or full
object/points
Seventh Step: React on EndCreateObj. Here, the created
SdrObject is in model coordinates and needs to be adapted
to evtl. GridOffset. This is 'tricky' due to calculating
the possible offset based on new coordinates 'close'
to the target position, but may be in the wrong cell.
Nonetheless this is the best we can do here.
Last (hopefully) missing are now all interaction
viszualizations. They already work and are applied
correctly, but wrong visualized.
Have taken the time to unify adding OverlayObjects for
selection visualization to OverlayManager, see
handleNewOverlayObject. This does all needed when adding
OverlayObjects in one place where the GridOffset can
also be handled. It makles things more safe - not possible
to forget one of the three steps for others.
Eighth Step: Do the same unification for creating the
OverlayGeometry, also rename methods to make usage more
clear. We now have
SdrHdl::insertNewlyCreatedOverlayObjectForSdrHdl
SdrDragMethod::insertNewlyCreatedOverlayObjectForSdrDragMethod
which can do the needed GridOffset changes centralized.
Needed to get a ObjectContact for this at SdrDragMethod,
so adapted ::CreateOverlayGeometry implementations
accordingly. Missing is now the implementation in
insertNewlyCreatedOverlayObjectForSdrDragMethod to add
the GridOffset - if used. This has no SdrObject at this
time, so we will need a fallback to do the same using a
Range (Rectangle). The stuff doing this for SdrObject
already has a fallback and is based on using the Rectangle
from the SdrObject anyways, so this will be possible.
Ninth Step: Cleanup of old stuff (no more //Z), adapted
some usages of OverlayObject creations to use
getViewIndependentPrimitive2DContainer instead of the
view dependent parts so that offset applied to
drag-overlays is correct and not already added. Adapted
insertNewlyCreatedOverlayObjectForSdrDragMethod to use
calculateGridOffsetForB2DRange. Use now that instead of
SdrObject-based approach in calc - is more generic.
Getting closer, but still not complete - there is an
error with dragging the grepped handle somehow - the
offset for drag is somehow wrong.
Tenth Step: Corrected that offset error. Of course at
interaction start and progress (move) the coordinates
are in GrifOffset coordinates and need to be corrected
to Model coordinates. Done that at ::BegDragObj and
::MovDragObj, works well.
Of course there are exceptions for the crop-handles, so
needed to add setting the correct parameters at SdrHdl
when these got created, then all works as expected.
The strategy is to *not* change the model data itself
in any way, instead do all changes/adaptions in the
view-only code. This has minimal impact and is needed
due to having a 1:n relationship between model and
views anyways.
There are two directions: All visualizations are adapted
to take the GridOffset into account (SdrObjects, overlay,
handles, InteractionObjects, ...). In the other direction
input like MousePosition is in principle in calc EditView
in 'GridOffset'-coordinates and needs to be mapped back
before usage.
Change-Id: I2ecdd409def96a7248a26a65a22e59eb962880a0
Reviewed-on: https://gerrit.libreoffice.org/64057
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
Change-Id: I1048d86bf11b4fdd4a5c90f6e98276893b8ffbf4
Reviewed-on: https://gerrit.libreoffice.org/64078
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I339e1d956ed6f3017453237f0b8ad540d7d4ad20
Reviewed-on: https://gerrit.libreoffice.org/64068
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I99b7c2ec397829c2f7ceb7ec18ae24195b9781e2
Reviewed-on: https://gerrit.libreoffice.org/61800
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9ee3318c79d3b59f272a2a5f89c38b26afa05974
Reviewed-on: https://gerrit.libreoffice.org/63775
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I4a45110e69fc76ff5b12e014586a0684c3737dfe
Reviewed-on: https://gerrit.libreoffice.org/64000
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
performLabelBestFitInnerPlacement fails.
Change-Id: Ic84e8b42e02da2023b22a9406c44d462170c5305
Reviewed-on: https://gerrit.libreoffice.org/64015
Tested-by: Jenkins
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
|
|
simplify the initialisaion and make them thread-safe i.e. initialise
them using the runtime's local static locking.
Thanks to mike kaganski for pointing out the nice lambda approach that
makes this feasible.
Change-Id: I76391189a6d0a3d7eed2d0d88d28dfa6541eaff7
Reviewed-on: https://gerrit.libreoffice.org/63645
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1346478fb8bbb1720ecc6cf7c88407be3b126bf1
Reviewed-on: https://gerrit.libreoffice.org/63867
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I81d3e03a0ccea3851b01d39b2e972b13ef4f6359
Reviewed-on: https://gerrit.libreoffice.org/63869
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8001d8c6c950e74df0f909e1cebfb3d1e52a84a4
Reviewed-on: https://gerrit.libreoffice.org/63846
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...which <https://ci.libreoffice.org/job/lo_tb_random_config_linux/>
occasionally stumbles across; plus some related loplugin:staticmethods fixes
Change-Id: If6998c302cfbabfcad626d9c68d94d3368548a41
Reviewed-on: https://gerrit.libreoffice.org/63808
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and put back original SvTreeListBox a11y factory use
Change-Id: I4ad8ce29d8fed6ec5d44e9a1d641919a89226b79
Reviewed-on: https://gerrit.libreoffice.org/63501
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
check for calls to constructors, and extend the list of types we check
for unnecessary temporary creation
Change-Id: Ia2c1f202b41ed6866779fff5343c821128033eec
Reviewed-on: https://gerrit.libreoffice.org/63472
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I00868938738e30afc2b212c01ed36d5223401ceb
Reviewed-on: https://gerrit.libreoffice.org/63683
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
a) use GtkTreeStores for GtkTreeViews
b) ironically can't store GtkTreeStore contents in .ui apparently
c) set show_expanders for all non-trees and unconverted cases
d) on-demand subtrees
Change-Id: I3c1036a222daba2c129b1a22ffeb3fe35005ae31
Reviewed-on: https://gerrit.libreoffice.org/63336
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: If18c80fc64e55d797953e24e40e5d5e62bd9c625
Reviewed-on: https://gerrit.libreoffice.org/63453
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|