Age | Commit message (Collapse) | Author |
|
Change-Id: I4359b7042f98586e2c9f5529d83d769cdf3d033c
Reviewed-on: https://gerrit.libreoffice.org/85775
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I062fef5f2316a3aa7560ecb42799496cd38362e9
|
|
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)
|
|
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)
|
|
Change-Id: Ib9ca0173f3b5bb090ae71f8622fef717a47e8a2b
Reviewed-on: https://gerrit.libreoffice.org/78704
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iae76994e275517d7a1e7b9e29111159f1ec93e2d
Reviewed-on: https://gerrit.libreoffice.org/77766
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Icc72fca62e189559956abc0ebbca9ce196a02073
|
|
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
|
|
Change-Id: I821a699ee4f44881aadac89f265974a10095b544
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Change-Id: I58beedfee1a55df971e778ba2aa3b6989ba53663
Reviewed-on: https://gerrit.libreoffice.org/68341
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
Change-Id: Ia124a4af642e449dc05f5bae2d5ca766bd67bd68
Reviewed-on: https://gerrit.libreoffice.org/62388
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib26ed91ca90cc2f38e21cce54c093795b1059877
|
|
Change-Id: Ic099761eaff80349e985ccf62e3f4aa6b2e98022
Reviewed-on: https://gerrit.libreoffice.org/61103
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I7b0c737b84f4528a8fba01e2998f525046834b1c
|
|
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>
|
|
Point .... were not defined
Change-Id: I725b3058d44d527ca2d3201060e4f467fd69c78d
|
|
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>
|
|
Change-Id: I1101c5b5426507ce8e5fd1ed34930f385f527775
Reviewed-on: https://gerrit.libreoffice.org/44639
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
needed more dummy stuff
Change-Id: I96392415a8f778be3ef1a44fb485d27049f7f324
|
|
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>
|
|
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>
|
|
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>
|
|
Removed pSys parameter from IosSalFrame
Change-Id: Ib61f09448ef0c6751d4261b11d6a7b9dc45e786b
|
|
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
|
|
Updated Rectangle to tools::Rectangle
Change-Id: I1577dffe8d51ac3a33bbc2e0771b338d5fdd0220
|
|
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
|
|
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
|
|
Change-Id: I55223078e189416c4181141a7a904e93d5c6a01e
|
|
Change-Id: I126aa5e9b96299eb25c2240d097859b3c0756535
|
|
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
|
|
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>
|
|
Change-Id: Ide3457c5baab3d7f84990f6c2311975002ba9f18
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
Change-Id: Idd4a1e6d50652a879493d8411c59605ca1a53dfb
|
|
Change-Id: Ic3f7fddcea36c18ffe43c4c633d415f596a58cbc
Reviewed-on: https://gerrit.libreoffice.org/19094
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I6eb213d6dcf387936967271fba9e2de3879ef479
|
|
Change-Id: Ia41276033c1f656217bc3ae929faab001db36ca4
|
|
Has all been obsoleted by LibreOfficeKit.
Only some MOBILE_* constant #defines are now left in touch.h, but probably
those are used only by dead code.
Change-Id: I646945c4408b4e6cd5510da535cfc12088dd391c
|
|
Change-Id: I155e45f58974a2b946c4a7703b350bcbfbad342e
|
|
Change-Id: I73e1498198cbb55ccd969713a38b6cd678c94643
|
|
Change-Id: I03a30793e02def731cb6c8f130c48aeb325a2528
|
|
Change-Id: I22fd5c1340ca0c646725d9fce77304c10d9eb5d5
|