use solenv/bin/add-modulelines script for the task
and remove all UTF bom from *.src and *.hrc files
svx/source/dialog/hdft.src
Change-Id: I745d4f0fe9b05436a142a03f8512970f91c41bd4
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
Apparently the TYPELIB has problems with paths if they contain
some "special" characters like "-", unless it is quoted. It can't seem
to be able to concatenate quoted strings properly either. So build
up the whole filename in the makefile and quote/escape extensively for both
shell and rc.
This library was never shipped with LibreOffice; presumably it is some
backward compat kludge for StarOffice versions older than 5.2 that only
shipped with StarOffice.
Change-Id: I5e07e14fde0f62814f4648b362f9e9333fd6c84f
This does not build from the top-level because it uses a relative path;
the command invoked from "make" runs in the top-level dir while the
command invoked from "make extensions" runs in the extensions/ dir, so
we have to use absolute path here. Presumably the weird substitution
going on here is just a relic from the days when WORKDIR was variously
converted with cygpath.
Change-Id: I73a61699ec0394bd40e63864f3e9f566c7d28a32
Once this was fixed it seems to work nicely. Add keywords in
File:Properties and they show up in Finder's Properties, and Spotlight
finds text from the document contents.
Change-Id: I203576a5a7e53ca3485b0a82f0c6d06122f361d1
Consider the following situation:
Property Name Property Order Index
------------- --------------------
propA4 4
propB5 5
propB4 4
And the loop goes over these properties in this order.
propB4 should be before propB5, but with the old code,
propB4 would be pushed after propB5: it asks for position
4, but as positions 4 and 5 are already occupied, it gets
pushed to position 6.
Remaining difficulty: properties from different
property index ordering series will be interleaved.
This should be solved at object model level;
ideally property order index should be unique,
at least within an object.
Change-Id: Ie235a4b22155df97df139f1dc354247845626620
Otherwise, in a LO built with hidden visibility (as gcc terminology,
not ELF, Mac OS X does not use ELF), Spotlight won't be able to use
our importer.
Change-Id: Ie19082f9f14e4cc75ae6f7583031b929b7b75330
to avoid error messages like:
error: could not convert ‘(const char*)"LocalFile"’ from ‘const char*’ to ‘const rtl::OUString’
Change-Id: I8b55049bd29c63b837f80b1562b9e8cd8324c603
...solved by removing the nPos member and instead calculating the index on the
fly. The difference is that old indices were before calling std::sort in
OPropertyInfoService::getPropertyInfo() while new ones are after, but that
should probably be OK per the documentation of
com.sun.star.inspection.XObjectInspectionModel.getPropertyOrderIndex (which
appears to be the only client of that functionality).
Change-Id: Id346bb219acbdad88ec43cf46feca8c37f2c7cf4
