Our convention is to just have the name of the abstract base class in
a comment before the declaration of the concrete overrides of its
abstract member functions. No need to say "Abstract struct" there.
Change-Id: I2b9bdf0555af5280771370a6df56fd4c8623661a
This is specifically for the benefit of DOCX import, but it
also makes sense in general. If a SwXCell is given char/para
properties, then apply those properties (without overwriting)
to the cell's contents.
This allows ANY paragraph or character properties that are applied
to a table style to become the "default" for the table.
This fixes a number of things:
-remove one-off hack to get PROP_PARA_LINE_SPACING to work.
-works for all character and paragraph properties (except those
shared with tables like borders).
-works in multi-paragraph cells. Previously those could return
AMBIGUOUS state, in which case the style wasn't applied at all.
Change-Id: Ia98c129879575c1aa8ca1fe2a64f4991c0a264e8
Reviewed-on: https://gerrit.libreoffice.org/54511
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here
A bit of fallout management was necessary as well
find-unneeded-includes gave no proposals for chart2/inc
Change-Id: Id382586f575cf45da758da453df9340b28e9ddd0
Reviewed-on: https://gerrit.libreoffice.org/54778
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This is really similar to commit
4c2172a3e9 (tdf#106702 PDF export: fix
missing images from Writer headers/footers, 2018-05-22) just this one is
about the size of the output rectangle for JPG content, while the
previous problem was about the position of them.
Also extract PdfExportTest::exportAndParse() from the last two tests to
avoid duplication.
Change-Id: I9812924d505e9fdaca2a95b4990e7aaa5e44fd7f
Reviewed-on: https://gerrit.libreoffice.org/54773
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The other function, setPropertyValues already has this variable,
so for consistency and flexibility, add it here as well. Plus, this
is prep work for another patch.
Change-Id: I16c5b1cbb9fd99a11be99a59005bd856d787a6ca
Reviewed-on: https://gerrit.libreoffice.org/54510
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Using the system ("native") menubar works fine since a long time
surely. No reason to keep a fallback possibility.
Change-Id: I0d9ed86c28b0d832c8123b18980740dbf895ec1c
Reviewed-on: https://gerrit.libreoffice.org/54775
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Can happen at least when LibreOffice is started from the command line
using the 'open' command line and passed a file name.
Change-Id: I93145974a56e124550579cae8fd69ccb4a7d3bda
Reviewed-on: https://gerrit.libreoffice.org/54758
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Also removes dead code because SwTabFramePainter::Insert()
is always called with a cell frame and IsTabFrame() always
returns false.
Change-Id: I2505d876d20e44ded1faf760bc3b7b1d34b0fd8d
Reviewed-on: https://gerrit.libreoffice.org/54684
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
a linear loop builds a recursive structure, if it gets too deep then later
processing, e.g. releasing the tree, can exhaust stack
Change-Id: I4421b9bae62ac2b6ffe32531d1167a482103bfde
Reviewed-on: https://gerrit.libreoffice.org/54762
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Also tdf#76476, and probably more.
Make it so that when a window is in full-screen mode from
LibreOffice's point of view, it is also full-screen from the system's
point of view, and vice versa.
All three ways to enter and leave full-screen mode can now be used
with the same end result: The Ctrl-Cmd-F shortcut, the "View > Full
Screen" menu entry, and the green bubble on the title bar.
Don't disable/deactivate/etc menus while in full-screen mode. The menu
auto-hides so there is no harm in having it function normally.
Don't display the floating toolbar with a single "Full Screen" button
in it as the way to leave full-screen mode. Instead, the same three
ways that can be used to enter full-screen mode work to leave it, too.
Sadly I could not figure out a way to set a window properly to
full-screen at the point where a document window is created and set to
be the same size as that kind of document window was the previous time
it was open in LibreOffice. Thus don't save state for full-screen
windows as we can't properly restore them. At least not for macOS. It
is not good to just restore them as non-full-screened but still at the
size they had when full-screen.
One irritating glitch remains, and I was unable to fix that properly:
I now prevent closing the document window that is in full-screen mode.
Otherwise, if it is closed, the full-screen mode remains even if no
window is open there; the desktop is completely black. Moving the
cursor to the top edge, the LibreOffice menu is there, though. I tried
to fix that but with no fully satisfying result. (Some attempts even
lead to crashes, so just disabling closing is better than crashing at
least.)
Change-Id: Id909077ef9de9f19d48c8b9ad10d748a65b2417f
Reviewed-on: https://gerrit.libreoffice.org/54760
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
regression from
commit 6529cd54c2
don't use heap for elements in ScRangeList
where I converted some loop variables from pointers to refs, forgetting
to assigning to a ref is quite different from assigning to a pointer
Change-Id: I4a365006317d16a24cbb1b43994906a0d4b4d424
Reviewed-on: https://gerrit.libreoffice.org/54756
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...that previously ended up in language-independent parts of installation sets.
The structure of that media/ tree doesn't allow to directly mis-use the existing
AllLangPackage machinery (which expects the language to be encoded in the first
pathname segment within the tree; and which is already mis-used for the
helpcontent2/AllLangPackage_html_lang.mk parts).
So introduce gb_AllLangPackage_add_files_for_lang that allows to specify the
language explicitly, independent of where it is encoded in the pathname (if at
all). The underlying gb_AllLangPackage_add_file sets a
gb_AllLangPackage_ALLDIRS that is used by `make packageinfo`, which may need
further fixing by anybody actually using that target; see the mail thread
starting at
<https://lists.freedesktop.org/archives/libreoffice/2018-May/080242.html>
"Broken --with-help=html `make packageinfo`".
All files in $(SRCDIR)/helpcontent2/source/media/ must now explicitly be listed
in either helpcontent2/Package_html_media.mk (for the language-independent
files) or helpcontent2/AllLangPackage_html_media_lang.mk (for the language-
specific files). Also note the two TODOs in
helpcontent2/AllLangPackage_html_media_lang.mk.
What is not quite right yet is that content from
helpcontent2/AllLangPackage_html_lang.mk and
helpcontent2/AllLangPackage_html_media_lang.mk is ending up in both per-language
helpcontent installation sets (as intended, via the instructions in
helpcontent2/CustomTarget_html.mk) and per-language languagepack installation
sets (which is unintended). This needs to be fixed with a follow-up commit.
This is the core part of a commit spanning core and helpcontent2.
Change-Id: Ib29e52cf8a3ca7bcd234a8f6919c8eac6157cdbf
Project: help 33551e7fd85aa327f76bb343a3740bceb162bbfa
Properly handle language-specific parts of --with-help=html media/ sub-tree
...that previously ended up in language-independent parts of installation sets.
The structure of that media/ tree doesn't allow to directly mis-use the existing
AllLangPackage machinery (which expects the language to be encoded in the first
pathname segment within the tree; and which is already mis-used for the
helpcontent2/AllLangPackage_html_lang.mk parts).
So introduce gb_AllLangPackage_add_files_for_lang that allows to specify the
language explicitly, independent of where it is encoded in the pathname (if at
all). The underlying gb_AllLangPackage_add_file sets a
gb_AllLangPackage_ALLDIRS that is used by `make packageinfo`, which may need
further fixing by anybody actually using that target; see the mail thread
starting at
<https://lists.freedesktop.org/archives/libreoffice/2018-May/080242.html>
"Broken --with-help=html `make packageinfo`".
All files in $(SRCDIR)/helpcontent2/source/media/ must now explicitly be listed
in either helpcontent2/Package_html_media.mk (for the language-independent
files) or helpcontent2/AllLangPackage_html_media_lang.mk (for the language-
specific files). Also note the two TODOs in
helpcontent2/AllLangPackage_html_media_lang.mk.
What is not quite right yet is that content from
helpcontent2/AllLangPackage_html_lang.mk and
helpcontent2/AllLangPackage_html_media_lang.mk is ending up in both per-language
helpcontent installation sets (as intended, via the instructions in
helpcontent2/CustomTarget_html.mk) and per-language languagepack installation
sets (which is unintended). This needs to be fixed with a follow-up commit.
This is the helpcontent2 part of a commit spanning core and helpcontent2.
Change-Id: Ie7916b75eee0dde3106e784d19e99fde5bb93195
Reviewed-on: https://gerrit.libreoffice.org/54749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
FullScreen in this context means a top-level window that is both
full-screen from the desktop environment's perspective (which
depending on the desktop environment might simply mean that it is as
large as possible to fill its screen, leaving any system menus etc
visible), *and* is in LibreOffice's full-screen mode (with no toolbars
or other UI elements except the document contents visible).
Not yet used, will be used in follow-up commits.
Change-Id: Ia6f86e0d2a7c5a621c6f19d897d3b17ba6bfb8b4
Reviewed-on: https://gerrit.libreoffice.org/54733
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
...on indirect dependencies too.
Here a self reference to any formula-group
means if there are any references in a formula
(of the formula-group itself or any of its dependencies)
that points to any element inside the formula-group.
If there are any self-references, then that formula-group
can't be computed in parallel.
For example, with this patch we can detect the following case:-
Suppose the formula-group that we want to check is:
"=(F2+G2-10)*10.0" spanning A2:A100. Let the formula-group
starting at F2 be "=A1*0.1-10". The indirect dependency
formula-group starting at F2, references back the elements of
our original formula-group at A2. This makes the F.G at
A2 unsafe for parallel computation.
Concretly, this patch fixes a recalc crash on tdf#63638/1
Change-Id: I7b999a34571b191d2f70da6a3831f78b24a6b0a7
Reviewed-on: https://gerrit.libreoffice.org/54433
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
