| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I0507dd797cd5a35e0ae14f4b69ee4e172d08a71a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105681
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
instead of a mix of unsigned and sal_uInt16.
Change-Id: Ice56d58d22856daa6645577610368ba19a849176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104076
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ide75232858599c275e023c2300201090acd22307
Reviewed-on: https://gerrit.libreoffice.org/63237
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
which seem to have snuck back in since the great rounds of removals.
Change-Id: I85f7f5f4801c0b48dae8b50f51f83595b286d6a1
Reviewed-on: https://gerrit.libreoffice.org/62229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This does not fix the root cause of this problem, which is simply that
the document has a bazillion style sheets. Either the program which
exported this document is broken, or our importer is not correctly de-
duplicating the imported stylesheets.
Anyhow, I made performance improvements until I realised that it was
simply going to be impossible to display that many stylesheets in our
UI.
But still, this bug was useful in flushing out some performance issues.
The improvements, in order of decreasing importance are:
(*) Use SfxStyleSheetIterator in SvxStyleToolBoxControl::FillStyleBox to
avoid an O(n^2) situation where the pool repeatedly marks all the
stylesheets as not-used, and then walks the document finding out if a
stylesheet is used. Which is a waste of time because we're searching the
documents pool, so of course they are all used.
(*) Add a virtual method to avoid dynamic_cast
(*) return raw pointers instead of returning rtl::Reference by value to
avoid unnecessary reference counting.
SfxStyleSheetIterator
Change-Id: I15ff9c1846d3ed3e6f5655fa44c762f7619d547a
Reviewed-on: https://gerrit.libreoffice.org/55751
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
no need to explicitly specify it anymore
Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec
Reviewed-on: https://gerrit.libreoffice.org/43567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* 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
|
|
Change-Id: I57f03fc43aff838c7066556319a3a5a187e46ad3
Reviewed-on: https://gerrit.libreoffice.org/35831
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I039f8ff491b42ea9c3936bf13922df8095434228
|