Age | Commit message (Collapse) | Author |
|
Change-Id: I0c17f40b3e593ae3771fa751a817f84bf2f2323d
|
|
Change-Id: I6fc9fe8ce78ad9cc1a7c2fe3e13ed38ce468ce6c
Reviewed-on: https://gerrit.libreoffice.org/10347
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
and while we're at it
- use the enum type all over the place instead of passing around
sal_uInt16
- don't use bitwise logic on enum values
- use enum values instead of numeric constants
Change-Id: I7f24cb4d242e1c00703e7bbcf1a00c18ef1e9fd4
|
|
Change-Id: I62127b23475dedf081fc981c20e916d5868ab086
|
|
and into a module-local header.
It's not like the methods have any actual relationship with the
SfxPoolItem class.
Change-Id: I1378364a1554642333b0c5c79d869d719b53fa0c
|
|
Change-Id: I57de8c0cebfd60fdf70c23c72ecf1e47c69d7ecd
|
|
Change-Id: I3cb720b62216f5534d0ff3b524c596158ffe824c
|
|
drop the ePresentation parameter, since all 4 of the callsites use
SFX_ITEM_PRESENTATION_COMPLETE as the parameter value,
and just inline the value into the method.
Change-Id: I42c8eae82837c9f9d4edc886d7c760f57b129125
|
|
Change-Id: I7cc9fa3ab6aebc541df4708e29b530f8021b14ba
|
|
so that we don't have to const-cast when modifying it
Change-Id: If584e4ddd440638169af00493f0194b34832177f
|
|
Change-Id: Ideb690df8a74efe55bff832e16e66a6b77b1530a
|
|
Change-Id: Idb20e9acd97a27801ff95dc53d3e179326c122d4
|
|
Change-Id: Ibf7b2f5e93748198eccbbbf54fad5f8053270003
|
|
since it is unused
Change-Id: Ib739240a362eeff6a72b2300804583b575edfb24
|
|
Change-Id: I4eade2d00d145d8f65ccd70a1c6bbd0a134a1ad5
Reviewed-on: https://gerrit.libreoffice.org/10346
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I79c669c1635192199d6ef135e1ab9b48a9e7e63a
|
|
Change-Id: I0d3d1a14d8eb880a5a054fe2e736f8ac97f8b727
Reviewed-on: https://gerrit.libreoffice.org/10284
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
when calling SetAccessibleName GetAccessibleName is called
in order to send a name changed a11y event. Getting an Accessible
Name is very slow in a non-layout aware widget because it scans
for a "nearby" label and there is none in this widget, but it
has a huge pile of other widgets to iterate over.
call add_mnemonic_label before hand to cut off that entire
branch.
While we're at it, only call InitControl to adjust to a new
width if the new width is different from the old width
Change-Id: Ie4ba1276127226e49442278e46447b84bbeb1cde
|
|
Change-Id: Ie4cef54a943fc456b042425b53286492a0bed0be
|
|
Change-Id: I1dd1b40d807c7c9d9b145aca9f69a67d786ec5ff
|
|
Also change behavior for the GetListenerCount() method which now
returns the count of listeners.
The previous behavior is available in method GetSizeOfVector().
Change-Id: I5b03fa55a309f4ff5aea5e8830c137786fc07e89
Reviewed-on: https://gerrit.libreoffice.org/10344
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I9ecd8fec395eafbdc2675dda9fa25ac32761123c
Reviewed-on: https://gerrit.libreoffice.org/10343
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ib332d04fa27501ec35267b5e389c2979c9c55be2
|
|
Problem Description:
The docx file contains a word art inside a drawing tool.
After RT, nesting of <txbxContent> tag is happening which
is causing the corruption.
Solution: Created a service in util.cxx for checking
few shapetypes for which textbox with content is not
allowed. This check also helps to find that if we are
already inside a DML then we should purely read VML
Information.An existing UT testWordArtWithinDraingtool
was failing. The UT is related to same issue
(word art inside drawing tool) hence changed it
accordingly. Following is the commit id of the
UT-Change-Id: I00e94712e912ad1977fcb65a945fefb927795d77
Change-Id: I7e456c9f6a69af80da443e29eb02a64ba7d59468
Reviewed-on: https://gerrit.libreoffice.org/10229
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Luboš Luňák <l.lunak@collabora.com>
|
|
- Generic fix for all warp properties
Change-Id: I77c37759aa49706fc3cd1a80770a85face53f0a2
|
|
Change-Id: Ie479d363152d3c6a109d6e924b09c155c79511c8
|
|
Change-Id: Ic18823fd60826c144058df32c27ab25d58664e30
|
|
and
coverity#706085 Unintended sign extension
Change-Id: I4bb617cd6927542dfef6dea89c5417ec4f9ed495
|
|
Change-Id: If3b7a6c71164f2b55defe8c28cdce69de9283175
|
|
should be explicitly initialized in the copy constructor
Change-Id: If375412e43bad6bced7bd5c69578f998b9e6618c
|
|
instead of hand-rolled code
Change-Id: I56e991c70334cb201a460ea8679be70808451a86
|
|
Change-Id: I0b03973b2d09a0ce51a6ee7dcca5a310a544c3a9
|
|
most of length in vcl are calculated in 'long'
but array of X position tend to be in sal_Int32.
As a prep work to be able to support 'double'
as the base type of Device Coordinate, harmonize
the use of 'long' for non-float coordinate.
Change-Id: I7cb33301ff6a5e2c62247b36a4e07e168a58a323
|
|
Change-Id: I165e403d2834d341f7da7a280859afccb995a3bb
|
|
Change-Id: Ifba7104a13cf737200c81d1a1bd5ece9a29da60e
|
|
The eventual goal is to make vcl capable of handling a backend
that use double instead of sal_Int32 as its base type
for device coordinate.
Change-Id: I6174f1f4afe00992b95c9163bc21dd54fec98631
|
|
Change-Id: Ic3e13e89480e3b18f84c3a8fd1a88627bd465d6a
|
|
Change-Id: I6b2fabd72fd34f4ac1b3a18f386c90794bc39ce4
|
|
Change-Id: Ide5a10d7f9c45970c3cc5c78213c151c85ff4570
|
|
Change-Id: I9e49abc490935710b471c79d19385bda37f038b0
|
|
e.g. convert code like
foo(X * const & p)
to
foo(X * p)
since the "const &" part of it adds nothing useful.
Change-Id: Icf5f2041517259e7b6e055b75ed1e0e77c547da5
|
|
Change-Id: I2a4066c66894e0bd9c349a7c5b8db3a8398451d2
|
|
Change-Id: I1566a20166e77ac1e00db9ba19b92c68ad14e2df
Reviewed-on: https://gerrit.libreoffice.org/10366
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I7aa4a9bf72732db95a67cee368f3a83a0d71bb9c
|
|
.. which more accurately reflects it's purpose
Change-Id: Ibb87a47a3d1f3e35ac2820f14c71adf3b227c961
Reviewed-on: https://gerrit.libreoffice.org/10283
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
- Remove includes from files where they are not needed.
- Update pch files
Change-Id: I0188e3934ef429008c1ef495ab1d5b27f38664d5
Reviewed-on: https://gerrit.libreoffice.org/10342
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
- Rotation property is not available for TextFrame in LO.
- Hence grabbaged this value.
- Roundtripped rotation value by converting it properly for both dml and vml textbox.
- Added UT for it.
Change-Id: Ia040d55dc2ea79500df76877ba44a02971c872a8
Reviewed-on: https://gerrit.libreoffice.org/10190
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
OOXML gradients can have an arbitrary number of "stops". LibreOffice gradients
have just a start and end colour, plus an optional uniformly coloured border
(on the "start" side). In addition, LibreOffice has the "axial" gradient mode,
which means the gradient is reflected in the middle.
It is thus obviously impossible in general to losslessly map OOXML gradients
to LibreOffice ones. But let's try a bit harder than earlier to get visually
more similar result, in at least some simple sample cases.
We look for the widest gradient segment and use that for the start and end
colours of the LibreOffice gradient.
Also, map an OOXML gradient to an axial LibreOffice gradient only if it is
symmetrical. Also, use the border property when suitable. In general, look for
the widest OOXML gradient segment (once a segment corresponding to the
LibreOffice gradient border, if any, has been accounted for) and use that as
the LibreOffice gradient.
Possibly some perceptionally better heuristic should be used... Like, if we
have a three-segment gradient, with a wide gradient segment between two
visually very similar colours (for example, two shades of red), and a narrower
segment ending with a visually very different colour (for example, yellow), it
probably would be best to represent that in LibreOffice as a gradient from the
first red shade to yellow, instead of as a gradient between the two shades of
red. Or even, if a first or last gradient segment is between very similar
colours, equalize those start and end colours, thus using a border colour in
LibreOffice instead. The possibilities for bikeshedding are endless.
I am sure there are instances where the old code (by accident?) produced
visually more pleasing results... But hopefully this works more pleasingly and
consistently in a larger number of cases.
Change-Id: If153e986ad943454307e3ba718479d5ac4cdc7ab
|
|
Context is correctly created and the OpenGL calls no longer crash but it seems that I still have a buffer problem so nothing is shown on the screen.
Change-Id: Ia9cc585cd92c6049197dbfa47a41e30e130739ed
|
|
Change-Id: Ifd9c0dd2ceec08f50f3a8c4356fb288e65040dc5
Reviewed-on: https://gerrit.libreoffice.org/10345
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|