| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I3d8778d23a21bdd4a6babf495552112c67938111
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163413
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I2e1aa828f194a104d354741518e8cb20015ac276
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163385
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ie471593779bd44382ebc83355aef0c1fae87ae92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163380
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Idec36cb54e998c9e4830d5e51a6d2df7d94170fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163350
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I was over-enthusiastic adding these to the merged list, they
are DLLs with their own DllMain functions
Change-Id: I78a4e026e746f9688bc982ea7c899b05cf8f441d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163309
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The existing --enable-mergelibs is in use by Linux distro people,
who do not want any further mergeing because they want to be
able to split libreoffice up into things like nogui, calc, writer,
dbaccess, etc.
So this work is to enable combining even more into libmerged
for platforms like Windows and macOS and COOL, where we really
want everything in one big lump of code.
Change-Id: I4b268864955747d9859e16ebb569debbfc32fa78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162999
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Driving forward the Item reworks I now take the
ItemPool in focus: It now does not hold any items
anymore and should be renamed to something like
ItemInfoProvider/ItemHelper, since it's main purpose
is to provide the Defaults for the Item functionality.
There is that SfxItemInfo, only a struct and bundling
SlotID and ItemFlags. There are also the DefaultItems,
just handled as ptrs in an array. It is/was always
error-prone to keep these in sync. Remember that it's
also necessary for the order to not only being sorted
but being increments of one with no gaps allowed in
the WhichIDs to which the Items are bound.
I now bundled that to a new class ItemInfo that joins
WhichID, SlotID, ItemFlags and the default Item. This
is a pure virtual base class, it comes in three
derivations:
(1) ItemInfoStatic:
This is supposed to be global static and hosts the
Item in a std::unique_ptr to ensure cleanup. It is
designed to be constructed once during runtime and
being shared globally. It allows the ItemPtr to be
nullptr to mark as non-static (if initial static is
not possible for some reason) but still offers the
needed data. Most cases (95%+) are of that case.
The contained Item is owned by that instance. The
flag isStaticDefault() is set at the Item.
(2) ItemInfoDynamic:
This is supposed to be used for cases where the Item
cannot be static: Mainly for SfxSetItem (that needs
a Pool itself in the contained SfxItemSet, so lifetime
is bound to that Pool), but other cases showed up in
the transition. These instances live while the Pool
lives and get destructed when the Pool goes down.
Also uses std::unique_ptr for the Item instance for
as much automated cleanup as possible, the contained
Item is owned by that instance, the instance by the
Pool. The flag isDynamicDefault() is set at the Item.
(3) ItemInfoUser:
This is used for UserDefaults that can be set for
every ItemInfo entry to 'overshadow' the default
from the 'outside'. It uses a regular Item and
the central access methods implCreateItemEntry/
implCleanupItemEntry to manage the Item instance,
thus works like a SfxPoolItemHolder. The Item
instance can be globally shared and re-used even
when the Pool goes down. Instances belong to the
Pool and are cleaned up when the Pool goes down.
This Item does not need any further flag to be
set.
The ItemInfos are organized using a class
called ItemInfoPackage:
This bundles groups of ItemInfoStatic to
functional instances. There are derivations/
implementations of this e.g. for Writer ItemPool
bundling all the needed defaults for Writer,
similar for draw/impress, Calc and other usages.
These ItemInfoPackage can be 'registered' at an
ItemPool using it's method registerItemInfoPackage.
This does all the needed stuff to setup that
group of ItemInfos at the Pool (It even sets
internal vars First/LastWhich, that info can just
be derived from the buildup ItemInfo Ptrs).
The ItemInfoPackage has methods 'size()' and
'getItemInfo(index) to allow looping over it
and deliver the infos the Pool needs. The
(forced, pure virtual) overloads of getItemInfo
in the specific implementations check for the
ItemPtr being nullptr and create a exclusive
incarnation of ItemInfoDynamic for the Pool if
needed, returning that. The Pool owns the
ItemInfoDynamic incarnations and uses the
ItemInfoStatic directly. On shutdown it cleans
up the ItemInfoDynamic as needed.
The ItemInfoUser is used by the Pool when a
UserDefault is set/used: for SetUserDefaultItem,
GetUserDefaultItem, ResetUserDefaultItem. It
is not held in a 2nd list, but directly in the
list of ItemInfo'ptrs: To keep track of this
an unordered_map is used that helds the original
ItemInfo associated with the WhichID. That way
no two lookups (as before) are needed to get the
current Pool's default for any WhichID.
The derivations of ItemInfoPackage are
encapsulated and just allow access to an
ItemInfoPackage& with a single method as
return value. All use a static local instance
of a std::array<ItemInfoStatic, FIXED_SIZE>
which constructs all ItemInfoStatic and the
static Item instances - if already possible.
Sometimes it is necessary to overload the
constructor to set some static instances
for Items later than the lib init. These are
also just marked with nullptr as Item instance.
Some need to overload getItemInfo to complete
instances of ItemInfoStatic, if needed, or
create and deliver instances of ItemInfoDynamic.
The registerItemInfoPackage also offers a
optional lambda callback: there were two cases
where local data from the Pool was needed to
incarnate the item - just add that to the
call to registerItemInfoPackage if needed,
see examples in the adapted code.
For the re-use of Items this means that now
in SfxItemSet/SfxPoolItemHolder *true* static
Items can and will be used without RefCount
directly and globally. This is also the case
for dynamic Items, with the exception of
differing Pools for SfxSetItems which cannot
be done.
Future:
That design is already prepared to allow
solving that Pool-chaining problem: currently
there are master/sub-pools and all accesses
have to traverse that structure before even
doing anything.
For the future the idea is more to 'compose'
a Pool by registering ItemInfoPackages, e.g.
for Writer pool you may start with SfxItemPool,
register the writer-specific ItemInfoPackage,
then the one for DrawingLayer (if needed) and
the one for EditEngine.
It should also be possible to get to smaller
granularities of that packages. Ideas for
new ones will emerge. We might also think
about composing Pools which can e.g. run Writer
and Chart, so allowing to use Chart *without*
OLE stuff in Writer - just ideas...
More changes:
- Adapted all stuff, cleaned up old stuff/
definitions
- Removed FreezeIdRanges, that can be done
once per Pool on-demand (and cannot be
forgotten to be called)
- Merged XOutdevItemPool with SdrItemPool
and offered a ItemInfoPackage which joins
both needed sets of Items
- All the cleanup hassle with Pools and
defaults cleaned up
- Adapted all access methods of the pool
to use that new stuff. Pool chaining
currently stays, but I use a central
method 'getTargetPool' instead of
recursive calling to get the correct
Pool for the action
Change-Id: I2b8d3d4c3cc80b1d0d0b3c0f4bd90d7656b4bab7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163157
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I16b930072d71947acd606a2103e12dea27be3b60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163113
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic5158faa07538a688fe609cfd1359ec9ce3b6807
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163089
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...so recent LLVM 19 trunk libc++ in debug mode complained during
CppunitTest_chart2_export2 about
> ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering
at
> 5 libsystem_c.dylib 0x0000000183279a40 abort + 180
> 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0
> 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960
> 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268
> 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68
> 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508
> 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528
> 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440
> 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728
> 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692
> 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288
But the introduced use of `std::strong_order(first[0], second[0]) < 0` then
triggered a false
> lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr]
> 105 | return std::strong_order(first[0], second[0]) < 0;
> | ^
so needed some hack in loplugin:nullptr.
And old versions of libc++, still used at least on Android, do not have any
implementations of std::strong_order. So detect those cases in configure.ac
(checking for std::strong_order for double, which is what is actually being used
in the code) and fall back to operator <=> for now, even if that will not
provide a strict weak ordering and will thus continue to violate the
requirements of std::sort.
And then our venerable clang-format 5.0.0 would have broken the token `<=>` into
`<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment.
Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
In files linenumbering.ui and optfonttabpage.ui the labels 'intervallines',
'lines' and 'font_label' respectively are there for visual coherence but do
not provide any meaning. Therefore, moved them from suppression to false file
Change-Id: Ied1001a8b445574e4ceca92c4fdf45a4e5a8ca97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161807
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: Ic178737da802e17f87d0b5b09004a847b0fe91be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162956
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I6605b4bc74ba186e06693ef5346e7b7fd0c0b9df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162938
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
by including the spellchecker library into the merged library
Change-Id: I427458005af3b30bfdcd2134ef102852e4c92ea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162861
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
remove CUI_DLLPUBLIC from stuff which is not exported
then drop the cui/include dir which is then empty and
the places we link to cui where we now don't need to
and restore cui back to a lib containing stuff that
doesn't need to be explictly linked to in keeping
with original #i106421# idea
Change-Id: I21894e6f8529dd3306df345fb52dbf5009015f3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162798
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
What I'm after in the context of our Embind-related code is the claim at
<https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management>:
"JavaScript only gained support for finalizers in ECMAScript 2021, or ECMA-262
Edition 12. The new API is called FinalizationRegistry and it still does not
offer any guarantees that the provided finalization callback will be called.
Embind uses this for cleanup if available, but only for smart pointers, and only
as a last resort." However, with the recommended emsdk 2.0.31 my tests did not
show any use of that finalization support. So I wanted to try with the latest
emsdk 3.1.51 instead. But then, linking vcldemo failed with
> wasm-ld: error: ~/allotropia-qt5/lib/libQt5Core.a(qlogging.o): undefined symbol: std::__2::__vector_base_common<true>::__throw_length_error() const
etc., so I gave it a try to rather build against latest Qt6.7, with
> --with-distro=LibreOfficeWASM32
> --disable-qt5
> --enable-qt6
> QT6DIR=...
TODO: The result is highly experimental, and it uses ENABLE_QT5 (i.e., the
recommended setup with emsdk 2.0.31 and the
<https://github.com/allotropia/qt5.git> v5.15.2+wasm branch) vs. ENABLE_QT6
(i.e., my experimental setup with emsdk 3.1.51 and the
<https://github.com/qt/qt5.git> 6.7 branch) not only to distinguish between Qt5-
vs. Qt6-specific behavior, but also to distinguish between old- vs.
new-Emscripten-specific behavior. Of note:
* The startup code appears to have changed substantially (and required setting
-s MODULARIZE=1 and -s EXPORT_NAME=soffice_entry now, and telling emcc to
build just soffice.js and not the wrapper soffice.html. TODO: This also
required hacking into qt_soffice.html: (1) The command-line arguments
(--norestore, --nologo, --writer, and the exammple.odt; all of which we should
eventually get rid of, anyway). (2) Saving the generated instance as
window.Module (and adapting the embindmaker-generated code, cf. the changes to
static/README.wasm.md).
* There were some symbol clashes between external/argon2 and
libQt6Core.a(qcryptographichash.cpp.o, so renamed the problematic symbols in
external/argon2.
Change-Id: I5420ab566d560b11954ac6613249bfc53d8acb31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162695
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I4f8dc3d338b64452dc92c850c7dc174bb59611bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162592
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Filter "empty" targets in Visual Studio solutions: it makes little sense
to add generated files to projects (they aren't intended for editing in
IDE); so most external libraries, which only have "generated" sources,
and aren't part of core anyway, would have zero source files in their
projects - thus excluded.
Handle C++/CLI files; use their specific CXXCLRFLAGS (set them to the
source files explicitly, overriding CXXFLAGS set on the project level).
While here, do the same with CFLAGS and C files.
Do not add H(XX) files (with names identical to C(XX) files) to the VS
projects. This adds a tiny subset of all headers, which is inconsistent.
Change-Id: I6bd932277287d3444bb547b93f2867d226072d60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162582
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... and to vs-ide-integration solution.
Change-Id: I5085e6a61df4bc03cfe595a1e6b99196f6f73643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162524
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Open Security Option Setting page directly from Security pop up
warning infobar.
Follow up of 1f440348eb0892fd2c9597806d87b5fe9d60d49a
(tdf#157482 UI: Turn Security Warnings popup windows into infobars)
Change-Id: Iac116677801bdb13a9680bcfdf532ec3d874ce0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162393
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
which was released on Dec 12th, 2018
https: //lists.boost.org/Archives/boost/2021/10/252209.php
Change-Id: I8d65d98648a44d7303fc46338bfdeba7801749e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162423
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
...as the former is more convenient for release engineering (see the discussion
in the comments at
<https://gerrit.libreoffice.org/c/core/+/162157/1#message-8d7ebbcc64a87ee8e4a073ae1a05e3b74f5a3d6a>
"Also enable --with-package-format=archive for LibreOfficeWin64.conf").
Instead of ONLINEUPDATE_MAR_OLDARCHIVE and ONLINEUPDATE_MAR_OLDMETADATA make
variables, the create-partial-info target now only needs an
ONLINEUPDATE_MAR_OLDMSI make variable.
TODO: There are two issues when comparing the content of msi files (extracted
with msiexec /a), which the old code comparing the content of archives had tried
to somewhat (but not fully) address with the metadata files that I had invented
(and now reverted): For one, msiexec /a also extracts content that would
normally be installed somewhere else in the system (e.g., it extracts Fonts,
System, and System64 directories). Differences in those directories will cause
a MAR update to create those directories in the installation directory, rather
than to update the corresponding files in their actual locations. For another,
optional components are not recognized as such, but their content must be added
to the MAR file as add/patch-if, not as plain add/patch. To work around that,
for now *all* files are added as add/patch-if, conditional on the files
themselves. Thus, addition of files will cause a MAR update to miss them.
(As they now exclusively operate on msi files, the create-update-info and
create-partial-info targets are no longer meaningful for non-Windows platforms,
so drop the non-Windows bin/update/create_full_mar_for_languages.py part.)
Change-Id: Ifb55b5e7d1a201b4f50a27cb449a634b96c2e29b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162399
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
The "which" utility is not guaranteed to be installed either, and if it
is, its behavior is not portable either. This means that when various
programs are installed, the `which` check will report a fatal error
because the which tool did not exist and the shell returned a nonzero
status when attempting to fork+exec. If it did exist, it might not be an
implementation of `which` that returns nonzero when commands do not
exist.
The general scripting suggestion is to use the "command -v" shell
builtin; this is required to exist in all POSIX 2008 compliant shells,
and is thus guaranteed to work everywhere.
For some in-depth discussions on the topic, see:
- https://mywiki.wooledge.org/BashFAQ/081
- https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
Examples of open-source shells likely to be installed as /bin/sh on
Linux, which implement the 15-year-old standard: ash, bash, busybox,
dash, ksh, mksh and zsh.
This commit updates documentation to no longer suggest a bad practice
that will confuse the reader when it doesn't work.
Change-Id: I0ed5ced353124919c7e09912c6d4d5aea146fa33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160666
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
The "which" utility is not guaranteed to be installed either, and if it
is, its behavior is not portable either. This means that when various
programs are installed, the `which` check will report a fatal error
because the which tool did not exist and the shell returned a nonzero
status when attempting to fork+exec. If it did exist, it might not be an
implementation of `which` that returns nonzero when commands do not
exist.
The general scripting suggestion is to use the "command -v" shell
builtin; this is required to exist in all POSIX 2008 compliant shells,
and is thus guaranteed to work everywhere.
For some in-depth discussions on the topic, see:
- https://mywiki.wooledge.org/BashFAQ/081
- https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
Examples of open-source shells likely to be installed as /bin/sh on
Linux, which implement the 15-year-old standard: ash, bash, busybox,
dash, ksh, mksh and zsh.
This commit updates a couple build scripts to not rely on fixed paths
calculated upfront. Checking the location of a tool with cmd=$(which
foo) just to run it as `$cmd` is pointless. It's exactly equivalent to
run it as `foo`, but less error-prone and easier to read.
For one of the scripts, it also simplifies checking for their existence.
Personally, I am skeptical it even makes sense to check at all. POSIX
mandates they exist, and it's exceedingly unlikely they will not be
installed. However, unlike the shell interpreter itself, we don't *know*
they are installed, so leave the existing checks in but simplified.
Change-Id: I4703c1165eb3a5aeb45fbab18df3222e8f5f9551
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160665
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
The "which" utility is not guaranteed to be installed either, and if it
is, its behavior is not portable either. This means that when various
programs are installed, the `which` check will report a fatal error
because the which tool did not exist and the shell returned a nonzero
status when attempting to fork+exec. If it did exist, it might not be an
implementation of `which` that returns nonzero when commands do not
exist.
The general scripting suggestion is to use the "command -v" shell
builtin; this is required to exist in all POSIX 2008 compliant shells,
and is thus guaranteed to work everywhere.
For some in-depth discussions on the topic, see:
- https://mywiki.wooledge.org/BashFAQ/081
- https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
Examples of open-source shells likely to be installed as /bin/sh on
Linux, which implement the 15-year-old standard: ash, bash, busybox,
dash, ksh, mksh and zsh.
This commit updates the build system to configure and build correctly on
systems without `which`.
Change-Id: I23dbde5c7f104dd610fd5f78c82bf9a7d0cc1930
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160663
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
(See a31f334d36b5735ba6fc8d0f89e834a73bdcc561 "Windows MAR update issues with
program/{setup,version}.ini" for why this cleanup is needed.)
It is unclear to me why these entries would be needed in the setup.ini file.
The *INSTALLLOCATION values are also stored in the Windows registry (see
scp2/source/ooo/registryitem_ooo.scp). FINDPRODUCT was once used as a
GetMsiProperty, in code meanwhile removed in
030124d836a3f8571e26c8ce6b5d752ca7ab2511 "remove CustomAction
ExecutePostUninstallScript" (so I also removed the FINDPRODUCT property file
line from solenv/bin/modules/installer/windows/property.pm, so FINDPRODUCT will
no longer in the MSI Property table). ALLUSERS is only used with some
SetMsiPropertyW/UnsetMsiPropertyW/IsSetMsiPropertyW/GetMsiPropertySetW code in
setup_native/source/win32/customactions/, but that should be unrelated to the
setup.ini file.
Removing the ProfileItems from scp2/source/ooo/common_brand.scp removed the only
uses of the INIFILETABLE style, so also remove the corresponding code from
solenv/bin/modules/installer.pm and the complete related
solenv/bin/modules/installer/windows/inifile.pm. Fingers crossed.
A# modified: scp2/source/ooo/common_brand.scp
Change-Id: If2aa72f0da50bc72f8c873df713340a142eed5e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161981
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
(See a31f334d36b5735ba6fc8d0f89e834a73bdcc561 "Windows MAR update issues with
program/{setup,version}.ini" for why this cleanup is needed.)
I couldn't find any traces of any code actually reading that entry from
ini-files. (There is some code in
setup_native/source/win32/customactions/shellextensions/ calling GetMsiPropertyW
with an L"UpgradeCode" argument, but that's something different.)
Change-Id: I8ed79e7f7911635c52e1c41f54014b1445c561de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161980
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
(See a31f334d36b5735ba6fc8d0f89e834a73bdcc561 "Windows MAR update issues with
program/{setup,version}.ini" for why this cleanup is needed.)
There were traces of actually reading that entry from ini-files in commits like
3f01a5e9e4ec757eb26cc056a161fb7832ccd5d6 "INTEGRATION: CWS nativefixer12
(1.2.2); FILE MERGED", d9d86a2d662f38aa0473211fbf3ef2241b1c9c93 "INTEGRATION:
CWS nativefixer18 (1.3.2); FILE MERGED", and
2521869690771c7af094520edf92ee8d2c5573a1 "INTEGRATION: CWS native36 (1.7.4);
FILE MERGED", but all of them have since been removed with commits like
50c26300e5b5ae9671f18a9e449516604d16105f "Remove lots of dead code",
26c142ca5f2b405b02ab5701dfaeab7bf281a727 "Kill the ancient StarOffice "patch"
concept", and e0ea85f61a5914508921b5e73119516219afa158 "we don't build language
packs on Windows". (And all of the original code appears to having been related
to ancient Windows patch mechanisms.)
Change-Id: I552830faf9006bae951fc60e97804abd9de718bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161979
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
(See a31f334d36b5735ba6fc8d0f89e834a73bdcc561 "Windows MAR update issues with
program/{setup,version}.ini" for why this cleanup is needed.)
The ini-file entry had originally been added with
d295757e7ec2cf0f7d83cf903ecb7c115a354bb9 "INTEGRATION: CWS nativefixer11
(1.23.2); FILE MERGED", and setting its value with
b993422e59287924d7d85afc75eb9cffc66311db "INTEGRATION: CWS nativefixer11
(1.21.38); FILE MERGED" and 127dd8d32a87cecdc678d4b8288142f65a7a1fc9
"INTEGRATION: CWS nativefixer11 (1.45.2); FILE MERGED", but it doesn't appear to
ever have been actually used for anything, other than being recorded in the
ini-file. Lets remove it completely for good.
Change-Id: I5f0372360416c2c6949ee2d5f0cc7e6babd8ba79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161978
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...that directly generates one large .cxx
Change-Id: I046539b83f8fde5eda7168c93a8b819137399665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162343
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
It is used in SC, DirectPut* in Pool, fetched using
Surrogates, all bad. Only to transport data over the
Pool, may not even need to be an Item.
Trying to solve/losen that gordian knot, looks good.
Is now a normal data holder class, could find a good
parent for it that the Dialog and the instances
setting up/using that Dialog can use.
Forgot to reset that data instance in one place, but
also checked in-between a version that still used the
Item to excluse that the Poolis the same, but the
ScTabViewShell does change. FOund an error with
SfxPoolItemHolder when reseting, also changed.
Change-Id: I1c99d675d1cc3d21205c3e2df78d4b52a696e7ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162313
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
It turns out, that this also works, despite all the documentation
refers to it as '.natstepfilter'.
Change-Id: I17ab0662a3de0e0f7db72e31f5e7ed0f00823447
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162311
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
Allows to avoid stepping into some functions, like smart pointer's
operator->(), when debugging.
Change-Id: Ia930ad6b0c94c9caefad8ac026252fced1265fb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162304
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...which had been added all the way back in 2002 with
6cd0bbd8ce6ae2774fc61dacc0f81725ba038d79 "adding new file to HEAD" to constants
group css.drawing.CaptionEscapeDirection, which has meanwhile been published, so
no chance of cleaning that up.
But cppumaker already has a mechanism to work around problematic UNOIDL
identifiers, but which was only used for "new-style" entities when they got
introduced, mainly to avoid compatibility issues when retroactively changing the
code generated for existing entities.
But for C++ keywords, the generated code was always broken, so no harm in fixing
it, so introduce an additional IdentifierTranslateMode::KeywordsOnly and use
that at least for constants, to address the immediate issue.
(And with that, a hack can be removed from gb_UnoApiEmbindTarget__add_embind.)
Change-Id: I5cf62fd8b3b298dff2ec28452fb97b424a4ba473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162305
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I24c429c7cb8283a384b72499d1c3f4c2f1457c33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162155
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
see
<https://github.com/flathub/org.libreoffice.LibreOffice/pull/268/commits/7c79189f674c7cc88f0ab2790d8d198f4a855182>
"Work around patched libpng in org.freedesktop.Sdk":
...which carries
<https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/873b28450476c434a3f6fa86cb1874b11968a479>
"elements/base/libpng.bst: Add support for animated PNGs", thus handles "acTL"
chunks by itself, thus doesn't call the LibreOffice handle_unknown_chunk
function (in vcl/source/filter/png/PngImageReader.cxx) for such chunks, thus
never sets APNGInfo::mbIsApng to true, so causes CppunitTest_vcl_png_test to
fail with
> PngFilterTest.cxx:382:Assertion
> Test name: PngFilterTest::testApng
> assertion failed
> - Expression: aGraphic.IsAnimated()
(<https://buildbot.flathub.org/#/builders/6/builds/92958>) since
<https://git.libreoffice.org/core/+/bf944e33569e4a1d6236a54671b7320cdc6ffaf6%5E%21>
"tdf#104877 Add basic APNG format support".
The patch appears to originate from
<https://sourceforge.net/projects/libpng-apng/>, and it might be possible to
adapt the LibreOffice code to also work with such a patched libpng (whose png.h
defines PNG_APGN_SUPPORTED). However, for now just use LibreOffice's own
external/libpng instead of the patched one.
Change-Id: Ib67056d11dfa6456920a18216a3b2bbec45f3662
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162112
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Need a dependency on UnoApiHeadersTarget.
Change-Id: Ie9ca3a4806d15e2535f1119a00f9214ce9520a5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161973
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I584956151b036e1ba781439205a76f579f32c064
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161955
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
The issue is that the flag RegisteredAtPool
at the SfxPoolItem is Pool-dependent: It marks that
the Item is registeres at *one* Pool/Model. This
makes it Pool-dependent. Due to this there is no way
to share Items that need to be registered globally/
in multiple Pools/Models what is one of the goals
for optimal sharing.
We can also not live without having access to all
Items associated with the Pool, due to mechanisms
in place like the Surrogate stuff.
This again is used for two purposes:
(1) Access all Items associated with one Pool/Model,
at least that is the assumption. This is not valid
since it gets corrupted with a single ItemSet/Holder
used that does not host model data, e.g. an open
Dialog or the Sidebar (or...). But works in
principle.
(2) Access extra-Items that are held nowhere and
are created using DirectPutItemInPool, e.g. infos
for a Dialog. These would need a instance/place to
host them, the Pool is (ab)used for that.
Both are 'compromizes' (to not use a more bad word)
and should not exist. (1) should iterate over the
Model and do actions. There are even places that
use (1) to *change* Items, by casting them to
non-const, even RefCounted ones, so having no control
over what all might be changed doing so. Since we
talk about ca. 100+ places there is no way to get
away from this - I can imagine how this happened:
The 'poolable' attr traditionally needed for the old
binary format was one day 'used' to not need to
iterate over the Model, an API was added to access
and this usage was copied. Sigh..
It is even used when ODF is loaded: E.g. the
FillStyle is imported from XML, interpreted, and
put into an ItemSet. Then it gets set at the
XShape using UNO API and a *name* -> that name and
the Surrogate mechanism is used to find and set the
FillStyle at the Model Object. The FillStyle could
probably just be set using UNO API and the data
directly.
The association between Model/Pool and Item is
created by the object hosting the Item, these are
ItemSets and ItemHolders. Thus it is possible to
register these at the Pool. This allows to iterate
and collect the Items associated with the Pool
and keep the Surrogate mechanism alive.
This is the main change done here. It limits
the registrations to Items for which (at the Pool)
the NeedsPoolRegistration is set, also
Item-independent. Speed is okay, I saw no big
changes in my tests here. The registration is
just pointers, no ownership or RefCounting needed
here.
The advantage is that Items get closer to be
shared office-wide, they can be referenced by
multiple ItemSets (RefCnt) associated with
different Pools/Models.
NOTE: This is not true for SfxSetItems, these are
and will stay Pool-dependent due to their need
to a Pool in the contained ItemSet.
Note that we have ca. six deivations of SfxSetItem,
but ca. 500+ Item derivations, so not too bad.
For the usages of Surrogates to change existing,
RefCounted Items: These can now at least be
changed - if they show up to be problematic - to
iterate over the registered ItemSets and change
Items there the correct way: Set a changed one
at the ItemSet. That also allows Objects to
*react* on ItemChanges, there is no way to do
that with the existing 'compromize'...
UnitTests show that this already works well for
SC and SD, but SW has still some issues. I will
put this to gerrit now, but there will be
additional work.
A involved problem is the current DefaultItem
handling and the state the Pool implementation
is in. E.g. StaticDefaults are not really static,
Pools hard-delete the DefaultItems (forcing the
RefCnt to zero to not have the destructor
complain) and other quirks. Looking at that
right now, hoping to get this change done without
having to change that too much.
I thought about adapting PoolItemTest to this,
but it is only related to DirectPutItemInPool
which is mostly gone and hopefully completely
soon.
Nonetheless I adapted that mechanism to use a
list of SfxPoolItemHolder at the Pool. That makes
it safe and abandons the need for indirect
garbage collection removal at the Pool.
Change-Id: Ib47f21dafa989202930919eace5f7e9c5632ce96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161896
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
* Incorporate
<https://github.com/flathub/org.libreoffice.LibreOffice/commit/d9e2f088aafe41c3c9cc4af14e935777dba794c1>
"Update gvfs-1.52.1.tar.xz to 1.52.2 (#272)"
Change-Id: I95bee83408caab8e27eae978068f8ec4e87a9c12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161956
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
That make target operates on an archive, but generates data to be applied to an
msi installation, so suffers from any mismatch between archive and msi install
sets. Two such mismatches, at least on Windows, are:
1 Files that msi will install outside the LibreOffice installation itself (but
which for an archive install set are included under LibreOffice/). This covers
(at least) .Net assemblies and associated files that are installed in the GAC
(scp2 styles ASSEMBLY and ASSIGNCOMPONENT) and fonts (scp2 style FONT).
2 Files that msi will only install conditionally. This covers optional
components (many of which in scp2 are assigned to gid_Module_Optional_...
modules) and user interface languages (which in scp2 are assigned to
gid_Module_Langpack_... modules).
The approach taken here is to create a
workdir/installation/LibreOffice/archive/install/metadata file while building an
archive install set, and to record any files matching 1 (as "skip" lines) or 2
(as "cond" lines). Then, the create-update-info target uses that metadata file
to act accordingly on those files:
1 Files from "skip" lines are simply removed for now from the extracted archive
that is passed to Mozilla's make_full_update.sh script. (TODO: That means that
changes to such files will not be updated with the MAR update mechanism. This
would apparently need some extra processing during the MAR update.)
2 Files from "cond" lines shall be recorded as add-if in the mar file manifest.
Mozilla's make_full_update.sh script already has support for emitting add-if vs.
plain add, but only for files under distribution/extensions/, which doesn't
match our needs. So we generate from the metadata file an ifs file that we pass
into the make_full_update.sh script, and patch that script to also take that ifs
file into account. (Each line in the ifs file is of the form
"testfile" "file"
which works as long as none of the pathnames contains double quote characters.
The Mozilla script code appears to be confused about the arguments to
make_add_instruction(), where this ifs file will be needed: There are calls to
make_add_instruction() with two or three arguments across make_full_update.sh
and make_incremental_update.sh, but make_add_instruction() checks $1, $2, and
$4 (but not $3), so leave that mess alone and pass the ifs file as a global
IFSFILE variable instead.)
The mar file manifest `add-if "testfile" "file"` adds "file" only if "testfile"
is already present, and those two can be different files. TODO: However, for
simplicity, for now I always use "file" also as the "testfile" (so that an
add-if file only gets updated if it was already present). That avoids having to
identify a specific "key file" for each optional component and for each user
interface language, where that key file would be used as the add-if testfile.
But on the other hand, it means that if an optional component or a user
interface language will bring along a completely new file in the future, we will
not install that file during a MAR update. What obviously remains to be done is
to properly assign each add-if file to a specific key file. (And the current
way of identifying add-if files by gid_Module_... names appears to be too
simplistic too. For example, there are some gid_Module_Optional_... that are
installed unconditionally for msi; but it should be harmless that those files
are recorded as add-if rather than as plain add.)
Change-Id: I2fdeed92604f3a2d8a0b500b9e3fa421cfb6a9cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161917
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Iaaa598cacb354140be422f4df256183ac0d91b2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161890
Reviewed-by: Sophie Gautier <sophi@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I6aa9a21d1422b8b3b6fe5dde9869dffa88be5535
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161744
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Ever since 9043c50f5e284f00a7eadeab5a3add0417c32227 "INTEGRATION: CWS native62
(1.68.8); FILE MERGED" and its "2006/09/15 14:51:02 is 1.68.8.2: #i67179# new
user dir for all simple-package installation sets" archive installation sets had
set the UserInstallation bootstrap variable to $ORIGIN/../... instead of the
normal $SYSUSERCONFIG/... that is used for other installation set formats.
However, I see no good reason for that, and it interferes with my current work
of making the --enable-online-update-mar `make create-update-info` work again
(which builds a mar file from an archive installation set, so contained a
boostrap ini-file with an unexpected UserInstallation value).
(I don't know about the "installed" installation set format, which also messes
with the UserInstallation setting, so I left that alone.)
Change-Id: I3bd1e00771a4149922c3ce4e4d187abd3889b4ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161650
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I9b4374a95598c08c06427ecc9348c68d56352d25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161607
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I9db309b15e490c9bd03e767c192ba364a4ffe214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161452
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
(An upcoming change will add an instset/update-settings.ini file containing that
value, but using a GeneratedPackage for a single file instead of a directory
seems unsupported, so it will use the hard-coded value and a plain Package
instead.)
Change-Id: I12ffef4db71ce36be9096df674588b39c660e4de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161545
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...broken since 84ef6d82546b044990f4efd57e51e29c6c6565c8 "Build external lxml if
not provided by system"
Change-Id: Ie76c32a1d3094e6d98db7d50195571ae31c0ada6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161536
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Also move some simple methods to header file and clean-up the
constructors and destructors.
Change-Id: I5113d785ecc71d36b4c6a480b15427ca68eb2e0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161474
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I9856302967de59368dc60b3e01f4a36fdb97e00e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161359
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
