Age | Commit message (Collapse) | Author |
|
Change-Id: I46eb4145bd79253c1c20b7a03d82b6873402d9ac
Reviewed-on: https://gerrit.libreoffice.org/64086
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I31f810383fb92b2d0dbe9fa9162b77f137154e91
Reviewed-on: https://gerrit.libreoffice.org/64085
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4f10e323293485e7a1969fd4c80873aa05971e6c
Reviewed-on: https://gerrit.libreoffice.org/64084
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I89a6244c01be811bfdfc443f687708ed6aec8a10
Reviewed-on: https://gerrit.libreoffice.org/64083
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Also add image scale to in-memory cache lookup.
Change-Id: I1e84b922d4a9ab2f1723c5cb8a72f295c6940504
Reviewed-on: https://gerrit.libreoffice.org/64043
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
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>
|
|
Change-Id: Ia1a45e7292a61efd21c4a7351af1a681b92e886e
Reviewed-on: https://gerrit.libreoffice.org/64077
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>
|
|
Change-Id: I940e1ae01ec384069cf2704fdc81b7561e9f8d63
Reviewed-on: https://gerrit.libreoffice.org/64094
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
With introduing String rotation support
I made mistake by not removing Maping from DX-Array.
With this commit I'm fixing that issue.
Now drawing with DrawDriverString record,
and rotation is working perfectly.
Change-Id: I7ae051b3791d9d2d8e2143ed33d21b7bfbc551c6
Reviewed-on: https://gerrit.libreoffice.org/64079
Tested-by: Jenkins
Reviewed-by: Patrick Jaap <patrick.jaap@tu-dresden.de>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
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>
|
|
At least on tinderbox MacOSX-x86_64@49-TDF the sed appears to ignore the
literal newline character, which is unfortunate, particularly since it
worked on the Jenkins builder.
Blind fix to replace this with a tr invocation that already appears to
work in Zip.mk.
Change-Id: I7a77e69774b050a018b12c73ddd9eff849c33a86
|
|
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>
|
|
Change-Id: I3a2145277212b7b45c25bea2e33aae3f6f4a7776
Reviewed-on: https://gerrit.libreoffice.org/64066
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and document in the registry that the SubstFontsPS is unused
Change-Id: I66a9e0b4353f17b34cffb02823726c9887b7bdd3
Reviewed-on: https://gerrit.libreoffice.org/64065
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I09a0eb661b66da78d8b3809124930bc761960712
Reviewed-on: https://gerrit.libreoffice.org/64064
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5e1a92d94e5b7963c8162b74f1b67dbbf3eeccc9
Reviewed-on: https://gerrit.libreoffice.org/64063
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0fffa7b02ac61ef009e566d04b903cc02e9b4b3d
Reviewed-on: https://gerrit.libreoffice.org/64062
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9e832da8f6b7a90d72c07ab712cbe00774496b76
Reviewed-on: https://gerrit.libreoffice.org/64060
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I604e3bf6362271e767a4862a2c9d789a2c89df88
Reviewed-on: https://gerrit.libreoffice.org/64070
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Most probably that was related to "pulsating" buttons that haven't
been used since 10.9. Whether the code even worked (made buttons
pulsate) on 10.9 anyway is unclear.
Much of the code in this file uses various HITheme (Carbon?) API that
as far as I know is long since deprecated and undocumented. It's weird
that it still compiles, and that it doesn't get caught by the private
API use checking when submitting to the the Mac App Store, in the
LibreOffice Vanilla case.
This change reduces the busy looping in Dialog::Execute() even when
nothing happens (no user input, no mouse movement) when displaying a
dialog.
Change-Id: I9c62db608f637aa5d8493176feb2873f6426fd00
|
|
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>
|
|
It is much over a year since we bumped to 10.9, so it is time.
Bumping to 10.10 will allow us to with good conscience get rid of some
code that (presumably) tries to emulate some aspects of OS X user
interface look that went away in 10.10. See tdf#114839.
Change-Id: Ic41f73d8e59a40c4696069af85bb3ff33146086c
Reviewed-on: https://gerrit.libreoffice.org/63880
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I01321f82958bbf22838554010abf706a3e9b9391
Reviewed-on: https://gerrit.libreoffice.org/64061
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia40e882af0df396895a19dd34caa60461cdf6c12
Reviewed-on: https://gerrit.libreoffice.org/64059
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idd62a6458d7aa0d1d8a479f5ebf78637e0360548
Reviewed-on: https://gerrit.libreoffice.org/63950
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I1048d86bf11b4fdd4a5c90f6e98276893b8ffbf4
Reviewed-on: https://gerrit.libreoffice.org/64078
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
This way it can't happen that we open a menu or context menu, the user
switches away (loosing focus) and a leftover floating window is still
there.
Handle this at the same place where we stop blinking the cursor on focus
loss.
Change-Id: I4321e8e3fa1d3f8976c0a1fa29c6a182972023bf
Reviewed-on: https://gerrit.libreoffice.org/64053
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Previously it tried to use a BUILDID Make variable that did not exist.
Change-Id: Ie31eb3928c69dc52fcb17a9a5593cbe166d95307
|
|
the pCP = pCodePairs statement was left behind in
- std::vector<sal_UCS4>::const_iterator itInt = aSupportedRanges.begin();
- for( pCP = pCodePairs; itInt != aSupportedRanges.end(); ++itInt )
- *(pCP++) = *itInt;
+ for (auto const& supportedRange : aSupportedRanges)
+ *(pCP++) = supportedRange;
Change-Id: Icedf7a4dae224f6b328f924691ec4c6767495389
Reviewed-on: https://gerrit.libreoffice.org/64038
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
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>
|
|
Missed this one in Change-Id: I47f9ae10a0fd967729ff6e83c1a312aa49e1d13c
Change-Id: Ibb825a922e7d7fcc31456386935b3a847642ebf0
Reviewed-on: https://gerrit.libreoffice.org/63966
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
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: I5d1559c2cb201ec69fc6353aaf491fbb5c0534dd
Reviewed-on: https://gerrit.libreoffice.org/64047
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I86775a5b7609f5e85c8fcc18a0be7e0ee3c8f84c
Reviewed-on: https://gerrit.libreoffice.org/64046
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I61023dc049b914fee1d5d8918b99972d34a82b4a
Reviewed-on: https://gerrit.libreoffice.org/64042
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4d63601ca3658b4ffd9eaf1c13d4c17503640aa0
Reviewed-on: https://gerrit.libreoffice.org/64041
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
it is no more complex, and it saves us the construction of an
intermediate vector
Change-Id: Ie92c2970c5b10805d7bcfc0cc2a74378f2cbda08
Reviewed-on: https://gerrit.libreoffice.org/64039
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id4eed12f3d4a32b71d00b99e6e82ca7cefb3f8ec
Reviewed-on: https://gerrit.libreoffice.org/63961
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
This changes how the list items are identified in the code, making
use of the support for item ids in comboboxes introduced in commit
83cefb5ceb4428d61a5b9fae80d1e673131e9bfe.
Change-Id: I69390c8f9d32b77454e2935cf28b38ea44be8ffd
Reviewed-on: https://gerrit.libreoffice.org/63238
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
* Update helpcontent2 from branch 'master'
- tdf#120927 Webservice functions needs linking to
Change-Id: I8d96025238fc2005dab37c1050a0c7915210d73a
Reviewed-on: https://gerrit.libreoffice.org/64055
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
Change-Id: I57cd718ed03846dbff164acb5cd3c329d9eee615
Reviewed-on: https://gerrit.libreoffice.org/64036
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
Change-Id: Ieb09d4d28cc2084da4660165a96561ee57d2420d
Reviewed-on: https://gerrit.libreoffice.org/64029
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6060b7130827346ac5d6955bf38ebe3b476819fd
Reviewed-on: https://gerrit.libreoffice.org/64022
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I75b28d20e2e0954fbd2fee396b8e06e9bb7d7073
Reviewed-on: https://gerrit.libreoffice.org/64028
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id63e1d73643a18d823dfcb35479f0f8eb3e20b15
Reviewed-on: https://gerrit.libreoffice.org/63972
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: I9ee3318c79d3b59f272a2a5f89c38b26afa05974
Reviewed-on: https://gerrit.libreoffice.org/63775
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
macOS's linker can take a -filelist argument, in place of taking the
list of object files to link on the command line. This is a more limited
version of "response files" as used elsewhere in the code base, and by
using it we make it far less likely that a linker invocation will hit
ARG_MAX.
A standard LibreOffice build probably won't hit ARG_MAX on macOS just
yet, but it's not far off - some LDFLAGS are enough to tip it over the
edge, which is what prompted me to fix the issue. If not fixed, a few
more object files will probably break LibreOffice builds on macOS! An
example of another large program that has encountered this issue is
Thunderbird, which implemented the same fix[1].
The changes I've made to use -filelist are adapted from the code
elsewhere in gbuild that creates response files, but this is slightly
different because -filelist files are a bit different - they can only
contain object files, as opposed to arbitrary linker arguments, and
arguments are separated by newlines rather than spaces.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=837618
Change-Id: I01b9126aad95056c3dc82f941dea4fd43f95d0f2
Reviewed-on: https://gerrit.libreoffice.org/64010
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|