This patch makes the selected data series entry color in the chart
colors list be selected in the color table for SvxDefaultColorOptPage.
The color selection made in the color table could be from a different
palette than the original. The first palette in the list of palettes
that has a matching color is choosen.
I noticed when a color selected from the Material palette was set for a
data series color, the Tonal palette was shown when reselecting it. An
off by 1 index bug that causes the last palette in the list of
palettes to not be searched for the color was found.
Another thing I noticed is when a data series chart color was set to a
color in the Freecolour HCL palette that needed to be scrolled to see
it, it didn't do it. Commenting out mbScroll in the condition in the
SelectItem function that checks its value solved the problem. I don't
get the need for the ValueSet mbScroll variable. The only place its
value can change is in the Format function. That doesn't get called in
the SelectItem function unless mnCols is 0. The SelectItem function is
the only place its value is checked. I don't see a problem with always
checking if the visible area needs to be scrolled. This patch removes
the ValueSet mbScroll variable.
Change-Id: I1f05a3ad8a0b64b2a28d3001cace391379cc00c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193437
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Click Sidebar -> properties -> slide -> master view, then launch the
Slide -> Slide properties menu item, this adds a new Theme tab page
there.
This is just an initial UI, only the theme name can be edited as a
start.
Change-Id: Ia2faa828c57a0e858881fb8640431f046b5739a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126798
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
* 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
Up to now the screenshot creation was added/dependent of
target slowcheck. Since quite some modules have added screenshot
creations now, I added an own target 'screenshot' to allow to keep
current slowcheck and screenshot creation separated
Change-Id: I80a49a0db607edf8e0405672d570f624d29912e7
- this renames the 'almost' module target to non-l10n
- and adds a l10n target which is intended to only build l10n parts of
the product
- packagers should then be able to build l10n and non-l10n parts of the
product independently, thus:
- enable quicker rebuilds
- distribution of load
- updates to l10n without a full rebuild
- security fixes to binaries without rebuilding all l10n
- the new targets are called build-l10n-only and build-non-l10n-only
- note this is not intended to move a concept of split packages
upstream -- while this exsists in distros, the number of test
scenarios for this would explode upstream
Change-Id: Ib8ccc9bc52718d9b0ebbfee76ad93dc29c260863
Conflicts:
filter/Module_filter.mk
I plan to use it to deliver all */uiconfig files, not just .ui, as a
preliminary step to get rid of postprocess/packconfig.
Change-Id: Ie7b4434b2f247165e3ab69a4d0c193418720a149
Reviewed-on: https://gerrit.libreoffice.org/3225
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Jim Raykowski