* 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:⭐:resource::OfficeResourceLoader
com::sun:⭐:resource::XResourceBundleLoader
com::sun:⭐:resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
Add new PACKAGE_FILELIST_FONT
The DONT_DELETE style has no effect for files.
The FONT_WARN_IF_EXISTS style has no effect.
Change-Id: Id062ada0a680341c01827e457b1166d625afe8cc
This patch registers vnd.libreoffice.command unconditionally,
and also registerd ms-word, ms-excel, ms-visio and ms-powerpoint
handlers according to SELECT_WORD, SELECT_EXCEL, SELECT_VISIO, and
SELECT_POWERPOINT properties (that are set in FileTypeDialog).
This allows to use these URIs in e.g. SharePoint WebDAV integration
Change-Id: I3231a15196858da77f1784a47f86f1729a6044bb
Reviewed-on: https://gerrit.libreoffice.org/29988
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Fix for double backslashes in paths to programs in shell/open etc.
registry entries for all non-native file types such as .doc that are
mapped by installer to use scalc.exe/swriter.exe etc.
Change-Id: Ice8033d4fee079c0fb6d8f84e00ebd784e85d135
Reviewed-on: https://gerrit.libreoffice.org/25849
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
...assuming the delayLoadHook in cli_ure/source/native/native_bootstrap.cxx is
no longer necessary and loading of cppuhelper from the program dir cannot fail
regardless in whatever scenario the cli_cppuhelper library itself is loaded.
Change-Id: I13f32b327bca4cce9780864f5e57cdad3860afe5
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
vs2012 express does not have atl so one need to
--disable-atl and --disable-activex
but then the packaging still try to include a few _x64.dll
that are not built.
Change-Id: I88ca5b9d23febd5a714fb48321dde5424cafceb6
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
This is a bit involved because since the LinkTarget now creates the
instdir/sdk/lib/* files itself a Package cannot be used; so convert the
URE libraries to AutoInstall and add special handling for them to
gb_Helper_register_libraries_for_install to create the necessary links
in the "sdk" install-module.
(regression from 70c35265f5)
Change-Id: Ia5467f3303d59f7f5f4a88adc22ceffb82a21ff1
This is somewhat annoying since it requires re-introducing stupid
directories in scp2, but if the executables should be put in INSTDIR
directly then the Package_bin needs to go.
Change-Id: I893694c7f9d4cb5b9ef8ec4a3d30e08536223740
INSTDIR has everything that will be installed anyway, so ideally the
file search patch should only be INSTDIR + whatever is needed to get the
Package file lists; especially WORKDIR seems inappropriate there.
The exception is extension .oxt files which apparently are not in
INSTDIR; not sure what to do about those.
Change-Id: I2477c25ab9fcf953fae9c219e76c467e14729cda
Version independent ComponentID in Component table of MSI means
that the GUID is calculated from the Component name only, the
PRODUCTVERSION is not concatenated to the name. Providing that
name is constant in all versions, the resulting GUID would be
the same e.g. for 4.0, 4.1, 4.2 etc. But what is it good for?
Faster upgrades maybe? But name can also change, we did not
pay attention to keep it constant. So in order to help scp2
cleanup, VERSION_INDEPENDENT_COMP_ID flag was obsoleted and
removed.
Change-Id: I8e1ee450524b02f07d0b0553f6b82d0321dbddcf
Second attempt, this time using a new type LIBO_LIB_FILE_BINARYTABLE
in scp2/macros.inc; for the resulting MSI file Orca lists the same
files in "Binary" table now.
Change-Id: I550ede75f16a46da9dd7377594aa28b7c06f0348
It's not actually that I am massively stupid, it's just
that I've got bad luck when it comes to thinking.
This patch makes the installer create the values in the
right location. Where now...? you'd better don't ask.
/me goes for a brown paper bag.
Change-Id: I792ba5e9a78a895d3df7dfc48d1fc7c5303ce28e
Reviewed-on: https://gerrit.libreoffice.org/5587
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
