Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I344d64212aa1d42171f18dae7659ab7f56fecbcb
|
|
Not suitably licensed.
Change-Id: I221cccb9d2ff5b6cb5e25161b6d5bfe504acb10e
|
|
I get exactly the same kind of artefacts as in the Android app, which
I guess is good as it is at least consistent, as the implementation at
the LO layer is identical...
Change-Id: Icf0690fd2c48a133cb66de2ab7977b7088d2199e
|
|
Change-Id: I737e43d35eb2ebd6aeadeb5695cb3ecc74cc4484
|
|
Now it re-orients and re-sizes the LO "frame" correctly upon rotation,
but it still starts wrongly if starting in landscape orientation.
Change-Id: I4c12a7e00d687391435a47400b6e8b4c7e49bdda
|
|
Change-Id: I94cfdc1b334539399faff29c046185bbbf698d23
|
|
Change-Id: I93102156c4713191c8ad49da9b9d2eda5be722e8
|
|
Change-Id: I191bc093def5d2965b463dcff9e1289901064ce8
|
|
Don't have our View class implement the UIKeyInput protocol any
more. It won't work properly anyway. The docs say: "Only a small
subset of the available keyboards and languages are available to
classes that adopt this protocol".
Instead, use a transparent UITextView on top of our View to accept
keyboard input.
Seems to work as expected.
Change-Id: I3093ea7fbfa0ecab0dc5d0a38e5695723e8ed4ad
|
|
Only react to hide notification for now, call lo_keyboard_did_hide()
Change-Id: I2f429039d2a84269783d103ad635ff4c407c4a15
|
|
Change-Id: Ib68928d7213a7dbba830b20c882ba53c6f3deb4c
|
|
Change-Id: I9321dcf9d863cb59eee9b2a012d887a17cb1b454
|
|
Change-Id: If37b5e646562357c4c6c9ce0a3821d92bbfc07f9
|
|
Change-Id: Idac1c756faa47236e4ebc3c7400f7e4412f02a44
|
|
Change-Id: Id0fdba93a5d3a46a79cebea8839bdfd467ef4f6f
|
|
Change-Id: I42991d7a9c9e0bd4a023739051393935efa5c29f
|
|
One can set environment variables to be used when debugging an app in
Xcode, which is when it is interesting to see SAL_INFO output anyway.
(This is very different from Android, where one can't set environment
variables "before" an app starts, as apps there aren't separate
programs that would be exec'ed.)
Change-Id: I3971d1b2d1a849deac2722a90271ef2458db1643
|
|
Change-Id: I433419e1ed7bda566bb13bf14346948d131abee6
|
|
Change-Id: I0015f7d751cb0e45262774c19a120f428cb35af2
|
|
long"
This reverts commit 3aae02d02d418222b0b51748008ed5c9c1f1d3c2.
|
|
When initially calling lo_render_windows() from a redrawRect(), just
post the user event asking for a redraw of the (headless) windows, and
return without actually drawing anything to the context.
Then when the RenderWindows() callback for that user event eventually
gets called (which during startup and/or loading of a document might
be several seconds later, as there is lots of other activity going on
also as "user events"), ask the UI thread for a fresh redraw, and wait
for lo_render_windows() in that phase to signal the actual redraw of
the "headless" windows into the context.
Unfortunately this doesn't work well enough. It is not a good idea to
not draw anything in response to a drawRect() it seems. The affected
rectangle gets initialised to black. So there is now irritating
flashing. One sees an almost ready document (and the UI elements which
still are there), but then it goes away for some time before finally
re-appearding. Quite silly. So I will revert this, and I am committing
it just to keep the code for reference in git.
Change-Id: I9ee490345f093d80113c36f9e3268cab5a810dd0
|
|
Change-Id: I01c9c26c6d282729101386266db898d759450a41
|
|
Change-Id: I8e27f0cb4a9605a97d8120f9f4697e7f939135c1
|
|
Change-Id: Idd44c792b4e0ee9cd27c3d66c2c5d794f4304045
|
|
Much faster. No need for the pixelBuffer inbetween.
Change-Id: I6493faca6da3a3e9a1285e00c887928b85dca56e
|
|
Change-Id: Ia5e84bc661d0de1140a259be7dd9fcdaca5e1930
|
|
No, it isn't any closer to being "ready" despite the name, but still,
using the current approach, it clearly isn't restricted to be just a
viewer.
Also drop the verbose LOViewer prefix from class and file names in it.
Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
|
|
Change-Id: I4c839e7b20e276b2fb3be60925de42ae91f47ee1
|
|
Was accidentally reverted.
Change-Id: I1d62003cfab222664b7cf2053f640287910b2892
|
|
Change-Id: Ic0fd7d60ddc66bcd5577988b3a4e5b2185d3ec1f
|
|
Change-Id: I33a67b4908759913e49608110cc2635cc50e54b1
|
|
Change-Id: I19a5ab15650cef4ee834af63e19bea7807b77477
|
|
Change-Id: I44df0946f59d1b9a2a6ea935b3c2ea3c96c1260d
|
|
Change-Id: I3298b985bc7f197e50f7246c8fe828d51804bde3
|
|
Change-Id: Iccd5f7bb99a76542481564b2f6475ca365756e45
|
|
Change-Id: I50ac91fd0e803b1b2322e5c7c25f7bf682a8208d
|
|
Don't try to use similar code as for OS X to manage windows, events
etc. I.e. don't use UIKit in vcl to do that. Instead, just do as in
the Android port, use the "headless" vcl backend. Do keep using
CoreText, though, not FreeType & fontconfig.
Start changing the iOS "Viewer" app to correspond to the Android
"desktop" app (so it should be renamed).
Work in progress since a long time, several crucial details still
missing, but committing for now.
Change-Id: Iac5fbf8def415e4d0d21e5200450a373420ad7ee
|
|
Change-Id: I7c3c8fcc81297ca97474b2b9482d40b47688febd
|
|
Change-Id: I03dd3639841bf00d427b8d1b3db13f65f705724f
|
|
Change-Id: Ie31bda8f1e035127d60b281cca9538d3e8803f9f
|
|
Change-Id: I104fde6ea294db55513ef11fe063e911e287cc31
|
|
Change-Id: Id0f13351108cbcd748f3c403fe7a6716145f1892
|
|
Get the app bundle directory from Xcode's SCRIPT_OUTPUT_FILE_0.
Copy .rdb, registry, .res files, set up the various rc files.
Don't list a bunch of .component files on the command line, surely
that is not sane.
Change-Id: I6fb8bd4bea8d5afd30900daa1b916defb894e78c
|
|
There was quite come confusion as to where Xcode wants the Run Script
phase (= our gbuild mechanism) to put the executable. I think I got it
right now. Xcode can be quite scary as soon as you do anything out of
the ordinary. (But then, what isn't.)
Change-Id: I22bbdfaef88174815bff66d6c7241f4ba2360246
|
|
The Viewer app is intended to eventually resemble the experimental
Android DocumentLoader app.
Build using the gbuild mechanism, which is also invoked from an Xcode
project. This seems to work out fine, the resulting app installs at
least on the simulator, and you can debug all the LO code involved
even if Xcode (obviously) has no knowledge of the LO source
files/classes/etc.
Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
|
|
Change-Id: I39bb14e47654afd5425098fb4aad80a29f058d67
|
|
Change-Id: I15981bf4827c29a7e1ce8e33d8b6fdc159e05522
|
|
Use the wildcard function to get all ibraries and component, like for
Android. (We won't of course actually link in all code from allof
them, just what gets referenced to by the getFactory methods
referenced in docloader.mm. Plus possibly unintentionally other stuff,
to be investigated...)
Change-Id: I6516964c83e7bf120de586550c40615b4337f760
|
|
Change-Id: I10c8a6806fd106128e151d470a51caa54aa074e8
|
|
Change-Id: I8a9e69b53fd84207d5673fc4635e54920864016f
|