summaryrefslogtreecommitdiff
path: root/vcl/ios
AgeCommit message (Collapse)Author
2023-10-01Fix iOS build breakages when building on macOS SonomaPatrick Luby
Change-Id: I347e48e9da69c8c9b15581a5afa5c61cdd1d380d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157411 Reviewed-by: Patrick Luby <plubius@neooffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Patrick Luby <plubius@neooffice.org>
2023-07-31tdf#156230 remove now unused various bit and piecesNoel Grandin
Change-Id: I0ad88d402329bbc6882f53f6c20c22b97189a27f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155077 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-05-28Use getXWeak in vclMike Kaganski
Change-Id: I665c9dc8c4f9cc4a996d9bf990cbfa33822bd07f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150885 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-14Handle pasting disallowed clipboard contents on iOSPatrick Luby
When another app owns the current clipboard contents, pasting will display a "allow or disallow" dialog. If the disallow option is selected, the data from the UIPasteboard will be garbage and GetLOKNotifier() will return a nullptr. Since calling SetLOKNotifier() with a nullptr aborts in an assert(), fix the crash by failing gracefully. Also, throw an exception if the -[UIPasteboard dataForPasteboardType:] returns nil. By throwing an exception, the "allow or disallow" dialog will display again the next time the user tries to paste. Change-Id: I05d689b679a7643a8478e3ce0f416205fdf8ec23 Reference-to: https://github.com/CollaboraOnline/online/issues/5908 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148655 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 1dd68786a927a23e5465589025abd90b8c9f4e7b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148627 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org>
2023-01-30Fix iOS build errorsPL
Recent code reorganization and macOS changes caused the iOS build to fail. This change fixes the build errors and updates the iOS code to use the same headless data structures as other headless builds. Change-Id: I9c5329eb6376120d6789447f991c93eb9839d595 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146265 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Patrick Luby <plubius@neooffice.org>
2022-07-25rename SwIndex->SwContentIndexNoel Grandin
to help my poor brain with the different kinds of index we have floating around Change-Id: I47ed223922170687d7e07812445aed66b3218230 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137404 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-23Revert "svp: don't directly yield in main thread"Stephan Bergmann
This reverts commit d2de55c93f94bbccff51fa7715b613341f1f4ae6 for now, because it appears to have caused a massive uptick in hung UITest_impress_tests (sd/qa/uitest/impress_tests/save_readonly_with_password.py, line 95) and UITest_writer_test6 (sw/qa/uitest/writer_tests6/save_readonly_with_password.py, line 54) tests across Jenkins, see the comments starting at <https://gerrit.libreoffice.org/c/core/+/117900/8#message-e439f5f2b9ed7a24d6f47fd640defe14dc392eb5> "svp: don't directly yield in main thread". Change-Id: Id114a0d904580024352e4acf37e2558f9f0ae6f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136250 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-22svp: don't directly yield in main threadJan-Marek Glogowski
AKA svp: always release SolarMutex on yield, v2 Implement the TODO when yielding a non-main thread: "use a SolarMutexReleaser here and drop the m_bNoYieldLock usage" This whole concept of "deferred yield" is prone to spurious "deadlocks", if DoYield spawns a nested event loop. This will not only block one yielding threads, but all indefinitly. And not releasing the SolarMutex is also not fair for any other threads waiting. That whole m_nNoYieldLock hack is just needed to defer GUI processing to the main thread without releasing the SolarMutex, the exact opposite of what yielding does. While we can't do anything for the main thread as long as the whole nested event loop concept prevails, we can prevent the yielding thread deadlock using conditionals. With all the special m_nNoYieldLock gone from SvpSalYieldMutex there isn't any reason to keep it around. Change-Id: I87c006ad36b4959f7e0dd18dda99a58c4e25032d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117900 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-17iOS+SVP convert remaining VCL plugins to salplugJan-Marek Glogowski
While this makes the preprocessor usage even larger, the code in salplug.cxx is now hopefully easier to follow. I added a comment about the main code structure at the beginning. It also includes changes to the generic plugin list to include gtk3_kde5 before gen, qt5 and qt6 after gen, but still skips the headless / svp plugin. And I explicitly excluded salplug.cxx from the externandnotdefined compiler plugin. I could have added a dummy, but that seemed not worth the effort. My try on a non-dummy with correct includes and defines made the code in salplug.cxx much harder to follow. FWIW, the iOS VCL plugin actually seems to use the osx SalData, so I think these changes to iosinst.cxx are more correct then commit 7d990aafdc363b2a12b5db78637d7f3bef7780bd ("VCL drop m_pInstance from *nix SalData"). But hard to tell without a compiler. Change-Id: I0e2944d4221ca5910fb2120cc8b24def5c5b3f33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128477 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-14VCL move SolarMutex (un)locking into (De)InitVCLJan-Marek Glogowski
Fixes all the backends, where SolarMutex access needs SalInstance. The ImplSVData::SalInstance is just set fron the return value of CreateSalInstance, so it can't be accessed earlier, globally. Regression from commit ad94bb5d23d9c4ecbb2ca84807f01623862de43e ("VCL drop m_pInstance from *nix SalData). Change-Id: I13259009571a9973ea7e3ded20c0ea4c660ee214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128420 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-14VCL drop m_pInstance from *nix SalDataJan-Marek Glogowski
AKA the "*nix SalData untangling" commit. The original plan was to get rid of vcl/inc/saldatabasic.hxx and even SalData for all the *nix backends. But after many backs and forths, reinspecting the code and imagining the resulting code, I decided against that plan. All these variants would have resulted in reinterpret_cast calls, I wanted to prevent. And they would have required larger renames for no benefit. An other, related idea was to include all SalData implementations in the vcl/inc/svdata.hxx header, but that seemed like an include explosion, so was also dropped. I tried to untangling iOS from using GenericUnixSalData, as it doesn't use any of it's features. The new, minimal SalData should be sufficient. I'm leaving the easier drop of mpInstance from the Windows and MacOSX backend as a minimal interesting EasyHack. Change-Id: I5be01c1f42131a7e31cb30899392308e1e2de53b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128402 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-14iOS+Android+SVP "merge" all SalData instancesJan-Marek Glogowski
It's always the same code. Change-Id: I2385d0bda24939b964306e27a3df99ea44356eac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128401 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-29tdf#143148 : Use pragma once instead of include guardsRamreiso Kashung
Change-Id: Ic9318847b387fb84af6124ad94d4340cbd57c797 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127637 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-12-16Fix iOS compilation after recent changes to SequenceTor Lillqvist
Change-Id: I73c519174029766a3a2f61f9ad93fd63589b8184 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126957 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-10-06drop 'using namespace std' in vcl (MacOs/ios), blindlyJulien Nabet
but hopefully there's a Jenkins machine on MacOs Change-Id: If5e87d16e64f010494ca1e5751ea6873f3a21a57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123190 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-09-27Need a dummy AquaGraphicsBackend::drawNativeControl() on iOSTor Lillqvist
Change-Id: I5264eb8dbd817cbf0e6fdc00a84d60249258d3ad
2021-08-23Make compilation for iOS get a bit furtherTor Lillqvist
Note that I did not try to refresh my memory of what anything of this actually *means*, I just did a couple of quick edits to get past compilation errors in vcl. The build now proceeds until "No rule to make target '/Volumes/TML13/lo/master-ios-debug/instdir_for_build/LibreOfficeDev.app/Contents/Frameworks/libgcc3_uno', needed by '/Volumes/TML13/lo/master-ios-debug/workdir_for_build/Executable/saxparser.run'." Change-Id: I42e2d60bf691f99631b2700e45921824144df2d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120892 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-08-23make SalGeometryProvider available for Aqua VCL backendsLuboš Luňák
This is needed for the Skia backend to know the geometry. The Mac Skia code now passes most VCL unittests. Change-Id: I6e35764d95ce821d8e11ed9979e5be75bcf6ff49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120806 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-07-02vcl: drop GenericUnixSalDataTypeJan-Marek Glogowski
It's just used for a singke assert and SalData is generally just used as a static cast. Change-Id: I8d74e82e511413d940a3f200f022a9204e588cd7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118288 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-05-22tdf#142061 Add window scaling to XOR emulation on macOSThorsten Wagner
Window scaling for retina displays on macOS has been added to fix tdf#138122 in commit 1a167625314bf36b735176ed488e6ba9b5e9b675 Missing window scaling for XOR emulation is added by this change. Code modified for macOS is moved from quartz/salgidcommon.cxx to osx/salmacos.cxx while original code is copied to ios/salios.cxx to prevent modifications for iOS. Change-Id: Ia8c52f9045379cc37d5aff1279650db0dddee8c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115816 Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-04-30vcl: iOS/macOS - move graphic render func. into AquaGraphicsBackendTomaž Vajngerl
This change moves graphic rendering function under AquaSalGraphics into a new AquaGraphicsBackend, which inherits from SalGraphicsImpl. This is part of the refactoring to make it mandatory that a SalGraphics always has a SalGraphicsImpl associated, which will make it possible to simplify the SalGraphics interface and enable the posibility to implement alernative graphic backends (Skia). Common variables and attributes are moved to AquaSharedAttributes and are shared between SalGraphics and SalGraphicsImpl. Change-Id: Ie48da87002ec8e4011ba92fdc9170f3a86761517 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114701 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-03-25tdf#141217: Improve plain text pasting on iOSTor Lillqvist
Handle public.utf8-plain-text. That is the actual concrete UTI for UTF-8 text. For instance if you copy text from the Safari address bar, public.utf8-plain-text is the only type put on the pasteboard. Previously we were not able to paste than into the iOS app at all. Change-Id: Idbdd3870431f3b9a312cc9b672ffe1f16d13edbd Signed-off-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113042 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113045
2021-03-23Log successful mapping from system pasteboard format to internal MIME typeTor Lillqvist
Change-Id: I98bedc8fc07a56fbbf3e175277cc9846da46a8c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109201 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112949 Tested-by: Tor Lillqvist <tml@collabora.com>
2021-03-23We only use the systemwide general pasteboardTor Lillqvist
Simplify code to explicitly use it then instead of using variables. Change-Id: I915a44cf7275fbf2140671a2edf1da29f1bf4e40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109202 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112948 Tested-by: Tor Lillqvist <tml@collabora.com>
2021-01-20Fix typosAndrea Gelmini
Change-Id: I8bab3efcd63c0f950bc3176e0d26cc896d601083 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109559 Tested-by: Jenkins Reviewed-by: Dante DM <dante19031999@gmail.com> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-18Clean up includes a bit for iOS and macOSTor Lillqvist
Change-Id: I1dc6256968503ee3865f90e3693acce911a1d65c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109485 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-17tdf#138122: Fix vcl for iOS after 1a167625314bf36b735176ed488e6ba9b5e9b675Tor Lillqvist
Make vcl compile again for iOS and make the Collabora Office iOS app work again when built against a master build of core. For now, keep the old versions of the functions touched by 1a167625314bf36b735176ed488e6ba9b5e9b675 in vcl/ios/salios.cxx, and move the modified versions to the new file vcl/osx/salmacos.cxx. Keep the functions as they were except that ifdefs for MACOSX or IOS are expanded. Keep the formatting as it was to make comparisons easier. Thus add the new files to the clang-format exclusion list. While at it, also move vcl/quartz/salgdiutils.cxx to vcl/osx as it is compiled only for macOS anyway. Change-Id: I990ef678f2263031d4a5af8cc547fffe185d17c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109480 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-15Fix handling of the OBJECTDESCRIPTOR clipboard (pasteboard) type on iOSTor Lillqvist
This should fix https://github.com/CollaboraOnline/online/issues/849 This is based on the corresponding fix for macOS. Much of our clipboard code for iOS is based on that for macOS. We need the pasteboard to have the OBJECTDESCRIPTOR type as a MIME type that includes the typename attribute, because the code in sc checks for that when it decides whether it is a proper OBJECTDESCRIPTOR. Simplify the data in the flavorMap array. No need to duplicate the same MIME type string as both the pasteboard type and MIME type, for those cases where the MIME type is used diretly as pasteboard type. We also know that for those types, the MIME type might have additional parameters, so be more lenient in checking. With this change, and my recent change to sot, this now works: Start the Collabora Office app. Open a spreadsheet. Select a cell range. (It can include formulas.) Copy. Close the spreadsheet document. (Killing the app process is not necessary, as no in-process clipboard is kept on iOS, but to make sure you are really accessing the system pasteboard and not some in-process cache, feel free to kill the process. After that, start Collabora Office again.) Open a spreadsheet. Paste. You get the very same cells that you pasted as such (with relative cell addresses in formulas properly adjusted, as expected). Previously, it would paste an image of the copied cell range, which is fairly pointless. There is still lots of opportunity for cleanup in the clipboard code for macOS and iOS. Change-Id: I4a385d52bbaafcd2ab8cb18e8f613c5efa592d11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109368 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-21Improve SAL_INFO output for clipboard operations on iOSTor Lillqvist
Change-Id: Id9ed115067655c62346f765ddc3ed9bdce05ab9f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108101 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108103 Tested-by: Tor Lillqvist <tml@collabora.com>
2019-12-24sal_Char->char in vclNoel Grandin
Change-Id: I4359b7042f98586e2c9f5529d83d769cdf3d033c Reviewed-on: https://gerrit.libreoffice.org/85775 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-19Rename GlyphCache to FreetypeManagerJan-Marek Glogowski
And while at it remove the unneeded getPlatformGlyphCache abstraction. Change-Id: Id5cad751eda9e6bf177dfb4816280d7c5af7066a Reviewed-on: https://gerrit.libreoffice.org/83125 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-11-11Fix copy/paste error that probably has had no ill effectTor Lillqvist
Change-Id: I062fef5f2316a3aa7560ecb42799496cd38362e9
2019-10-07Avoid dialog headings showing up as some serif font in the iOS appTor Lillqvist
Apparently the use of [UIFont systemFontOfSize:10] familyName] to get a default font family name is a bad idea. Presumably the return value from this, ".SF UI Text", is matched against the list of font family names enumerated from the system. (The "SF" apparently stands for "San Francisco".) That ".SF UI Text" is not among them, so maybe vcl chooses some arbitrary other font instead that happens to be a serif one? If we instead use "Helvetica", at least we get a sans-serif font, even if it doesn't match the system UI font exactly. Change-Id: I7ff39d8e7893ce3c27f3f12d227f87209bbc7952 (cherry picked from commit 685e91a7aee4a4acc60e33bf1313a394fd15b1ff) Reviewed-on: https://gerrit.libreoffice.org/79196 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit ba9f91a909cb52194178ac2ed78dc62bd61c1be3)
2019-10-07tdf#126964: Set background colours to white in IosSalFrame::UpdateSettings()Tor Lillqvist
Change-Id: I92110a7a501571d7fd707dc33502ff553f02ae5e Reviewed-on: https://gerrit.libreoffice.org/77823 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit e84c42ee32d1a23729c65b534c4418e2043f706d) Reviewed-on: https://gerrit.libreoffice.org/78994 (cherry picked from commit 1e7a3f82324c3b855c2b3c1f8d4dec73c5162806)
2019-09-06use unique_ptr in CreatePrintGraphicsNoel Grandin
Change-Id: Ib9ca0173f3b5bb090ae71f8622fef717a47e8a2b Reviewed-on: https://gerrit.libreoffice.org/78704 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-20Fix typosAndrea Gelmini
Change-Id: Iae76994e275517d7a1e7b9e29111159f1ec93e2d Reviewed-on: https://gerrit.libreoffice.org/77766 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-05-29The iOS DataFlavorMapper::getAllSupportedPboardTypes() is unusedTor Lillqvist
Change-Id: Icc72fca62e189559956abc0ebbca9ce196a02073
2019-05-29tdf#124752: We do need to accept text/html from the system clipboardTor Lillqvist
Sadly we can't accept public.utf8-plain-text, i.e. text/plain;charset=utf-8, as the code does not know of such a SotClipboardFormatId. The only text/plain is UTF-16. And it probably is a good idea to accept HTML anyway. We have to continue to (I think) not offer text/html because of the assertion failure issue, see comment in DataFlavorMapper::openOfficeToSystemFlavor(). Change-Id: If5d77b97649424e347c50af10475c2be997c8632
2019-05-29Add a couple of SAL_INFOs about types available on the system clipboardTor Lillqvist
Change-Id: I821a699ee4f44881aadac89f265974a10095b544
2019-05-28tdf#124752: Simplify the iOS DataFlavorMapping thing a lotTor Lillqvist
Now it works to copy and paste images (PNG ones at least) between the iOS Collabora Office app and other apps. We don't seem to need the PNGDataProvider after all, as we use it only for data that is already in PNG format. Possibly I am missing somethin, though. Change-Id: Ia6bcc8aefbe1a6687f13e28454b96658fc66c856
2019-05-28tdf#124752: Add system clipboard interface for iOSTor Lillqvist
Based on the corresponding macOS code. Work in progress. The image support ifdeffed out still (because it uses some macOS specific APIs for which I couldn't right away find the equivalent iOS ones). I made it much simpler than the macOS code. I dropped the keeping of a local in-process clipboard completely. Firstly, as far as I see, the iOS clipboard API (UIPasteboard etc) does not even offer the possibility to separately offer some formats and actually provide the data on request. Secondly, we must be prepared anyway that the system can kill an iOS app at any stage while the user is using some other app, so we need to make sure everything that is copied goes onto the system clipboard right away anyway. I had to disable the copying of HTML to the clipboard as that lead to a mysterious assertion failure. See comment in DataFlavorMapper::openOfficeToSystemFlavor(). But RTF seems to work well, too. I assume RTF is what gets used for cross-application copy/paste (and cross-device, even, through Apple's Universal Clipboard thing, where you can copy/paste between your Macs and iOS devices on the same network). I am not sure how relevant the various application/x-openoffice-foo formats are. Change-Id: I174495e33d86fc3990996c229243c05d6cbfcda7
2019-03-14Further tweaks that affect the "tunnelled" dialogs in the iOS appTor Lillqvist
The bestmaxFrameSizeForScreenSize() function is full of magic numbers. (There originally, in OOo times, was a comment in there that said "fill in holy default values brought to us by product management" which says it all, really.) Those numbers have little or no relevance on iOS. Instead, make this function return the largest square that will fit on the display (square so that it will fit in either orientation, in case the device is rotated while a tunnelled dialog is displayed). And as a consequence the defaut font size on iOS can be bumped up a bit, to 10. Now the problematic dialogs look even better. Note that this is a cherry-pick from our vendor branch (cp-6.0). It hasn't actually been tested as the iOS app doesn't work at the moment if built from the master branches of online and core. Change-Id: I043d8f9947520adb04bd952ee49f9c7844a1fa8c
2019-03-14Use smaller default font on iOS (in practice used for dialogs in the iOS app)Tor Lillqvist
I suspected all the time that just one single-line change will be what is needed to make the dialogs look mostly sane. (Especially Format > Character... and Format > Paragraph...) No exotic hacks were needed after all, even though I experimented with more or less crazy ones for several days before I thought of changing this font size 14 to something smaller. The problem was apparently simply that with the larger default font, the dialog controls didn't fit properly in the space provided. Especially the four combo boxes on one line in the Font page were problematic. (It has three such lines of combo boxes.) Apparently the dialog machinery isn't especially good at reducing width of controls. The Size control shrunk to (almost?) zero width and was not visible, the Style control was too narrow to be usable, but the Language control was left as unnecessarily wide. Note that this is a cherry-pick from our vendor branch (cp-6.0). It hasn't actually been tested as the iOS app doesn't work at the moment if built from the master branches of online and core. (cherry picked from commit 96dce784c7971f22dcf44b66a242c22b455e32a3) Change-Id: If5675856345be2ae502346e8c097ef04216e2986
2019-02-26sal_uLong->sal_uInt32 in drawEPSNoel Grandin
Change-Id: I58beedfee1a55df971e778ba2aa3b6989ba53663 Reviewed-on: https://gerrit.libreoffice.org/68341 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-08o3tl::make_unique -> std::make_unique in tools..xmloffGabor Kelemen
Since it is now possible to use C++14, it's time to replace the temporary solution with the standard one Change-Id: Ib3201f865d43f372007cdf381c7e244e9cbeae26 Reviewed-on: https://gerrit.libreoffice.org/67474 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-11-08Bin some leftover and actually unnecessary iOS crack in vclTor Lillqvist
We don't need the '#define SvpSalGraphics AquaSalGraphics' in vcl/inc/headless/svpgdi.hxx. The actual AquaSalGraphics we use for iOS is in vcl/inc/quartz/salgdi.h. I don't remember the details of the convoluted history behind this. Change-Id: Ie56c3c93acf7ad89e10a05e75aa4ca7fd596ba98 Reviewed-on: https://gerrit.libreoffice.org/63098 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-10-31loplugin:useuniqueptr in DeletePrinterQueueInfoNoel Grandin
Change-Id: Ia124a4af642e449dc05f5bae2d5ca766bd67bd68 Reviewed-on: https://gerrit.libreoffice.org/62388 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-08Define a dummy GlyphCache class here for nowTor Lillqvist
Change-Id: Ib26ed91ca90cc2f38e21cce54c093795b1059877
2018-10-02Unify sal plugin loadersJan-Marek Glogowski
Change-Id: Ic099761eaff80349e985ccf62e3f4aa6b2e98022 Reviewed-on: https://gerrit.libreoffice.org/61103 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-08-27Fix iOS build after f05f4e042ca6ac8ae7f1d1e8e6bfb4cbba17a044Tor Lillqvist
Change-Id: I7b0c737b84f4528a8fba01e2998f525046834b1c
generated by cgit (git 2.34.1) at 2025-01-12 22:34:31 +0000