Age | Commit message (Collapse) | Author |
|
Change-Id: Icc20ae913052a7ae96c0722a458d75bbb5eef1cd
Reviewed-on: https://gerrit.libreoffice.org/64862
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: Ie87d27dd2c385a63349e0b322fd067ba03d2d152
Reviewed-on: https://gerrit.libreoffice.org/64479
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Use range-based loop or replace with STL functions
Change-Id: I13c9982ad1e1aadbc6189068c5a5e29dfb171e97
Reviewed-on: https://gerrit.libreoffice.org/64811
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9a85e6ee0b1d2df36999cbd968d84bf60e62f0a9
Reviewed-on: https://gerrit.libreoffice.org/64758
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
Change-Id: I37b1397dc8406759ac138921aa9fa6c528f95bc7
Reviewed-on: https://gerrit.libreoffice.org/64827
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
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>
|
|
...between adjacent switch labels without any intervening statements
Change-Id: Ieb8a0d9f71ea4382b5f7d005cdf7111d06aeb5d0
Reviewed-on: https://gerrit.libreoffice.org/64789
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...but for safety, leave the configure.ac check in for some longer.
Also remove now-redundant SAL_INLINE_VARIABLE again (which was
LIBO_INTERNAL_ONLY).
Change-Id: Id049e0cb84b4f97f5859f1b16b867b39b448dec0
Reviewed-on: https://gerrit.libreoffice.org/64772
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I118039f4e47818a43da9302ce3550ea800522675
Reviewed-on: https://gerrit.libreoffice.org/64765
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I134f86dc0c49ddf26e7a3cfe790c49ab200de9e9
|
|
Change-Id: Ib30be297d87fa40c03974e0a97f243812dc488f3
|
|
Change-Id: I182aa395ce0f4e4185c9c85a866dec89499842f9
|
|
Change-Id: Iceb0e744f8e994ece91cd8f50fefaed631aa8396
Reviewed-on: https://gerrit.libreoffice.org/64126
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which is dead as far back as its introduction in
commit fd069bee7e57ad529c3c0974559fd2d84ec3151a
Date: Mon Sep 18 16:07:07 2000 +0000
initial import
Change-Id: Ieff923732005aaa48cfae4918e8094020e6a540b
Reviewed-on: https://gerrit.libreoffice.org/64715
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic238bb5291539fd1b7e98cb4afc9b25f37e7d528
Reviewed-on: https://gerrit.libreoffice.org/64710
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Similar to 6d9a2557a0f0366fff169f3c3581414b3cec80bd
Change-Id: Ifecc3f86a3da8fdd4b0535cb67c6315e0d418f5a
Reviewed-on: https://gerrit.libreoffice.org/64645
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Change-Id: Iec7660563e96f821f72caae5047820f425ca69fb
Reviewed-on: https://gerrit.libreoffice.org/64565
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9fb8366634b31230b732dd38a98f800075529714
Reviewed-on: https://gerrit.libreoffice.org/64510
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I10f801de49cdf3d5fb37657ee88842223bf50570
Reviewed-on: https://gerrit.libreoffice.org/64385
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: Ibac6bddcd683792a9a520e1bd9269b130321e181
Reviewed-on: https://gerrit.libreoffice.org/64384
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: I594e7beb3fb320b70ffe4dd98fee46c833f443dc
Reviewed-on: https://gerrit.libreoffice.org/64453
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: I5a4951e983078ab6b6cbf0e96b00a20584b85e20
Reviewed-on: https://gerrit.libreoffice.org/64398
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Id7af9a6eaefc8b49a790eb299620c4fa97067a11
Reviewed-on: https://gerrit.libreoffice.org/64429
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I790f957c9ebc6d87a94a355c30215245aaabeb30
Reviewed-on: https://gerrit.libreoffice.org/64345
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia9c496ec93bedb13764969bf21c3f21d84caacef
Reviewed-on: https://gerrit.libreoffice.org/64413
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... after commit cf7b97d1328ec2f2c8254abb9ce67d63d9c54c80
Change-Id: If46265f49a85d92254fedb719d76ff7319c092cc
Reviewed-on: https://gerrit.libreoffice.org/64396
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I735ca7d70045b278d6b885cc2de35bf76885b487
Reviewed-on: https://gerrit.libreoffice.org/64258
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
The constraints explicitly said that the width should be larger than the
height, but it was the opposite as constraints were not parsed.
Unfortunately it would be too brave for globally start handling all
constraints which lack a forName, so add a switch to opt in for this,
and use that with the conn algorithm. All clients should migrate to
bRequireForName=true at some stage, though.
Change-Id: I24ae79b141c0f7a11e4d19f141759fc1dd2169b0
Reviewed-on: https://gerrit.libreoffice.org/64350
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The shape was created, but we literally tried to create a "conn" type,
while that has to be resolved to the relevant arrow type based on the
context.
This means now arrows show up between the parent-child pairs (but their
size is not yet correct).
Change-Id: I82594e46579e4ef723093e1dd0ba31bfcbbec4a0
Reviewed-on: https://gerrit.libreoffice.org/64348
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ia658f5c5ae6b0a6a82bf322d7fa22a1640d013ef
Reviewed-on: https://gerrit.libreoffice.org/64206
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
nDepth is only set in ParagraphObj::ImplGetParagraphValues
where the limit is checked, so the checks elsewhere are
unnecessary, and aren't comprehensive anyway
Change-Id: I566335da6b0cf13a76dcb247ad45c8b551af4456
Reviewed-on: https://gerrit.libreoffice.org/64223
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iecf66e31b66d65b9077da4870385ef8f9012f043
Reviewed-on: https://gerrit.libreoffice.org/58361
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
Change-Id: I17733d83cc652be8c5abaf20cd4b5e23d3a577a1
Reviewed-on: https://gerrit.libreoffice.org/57380
Tested-by: Jenkins
Reviewed-by: Daniel Silva <danielfaleirosilva@gmail.com>
|
|
Change-Id: I7d7082fffe6164dc751ede704b8707bd35b95aca
Reviewed-on: https://gerrit.libreoffice.org/57587
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
Change-Id: I62bd9affc9e065d7afcc60296a72eae4612b0ddd
Reviewed-on: https://gerrit.libreoffice.org/55840
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
found with
git grep -n -A4 'if.*!.*empty' | grep -B3 -P
'(\bfor)|(\bwhile)|(\bdo)'
Change-Id: I582235b7cf977a0f9fb4099eb306fdb4a07b5334
Reviewed-on: https://gerrit.libreoffice.org/64169
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
add missing colibre icons
improve layout for large icons
Change-Id: Id9d003b945654f958ec43d530083e2070d4b580e
Reviewed-on: https://gerrit.libreoffice.org/64159
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
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>
|
|
Currently the accept process document creates 0 connectors. Instead, it
creates empty custom shapes: this commit fixes the loop, so that only
one of them is created.
The whole purpose of the follow sibling axis is that N - 1 connectors
are created for N shapes, not N connectors.
Change-Id: I54244c7615b83f607ef53a4ff8d01d3c9594856e
Reviewed-on: https://gerrit.libreoffice.org/64122
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I3e6424e10eade04951f8ab24bb61af4ce19d1204
Reviewed-on: https://gerrit.libreoffice.org/64113
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This allows us to choose to render HiDPI images at the right time,
when we have the DPI of the device to render to.
The first step in a better, and more industry standard way of
improving our UI for HiDPI via rendering level scaling that should
retain a consistent look across the app with many fewer changes.
Change-Id: I36681f3242cb650de4f0b2d0fcdffbe5618e30fc
Reviewed-on: https://gerrit.libreoffice.org/64040
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.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>
|
|
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>
|
|
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: I5b776f89b7a49307e7a3ed4382f28ac58fc738ff
Reviewed-on: https://gerrit.libreoffice.org/64054
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic333dd44c980ace2f52057d795c29930515965f1
Reviewed-on: https://gerrit.libreoffice.org/64006
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: I4531a32f38ecfc1cd26b092d84ec9da442a71ea9
Reviewed-on: https://gerrit.libreoffice.org/64005
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: I8d98aa7dd77fbd79611b8a4aba77e8c378fd1cae
Reviewed-on: https://gerrit.libreoffice.org/63981
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|