It is obvious that I don't fully understand how to handle the view
coordinates, the applicationFrame etc. Possibly I am doing something
slightly wrong... Anyway, add a hack to make the touch input actually
refer to the thing under the finger;)
Also fix the handling of the selection end dragging.
Change-Id: I27a6a978e7fc28759b70d29ebca75bfd6b5f54a1
Note that this *is* still just an experimental app, not intended to be
in any way carefully designed for end-user use. I tweaked the look and
feel a bit just for fun.
Change-Id: I98339d32a8c3ac332fc42b206ab185a61abc4cc6
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
Manual intervention still needed to copy over the
ios/MobileLibreOffice and ios/shared directories, though.
Change-Id: I1e985cb9bf61238631bd01cd222eeaeb447d58b9
It seems that using libc++ when building with Xcode 4 (and iOS SDK 6)
you get linking errors. Stick to libstdc++ for now then with that.
Propagate the choice to the iOS Xcode projects through the lo.xcconfig
file.
Change-Id: Ic61dd2336066a77c4219c532106e3e50e85d0689
For many 3rd-party libraries we have for some time already kept the
archives only in their build directories, under workdir's
UnpackedTarball. Also, we now use upstream names for them which often
contain a verison number.
Change-Id: I51888de287e2c352a890bd4ae1dfdf0c6dc77158
Link libs from where they are now. Yeah, a third place where we
tediously list this (also in solenv/gbuild/platform/IOS_ARM_GCC.mk and
ios/Executable_LibreOffice.mk, although the latter will probably now
go away when/if the experimenatl iOS app is superseded by this
MobileLibreOffice app).
Also, don't duplicate the lib_link directory, and don't use a path to
the randomly-named DerivedData directory.
Change-Id: I7b685085d07da18a4594db067fb586b4eb3d2d4a
We use GNU cross-compilation terminology: "host" means the platform
the code being compiled will run on (this is often somewhat surprising
to those unaware), and "build" means the platform the build tools (=
the compiler, linker etc) is running on.
For an iOS app, "host" is iOS and "build" is OS X.
There is also "target" but it is in this case the same as
"host". (Only in a so-called Canadian Cross situation is "target"
different from "host" (and from "build").)
Change-Id: I6eefa982916f0660afd259770bf455cf28793670
