I think I managed to disable this when I converted it to
use the shared plugin infrastructure.
So fix that, and then make it much smarter to avoid various
false positives.
Change-Id: I0a4657cff3b40a00434924bf764d024dbfd7d5b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176646
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Enable UI color customization via an extension. This patch doesn't
include any UI changes as that needs to be discussed with the community
first (ticket: https://bugs.documentfoundation.org/show_bug.cgi?id=163620)
Part 1.0 (this change) is responsible for loading all the ThemeColors
from the registry into a `static ThemeColors` object, which then is
accessed in various VCL_PLUGINS as a source for the application colors.
The user now has to go to the registry (expert configuration), and
enable the theme by setting "LibreofficeTheme" to "true". It can also be
enabled via an extension (demonstrated in the Theme Template).
`testGetViewRenderState` changes to "Dark" scheme which is not present.
Changes in this patch don't allow that and use 'Automatic' as the
fallback. This caused the unit test to fail. So the test was changed to
have "Dark" scheme before changing to it.
Theme Template: https://github.com/printfdebugging/libreoffice-theme-template
Project Report: https://printfdebugging.in/libreoffice/01-themes-gsoc-2024/
Change-Id: I5193d4d34fcd2f4c5d6f124a871bd5c7f14e95a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168016
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
When an optimized build of this branch is compiled on Silicon Mac,
a dynamic_cast from com.sun.star.awt.XPopupMenu to VCLXPopupMenu
will fail.
The pointer being casted has not been deleted and is an undeleted
instance yet dynamic_cast fails. However, a dynamic_cast to
VCLXPopupMenu's superclass VCLXMenu succeeds so cast to that class
instead.
Change-Id: Ie9ab79df109eece46351545a71325d1e37bde94d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175992
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
It controlled how the FilterConfigCache initialized, and also how
the unused aFilterPath was initialized. The FilterConfigCache is
reused, when there are other instances of GraphicFilter - so that
means, that the "bUseConfig" flag doesn't necessarily mean that
the initialization will happen as intended: the existing instance
could have been initialized using the other value.
Avoid this indeterministic behavior, and always use the config,
except in fuzzing. The VCL tests, that could possibly once depend
on that, now use config, so this is not an issue - and that means
testing the same thing as used in the working code, not something
different.
Change-Id: I6555dc47328b362e020138cf454f5ede7f39d063
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175894
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Align the order in which the focusable widgets (combobox, "Properties"
button) are defined in the .ui (XML) file with the order in which they
should receive focus. While the position in the GtkGrid is defined
by the "left-attach" and "top-attach" packing properties and
QtBuilder evaluates those, the tab order in Qt by default matches
the order in which widgets are created (s. e.g. [1]).
Without this commit in place the "properties" button was constructed
before the "name" combobox (because it was further up in
the .ui file, i.e. the XML parser processed it earlier), resulting
in an unexpected order when using the Tab key to navigate through
the "Tools" -> "Printer Settings" dialog:
From the "Options" button in the button box, focus would jump
to the "Properties" button, and only then to the combobox, and
from there, it would jump to the "Help" button in the button box.
Now, it jumps from the "Options" button to the combobox,
and after selecting the printer there, pressing Tab another
time moves focus to the "Properties" button as expected, which
can be used to open another dialog that allows to change properties
of the previously selected printer.
A potential alternative to adjusting the .ui file could be to
explicitly set the tab order using QWidget::setTabOrder [2]
in QtBuilder.
[1] https://doc.qt.io/qt-6/designer-tab-order.html
[2] https://doc.qt.io/qt-6/qwidget.html#setTabOrder
Change-Id: If3aa014e20b97fe8bb772ef212741af1433b0244
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175523
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This ctor is meant to set the value of nTime directly; and that value
is not nanoseconds, but an encoded value, using SEC_/MIN_/HOUR_MASK.
But in some places, this ctor was misused for setting of nanoseconds,
which would only accidentally work for values less than one second.
All places that initialized tools::Time with 0, now use EMPTY.
This makes the ctor private; and for the very few cases where really
the encoded value of nTime is stored / restored, fromEncodedTime is
introduced.
Change-Id: I1f1994bd9aab1b51a41b1de637619049fe820da4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175283
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When creating an export graphic,
the view options are changed to hide hidden stuff,
not show the formatting marks etc.
However, the user's view settings were not being restored
after the export was done.
Change-Id: I3e236e5ef47eddca487621c92ec639f7bac073de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175185
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Set the "use-underline" property for the buttons in the
"Restart %PRODUCTNAME" dialog and specify the accelerators.
This way, the dialog can easily be closed using Alt+[accelerator]
with the gtk3 and qt5/qt6 VCL plugin as well.
Use those characters that the VCL logic was using as well.
(The VCL implementation seems to have some way to auto-generate
mnemonic characters if none is set automatically.)
This dialog is e.g. seen when toggling experimental mode in
"Tools" -> "Options" and closing the options dialog with the
"OK" button.
Change-Id: I50c3402fb89d5fbfc0e610c0e41f5f035cf0b0e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175137
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When the selected item in a ValueSet changes,
only send an AccessibleEventId::ACTIVE_DESCENDANT_CHANGED
event for the newly selected item if the ValueSet itself
has focus, as the active descendant is the currently
active child of the current focus object.
This prevents incorrect events that e.g. broke Orca's
focus tracking and thus announcement of the current slide
in Impress when moving between slides in the "Slides" panel:
1) start Impress
2) select the "Beehive" presentation template
3) move focus to "Slides" panel
4) use up and down key to navigate between slides
Instead of saying "Slide 1" and "Slide 2" respectively,
Orca sometimes announced "Layout, list with 16 items", as
the 2 slides use a different layout, and thus switching
between slides implicitly leads to the selection of the
corresponding item in the "Layout" deck in the sidebar,
which resulted in a corresponding ACTIVE_DESCENDANT_CHANGED
event being sent prior to this commit, making Orca think
that that item received keyboard focus.
With this commit in place, Orca now announces "Slide 1"
and "Slide 2" according to the newly selected slide
in the "Slides" view.
Change-Id: I543a4c94bae75dede7274a8b35f183ccd2ac0515
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174342
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Commit 8872f7121b (crashtesting: crash
on exporting kde274105-6.docx to .rtf, 2024-03-27) added some safety
code in EmbeddedObjectRef::GetReplacement. It mentioned, that there
are likely some bugs in the management of the graphic.
This tries to fix this management, avoiding the intermediate states,
and only changing the graphic when all the data is ready. This also
reverts the changes of the mentioned commit, obsoleted now; and of
commit 8780fa41dc (svtools: fix lost
replacement grpahic when updating it via OLE fails, 2018-10-30);
but keeps commit 24231f2a33 (svtools:
fix lost replacement non-rendered graphic when updating it fails,
2022-02-17).
This has revealed that the second part of unit test for tdf#143222
("Check export of embedded worksheet in slide"), introduced in
commit 92a407b7f9 (tdf143222 Handle
alternate content of graphicData element., 2021-07-08), has never
really worked: the "pGraphic != nullptr" check would never fail;
in fact, that used to always return an empty graphic. The problem
was filed as tdf#163064, and the test was modified accordingly.
Commit 5d997c029e (sw XHTML export:
improve dummy OLE object handling, 2018-08-30) made ReqIF export
handle missing replacement graphic. However, it had assumed that
SwOLENode::GetGraphic always returns a valid pointer even for the
missing data. That is fixed here in OutHTML_FrameFormatOLENodeGrf.
Other places, where the pointer was dereferenced unconditionally,
were fixed (keeping current behavior).
Change-Id: Ica97a691ecc11b856bdb003f89467ea3392684bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173716
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit 8872f7121b (crashtesting: crash
on exporting kde274105-6.docx to .rtf, 2024-03-27) made sure to provide
a graphic in all cases, to avoid crashes revealed by crashtesting.
In commit f317746f55, I removed that.
This reinstates the safety measure for cases when there's no graphic
yet.
Change-Id: Ida3eecd5c7ccff087c2ca8b6076ca01b8a145adc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173697
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Connecting from an external Java process on Windows, and running a
code similar to this:
XComponent xComponent = xComponentLoader.loadComponentFromURL(url, "_default", FrameSearchFlag.ALL, args);
XTextEmbeddedObjectsSupplier textEmbeddedObjectSupplier = cast(XTextEmbeddedObjectsSupplier.class, xComponent);
XIndexAccess embeddedObjectsAccess = cast(XIndexAccess.class, textEmbeddedObjectSupplier.getEmbeddedObjects());
XEmbeddedObjectSupplier2 embeddedObjectSupplier = cast(XEmbeddedObjectSupplier2.class, embeddedObjectsAccess.getByIndex(0));
for (int i = 0; i < 100; i++)
{
XGraphic replacementGraphic = embeddedObjectSupplier.getReplacementGraphic();
String graphicStatus = replacementGraphic == null ? "missing" : "present";
System.out.println("The replacement graphic is: " + graphicStatus);
}
(when 'url' points to a file with OLE) could produce output like this:
The replacement graphic is: present
The replacement graphic is: present
The replacement graphic is: missing
... 94 more copies of "missing"
The replacement graphic is: missing
The replacement graphic is: present
The replacement graphic is: present
i.e., the replacement graphic suddenly disappears, and then re-appears.
This happens when some idle needs to update the replacement graphic,
e.g. when generating a thumbnail. This happened because the code in
EmbeddedObjectRef::GetReplacement cleared the graphic prior to calls
to OLE object's async methods to get the graphic stream.
The code does not depend on the current content of mpImpl->oGraphic,
so this change takes care to avoid this transient "no graphic" state.
Change-Id: Ia825185a6e9b749697209443ee5db187b5ddbd16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173690
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
of the current frame window. Creating the popup will grab focus
into the dropdown, making the embedded frame lose focus, so it considers
itself inactive (like right clicking in main frame area makes the
embedded frame lose focus), so for this embedded object in another frame
case make the original frame the active child of its parent after
the popup has been created.
Change-Id: Id6e12babcf4ebce05c297888b7b04756f2a12ccf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173624
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
so when scrolling through fonts that might not have the original or
explicitly picked style, then on moving to the next font that does have
that style, then the original bold/italic/etc gets picked again.
Change-Id: If818a116ed4ab248cb67f60845acad2cd4eeb8ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173071
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Using the same mechanism as with theme changes, we can avoid LOK getting
invalidations if we have an invert-background change that doesn't apply.
The trouble is that this method of inverting the background causes *lots
of* properties to change, so there's no single "If we inverted the
background" to check...
To get there, I've checked if all of the following are true
- We didn't change the color scheme
- We didn't have any new colors after this change
- All of the properties we were changing should have been within this
color scheme
While they don't necessarily mean "there was a background inversion",
they do mean "something changed in your theme but no action is needed
from you" - which should only be a background inversion - and if we
added anything else that could fit in that category, it should also
avoid LOK invalidations
Change-Id: Idb680d5241db7879d9be834268ab616848c1f165
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172505
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Fix to regression from I773793de8cfbdc0d23124db790604b93030375c2
* base color is now anchor, light/dark calculated as luminance
* default colors adjusted respectively
Change-Id: I9872a959d51714c736cd2adb216d76a0846aeec6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171753
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
* COL_AUTHOR<1..>_DARK/LIGHT/NORMAL removed Author1..9 added
* dark variants calculated from light with 50% brightness
* light does In/DecreaseLuminance(30) and dark (sd) resp. anchor (sw) In/DecreaseLuminance(80) depending on GetUseDarkMode()
* sw: font color depends on outline background, which now picks up DOCCOLOR; this does not work for dark colors in light mode, for example
* sd does not update on changes and requires a restart
Change-Id: I773793de8cfbdc0d23124db790604b93030375c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171523
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Context modified because the same strings are in svtools/uiconfig/ui/calendar.ui
Don't know at all if these could be merged.
Change-Id: I72e37b54b53e4717f513dd313757af7318bbc4f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170898
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
In various places, the code checks if we are running as a unit test or a
UI test. This code grew organically, and is most re-using environment
variables that were designed for narrower purposes.
Rather than being clever, just add two new explicit and simple
environment variables in the natural place (the command that runs them),
and check for those variables in the code.
Change-Id: Icce0997914fa0be30a5ac1f29bd870bdb5893a8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170618
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Make variable nHScrX have tools::Long data type as it is expected to be tools::Long when used in SetPostSizePixel
Change-Id: If7e0c1ee1a9832b215c766cbf8bf916c731edfd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167804
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Following
Change-Id: Id48f81deb05aee2026509037f7d14575735e5be0
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 10 14:49:03 2024 +0200
VCLUnoHelper: Align AWT <-> VCL helpers with convert.hxx impl
, port all uses of the helper functions defined in
`include/toolkit/helper/convert.hxx` to use the
`VCLUnoHelper` equivalents instead, to unify usage
and avoid duplication.
Drop `include/toolkit/helper/convert.hxx` now that
it's unused.
Change-Id: I22695a93e40e47bb2b14d191a2e0a4eb7c856895
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170317
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Noel Grandin