Instead, act as if it was true on all platforms. Don't do XOR clipping on any
platform. Simpler code is better code, and XOR tricks are generally very much
out of fashion these days, I have been told. Didn't seem to have any visible
ill effects on Linux at least.
Change-Id: I6192006c77a4a81363ec7b3292f72d512d5e9b53
Reviewed-on: https://gerrit.libreoffice.org/8901
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
No visible effect, though. Which is both good and bad: Good because it
means that without ill effects a larger degree of idenical code paths
can be used for both iOS and OS X. Bad because this change didn't help
in getting rid of the annoying misrenderings on iOS of some Smart Art
objects.
Change-Id: I9da0f98ca90554dbac963688705b3c7955021741
Possibly quite broken intermediate commit. But anyway, now it is
possible to render the tile diretly to a CGContext. Can be seen in
the MobileLibreOffice app when build in the Debug_tile_tester
configuration. See touch_lo_draw_tile() in viewsh.cxx. Unfortunately
the old plain LibreOffice test app is now broken, though, and
displays nothing at all.
This refactoring and hacking in vcl was done in a quite ugly fashion,
with ifdefs etc. But trust me, I did try, several times, for many
days, to get where I wanted in an elegant and clean fashion. But doing
it cleanly meant not being able to actually build it for days while
trying to figure ut which bits go where and which class should be
split into what base and derived class(es), and it was too much for my
limited brain capacity. I just couldn't juggle all the vcl class
structure in my head, especially as I don't have any good
understanding of the general design of it all.
Change-Id: Ia59d6a9cce15a63e63f94e8d8574bef21993fb1f
Use RGBA consistenly. Wonder why the code was changed to use BGRA at
some point?
I got the picture in the document to show up with correct colours but
unfortunately not the RED GREEN BLUE etc text. Weird. Even weirder, if
I add a temporary hack in CoreTextStyle::SetTextColor() to use some
other colours for non-black text (instead of the ones passed in the
parameter), those colours do show up. This is a mystery.
Change-Id: I591424a19fa02b3f095035e989cbc49fff94b8ca
Got the selection start and end handle dragging working... The trick was not
to call SwWrtShell::SetCursor(), but SwCrsrShell::SetCrsr(). Sounds easy but
took a lot of guessing and experimentation to figure out. Anyway, now it does
what I had expected it to do a few das ago already.
There are glitches, especially in corner cases like if you move the start
handle past the end handle or vice versa.
more
Change-Id: Id6c1d99a4052531789bccf0d48165cfb41b89cfe
9b94c0dd55b04a7b6b3c40654562a9c51fa9b450
Faking mouse clicks is a stupid way to do it of course. Try to do it
"right". For now just worked on moving the end handle, but once that
works, similar code should be used for the start handle, too.
Does not work yet. It is hard to extract out from
SwEditWin::MouseButtonDown() exactly what all is relevant, and what
isn't, for this use case.
Change-Id: I76a226f787facbac645aaff8b4852d693bcf4ccb
Rename functions so that functions called by the UI layer for actions
to happen in the LO layer and functions called by the LO layer for
things to happen in the UI layer use different prefixes. Move
declarations to the generic <touch/touch.h> and avoid iOS-specific
types in the API.
Change-Id: Ieb8979065e02a87c4a415c934163265f2790d011
Minor further changes by tml to match the coding style of surrounding
code mainly.
Change-Id: Ied6087a264f1c6b00763ea36fba9808329afede4
Reviewed-on: https://gerrit.libreoffice.org/5742
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
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
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
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
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
I am not really satisfied yet with how the UI redrawing in the app now
works (during startup, which of course is more or less all the app
does so far).
It can take quite some time before a "link" (function to be called)
posted with PostUserEvent() gets run (if there are lots of
time-consuming other "user events" in the queue already, or
something?), and blocking the UI thread for that time is not
acceptable. Will have to come up with some more complicated solution.
Change-Id: Icab20183df3bc4980ae33f0502d10397802cc391
We used to render them in the app main (GUI) thread, which is
dangerous, accessing the headless frames in one thread while the LO
thread (where the "main" LibreOffice code is running) might be
updating and changing them.
This fixes some problems like that part of the document did not show
up. If I would test the app on a multi-core iPad, presumably I would
have seen even more problems.
But this also introduces new problems: Now the UI doesn't appear
incrementally (for instance, with an actually progressing progress bar
during the loading of the document) as it used to. Now it all appeads
all of a sudden, everything at once. Which would be fine if it
happened very quickly after starting the app, but it doesn't... on the
original iPad it takes half a minute.
Change-Id: I04068e0d884aa5cb86acefa76449aac4e081b193
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
