Age | Commit message (Collapse) | Author | Files | Lines |
|
no idea why this only started warning now
Change-Id: I61c1de875c825a55d2ec41a358503354688183bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163933
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use existing rtl_ustr_ascii_compareIgnoreAsciiCase, instead of inventing
an own local comparison function.
And standardize on WM_SETTINGCHANGE, which is the same as WM_WININICHANGE.
Change-Id: Ifaf1f73066edf7d553174b529be5aa55179ae92e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163212
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I6abad4ab4ea357ab55ea97b8a0d39c453dffc249
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161493
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
German keyboard layout has number sign key.
Users can print number sign without using modification keys.
So this key can be assigned a shortcut.
Subscript is assigned to CTRL + NUMBERSIGN.
Below PR is used as reference when adding the new key handler:
https://gerrit.libreoffice.org/c/core/+/86713
Signed-off-by: Gökay Şatır <gokaysatir@collabora.com>
Change-Id: I340dc47764e9200d2477f8db740a629f62f48004
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157554
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 1db8f6d484b884301a7d3673f4d05478e28cd853)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157959
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5553138bfc8dd989e68b8bcc2be981746e8c1e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150783
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Icc24e0aaf1762e5b318b8364dd9fdb496edfb77c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150279
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ever since it was added in
commit 8229967979d96bd01e63e2954b7af35a57d9e08c
Date: Thu Sep 20 15:23:39 2007 +0000
INTEGRATION: CWS os2port01 (1.2.2); FILE ADDED
2006/11/29 14:34:20 ydario 1.2.2.1: Initial OS/2 import.
Change-Id: Ic1bbf9f9167f9a7146f3c7d18b6fdb69c1f44e0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150275
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I17978dbb100fbfa6f6ddbbbdf96872076bc2a289
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86713
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
to make it easier to find in profilers and debuggers
Change-Id: I8ce3ee0b89ca8498683367c2b39176edc571137b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142415
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which started to hit me now either due to building against a recent Visual
Studio 2022 Preview 17.4 (which would presumably no longer define those macros
in some system headers, so that the #ifndef's started to kick in now), or due to
building against a more recent Windows SDK (see below), no idea which.
But just dropping the seemingly unused macro definitions from the various .cxx
caused builds against old Windows SDK versions like Jenkins
<https://ci.libreoffice.org/job/gerrit_windows/139228/> to fail like
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(479): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(480): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(481): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(482): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(503): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(504): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(505): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(506): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(667): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(668): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(669): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(670): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(691): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(692): error C3861: 'max': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(693): error C3861: 'min': identifier not found
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um\GdiplusTypes.h(694): error C3861: 'min': identifier not found
[...]
> make[1]: *** [C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/solenv/gbuild/LinkTarget.mk:334: C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/workdir/CxxObject/vcl/win/app/salinst.o] Error 2
so move those macro definitions to prewin.h (where they don't trigger clang-cl's
-Werror,-Wunused-macros from within an include file, even if they happen to be
unused in a translation unit). (For simplicity, see whether it works in
practice to drop those #ifndef wrappers. If they turn out to be relevant for
some build scenarios after all, they can be added back.)
Change-Id: I76d8794ae2de310bdca420e5488db2bc19de23ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142090
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The previous call to SystemParametersInfoW with SPI_SETSCREENSAVEACTIVE
only prevented screen saver from running (which is not often used these
days), but screen was still turned off (and power saving was started).
Despite SetThreadExecutionState documentation [1] claims that it does
not stop the screen saver from executing, my experiments show that it
does (on my Windows 10). So just use it, because it is designed exactly
for this task (documentation discusses the presentation applications).
[1] https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadexecutionstate
Change-Id: I6eced8f0a7c17211a0b68851a40227eed9a22b1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141289
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If2460da367356ef04ca344542c2c82f8283c9e67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139935
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
the = key is } on a french keyboard,
so remap the
ctrl-alt-=
shortcuts to
ctrl-alt-}
which means the user gets to keep pressing keys in roughly the same
physical location for this action, regardless of keyboard
Change-Id: I03e251dacc1c19e543182a44ae23fde2a57cfa45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139474
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6b18a514358488ed8a03b42313c3986c2b3fc9df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132021
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ieb1035410c3c6c4b40ea779e829a940460d19b5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131922
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
If experimental mode is enabled and only for windows >= 10.0.18362
Toggling from dark to light mode is detected, and getting some
suitable colors for dark mode works.
The titlebar will toggle into dark/light mode successfully.
DrawThemeBackground does something sensible for buttons and scrollbar at
least, comboboxes can be forced to work. SpinButtons are less
successful. Menubar and toolbar just bodged to draw a solid backcolor.
Notebooks/TabControls don't respect the theme.
Its possible it makes more sense to not try and use the windows control
drawings apis and just set some dark colors and draw with the old
built-in vcl widget rendering or alternative.
Change-Id: Ic7927fb9af7ec94444d9de6e0204560e2789be46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131453
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
... by moving it into ImplCreate(DragSource|DropTarget).
The existing Create* variant now checks for headless mode and the
IsRunningUnitTest flag, before creating the platform variants.
There are two small helpers to initialize either X11 or Ole based
UNO DnD interace implementations.
Unfortunatly Windows requires to move two dtrans header files, but
at least any other changes are minimal.
Change-Id: Id79459ad71a26243b1c9cb1fe38ab236b0ab8fa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128049
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ifb40e7672671df03b5ffc89905ad1e7b68451b68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127232
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3e9c906a026e7455fb775d110eca32f8533614e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121836
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... and as a result drop setting a default in SalSvpInstance.
This is also more consistent: now you must explicitly implement
CreateOpenGLContext() and set "m_bSupportsOpenGL = true".
Change-Id: I591580bf134907213b8308e0843c278d2f470ed3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121632
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
... and get rid of the whole GetBackendCapabilities, which was
just overkill. Maybe this should even be some bitmap + enum
+ set/get function, but I'm too lazy...
In the end add a bool for the OpenGL support of the VCL plugin
(or maybe sticking it into ImplSVData, which is already some
catchall for common VCL data).
Change-Id: I9f0ececac482d8e2a94ef6024628e9631b49e773
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120760
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This reverts commit 57d122258437c0a14b303a8d961aa5e8f6f67f57.
Reason for revert:
As mentioned in https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getwindowrect,
> In conformance with conventions for the RECT structure, the bottom-
> right coordinates of the returned rectangle are exclusive. In other
> words, the pixel at (right, bottom) lies immediately outside the
> rectangle.
So it was incorrect change.
Change-Id: I2b29871a5d9b944ce2f9119edb2e87c53d9ae298
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117212
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The size was calculated wrong - it needed a "+1". But a rectangle
constructor taking L, T, R, and B is actually simpler.
Change-Id: I4152f9b43f0ae8f1829038645fcf83bae156c618
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117129
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
.. and convert Android to it. Will also be used by WASM.
It's also kind of a followup on commit
f5af2104fc490b90510e36bbf1d2adec8017c594.
Change-Id: I3a1b5bc2eae2692e706da10c6352534433c61e57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116385
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I132643eb73129e1319af36b7c8aac36a516714b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114896
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I41a8fa48b762d8f4da1c23785a86d651cfb4aa89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113851
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I49a01e9cae16a408c6be11fe0501f489c3db6e3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113438
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... after commit 6a6cd129f34220fadf5d134a2dc2c1e368acbc4f
Change-Id: I681fec2e801a02681f4f6722681832d7046e164f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113437
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
On Windows only, and only on a non-admin installation, check on application
startup whether the file formats ".ods", ".odt", and ".odp" are registered
to be opened by LibreOffice by default. If any of the formats are not
default, show a UI dialog informing the user which formats are not default
and ask the user to set the defaults. If the user selects "OK" to set
defaults then the Windows UI corresponding to the user's Windows version is
opened for selecting defaults per program. There is also a checkbox on the
dialog to select whether checking is performed on application startup.
Also, in Tools -> Options -> General, add a UI checkbox for performing this
check on application startup, and refactor the existing button "Windows
Default apps" to use the same Windows UI Launch APIs.
Change-Id: I5e7258d111ff7da8f68805e60405aec064ddcf7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112370
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Win32 API PeekMessage() actually may deliver events, despite
what the name may suggest, even with PM_NOREMOVE argument.
That means this is problematic for use in AnyInput(), as that
function should just check the event queue but not do anything
with it. Using GetQueueStatus() should solve the problem.
See https://lists.freedesktop.org/archives/libreoffice/2021-February/086788.html
for further details.
Change-Id: I10d3423f89f6f050534625110113dee60959f7a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110718
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
we end up trying to process a timer message, but from inside
the vcl de-init function, which means the timer stuff has already
been de-initialised.
Change-Id: I94703219754f1ccabd3065fc5ea437f39264197b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110397
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie9dab2d4813b986bf7eb4e2f7dee37171e9be9fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110162
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
While looking for some reason for multiple ABORTED Jenkins runs,
presumely due to unprocessed Idles, I found the ImplSalYield code
way too hard to follow, so this restructures the PeekMessage loop
and adds some better comments to make that easier.
We now bail out a bit earlier in m_nNoYieldLock mode and also
account for eventual tick wraps in single message mode, which
isn't needed, as we already just process one message, but it
removes additional conditions and further simplifies the code.
We also now explicitly report GetMessageW non-message return
codes.
Change-Id: Ibd745d5540dd9998570ece9aeb0d37886b627eb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110042
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ie36d7c4dfee5115b5909ed58a0b16b367e05866d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107734
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I91e5a469344ab951225e61237b462ed58ed796be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107733
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since "forever", SalAbort has been declared as non-exported in
vcl/inc/salinst.hxx and (only) called from Application::Abort
(vcl/source/app/svapp.cxx) in Library_vcl. Its various implementations for
different platforms have always been scattered across Library_vcl.
For Windows, SalAbort was originally implemented in vcl/win/app/salinst.cxx,
until 1698debed2993fc5f262aa3ebbdb32fc112ac556 "Implement Windows VCL backend as
plugin" introduced an incompatible implementation in vcl/win/app/salplug.cxx
(which was added to Library_vcl) and moved the original implementation in
vcl/win/app/salinst.cxx from Library_vcl to Library_vclplug_win, where it thus
became dead code (and where it now gets removed).
For macOS, SalAbort was originally implemented in vcl/osx/salinst.cxx, until
3af4e1a0825c5b11ae4ef58fc411378aab669387 "Implement MacOSX VCL backend as
plugin" introduced a different implementation in vcl/osx/salplug.cxx (which was
added to Library_vcl) and moved the original implementation in
vcl/osx/salinst.cxx from Library_vcl to Library_vclplug_win, where it thus
became dead code (and where it now gets removed).
(In 0f3be2e19fa408d7069d586ccf04cb3f3eccd6b9 "Unify sal plugin loaders", the---
identical---new implementations in vcl/osx/salinst.cxx and
vcl/win/app/salinst.cxx where then consolidated with other---also identical---
implementations in vcl/source/app/salplug.cxx.)
For macOS, the original, now removed implementation in vcl/osx/salinst.cxx and
the consolidated implementation in vcl/source/app/salplug.cxx only differed in
an added
CrashReporter::addKeyValue("AbortMessage", rErrorText, CrashReporter::Write);
which is presumably harmless to add.
But for Windows, the original, now removed implementation in
vcl/win/app/salinst.cxx differed substantially from the consolidated
implementation in vcl/source/app/salplug.cxx, which is updated here to reflect
those differences. The one thing that cannot easily be updated, though, is the
//TODO: ImplFreeSalGDI();
call, as ImplFreeSalGDI is defined in Library_vclplug_win. I'll thus leave
fixing that TODO for another commit (if calling ImplFreeSalGDI from SalAbort is
even necessary, given that it ends in FatalAppExitW anyway)---my gut feeling is
that the whole 1698debed2993fc5f262aa3ebbdb32fc112ac556 "Implement Windows VCL
backend as plugin" was somewhat misguided.
Change-Id: I641a3d7b1bc27ae14c38eb1ec0838bc04e4290d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107666
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I346cf6cf148cd3b4ac851f8c441d54c858f55935
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107674
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It is by now practically unmaintained, even bugreports in bugzilla
have been already closed for it. AFAICT this used to be really
used only on Windows, where it's no longer the default.
There's still some OpenGL code left, because there are still two
other places that use OpenGL. One is OpenGL slideshows, which
reuse some of the base OpenGL code (and I've checked they
still work even after this removal). Second one is OpenGL canvas,
which it seems has never been finished or enabled (or so it
most probably should be dumped too).
Change-Id: I7ea5aef77ec252eb8e712d167db591209be84a13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107290
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This reverts commit e9a16702ba025ca340bcded4fda37235d22410a1. My understanding
that the code was pointless was apparently wrong (the relevant part being hidden
in m_condition.wait() internally doing the call to MsgWaitForMultipleObjects;
I've improved the relevant comment now). (And my fears that the code using
osl::Condition might be broken by design were hopefully unfounded.)
Change-Id: Icb244ec9df8a2b0dacf115700ed850d471446f3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103310
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
|
|
The code had been introduced with 9c9970952b0adec4a8c6de9a4cd54d0980cd47ec
"tdf#96887 enhance SolarMutex AcquireWithWait for Windows", which mentions
MsgWaitForMultipleObjects in multiple comments as if it had intended to make use
of it somewhere, but no such use can be found in that commit.
(I had come across this code when on Windows some CppunitTest had
deadlocked for me during DeInitVCL when re-acquiring the released SolarMutex at
the end of
> #if defined _WIN32
> // See GetSystemClipboard (vcl/source/treelist/transfer2.cxx):
> if (auto const comp = css::uno::Reference<css::lang::XComponent>(
> pSVData->m_xSystemClipboard, css::uno::UNO_QUERY))
> {
> SolarMutexReleaser r; // unblock pending "clipboard content changed" notifications
> comp->dispose(); // will use CWinClipbImpl::s_aMutex
> }
> #endif
at vcl/source/app/svmain.cxx:490--498, and SalYieldMutex::doAcquire was waiting
in m_condition.wait() for an m_condition.set() from some other thread that would
never come---there were not even any other relevant threads left. At first I
thought this might be an issue with broken-by-design osl::Condition, where some
other, meanwhile gone thread's m_condition.set() had been cancelled by this
thread's m_condition.reset() in SalYieldMutex::doAcquire, but then its
m_aMutex.tryToAcquire() should probably have succeeded so that it wouldn't have
ended up in m_codition.wait(). But even if the use of m_condition might not be
broken after all and the deadlock I observed would be caused by something else,
it nevertheless looks pointless, so better clean it up.)
Change-Id: Ia6c1aa133c14e19224d0f24c810f43363cb5898c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103253
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As https://docs.microsoft.com/fr-fr/windows/win32/api/objbase/nf-objbase-coinitialize?redirectedfrom=MSDN
advised.
Moreover, it'll make concurrency model explicit
Change-Id: I247a49248bf45beb64a7985a7c0d078ee48efe2d
Change-Id: I6e755fd516d9fb2dd2a9df0c66d9afd6070447ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94669
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
specifically looking for the pattern
if (map.find(...) == map.end()
map[...] = value
Change-Id: I99f20d73f6e71a10726c9d39d8644c2e51120091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94151
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Id5a811e4227052fd9117ab2b099de31e8e3b90c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90413
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Calls to SkiaHelper::isVCLSkiaEnabled() may be done from many places,
even if LO uses a VCL plugin that doesn't use Skia, which leads
to the Skia code not being prepared properly (and crashing/asserting).
So make the SalInstance of those relevant VCL plugins call a setup
function that is required for Skia actually getting enabled.
Avoids crashes/asserts in the About dialog if the Skia UI checkbox
is enabled but e.g. the KF5 VCL plugin is actually used.
Change-Id: Ib56a5f32e88bd130a4c564031313f85e99898ba7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90376
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I95f348cc8b69b6c865ad0038b9ee0017def01e43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87896
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As said in previous Skia commits about BackendCapabilities::mbSupportsBitmap32
this should be preferrably enabled, but there are still parts of LO code
that have a problem with it, so make it easier to enable/disable this.
Change-Id: Iae7a8d5fc77a27372c00f6745317d168e8b2a05b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86489
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This got reverted in 84f84f59ce7c83a99e4e340071d58b6557dbe91a,
but using 24bpp bitmaps means SkiaSalBitmap::GetAsSkBitmap() does
a needless 24bpp->32bpp conversion, and this whole rgb/a separation
is kind of lame ancient cruft that it'd be better to get rid of,
so enable this again to find all the code that can't handle 32bpp
bitmaps properly, so that they can be fixed.
Change-Id: I9bbd8ff94a4ad680cb42dee649e371c5716a9d20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85545
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I4359b7042f98586e2c9f5529d83d769cdf3d033c
Reviewed-on: https://gerrit.libreoffice.org/85775
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|