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
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
Done with a perl regex:
s/OUString\s*\(\s*RTL_CONSTASCII_USTRINGPARAM\s*\((\s*"[^")]*?"\s*)\)\s*\)/OUString\($1\)/gms
Change-Id: Idf28320817cdcbea6d0f7ec06a9bf51bd2c3b3ec
Reviewed-on: https://gerrit.libreoffice.org/2832
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
According to documentation, the system does it automatically. Testing
seemed to confirm that, with the code still in I got mysterious
crashes.
Not sure if the corresponding code is unnecessary or wrong on OS X,
too.
Change-Id: I14e9f5bcc0376e9235f8d36b484b38c1e44932c4
I ran the following code replace:
s/(Uni|Xub)?String\s*::\s*CreateFromInt32/OUString::number/
And finally removed String::CreateFromInt32().
Change-Id: I53b26a59c68511ae09f0ee82cfade210d0de3fa5
Reviewed-on: https://gerrit.libreoffice.org/2279
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
Call it QuartzSalBitmap. The more we get rid of that "Aqua" term the
better. Aqua is the name of a visual theme, not of an API. The Quartz
2D API is shared between OS X and iOS.
Nominally renamed the AquaSalGraphics class to QuartzSalGraphics, as
it isn't now then "Aqua" (Mac OS X) specific any more.
Actually, for Mac OS X, because lots of code in vcl/aqua expects it to
be called AquaSalGraphics (just like the alternative class used when
using the obsolete ATSUI API on Mac OS X), use a #define to make it
still be called AquaSalGraphics to the compiler's eyes. For iOS it can
be called QuartzSalGraphics.
If there is a need to optionally get a thread identifier or the
function name into logging output (as msgs_debug did), we should
figure out a way to do that in some elegant fashion in the sal logging
macros instead of using some local solution in just one place in the
code.
Yes, the iOS and OS X CoreText code should be de-duplicated. Will
happen soon.
Adapt to the fairly pointless privatisations here, too. Unify with the
OS X CoreText code. Yeah, probably should unify physically, i.e. use
the same source files for both, with as little ifdefs as possible.
Change-Id: I63bc477f0c979769bb995db37a3c4194e8091b30
Thomas Arnhold asked me to take a look at the method SetBackgroundBitmap.
In my XFCE, removing this method didn't chnage anything. So this needs more
tests in Windows and other WM's.
Change-Id: I3e10bea4eac114326ff981fb21ba0d292818b1da
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
...that (indirectly) allocates memory via rtl/alloc.h, thereby causing the
rtl_cache_wsupdate_init thread to be spawned before main, as on Mac OS X that
would interfere with the code in sal_detail_initialize to close all file
descriptors >= 3 -- on Mac OS X the pthreads implementation makes use of KQUEUE
file descriptors.
* This commit removes enough global static data to make ui-preview work again on
Mac OS X (where it crashed at startup when the main thread closed the KQUEUE fd
used by pthreads implementation threads). gengal uses further static data (at
least from module sb), so needs further clean-up.
* Avoiding global static instances derived from class Application required the
introduction of vcl/vclmain.hxx.
* That the vcl library was linked against the static vclmain library (which only
provides an implementation of main) appears to me to be a historic relic (all
executables should either include a SAL_IMPLEMENT_MAIN or link against vclmain),
so I removed that.
Change-Id: I048aa616208cb3a1b9bd8dcc3b729ba1665729bd
Note that this is code basically copy-pasted from the MacOSX ("aqua")
back-end with some small edits, and it is not clear at all that it
will eventually be used in this form at all. But until then, let's
keep it compiling.
Change-Id: Ia1bd63f2ecc621cd4ce699ffc754cab423321d42
...which effectively is just a glorious wrapper around
comphelper::getProcessServiceFactory.
In turn gets also rid of ImplSVAppData's mxMSF and mpMSFTempFileName and the
rSMgr parameter to InitVCL.
All the VCL users "soffice", "spadmin", and "unopkg gui" appear to still work
fine.
Change-Id: I797d48f7d0d8c35bb82124c9ab0ee63850c4d863
...so that displaying a (non-translated) error box upon BE_UNO_SERVICEMANAGER
works after all. Augment the error text with an exception message where
appropriate. This allows to revert fdfb7a3c4b
"Related fdo#51252: Report uncaught exceptions with MessageBox on Windows" as
that was to catch and display failures from instantiating the service mgr.
Change-Id: I049a38e95342634796eb0e940e2ee8e55193c9d3
i.e. honour gtk-fontconfig-timestamp so that if we request a font from
packagekit to be installed, then we can auto-use it when it appears.
Change-Id: Id0d914a3f9cd589d9e8a87bf9be4b6e47de2e191
