using
git grep -lwP "Color\s*\(\s*(COL_\w+)\s*\)"
| xargs perl -pi -e "s/Color\s*\(\s*(COL_\w+)\s*\)//g"
and then some manual fixup where the resulting expression no longer
compiled
Change-Id: I0e268d78611c3be40bba9f60ecfdc087a36c0df4
Reviewed-on: https://gerrit.libreoffice.org/50372
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Moved struct FltCallDialogParameter to svtools/inc as this struct is
used only in the files located there . A separate header file is made
named FltCallDialogParameter.hxx which has this struct and appropriate
modification are done to the inclusion of header files in each file.
Change-Id: I60326b58fcbbb9c34abdb7c3de48667268b5d5e5
Reviewed-on: https://gerrit.libreoffice.org/50265
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Extend vcl::PDFExtOutDevData so that it's possible to use it outside the
PDF export; this way the EPUB export can know which chapters start on
which page.
This means fixed and reflowable layout has the same table of contents,
instead of just Page <N> in the fixed layout case.
Change-Id: I935fb23c66ec747431b91e83b0e677d4e5f704b9
Reviewed-on: https://gerrit.libreoffice.org/48332
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: Ide9e7c53b554f0a36e2078a8823f5ef6fb5cc8fa
Insert constructor everywhere, except a couple places that apparently
want to compare GetMapUnit().
Change-Id: I1910deb60562e5e949203435e827057f70a3f988
That was a dead end anyway, trying to partly reimplement
SvFilterOptionsDialog ExportDialog, instead of implementing the
necessary bits to use that one which has everything.
Change-Id: Icde7422f2c2d7e26c07dfe921a4abda41e222b09
Reviewed-on: https://gerrit.libreoffice.org/42503
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
With all bells and whistles, instead of the crude size/dpi JPG dialog
even for PNG.
Change-Id: I695a78643e07900822ec9253ac818efd52339cc0
Reviewed-on: https://gerrit.libreoffice.org/42498
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
... and not the crude JPG ones.
The com.sun.star.svtools.SvFilterOptionsDialog service has all we need,
so teach it to cope with non-Graphics source documents and let
ExportDialog handle that as well, just the actual rendering needs to go
via GraphicExportFilter (and effectively DocumentToGraphicRenderer), so
don't let that overwrite the properties set by the filter dialog.
Switching to the dialog then is just a matter of changing the
UIComponent in filter/source/config/fragments/filters/calc_png_Export
The same mechanism probably could be used by Writer as well by adjusting
filter/source/config/fragments/filters/writer_png_Export.xcu and maybe
filter/source/config/fragments/filters/writer_jpg_Export.xcu
in which case the GraphicExportOptionsDialog likely would be moot
then.
Also, it looks like a
filter/source/config/fragments/filters/calc_jpg_Export.xcu
(which doesn't exist yet) could be possible using the same mechanism.
Change-Id: I1fb9b33a6490dc39d7591b2b5913be182bb820e5
Reviewed-on: https://gerrit.libreoffice.org/42421
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
and simplify some of the calculations that needed to be changed.
Which resulted in one unit test needing to change by one pixel,
let's hope not an indication of a real problem.
Change-Id: Ie56434f35f4e58d21ee6f671392e93dc7542fca3
Reviewed-on: https://gerrit.libreoffice.org/42240
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This whole concept of "use a JPG dialog for PNG export" is nonsense anyway,
but.. as long as there isn't anything better at least have sensible defaults.
Change-Id: I0c074f7bb2989122aed039c739fd1813f371cbca
The SelectionOnly property from the export file dialog was not passed down from
GraphicExportFilter::filter() to DocumentToGraphicRenderer so that always
passed a component model instead of a selection object to the implementation of
XRenderable (getRendererCount(), getRenderer(), render())
Also have GraphicExportDialog consider the selection so the
DocumentToGraphicRenderer at its GraphicExportOptionsDialog calls XRenderable
the same.
Change-Id: I976bf16cf87cf5ca2678bdba7adfaf61c2063168
Reviewed-on: https://gerrit.libreoffice.org/40380
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
* 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
When user save the selected image in a non-vector format the filter
dialog used in Draw pops up for filter setting.
Change-Id: Ic98b48a47322e807627b7a2ccd8044ec0db30efc
Reviewed-on: https://gerrit.libreoffice.org/40223
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>
change various ResId classes that use conversion operator to OUString to
functions that return a OUString
drop various defines
drop unnecessary toString calls
Change-Id: Ibeccdf2b91a46a2ed5b4b74e6024e301a023bc92
Reviewed-on: https://gerrit.libreoffice.org/37817
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I left a prefix on the names "Map" so that I would not have to re-arrange
each name too much, since I can't start identifiers with digits like "100thMM"
And remove RSC_EXTRAMAPUNIT, which doesn't seem to be doing anything anymore.
Change-Id: I5187824aa87e30caf5357b51b5384b5ab919d224
Reviewed-on: https://gerrit.libreoffice.org/29096
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which was introduced with 3ead3ad52f "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
The issue of 362d4f0cd4 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
Noel Grandin