Age | Commit message (Collapse) | Author |
|
which is a problem when we swap item ids under SAL_RTL_ENABLED=1
in sidebars
Change-Id: Ib949f7836893b2f06b748fc3a2546788555782ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106662
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5399f5aca07dd27dfc668cad66cf347936bbba7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106664
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: Id7bbf6443f25eee7745123f127cd9d6424a684b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106599
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id89d5655c2428cecdaf9faa224133302c6448a87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106600
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Did not work at all
Change-Id: I388ce579691a1e7ad2eff8420c2f8b6b3e939ef0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106665
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: Ie40632ab8ce53e0b1f9277dce3d46032a508edce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106663
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: If69eac02db386fd94420aff5a8b082281e913c15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106658
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I38bf65eb96b560970fb03eafaea89446e89a2896
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106591
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: If17738b7f58037929e29def75736434c33649b42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106590
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Once reason and time has getters, no need to expose the underlying
PDFium type.
Change-Id: I8f6b152fddf38e76ad7c3b1897fcb2026129820f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106631
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
So that this option can be set via UNO API
Change-Id: I0b69162661a4327d59aaed82d5eff98cb50d852c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106593
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
This was already working on master since commit
5868745db74ae930edb0058490076d82aaeafbe9 (emfplus: make VectorFormats
Emf/Wmf/Svg work, 2017-06-12), but a matching testcase was missing.
Change-Id: I7661cd5e66d13b1750f16c0c423c4b69420577a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106607
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ib19997f600404cc9555acbfaf87acac32f8aa5fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106562
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I6031025a72cc72e8bc3834c256479ec1a07971b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106561
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I7c1cc683e8c5d5bdc00c1e3d3d0a2c85846bbda0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106560
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
MSVC seems not to mind, but a Windows 64-bit build with clang-cl fails with
"error: non-constant-expression cannot be narrowed from type 'tools::Long' (aka
'long long') to 'LONG' (aka 'long') in initializer list". But adding explicit
casts would have the downside of preventing tools like
-fsanitize=implict-conversion (if we ever use that on Windows) from detecting
truncation, so introduce o3tl::narrowing.
Change-Id: Ia33a9ae4d8134b5ad0c8b7cf6812fbdd625ca89e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(The "%l" format specifiers had now caused -Werror,-Wformat with clang-cl for a
Windows 64-bit build.)
Change-Id: I86b9617310f7348d72172cc7a29f0976c7030dd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106576
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
VCL GTK (in contrast to X11 and apparently Windows) pre-activates popup
menus in GtkSalMenu::UpdateFull by calling GtkSalMenu::ActivateAllSubmenus.
Before this patch, this, called on the main menu, would not activate
the main menu itself (which does get activated in X11 eventually).
This patch changes the logic to also activate the main menu.
This patch deals only with gtk3. A followup patch would do the analogous
change in the VCL Qt5 plugin in Qt5Menu::DoFullMenuUpdate.
I haven't discovered yet where this type of functionality is currently
tested, so sadly I don't have an idea how to test this and so didn't include
a test case.
Change-Id: I6cd9929acfd3b3af731bbc62d649d643044ca692
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106454
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ieab577de92898568e27a879af1ca1bda170a307d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106554
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ie49f4113332de5c4fa825f93dde46bb408187fe4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106536
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: Id6152a1b96a92a8ee863e1426d458b9f81605065
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106535
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
regression from
commit 548d77d0c06f7088dd3eb408797aa1fc1d7eb277
Author: Noel <noelgrandin@gmail.com>
Date: Fri Nov 13 10:23:36 2020 +0200
tools::Long->sal_uInt16 in ImpErrorQuad
Change-Id: I29403afcb7d88dee27f1565793ffbd7ad4c53a17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106545
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I42208dd69bc790d136637253d7f1ae39a6306820
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106503
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Don't create synchronous dialogs on errors
which were causing infinite loops.
Just send error for logging purposes.
Change-Id: I88e57ae34502a6f82e44051033c91ca41c1a7b8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104579
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Ashod Nakashian <ash@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106418
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
of widgets loaded from the same .ui snippet in the same dialog so
ui-testing can identify the right one
Change-Id: I2ecc7fd60ab891ae9f94971a3035585d4500f694
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106500
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I78e2b60945f256de5e7455373a2ecff72f9eaae7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106484
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This displays an empty rectangle at the upper left of the tabpage.
Change-Id: I8424a3f8ec4896814b135aa2c86012f0b33ee1be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106480
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If4a6264729432cee6fc27765ad0f35e9bc4f0f43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106417
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I0263fb832f31c6926ac63cab79ce8fd0b9548581
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106415
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6ee795694959f1750a3c84421e632d00ad805b3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104611
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This tests the copying of complex resource when we reexport a
document which contains PDF graphic obects (and thus contains the
original PDF data in "Form" XObjects).
Change-Id: I680eb4702a7de7d48b67bd8cb8aa39e5195d876c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105812
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I4fcc4d912d4ce9d7800782b69811f877b85d9857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105811
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
basic.pdf is custom created so it covers all different parsing
use-cases.
Change-Id: I6eefa55b1cec5bf7eb91518d6a2df2cb48746dcc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105494
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This moves the parser into it's own class as it is not only
limited to dictionaries.
The parser has been rewritten to handle the array elements
correctly and properly. Previous array elements were filled during
the tokenization step, which is wrong, and the arrays weren't
parsed recursively, making the parsing incomplete in some cases.
This rewrite handles arrays similar to dictionaries and thus
allows them to be parsed properly.
All the sub-classes of PDFElement have been moved into the
header file.
Another change is also to not have a separate input dictionary
for the root object and instead always look into the dictionary
element that should be available instead.
+ many other smaller changes
Change-Id: I7fcf94760967bbd1474a0b432ba3a4e3c9b7cabe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105517
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia2f8d86ae012b530f3e9c39842bb75ef8ca27718
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105493
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This is in the spirit of tdf#108151, based on the information Qt
provides for the IM setting. I don't know how correct it is,
especially looking at Caolans comment 3 in that bug report
regarding the assumed validity of GtkIMContextInfo. OTOH it seems
to work well enough for my simple tests.
Some BG info: while the QInputMethod object is a global one, it's
"bound" to the focused window. So you'll get change events, when
you change the input window, with the correct IM settings for the
new one, be it a real window or just the menu bar.
To prevent unneeded flushes of buffers and language lookup, this
caches the current IM language of a window.
The language is not affected just by changing keyboard mappings,
which the bug reporter requested! It just works with a configured
input method, like fcitx or ibus (which can have keyboard mappings
too, which work correctly).
Change-Id: Ia9133edf4d1ce77d29adbfe57c180db15db0a560
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106354
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ia162ad5b7499c0ddfdbfca59ae76b81335ce2d45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105728
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
Change-Id: I224969de51a1d7e0176facb503a5b27cd8da530c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106265
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
See https://github.com/CollaboraOnline/online/issues/403 .
It seems that perhaps we can just bypass the whole ImplHandlePaintHdl
handler function on iOS. Not sure whether this has any unintended
side-effects. Testing will show. (Sure, if this is the right fix, it
would make more sense to not create that idle paint thing at all. Feel
free.)
As discussed in the issue, there is a problem on Linux, too, that
might have the same root cause, that can be reproduced in a simple
"make run" scenario. It is possible that to fix that, the
ImplHandlePaintHdl function should simply return right away if
comphelper::LibreOfficeKit::isActive() is true. (And if that is done,
the #ifndef added here can be dropped.) But I am even less convinced
that such a change doesn't have any ill side-effects, and the symptom
is perhaps less serious than on iOS, so I will leave that to others to
investigate, for now.
Change-Id: Ie4c1c70c65746961fa0730cae348ecc9bcdccf1d
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104918
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106257
|
|
and consider focus in a GtkToolbar child as focus the GtkToolbar
has focus
Change-Id: Id3299dd9246da22b21b3e1a347faff8bc867c438
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106270
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I91f3b012605416afd53e5d445ec10d683e8c1641
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106269
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie7417efd4113851615ee1c17a1297017a49a992d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106268
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iddd781b1acfb3d0fd8352cb50566fbebea4b3024
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106217
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It just hides the underlying FPDF_SIGNATURE, no real member functions
yet.
Change-Id: I37d27c26d6f05b1f8c697a5afe682c795e5d4d1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106184
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...for consistency with its internal workings of computing a value from other
tools::Long values, even if the result can never be negative. (And where the
additional bit for the unsigned type's magnitude probably doesn't make a
difference here.)
Change-Id: I1c6bcd2b8bdb70b9cd553758246af776b28500fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106178
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which had been unused ever since the code had been introduced with
aed8f7e44502be1eacfc179ceaede8a2118c462c "fix: #85201# new template dialog".
(And fix the resulting loplugin:cstylecast warning.)
Change-Id: I0f4fb1a630d7cd5f509d82067803284a133cfc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106179
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Avoid to toSkX()/toSkY() tweaks for rectangular areas, so with AA
enabled it leads to fuzzy edges, and rectangles should line up
perfectly with all pixels even without tweaks.
Change-Id: I45bf5a57a9f2d941eb7ec224992fc452481a2f98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106060
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The frame drawn by 'DecorationView::DrawFrame' may
use native drawing, in which case the frame may be wider
than 1 pixel.
Take that into account and calculate the frame width
and resulting position/size of the scrollbars and
child widget using the content rectangle returned when
drawing the frame using 'DecorationView::DrawFrame'.
This avoids that the child widget is drawn on top
of the frame, which e.g. resulted in no visible border
when using the Qt/KDE Breeze style, which has a frame
width of 2, with the actual 1 pixel border being
surrounded by a 1 pixel padding/margin, and the content
being drawn on top of the 1 pixel border. With the
child widget being drawn on top of the actual border,
only the invisible padding was left where a visible
border was expected.
(The current implementation assumes that the same frame
width is used on all sides, which matches the
way Qt styles handle it, but could be further extended
if necessary.)
Change-Id: I44268728838406fc578774c0f4fcc167fb2798b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106157
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
commit 1fe4a1a76da8fd3c196ccd9529b01ee093516b25
Date: Fri Mar 30 13:30:38 2018 +0100
draw a border around scrolled window
had added a 1 pixel border for scrolled windows.
Extract the value for the border width (currently hard-coded
to 1) to a variable.
This will be extended to take into account the actual width
of natively drawn frames in a follow-up commit.
Change-Id: I2503105c42fae9eae66ec931d54c9d6883f83bf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106156
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|