Multi-select explorer action on Windows defaults FILEOPEN 2 different
ODF file type documents as template - e.g. opening two different type
of files (ie : ODS & ODF) then doesn't keep the original filenames.
So now changing the open command for the different file extensions to
the same one "soffice.exe -o %1", will keep the names of the _2_ files
as they originally are when they are opened together.
Change-Id: I2cd5fcb046f294742e59f69b7bf2a897a6ce0c29
Reviewed-on: https://gerrit.libreoffice.org/36995
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
Using advertised shortcuts -- inspired by Intel AppUp Centre's
requirement -- was not a good idea after all. I revert this,
and I also revert the commit that actually disabled it in
default Windows builds.
This reverts commit aa2450cb51.
This reverts commit b40012bd6d.
It's always possible to run the soffice executable from the same
location with a --base, --calc etc command-line option instead.
(That is not the normal way for Mac users to open an empty document
for the specific aspect of LibreOffice (Calc, Writer, etc) either.
Instead, the usual way (says cloph) is to keep a corresponding
template document in the Dock and click that.)
Change-Id: Iceea270c03a63f674e7dfdfa95117cb3bdd15184
Reviewed-on: https://gerrit.libreoffice.org/3930
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
math.dtd was dropped from installation in 2009, see
https://issues.apache.org/ooo/show_bug.cgi?id=97200#c3 :
"In agreement with MIB and MT it was diecided that the Math.dtd should
be removed from the installation set as well since it
a) has incorrect content
b) is no longer used nowadays at all"
Change-Id: Id2a727338c224b0beb4b8def197988ab071a7d94
See developer mailing list for discussion, subject "LibreOffice is one or
several applications?"
Change-Id: I7a4a5a76f980eb458a2b6d4558a553b8508fd990
Reviewed-on: https://gerrit.libreoffice.org/3638
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
In VersionInfo of Windows executables the FileDescription property originally contained
80 times 'x' character. These executables were marked as PATCH_SO_NAME and later the
installer maker perl program replaced the xxxxxxxxxxx to the actual file description
which was defined in scp2. WHy was it good, I have no idea. The problem was that it
happened after postprocess, where we signed the binaries, thus diigital signature became
corrupted. It is better to give file descriptions via makefiles.
Change-Id: Id5ad4470bb7a6313b33fbba09d72d9a009163a89
The main goal of this patch was to simplify things. The LibreOffice
version that goes to Intel AppUp use advertsied shourtcuts, because
it is what Intel AppUp Center requires. We can reduce complexity a
bit, if we use advertised shortcuts in normal builds, too.
Change-Id: Ia35a753c83cb592137232428ab897a640e7ccc1f
64-bit registry entries were entered via a custom action, which
did not always work. By default the custom action ran with user
privileges, which were not sufficient to write the registry.
It is not necessary to use custom actions for this task. Windows
installer supports it well.
Change-Id: Id65458c363c2b90b3e7d166b4c836bfb1ff19bf4
Adapt some of the DLL names to match conventions we currently use in a
MinGW build. If those are changed to be exactly like when built with
MSVC (for SDK ABI stability reasons), will have to change here, too.
Bypass stuff that we can't build with MinGW when necessary. Should be
synchronized with the corresponding makefiles, obviously. We can't
currently build the Explorer extension or MSI installer custom actions
with MinGW due to lack of some required headers and/or import
libraries.