Terribly sorry to revert this - but the UX-advise consensus is to show the
rulers by default.
This reverts commit ae991a10701caac3db2483a8aef05e4e8385765c.
This is a rework of f9059d4eee8e53c0a6b531fff16e1fade58cb8b0 "Key all browser
plugin features to --enable-nsplugin." The problem with that was that Mac OS X
supports pluging browser plugins into LO documents (which was originally
controlled by --enable-mozilla) but not plugging LO into browser windows (which
was originally controlled by --enable-nsplugin), so controlling the former with
the same switch as the latter did not actually work.
Thus I replaced the single ENABLE_NSPLUGIN feature flag with two dedicated ones,
ENABLE_NPAPI_FROM_BROWSER (for plugging browser plugins into LO documents) and
ENABLE_NPAPI_INTO_BROWSER (for plugging LO into browser windows). The
--enable-nsplugin configure switch is gone completely, setting the feature flags
is always done fully automatically now.
Change-Id: Iecf706637465e865c987563b5de489fa90b4c904
It seems that previously onCreate served 3 different purposes:
1) bootstrap UNO machinery
2) load the document
3) create the view
Ideally it should do the first two only if not done already -- as a
first step, this commit extracts 1) and does only once.
Change-Id: I087a6b934c05295263080f571c95ef152e4602cb
we use git submodules, so it makes more sense (hopefully)
Replaced options:
--no-lo-pieces with --no-submodule
--piece=<piece> with --module=<module>
Removed hopefully unused option:
--no-lo-core
Change-Id: Icbf742991ccda2f7833a5b50d51cb1421885383d
...instead of having them spread across --enable-nsplugin (plug LO into browser
windows) and --enable-mozilla (plug browser plugins into LO documents). The
ultimate goal is to clean up the various configure options mentioning "mozilla"
and WITH_MOZILLA.
Change-Id: I6f4b1c3a5701424f586cc1e303af90c9d59a91b6
It allows to avoid symlinks more easily.
In addition, I did some clean up. I removed support for packing pieces
from standalone checkout. I guess that noone is using it.
Change-Id: I3c712f5eb12108229a157c636e0a63eca4ae0d6b
...past 8648c974ea5e222027a5ac1c9a01cd9ac6e344a8 "Clean-up 'SYSTEM_MOZILLA' ->
'SYSTEM_NSS.'" Looks like -DSYSTEM_MOZILLA in RepositoryExternal.mk's
gb_LinkTarget__use_nss3 was only relevant for
xmlsecurity/source/xmlsec/nss/nssinitializer.cxx (for which it had been set
explicitly in xmlsecurity/Library_xsec_xmlsec.mk, and renamed to SYSTEM_NSS
already). And looks like xmlsecurity/Library_xsec_xmlsec.mk's explicit
SYSTEM_NSS code was more or less a duplication of RepositoryExternal.mk's
gb_LinkTarget__use_nss3, so made that DRY.
Change-Id: Ie6eca2c4eb7fb70f6a36c97d8681b4140f9870cb
...so that only a "not-registered" that is non-optional and non-ambiguous is
considered as "disabled" by user's intention. Other combinations can occur for
broken extensions (that will thus become disabled again anyway when we try to
automatically enable them) and for originally enabled extensions for which
cleanExtensionCache in desktop/source/app/app.cxx has forecefully removed
user/uno_packages/cache/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/unorc
(and which should rather be kept enabled).
Change-Id: Ic85b609ec9b3634cfa94a77151d42c07b9488030
The file unused.easy contains a lot of symbols which are known
to be required, even they're currently not referenced by anyone.
Change-Id: I048c1656b240f7d601e4c99b8d9c4969b3954c87
Reviewed-on: https://gerrit.libreoffice.org/1084
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
In general, DOCX tables provide a grid for the table, then use spans in
case different number of cells are used in different rows. In this case,
the cell width is ignored, as the wished width can be counted from the
grid and span values.
However, it's also valid to simply provide more cells then the amount
defined by the grid, and in this case the cell width should decide the
final width of the cells. This commit adds support for this later case.
Change-Id: I0dd6c1f0c06f81c2afa00489b7ad1f33ff300a7c
