Age | Commit message (Collapse) | Author |
|
It passed "make check" on Linux.
If accepted, I have to update these files:
helpcontent2/helpers/help_hid.lst : SID_EXTRUSION_TOOGLE,10960,.uno:ExtrusionToggle
helpcontent2/helpers/longnames_commands.csv : SID_EXTRUSION_TOOGLE,.uno:ExtrusionToggle
helpcontent2/helpers/uno_hid.lst : SID_EXTRUSION_TOOGLE,10960,.uno:ExtrusionToggle
Change-Id: Ie315ef92b6aa8c03c6fc180f4e82d95f28975c2e
Reviewed-on: https://gerrit.libreoffice.org/60631
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
Change-Id: I474b5762e6a07982fddc0315a67181399ea4c30e
Reviewed-on: https://gerrit.libreoffice.org/64156
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I89a6244c01be811bfdfc443f687708ed6aec8a10
Reviewed-on: https://gerrit.libreoffice.org/64083
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ice2eb8c5994bf2ccb88972332ca4a1d3ed41752a
Reviewed-on: https://gerrit.libreoffice.org/63826
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I0a8867399699d1c5ce17c2e5dadf96510246f173
Reviewed-on: https://gerrit.libreoffice.org/64067
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This restores compatibility for API users who called getByName() on the
bitmap table and expected that the result can be set as a value for the
GraphicURL property.
The case is similar to the Writer images, which was handled in commit
587803ba46055d43b5b108be744fdde17aeabc7c (sw TextGraphicObject: handle
XBitmap for GraphicURL, 2018-08-08) already.
Change-Id: I3740a68989b306425d0d6c4d4e350ac163cb4170
Reviewed-on: https://gerrit.libreoffice.org/64069
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I1ac4c52ea51503373644bc58dcd4395c69f1a675
Reviewed-on: https://gerrit.libreoffice.org/64007
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ia33ac2dfa23bdc4e2990e6d028d1bae7fedfe4f5
Reviewed-on: https://gerrit.libreoffice.org/63853
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I2ae298f49ceba8059cd7236431db9a4d9a46b125
Reviewed-on: https://gerrit.libreoffice.org/63992
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I8d98aa7dd77fbd79611b8a4aba77e8c378fd1cae
Reviewed-on: https://gerrit.libreoffice.org/63981
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I80045f1d1ca189fc490dc88b3471d68782df6f1c
Reviewed-on: https://gerrit.libreoffice.org/63976
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If173f42302553b164267909a0a3156bb25a6d558
Reviewed-on: https://gerrit.libreoffice.org/63957
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iaf1c82ee454139553dbc9fd1b0cf38b9e7971fdd
Reviewed-on: https://gerrit.libreoffice.org/63931
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
By always setting all existing properties again the calls started
to differ between XMultiPropertySet::setPropertyValues and
XPropertySet::setPropertyValue. This patch reduces the changes in
the called methods. We can not avoid slight differences but at least
the risk is minimized that something is unexpectedly changed.
Change-Id: I5866db7be2829e6aba930f620f45db655df4e3f7
Reviewed-on: https://gerrit.libreoffice.org/63854
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Id6ee2eed8ee96b901be8172cccc9b50e01877e3b
Reviewed-on: https://gerrit.libreoffice.org/63361
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I12f868611860867df26bd29474aa19189c2b9a96
Reviewed-on: https://gerrit.libreoffice.org/63818
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I312cef93a0cef48207a3b7f5165dd48d702de3c6
Reviewed-on: https://gerrit.libreoffice.org/63810
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I636fcc8ba1012d774d98f6a880bf29eb4b233128
Reviewed-on: https://gerrit.libreoffice.org/63783
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic5fb01ac088cc777534e7986001defb61bc6ee60
Reviewed-on: https://gerrit.libreoffice.org/63733
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@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: I4776e416071e94468868847420c17d752d39c081
Reviewed-on: https://gerrit.libreoffice.org/63695
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
regression from
commit eec9f6c8b928de38dd9e683f46bfab00f3243048
Date: Mon Jun 4 15:01:43 2018 +0200
loplugin:useuniqueptr in FmEntryDataList
and rename the method to make the it's operation clearer
Change-Id: Ife366f02c3d8907c397345d825ef7d1721d8930c
Reviewed-on: https://gerrit.libreoffice.org/63694
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Iabe571aa8f00492902c499094bea8365a3e17fca
Reviewed-on: https://gerrit.libreoffice.org/63623
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Use range-based loop or replace with STL functions
Change-Id: I7a24407f9e8f38b4903a643210ca4511372d91f2
Reviewed-on: https://gerrit.libreoffice.org/63687
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I301a27edf47588d11080b91507b79be177a6f99c
Reviewed-on: https://gerrit.libreoffice.org/63608
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I25ce389bd46beff2dd9b0507581736f2f9511383
Reviewed-on: https://gerrit.libreoffice.org/63574
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Use range-based loop or replace with STL functions
Change-Id: Icd11c895b7eca5ad438a8b0e29a762bb22d43b1b
Reviewed-on: https://gerrit.libreoffice.org/63531
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I99bd67f45796eb85635543a5e4563bb7477cf63e
Reviewed-on: https://gerrit.libreoffice.org/63547
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
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>
|
|
Change-Id: I0c966f517e337caa340526b48fa62b9910ce0a3e
Reviewed-on: https://gerrit.libreoffice.org/63504
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Use range-based loop or replace with STL functions
Change-Id: I2ec3e58cc46c9286ef863c732912ca7a729bab62
Reviewed-on: https://gerrit.libreoffice.org/63522
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I60bb778a88dd5619efd4858eb74d56d28616c777
Reviewed-on: https://gerrit.libreoffice.org/63520
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I9335fa2ab94f69853b45f070499d7e18aac458c3
Reviewed-on: https://gerrit.libreoffice.org/63499
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Next commit will use this for all color status updates,
not just for borders.
Change-Id: Ibd95d755a33bfc079fcbffabfd8896b6b777609f
Reviewed-on: https://gerrit.libreoffice.org/63498
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Regression of 9125a4f3f63a7f49fd307908c181e999120063e0
("Use FeatureStateEvent directly for status updates").
Change-Id: I57856c5707fffcf84f95afa9ef80a394b550c56f
Reviewed-on: https://gerrit.libreoffice.org/63497
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
u8 literals incompatibly change their type (as implemented by recent Clang
trunk)
Change-Id: Ia4f7b91f5d86656a056303d2754981ab2093a739
Reviewed-on: https://gerrit.libreoffice.org/63494
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I954c12d9e1c493be6ac8c7b15076077b5bff5b74
Reviewed-on: https://gerrit.libreoffice.org/62811
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
.. as MS PowerPoint"
This reverts commit 1da3a3cb74a415a76fa547ef0c8f61780e260e7f.
It was a bad solution for the problem.
Change-Id: I6f6fecb7c74a884fbfb04c6e7204eb8bf347a272
Reviewed-on: https://gerrit.libreoffice.org/63473
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
The old implementation has used 4 segments and a questionable control
point distance. The patch changes this to use the common
implementation in basegfx. The method in basegfx is extended to allow
to set the start quarter, so that the custom shape circle can get the
same start quarter as it has before. The method descriptions in
basegfx are adapted to the current implementation.
Change-Id: I3a40f81827227ee0037d336bdf3c1ec6fdd64b4b
Reviewed-on: https://gerrit.libreoffice.org/63366
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I00333677db711761510a35dfae5ce70d61fb9491
Reviewed-on: https://gerrit.libreoffice.org/63397
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I94df3aa40fa79877ccebf1ed8709bd7cc47748d9
Reviewed-on: https://gerrit.libreoffice.org/63398
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic3f4388ea2ca92d9e97d4a9e066eea07c7de79e5
Reviewed-on: https://gerrit.libreoffice.org/63363
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: Ide75232858599c275e023c2300201090acd22307
Reviewed-on: https://gerrit.libreoffice.org/63237
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I94d21bb868c54638b843c6abaab370a05ec3471e
Reviewed-on: https://gerrit.libreoffice.org/63317
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibb94b2b16afbcca84dd55ae51fde6fd27afede3a
Reviewed-on: https://gerrit.libreoffice.org/63297
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I3e27d8444c5a152ee39b9e2cc12b9df707f092b8
Reviewed-on: https://gerrit.libreoffice.org/63281
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: Ib29701a44ab42806951a5b2ad6b63aabda4abfba
Reviewed-on: https://gerrit.libreoffice.org/63262
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|