summaryrefslogtreecommitdiff
path: root/vcl/ios
AgeCommit message (Collapse)Author
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
2018-06-09hold and return SalPrinter with std::unique_ptrNoel Grandin
and remove DestroyPrinter, doesn't not anything beyond delete'ing the object Change-Id: I25e14b962e65a0e131fae3ff5771c82920a4e375 Reviewed-on: https://gerrit.libreoffice.org/55498 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-03-05vcl, make ios/dummies compilejan Iversen
Point .... were not defined Change-Id: I725b3058d44d527ca2d3201060e4f467fd69c78d
2018-02-26vcl: fix hangs in SvpSalInstanceMichael Stahl
Since commit cb8bfa9a32799bcde4e960fa56e388d5f7b2a928 the main thread will read from the timer pipe until it is empty. But evidently this introduces the problem that the poll() in another thread will not return, as the file descriptor will no longer be readable; see https://paste.debian.net/1011306/ for a reproducer of that rather under-documented poll behaviour. So other threads can get stuck forever in poll, and then the main thread can block in poll too with no other thread to wake it up. This is the problem that plagues UITest_writerperfect_epubexport. The timer pipe is difficult to fix, since the main thread can block on either the poll or the subsequent AcquireYieldMutex(). So replace the timer pipe with a condition etc. that is mostly copied from the OSX AquaSalInstance/SalYieldMutex implementation. The main thread now does something different than the other threads, and blocks on a condition_variable with a timeout, while other threads still block on acquiring the mutex. Non-main threads can poke the main thread to do a DoYield() on their behalf, and then get the result back with a blocking read from a pipe, all while holding the YieldMutex. This requires some fudging of the YieldMutex so that the main thread can borrow the ownership temporarily. Unfortunately SvpSalInstance, in addition to being directly instantiable for --headless, has a whole bunch of subclasses: * HeadlessSalInstance * AndroidSalInstance * IosSalInstance * GtkInstance (in the gtk3 case) * KDE5SalInstance Of these GtkInstance overrides everything related to the DoYield/SalYieldMutex implementation, but the others will be affected by the change. This commit will probably break IOS due to me not understanding the point of the undocumented random #ifdef IOS in svpinst.cxx. Change-Id: I1bbb143952dda89579e97ac32cd147e5b987573c Reviewed-on: https://gerrit.libreoffice.org/50237 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-11-11Replace list by vector for ShowNativeDialog (vcl)Julien Nabet
Change-Id: I1101c5b5426507ce8e5fd1ed34930f385f527775 Reviewed-on: https://gerrit.libreoffice.org/44639 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-10-31ReleaseYieldMutex is always called with trueNoel Grandin
so drop param and rename to ReleaseYieldMutexAll Change-Id: Ic4fcee24d46405659e54363c87f21d88696b0ce1 Reviewed-on: https://gerrit.libreoffice.org/44057 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-10iOS, solve missing vcl referencesjan Iversen
needed more dummy stuff Change-Id: I96392415a8f778be3ef1a44fb485d27049f7f324
2017-09-19rename SalGenericData to GenericUnixSalDataNoel Grandin
since it's generic over the various unixen, not anything else Change-Id: I994d5c9be99134b804e96bc045bf054fd9b434ef Reviewed-on: https://gerrit.libreoffice.org/42455 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-19Unify SolarMutex implementationsJan-Marek Glogowski
All backends implement the SolarMutex in mostly the same way. So this consolidates this code into a GenericSolarMutex. We still need the abstract SolarMutex class for the fake AKA fascade implementation in dbaccess. The patch also replaces various places of direct mutex usage with either SolarMutexGuard or SolarMutexReleaser objects. Change-Id: Ia0146dd6c51a3b9a513cc6af34a66def58aad831 Reviewed-on: https://gerrit.libreoffice.org/42325 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-08-08loplugin:constantparamNoel Grandin
Change-Id: Ib92aba17c46a4ada75c2a0630f281759d995f32e Reviewed-on: https://gerrit.libreoffice.org/40843 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-05-03iOS remove unused parameterjan Iversen
Removed pSys parameter from IosSalFrame Change-Id: Ib61f09448ef0c6751d4261b11d6a7b9dc45e786b
2017-04-28iOS, fixed build breaker.jan Iversen
Fast fix to build breaker from commit 3a36cf434fb4a967c9ea767cb7ac5f4da0502a0d Removing the parameter from the constructor gave ripple effects to move/copy constructors, so not done for now. Change-Id: I98e060e80946dbfe6586744e4f362ccb358a210d
2017-04-03iOS update for Rectanglejan Iversen
Updated Rectangle to tools::Rectangle Change-Id: I1577dffe8d51ac3a33bbc2e0771b338d5fdd0220
2016-10-05InfoFont/Color is not used by vcl nowCaolán McNamara
anywhere anyone wanted to Get[Font|Color] give it the Label ones instead. why this is exposed through uno is bewildering, stubbed those out for the moment Change-Id: I7a31d027287436be1c075c76a370047efd010bf3
2016-08-17Massage ifdefs etc for iOS to avoid undefinedsTor Lillqvist
I think it's best to not use cairo on iOS, even if we do use it on Android. We probably want to use native APIs for the functionality that cairo would provide. Just like we do on OS X. No idea whether the resulting TiledLibreOffice will still work like it used to in May last year, when I last tried. Change-Id: Ie15cad6918d7a66e2aff7faabfcade7f3246b060
2016-08-10gendata.hxx has movedTor Lillqvist
Change-Id: I55223078e189416c4181141a7a904e93d5c6a01e
2016-02-01Resolves: tdf#93821 assume mbNoSaveBackground as true everywhereCaolán McNamara
Change-Id: I126aa5e9b96299eb25c2240d097859b3c0756535
2016-01-20replace use of basebmp in vcl entirely nowCaolán McNamara
we're just using it to store bitmap data and to convert to preferred destination format, so we can use the preexisting vcl BitmapBuffer for that Change-Id: I0e800956d95faddfafa53d2c48b09494a7a867c0
2016-01-08cppcheck: noExplicitConstructorCaolán McNamara
Change-Id: If1ddb112c85f127295eb55566360b066e7173ba2 Reviewed-on: https://gerrit.libreoffice.org/21245 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-12-16SvpSalFrame ctor parameter list has changedTor Lillqvist
Change-Id: Ide3457c5baab3d7f84990f6c2311975002ba9f18