The method only gets called from AccessBridgeUpdateOldTopWindows
which always passes a non-null window.
Change-Id: I7d6d4effb75c722af6176257b8f296b5a77734cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177880
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Application::GetTopWindow also takes a tools::Long param,
so there's no reason to cast to sal_uInt16.
Change-Id: Ic592262bee8173329986ccb83298a26deb3586b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177879
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This was using a weak reference when the comment
was added in
commit 9b34eb7c85
Author: Frank Schönheit <fs@openoffice.org>
Date: Thu Apr 25 10:24:33 2002 +0000
#98750# be an XEventListener at the AccessibleContext
, but later changed to be a hard reference in
commit 23d689d4e4
Author: Thomas Benisch <tbe@openoffice.org>
Date: Thu Nov 7 16:19:24 2002 +0000
#103674# change the reference to the accessible context from weak to hard
. Unfortunately that commit only references a StarDivision
internal ticket, so the exact reason remains unclear,
but at least update the comment.
Change-Id: Icdc9aec97647ae05ae7fb3f2bdc1be43c3a62619
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177848
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
follow up for f5ebf512ccd3d5ae3af5fe706b411a85fa19182d
now same actions are performed on all the dialogs
Change-Id: I6531a766327dda106770a2c513ebd492dea7c655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176933
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 2fba6df7242586870988b62909156538b42c2bc0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177892
Tested-by: Jenkins
It turns out the majority of getCommandValues() return values specify a
commandName and a commandValues key, which is helpful when we don't
track the request for this reply.
Fix .uno:Signature to do the same for consistency.
Change-Id: I46ffe5c36047ef2b59113d0221a1874ba28d335b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177857
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
which causes problems on export to docx. Sanitize at the original
import.
Change-Id: I3b5521dac6a2b6926db6362d33500b11f0a69098
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177869
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
but still has the same problem as the gtk3 iconview with reporting
positions when scrolled
a problem since:
commit a36a58933a
CommitDate: Wed Dec 4 07:40:30 2024 +0100
sd: convert sidebar masterpage panels from drawingview to iconview
Change-Id: Ice549b40d88c5d2063e37ccb63490e3537736d39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177855
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
A crash was reported in HasOnlyOneListener, with the following call stack:
ntdll.dll!KiUserExceptionDispatch()
swlo.dll!SwModify::HasOnlyOneListener() Line 204
swlo.dll!SwFormatField::~SwFormatField() Line 142
swlo.dll!SwHistorySetTextField::`scalar deleting destructor'(unsigned int)
swlo.dll!std::default_delete<SwHistoryHint>::operator()(SwHistoryHint *) Line 3090
swlo.dll!std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>::{dtor}() Line 3198
swlo.dll!std::destroy_at(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * const) Line 311
swlo.dll!std::_Default_allocator_traits<std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::destroy(std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>> &) Line 688
swlo.dll!std::_Destroy_range(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * _First, std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * const) Line 905
swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::_Destroy(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * _Last, std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> *) Line 1667
swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::_Tidy() Line 1751
swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::~vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>() Line 699
swlo.dll!SwUndoSaveContent::~SwUndoSaveContent() Line 740
swlo.dll!SwUndoDelete::~SwUndoDelete() Line 633
swlo.dll!SwUndoDelete::`scalar deleting destructor'(unsigned int)
svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
svllo.dll!std::destroy_at(MarkedUndoAction * const) Line 311
svllo.dll!std::_Default_allocator_traits<std::allocator<MarkedUndoAction>>::destroy(std::allocator<MarkedUndoAction> &) Line 688
svllo.dll!std::_Destroy_range(MarkedUndoAction * _First, MarkedUndoAction * const) Line 905
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Destroy(MarkedUndoAction * _Last, MarkedUndoAction *) Line 1667
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Tidy() Line 1751
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::~vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>() Line 699
svllo.dll!SfxUndoArray::{dtor}() Line 1389
svllo.dll!SfxListUndoAction::~SfxListUndoAction() Line 1318
svllo.dll!SfxListUndoAction::`vector deleting destructor'(unsigned int)
svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
svllo.dll!std::destroy_at(MarkedUndoAction * const) Line 311
svllo.dll!std::_Default_allocator_traits<std::allocator<MarkedUndoAction>>::destroy(std::allocator<MarkedUndoAction> &) Line 688
svllo.dll!std::_Destroy_range(MarkedUndoAction * _First, MarkedUndoAction * const) Line 905
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Destroy(MarkedUndoAction * _Last, MarkedUndoAction *) Line 1667
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Tidy() Line 1751
svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::~vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>() Line 699
svllo.dll!SfxUndoArray::{dtor}() Line 1389
svllo.dll!SfxListUndoAction::~SfxListUndoAction() Line 1318
svllo.dll!SfxListUndoAction::`vector deleting destructor'(unsigned int)
svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
svllo.dll!std::destroy_at(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * const) Line 311
svllo.dll!std::_Default_allocator_traits<std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::destroy(std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>> &) Line 688
svllo.dll!std::_Destroy_range(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * _First, std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * const) Line 905
svllo.dll!std::vector<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>,std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::_Destroy(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * _Last, std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> *) Line 1667
svllo.dll!std::vector<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>,std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::clear() Line 1442
svllo.dll!svl::undo::impl::UndoManagerGuard::~UndoManagerGuard() Line 325
svllo.dll!SfxUndoManager::ImplClearRedo_NoLock(const bool i_currentLevel) Line 468
swlo.dll!sw::DocumentContentOperationsManager::InsertPoolItem(const SwPaM & rRg, const SfxPoolItem & rHt, const SetAttrMode nFlags, const SwRootFrame * pLayout, SwTextAttr * * ppNewTextAttr) Line 3694
swlo.dll!SwXTextField::attach(const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> & xTextRange) Line 1972
swlo.dll!SwXText::insertTextContent(const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> & xRange, const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextContent> & xContent, unsigned char bAbsorb) Line 606
mscx_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 214
mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 430
binaryurplo.dll!binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny * returnValue, std::vector<binaryurp::BinaryAny,std::allocator<binaryurp::BinaryAny>> * outArguments) Line 239
binaryurplo.dll!binaryurp::IncomingRequest::execute() Line 79
binaryurplo.dll!request(void * pThreadSpecificData) Line 84
cppu3.dll!cppu_threadpool::JobQueue::enter(const void * nDisposeId, bool bReturnWhenNoJob) Line 101
cppu3.dll!cppu_threadpool::ORequestThread::run() Line 169
cppu3.dll!threadFunc(void * param) Line 190
sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67
I don't know why pType->Which() succeeded before the broadcast and reset,
and pType->HasOnlyOneListener() crashed; field destructors themselves do
not seem to destroy their types (except SwDBField, which is handled here
explicitly). My blind guess is, that a change could happen in broadcast.
Change-Id: I5c7f07da2e1283510bce3a3e3e80b6f8d849f38b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177854
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
no need to copy things to a std::deque, it is quite straightforward to
just iterate over the SwNodes structure.
Shaves off about 30% of the time spent processing post-load.
Change-Id: I852079c18738299be04cec52b82e0f6949f2d81c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177837
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
The option also affects hyphen and the label should reflect this
Change-Id: I5e092f8c5d67c1c039de709d024c89481b40a82d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177841
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Previously, Writer was not correctly terminating layout contexts at the
starts of small caps spans. This could cause incorrect character
placement in certain cases.
Regression since:
Commit 30d376fb7d
"tdf#61444 Correct Writer text layout across formatting changes"
and
Commit ab0a4543ca
"tdf#124116 Correct Writer text shaping across formatting changes"
Change-Id: I863b9b66356eb0a9efb5bbdc75e80b43d56aaaf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177839
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
In QtInstanceWidget, connect to the QApplication::focusChanged
signal [1] and when either the old or the new focus widget
is the one belonging to this QtInstanceWidget, notify
about the lost/gained focus.
With this in place, SvxSearchDialog::FocusHdl_Impl
now gets called in a WIP branch where support for the
"Find and Replace" dialog is declared when moving
focus into one of the comboboxes in that dialog.
[1] https://doc.qt.io/qt-6/qapplication.html#focusChanged
Change-Id: I15190cf9b0d2e72d78a57f58da7ff2ebd1e7a6d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177835
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to what already exists in most subclasses,
add signal_<event_name> methods to call the handlers
and use these in the subclasses instead of calling
the handlers directly.
Change-Id: I6b79ddd859b360e947d97ada57f1573a276d6177
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177834
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Also add Q_OBJECT macros for all subclasses
that didn't have them and run moc for them, too.
Change-Id: Ia42ee7d02b68d54df308d33c88bf286468bfa68f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177833
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This e.g. gets called when pressing the "Find Next" button
in the "Find and Replace" dialog.
Change-Id: I30e33d52d19b0afe44564486bfa79e3b500ae856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177832
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As the comment for weld::ComboBox::connect_changed
(in vcl/include/weld.hxx) says:
/* m_aChangeHdl is called when the active item is changed. The can be due
to the user selecting a different item from the list or while typing
into the entry of a combo box with an entry.
Use changed_by_direct_pick() to discover whether an item was actually explicitly
selected, e.g. from the menu.
*/
void connect_changed(const Link<ComboBox&, void>& rLink) { m_aChangeHdl = rLink; }
QComboBox::currentIndexChanged is not emitted while
typing in an editable combobox, so connect to the
QComboBox::editTextChanged signal in addition.
Also, hold the SolarMutex when calling the signal handler.
QtInstanceComboBox::changed_by_direct_pick isn't implemented
yet, but would trigger an assert when called, so this doesn't
go unnoticed at least.
Witht this commit in change, typing in the "Find"
combobox in the "Find and Replace" dialog in a WIP
branch declaring support for that dialog now results
in the buttons getting enabled or disabled as expected
(disabled when text is empty, enabled when non-empty).
Change-Id: I9b89b3a3c8b5ed7ebdeda7b486bdbf2f7e54fd86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177831
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Not doing so would e.g. trigger an assert when
toggling the "Match case" checkbox in the "Find and Replace"
dialog in a WIP branch where support for that dialog with
native widgets is declared.
Change-Id: I5dc95e81e81bceaf258ecba6e55dfa280dfdd572
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177830
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reuse the logic previously implemented in
QtInstanceEntry::set_message_type by moving it to a
static helper method that takes a QLineEdit* param,
and for QtInstanceComboBox::set_entry_message_type,
pass the combo box's line edit.
Change-Id: I8e81c9473da294d2a8c863ed143d735c30ade2a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177829
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Map to/from what looks like the corresponding QWidget
equivalents.
No explicit testing done.
Change-Id: I47152c8789223372c49ea60f774d0a04a64db2b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177828
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Used e.g. by the "Find and Replace" dialog (Ctrl+H).
Change-Id: Ie181eea1600616ddb6a8044864df221ac4bb108d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177826
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Not relying on rData.pCellTransfer anymore since it is always null
when rEvt.mbLeaving is true.
Change-Id: I4755e8f9b62efacd2eb4d515e1993578beadef09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175970
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Clip stroke paths coming from the PDF import.
Similar to my previous patches for fills.
(It's possible we might have to do something clever with cropping
of arrows/etc but not sure yet)
Change-Id: I9e46deac4a722e3ac510f0cc4bdb6b38b67c579e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176952
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
... instead of using the toolkit/UNO wrapper class
VCLXCheckBox.
Change-Id: I271535f3e2e46202e2ca3d2e3f9a1d05ac380c41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177815
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... instead of using the toolkit/UNO wrapper
SVTXNumericField.
Change-Id: I86e274a06f210e2076e287087a1d4b979abe7c35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177814
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Use the vcl::Window for the null check instead of the
corresponding VCLXWindow. There's no need to
use a toolkit class here, in particular since the
vcl::Window is used later anyway.
Change-Id: Ia2c80f9634eadf33601af8c9ea1f628e7ea3e96b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177813
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Other than most of the a11y implementations for vcl
classes, VCLXAccessiblePopupMenu etc. do not
make use of any VCLXWindow (i.e. UNO/toolkit wrapper of a
vcl::Window) and thus do not depend on the toolkit
module, which the accessibility module depends on.
Therefore, there's also no need to use the accessible
factory to create them (which is needed when toolkit
classes are involved to avoid a dependency cycle).
Move those classes from the accessibility module to
vcl and add a new method Menu::CreateAccessible and
move the logic from AccessibleFactory::createAccessible
there. Drop the now unnecessary factory methods
previously used for those classes.
No change in behavior intended (yet), but this
also simplifies the code involved for the
tdf#164093 scenario.
Change-Id: Ie3f6f1a02bf6662206d31383473cdc868e1f9164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177812
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move helpers to convert between the Rectangle, Point and Size
classes in vcl and in css::awt from VCLUnoHelper (in the toolkit module)
to vcl::unohelper (in the vcl module), for reuse in vcl in upcoming
commits.
Change-Id: I7b11c8a6b8c843a01ce25b1e4c0fb1869ad1e6ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177816
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... so these constants can be reused in vcl.
See commit message of
Change-Id: I6aeee104f271c804c85727002822b89a9263628f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Dec 4 11:45:44 2024 +0100
a11y: Move CharacterAttributeshelper from accessibility to vcl
for motivation.
Change-Id: I1552c0a0111c81643ab9bb6f202c8a31662251d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177811
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is in preparation of moving more from
the accessibility module to vcl.
Currently, the a11y implementations for vcl widgets
are implemented in the accessibility module (in
directory of the same name), which in turn depends
on the toolkit module.
To break the dependency cycle (vcl needs accessibility
to create a11y objects for its widgets), there's a UNO
service.
At least some a11y classes don't really need toolkit,
however, so the plan is to decouple this and move those
from the accessibility module into vcl in upcoming
commits.
Change-Id: I6aeee104f271c804c85727002822b89a9263628f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177810
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This method from the unpublished XAccessibleExtendedComponent
interface is not used by any of the a11y platform bridges, and
I don't know of any platform a11y API that would need it.
In order to report character/font attributes, there is the
XAccessibleText interface and its
XAccessiText::getCharacterAttributes method instead, which
actually gets used by the platform a11y bridges.
Therefore, drop this method to simplify code, and also decouple
the accessibility module a bit further from the toolkit
module without having to reorganize code further.
(VCLXFont from the toolkit module currently gets used in
various implementations.)
Change-Id: I06ea3cc5998a13927b3f869877b28f03ac07c89b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177809
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Pass arguments right away in ctor rather than
having a ctor that takes no arguments and then
having to call VCLXFont::Init with the arguments
right after calling the ctor.
Change-Id: I651e27154499f61638409377438f9589bc7412a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177795
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
To make it easier to see the modifications I want to do to improve
performance here.
Change-Id: Icbb663b39905ce0fe82544bac7afd21314d4c7c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177801
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The call sites are actually passing in transparency, in fact to be
consistent with current conventions we are actually dealing with alpha
values. So we need to take the transparent values at the call sites and
convert to alpha values by just subtracting 255. Hence fixing the FIXME
comment.
Change-Id: Ibc55ea77f469ec8afcab0cc26d2b8cdf25ea8a72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173858
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
to make it easier to read
Change-Id: Ifaece90d4fb18be3caae9fd4afbbbdf64ff9d18a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177800
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
