summaryrefslogtreecommitdiff
path: root/vcl/win/app
AgeCommit message (Collapse)AuthorFilesLines
2024-02-26fix Windows release buildNoel Grandin1-0/+2
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>
2024-02-10Simplify a bitMike Kaganski1-25/+0
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>
2023-12-31Expand some macros inlineMike Kaganski1-54/+79
Change-Id: I6abad4ab4ea357ab55ea97b8a0d39c453dffc249 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161493 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-10-14Add NUMBERSIGN key handler.Gökay Şatır1-0/+1
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>
2023-08-02split Point/Size/Rectangle into AbsoluteScreenPixel* typesNoel Grandin1-7/+7
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>
2023-04-22Introduce sal::systools::CoTaskMemAllocated to use RAII for CoTaskMemFreeMike Kaganski1-10/+6
Change-Id: I5553138bfc8dd989e68b8bcc2be981746e8c1e84 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150783 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-13no need to allocate these separatelyNoel Grandin1-1/+0
Change-Id: Icc24e0aaf1762e5b318b8364dd9fdb496edfb77c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150279 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-12mpMouseLeaveTimer has been deadNoel Grandin1-1/+0
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>
2023-03-14Related tdf#129547 and tdf#154136: add COLON keyJulien Nabet1-0/+1
Change-Id: I17978dbb100fbfa6f6ddbbbdf96872076bc2a289 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86713 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-11-09give main thread on Windows a nameNoel Grandin1-0/+9
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>
2022-11-01-Werror,-Wunused-macros (clang-cl)Stephan Bergmann1-9/+0
...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>
2022-10-13tdf#120326: properly prevent Windows from entering power savingMike Kaganski1-1/+0
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>
2022-09-14should be releasing the DC hereNoel Grandin1-0/+1
Change-Id: If2460da367356ef04ca344542c2c82f8283c9e67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139935 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-06tdf#150682 - bad shortcut in french langageNoel Grandin1-0/+1
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>
2022-03-24loplugin:externalStephan Bergmann1-0/+4
Change-Id: I6b18a514358488ed8a03b42313c3986c2b3fc9df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132021 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-22Simplify CoCreateInstance / CoGetClassObject with COMReferenceMike Kaganski1-4/+3
Change-Id: Ieb1035410c3c6c4b40ea779e829a940460d19b5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131922 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-03-16Related: tdf#118320 enable some windows dark theme supportCaolán McNamara1-0/+49
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>
2022-01-07VCL move platform code from mouse.cxx into pluginsJan-Marek Glogowski1-0/+18
... 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>
2021-12-21Use sal::systools::CoInitializeGuard and sal::systools::ThrowIfFailedMike Kaganski2-14/+6
Change-Id: Ifb40e7672671df03b5ffc89905ad1e7b68451b68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127232 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-09reduce time in ResetEvent (tdf#144052)Noel Grandin1-0/+5
Change-Id: I3e9c906a026e7455fb775d110eca32f8533614e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121836 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-04tdf#144289 invert / disable default OpenGL supportJan-Marek Glogowski1-0/+1
... 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>
2021-08-20VCL allow plugins to declare OpenGL supportJan-Marek Glogowski1-12/+4
... 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>
2021-06-15Revert "tdf#142832: a blind fix - calculate rectangle size properly"Mike Kaganski1-2/+4
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>
2021-06-14tdf#142832: a blind fix - calculate rectangle size properlyMike Kaganski1-4/+2
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>
2021-05-29vcl: Implement static vclplug usageJan-Marek Glogowski1-0/+5
.. 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>
2021-04-30loplugin:stringadd (clang-cl)Stephan Bergmann1-1/+1
Change-Id: I132643eb73129e1319af36b7c8aac36a516714b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114896 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-09loplugin:nullptr (clang-cl)Stephan Bergmann1-3/+3
Change-Id: I41a8fa48b762d8f4da1c23785a86d651cfb4aa89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113851 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-01Simplify CheckFileExtRegistrationMike Kaganski1-21/+13
Change-Id: I49a01e9cae16a408c6be11fe0501f489c3db6e3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113438 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-01Fix --disable-pch Windows build - missing includesMike Kaganski1-0/+5
... 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>
2021-04-01tdf#45735 New UI dialog at app startup to check default file formatsMatt K1-0/+198
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>
2021-02-11make win32 variant AnyInput() not deliver events (tdf#140293)Luboš Luňák1-167/+18
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
2021-02-04fix sporadic crash in sd_misc_tests on windowsNoel Grandin1-0/+6
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>
2021-01-29Fix typoAndrea Gelmini1-2/+2
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>
2021-01-28WIN refactor ImplSalYieldJan-Marek Glogowski1-37/+42
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>
2020-12-14Silence warning C4189: local variable is initialized but not referencedStephan Bergmann1-0/+2
Change-Id: Ie36d7c4dfee5115b5909ed58a0b16b367e05866d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107734 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-14Reuse pInstStephan Bergmann1-1/+1
Change-Id: I91e5a469344ab951225e61237b462ed58ed796be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107733 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-14Fix and clean up SalAbort implementations on macOS and WindowsStephan Bergmann1-19/+0
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>
2020-12-14Silence MSVC warning C4189 "local variable is initialized but not referenced"Stephan Bergmann1-0/+1
Change-Id: I346cf6cf148cd3b4ac851f8c441d54c858f55935 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107674 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-07remove OpenGL VCL backend codeLuboš Luňák1-6/+0
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>
2020-09-24Revert "Directly acquire m_aMutex, instead of looping on m_condition.wait()"Stephan Bergmann1-4/+31
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
2020-09-23Directly acquire m_aMutex, instead of looping on m_condition.wait()Stephan Bergmann1-30/+4
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>
2020-05-22Prefer CoInitializeEx instead of CoInitializeJulien Nabet1-1/+1
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>
2020-05-15use more try_emplaceNoel Grandin1-4/+1
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>
2020-04-22tdf#42949 Simplify use of rtl::math::approxEqual in include/basegfx/Gabor Kelemen1-0/+1
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>
2020-03-16Some more checks for correct screen sizeSamuel Mehrbrodt1-1/+9
Change-Id: Id5a811e4227052fd9117ab2b099de31e8e3b90c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90413 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-03-12rework Skia setupLuboš Luňák1-0/+3
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>
2020-02-03Avoid loplugin:unsignedcompare (clang-cl)Stephan Bergmann1-2/+3
Change-Id: I95f348cc8b69b6c865ad0038b9ee0017def01e43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87896 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-09add setting to config_skia.h whether to use 32bpp bitmapsLuboš Luňák1-0/+3
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>
2020-01-06set BackendCapabilities::mbSupportsBitmap32 for Skia againLuboš Luňák1-0/+10
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>
2019-12-24sal_Char->char in vclNoel Grandin1-1/+1
Change-Id: I4359b7042f98586e2c9f5529d83d769cdf3d033c Reviewed-on: https://gerrit.libreoffice.org/85775 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>