Move the ScreenShotEntry class and ScreenShotCollection
typedef out of weld.hxx into an own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I3a040759e2ae6cd056613c598062e9716ee04649
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205888
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of having a purely virtual weld::Window::GetLOKNotifier
and dummy implementations returning nullptr in all subclasses
except the vcl/SalInstanceWindow one, have a dummy implementation
right in the abstract weld::Window base class, which reduces
duplication.
Change-Id: Ice3a24f40f0108cd58c735dffe8a509b3d45fe66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205879
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
LOK_HELP_URL, LO_CERTIFICATE_DATABASE_PATH, DEEPL_API_URL
and DEEPL_AUTH_KEY are never used internally
Change-Id: I995768a7ecd4b56b249dee261574e6709cd5f639
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205890
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* Update helpcontent2 from branch 'master'
to a2ce42584cae2413c0546836adaa033ab0a8c442
- Make the right string translatable
Change-Id: If49f8e1e70ab62d6538d1b58b57564bdb816d32f
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/205856
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins
It is not only tabstops that cancel a bTmpDummy,
so just use the consistent check to see if it is still bTmpDummy.
I also took the opportunity to prevent some minor processing,
which I also find a bit easier to code-read.
&= doesn't evaluate bTmpDummy first. In this case there is no point
in evaluating the other statements if bTmpDummy is already false.
Change-Id: Iea903960a98937ff5616d72981d3b380cc5429e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205884
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
* Update translations from branch 'master'
to f2dd6916c8c5247a4cc77ec6f85df6fe65f580f5
- update translations for master
and force-fix errors using pocheck
Change-Id: I24d08bb3ba5ff922531b237381bd7982fc6822e2
* Update translations from branch 'master'
to 336f42de3fd1bbbe92651da99dbb04b3085a6f45
- fix sl build breaker, msgfmt enforces newline to match at start/end
it is a fatal build breaker if the translated string doesn't match the
source string with respect to starting / ending newline.
Change-Id: I70ba38ee8c884b90a6bb96c25356f969002109bb
Reviewed-on: https://gerrit.libreoffice.org/c/translations/+/205867
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Always paint text even for zero-width glyphs (combining diacritics) by
calling SwTextPortion::Paint() which already handles zero width. Adding
the additional check improves the readability of the change.
Change-Id: Ib4044a31c8f1999b15e0fc71f457243e642ad86d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205713
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
Use a weld::TreeView inset of the custom ValueSet widget
for the SvtLineListBox that can be used to select a line
style.
Show the name of the line style in a column next to the
icon, which makes this more consistent with the popup used
to set a line style for Calc cells in the "Properties"
sidebar deck, section "Cell Appearance".
Using weld::TreeView also helps to be more consistent with
other platform/toolkit widgets and reduces use of custom
widget logic (implemented in the ValueSet class).
Some notes:
* ValueSet uses a 1-based ID for its items. weld::TreeView
uses a 0-based index, so adjust places using those
accordingly.
* Use the weld::TreeView handler for item activation
(set with weld::TreeView::connect_item_activated) instead
of the ValueSet selection handler (set with
ValueSet::SetSelectHdl) and activate single-click activation
(using the GtkTreeView::activate-on-single-click property
in the UI file) so that a single click on an item still activates
it but keyboard navigation using the arrow keys doesn't.
SvtLineListBox gets used e.g. in the control to pick the line style
in Writer's "Format" -> "Page Style" dialog, tab "Borders".
Adjust a UI test accordingly (use TreeView widget, use
new 0-based indices and press the Return key after selection,
to activate selected entry).
Change-Id: I54fb1d2a49774c6c64eda0ad5de7af36c3603cee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205821
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
ID and position are not specific to IconView but
apply for the SvTreeListBox base class just the same.
Move the logic to set those properties in the UI test
to the TreeListUIObject base class, so it can be reused
for SvTreeListBox/weld::TreeView tests in an upcoming
commit.
Change-Id: Ia6f27e714cebfe6a6cdc1bf0558c50ff09e41757
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205840
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
No longer use the underlying integer value for the
SvxBorderLineStyle enum values for the ID of the
ValueSet items in SvtLineListBox.
Instead, use the usual approach of using a 1-based
index and use/determine that index as needed to
find the corresponding enum value/item ID.
This avoids casting and prepares for an upcoming
commit that will port away from using ValueSet
to use weld::TreeView instead.
SvtLineListBox gets used e.g. in the control to pick the line style
in Writer's "Format" -> "Page Style" dialog, tab "Borders".
Adjust a UI test accordingly to use the new item IDs.
Change-Id: I754e2b399643003c9f06ab6b3b34c3ad021f2b95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205820
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Jun Nogata pointed out in Weblate 4 years ago that this badly written
description made it seem like the option had the reverse effect of
making the grid square, when in fact enabling it adds a ruby line.
Change-Id: I34d71f7dfbcfc38e1e4ada2d210298c1ff68f1b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205857
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
+ change testList QA test accordingly
TODO: in this commit we always use ordered list (since it's the example of the bugtracker)
but we should find the way to know if we must use ordered or unordered list.
Change-Id: Ibcc5281a1fae869808af7054128e412a18bec3e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205853
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Update the title and text of this infobar to be more concise and
user-friendly. "You are using generic controls!" is replaced with a
more neutral statement, and the recommendation is clarified to explicitly
mention a "desktop environment integration package", which may
help users who inadvertently forgot to add a missing dependency.
Follow-up to 999e18ad24
Change-Id: I9629b55dfa833a360f4569aa944dcabd2f433cde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205844
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
SwFlyAtContentFrame::SetAbsPos() changes the position of a fly by
converting the absolute position into a relative position. In order to
perform this calculation for flys anchored to an RTL frame, the width of
the fly is required.
Using handles to resize a fly may require a position change in addition
to a size change. SwFlyAtContentFrame::SetAbsPos() is used to apply this
position change. Unfortunately, though, during the resize the fly frame
area size is invalid. SwFlyAtContentFrame::SetAbsPos() was using this
invalid frame size to calculate the new relative position, causing
strange behavior for RTL-anchored flys.
Change-Id: Ie54d488c295cfa0a0585ec4cdbacea187be6f8f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205845
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Recalculate visible area when hiding whitespace since pages become more
compact and the number of pages change.
Change-Id: Ie6e411a61d57d722eb998e1e2d1a853a43a7d2a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205833
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
When importing OOXML math formulas, encloseOrEscapeLiteral() quoted
every delimiter character, including standard math operators like =, -,
and +. StarMath then rendered them as text-font glyphs instead of
math-font operators. This caused the equals sign to misalign with the
fraction bar and the minus sign to render as a shorter text hyphen.
Skip quoting for single-character standard math operators (+, -, *, /,
=, <, >) so StarMath treats them as proper operators with correct glyph
selection and alignment.
A bare operator alone inside braces (e.g. rsup {+}) is a StarMath parse
error because the parser expects an operand. Add a safety re-quote in
readOMathArgInElement() for that case, since all its callers wrap the
result in {...}
Change-Id: I22f01a25212d3c030e8104a00418ab1f6bdb2d07
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3329
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit f2ccbc5a30dbac56b600747af655076d6f7058c2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205823
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* gla11y-conform
* consistent IDs (gd*/lb* and btn*/bx*)
* consistent layout with grids
* defined spacing of 3px
* defined margins of 6px
* category labels
* redundant Insert sections from Home and Forms from Tools removed
* customization of Notebookbars removed since the new position
of commands is not properly found
Change-Id: I9b08211f1cba76942fb827702a5c99913dfd6f0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205443
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Entering =TRANSPOSE(...) (or any other auto expanded matrix formula)
over a range with a blocker correctly produced #SPILL!, but deleting
the blocker afterwards left the matrix stuck. Only formulas using a
dynamic array function (UNIQUE, SEQUENCE, ...) auto-resolved.
Use the same "spill and auto resolve" path for both kinds: any
formula that entered with the auto-expand spill check now keeps
re-evaluating its spill state on subsequent recalculation,
regardless of whether it uses a dynamic array function.
Conventional matrix where the user explicitly picked the range are
unaffected.
Change-Id: I0a9d214a2edfdad99856649289e439057a400374
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2867
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 679de09609c5da17a44ef34daa73d0380c0c7d37)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205805
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Typing =SEQUENCE(4) (or any other dynamic array function) over a
range with a blocker in it correctly produced #SPILL!, but
deleting the blocker afterwards left the matrix stuck in #SPILL!.
The auto expanded entry path used a sticky error and never
registered the cell for spill resolution.
Switch the dynamic array case to a re-evaluable spill state so a
later cell change operation reconciles it. Conventional array
formulas keep the old sticky behaviour (for now).
Factor out the shared "mark this master as spilled" sequence into
MarkAsSpilled method, reused from the cached-spill XLSX/ODS import
path.
Change-Id: I437c516c1ad810e1c38bf6de742bc124933e8fa9
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2866
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 66927439f3bb0bcee0ace74ec90f70c0b821e5d1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205804
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Make the spill state of a dynamic array survive a saveAndReload
to XLSX and make the XLSX be properly accepted by MSO. There is a
special way, with dynamic array extension to the format, which
must be written to the file.
Export:
- Emit xl/metadata.xml with an XLDAPR dynamicArrayProperties block,
and register it in [Content_Types].xml and workbook rels.
- Mark the master cell with cm="1" and write aca="1" + ca="1" on f.
A 1x1 collapsed master is written as a single cell reference.
- Map the SPILL cell error to "#VALUE!", since OOXML has no #SPILL!
literal. Recalc on reload reclassifies it back to SPILL.
Import:
- Remember "cm" on the cell. A cached "#VALUE!" on an array master
with "cm" set is treated as a SPILL hint so the blocker survives.
Extend the XLSX round-trip tests in subsequent_export_test2.
Change-Id: I9209e43f3a398e23fc7ca46daf58a88546687dba
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2865
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit eb85edc75e5100beb7802381175de914f4102a81)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205803
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Xisco Fauli