Age | Commit message (Collapse) | Author |
|
Change-Id: Idb847766d93dc222d6c55889616da21eeac212ee
|
|
This looks wrong. Compared to ThesDummy_Impl::getLocales() it seems
sane to remove the duplicate.
Change-Id: I494b22039846da4d4e84d7f289e501d1315075bd
|
|
This came in with 3ecdcbaee0a906bc0d1700f60a4d360f4f51291c and is
apparently wrong.
Change-Id: Ic048d20c728aca2f8c97a90ede74d77e51b16e1c
|
|
So if we have an INVALID_ATTR event in the queue and receive
INVALID_CONTENT, drop the attr and replace it with invalid-content
And anyway filter out the RSID change event from hitting the
a11y queue, humans don't care that this changed, it's just noise
Change-Id: I4842f217153fc90aa1dce75c3445053004c74536
|
|
Change-Id: I0c2a2301de1b0de71fc6724ff2af73fbf6b406ef
|
|
Move unoidl functionality into a module of its own, as a prerequisite to use it
in codemaker etc. (This is intended to ultimately remove modules store and
registry, modulo backwards compatibility constraints.)
Change-Id: If5274cbd3a595951e6cf7a9664bc542f01833f38
|
|
Change-Id: Id7b5e421f8ff9d6db923a1fb01b1071f75a6842d
|
|
Change-Id: I794b34c1864f619d91f0b105ba08a4f607abd291
|
|
Change-Id: I17f68196edeb685fb8d3f95616be1199fd5f1de2
|
|
Change-Id: Icb3044f1dc8b8a816cc93c9764908532a9cdcec4
|
|
Change-Id: Ib655b1177ffb4609bd7c50d54a818de659f284f3
|
|
Change-Id: I7e12a4ddd68ffb2c2b1cd1730a8ab17c79311fb2
|
|
Change-Id: I006230e190eb4e35f72c598c0016f7a7aa27cc7d
|
|
Change-Id: Iaced34a334e216ac2f4df783d76fb3003051e3b5
|
|
Change-Id: I7687af837d116ef7ec444049d941f3ca337aca03
|
|
Change-Id: Ib7721d6b97b2d5f11f9f6dd05f5bc236c09c4f42
|
|
Change-Id: I2bb9d4598d31462f9b661ed076046eb643c0a9e5
|
|
Change-Id: I74232178bb8c8a528d03274fbc8c1c9573874421
|
|
Change-Id: Id90ffae1f38b69005ead8bef9fadc54833813184
|
|
Change-Id: I198238f52b232dab4dc1d39fff70eb2dda2ddcfd
|
|
Change-Id: I4f5edb370a77e9d364e2b1df1271f20f99cef193
|
|
Change-Id: I58ed1ba6992b413aad9aa39f77623371a3e7972e
|
|
Change-Id: I9e26a6a32a70275174c83d109256dde5c718e42b
|
|
Change-Id: Ia75627e720f1edf7dba8aeb4684cdc0e3bfebb33
|
|
Change-Id: I3d0f0320fff1e9b6609bac152ff27552d58d928f
|
|
Change-Id: Ibe4c7753c1494cc665f52cefcc65875fd75fe051
|
|
Change-Id: Ib5ac31222fb9007336e49b872719c4515d51d5ad
|
|
Change-Id: Iee64a80118e927bfa66d24edb34187f7f7551533
|
|
Change-Id: Iff0150f99336c9650c9d9a9aaf34d0badf32c562
|
|
Change-Id: If2b1df2e71f6f206bff0951205490283e481c199
|
|
Change-Id: I6619cb27b1e49eb4ee7a91ad5e6f09f2b617e514
|
|
Change-Id: Ifba88d55c6fa9f86d46b2460aca9d62e0d47fee7
|
|
Change-Id: I98019eabc170b638275531036012cf8812e7f43c
|
|
Change-Id: I47280399bd9e0757365db8f4f1930efd0a340424
|
|
Change-Id: I2d6cf0afad4d5237b44e21be051f6f593a12830d
|
|
This reverts commit 199f0edc93e25ff8144f16599184049573154232.
the problematic emf+ file with embedded wmf suffered from different problem
so I reverted this fix as it is not needed
|
|
Change-Id: I5005961e1b618af949dc978a7ac560fc9eca3e65
|
|
This rewrites commit fa694a21b806ed7837c1337ec49a4b299c478393 (fix of
fdo#55931), and fixes it a better way.
Change-Id: I9ac0c78294e6a9c510c12b22547564b736416131
|
|
Printing to stderr is not at all any faster or more direct in an Android app
than just using the Android standard logging API.
Note that in a normal Android app, stdout and stderr are not connected
anywhere. (Just like in "GUI" subsystem (as opposed to "console") Windows
programs, heh.) It is our own code in sal/android/lo-bootstrap.c that
redirects stdout and stderr to pipes which we set up and which are read in a
separate thread that we start. The lines read are then, surprise, passed on to
__android_log_print(). Thus writes to stdout or stderr in "normal" LibreOffice
code aren't lost.
But in code that is by definition Android-specific it makes little sense to
use stdout and stderr.
(Much of the affected logging in this change is in NativeActivity-related #if
0'ed code, sure, so won't actually be reached.)
Change-Id: I409114f36f3e535bb144b4bde0d378110b3336a1
|
|
The View size is available only after the view has been connected to the
activity, it seems, so move the Bitmap creation to onDraw().
Note that the code in SvpSalFrame::SvpSalFrame() in vcl/headless/svpframe.cxx
still hardcodes another (!) size, 800x600. This affcects the size of the
desktop-style "top-level window" displayed by the android/experimental/desktop
app. I didn't yet figure out the right way to pass the actual view size to the
SvpSalFrame. And there is also a hardcoded third (!) size, 1280x750, in
AndroidSalInstance::GetWorkArea(), although I don't know what that affects, if
anything.
Change-Id: I042bf764cd66efa7069c36601170b90d57fa174c
|
|
Change-Id: I113f7bf3fd4194011efe83b1776ca42ad489f652
|
|
When editing the Visio OLE object, there is a "preview" file generated,
which is apparently an EMF file (strangely initially inserting the Visio
object seems to result in a totally unproblematic WMF file).
The EMF file apparently has almost its entire content stored in
MetaCommentAction of type "EMF_PLUS", which is thrown away when writing
the file again.
Change-Id: I77a08454da673c1825aaa8421606737e7e8bc82c
|
|
This can be observed when inserting the bugdoc from fdo#59405.
Apparently the "size" and "length" do not agree; ensure that the
"length" does not underflow.
Change-Id: Idfc68919859b8284c724831de21208e4392af328
|
|
The mnViewAspect member is otherwise only initialized if a
SOT_FORMATSTR_ID_OBJECTDESCRIPTOR thingy is in the clipboard, which only
happens if the clipboard source is OOo/LO.
When inserting an OLE object, the value MSOLE_CONTENT apparently results
in requesting the current size from the OLE object, which looks much
better than the square default.
Change-Id: I8c7fb80a8ae88272f1ecaf3a375bef5d917f2a5b
|
|
Change-Id: I98794721c21231800d7d28cbdd34dd300b69a9c2
|
|
Change-Id: I37099d15cd403f48ca1716414f2e79cc1213d8c8
|
|
Stale component files result in failure to load libraries in incremental
builds; because rebuilding these is fast just depend on the 2 Repository
makefiles that define the library file names.
Change-Id: Ia72a0460d3bb8bceb0e17334415ca3dde0401c24
|
|
Changed all occurrences of 'charcter' found by git grep. All of them
were used in comments only, so it should not break anything.
Change-Id: Ief2c00d929ae7972c55a4920fc0eaa8d6b18ab82
Reviewed-on: https://gerrit.libreoffice.org/2372
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
|
|
Change-Id: I7c9ebd01c16ff066008e53de865560ad78215bab
Reviewed-on: https://gerrit.libreoffice.org/2330
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
but *sob*, it's not really that, because there's a dialog scale factor which is
per-language which adds a bit to it depending on the language, MAP_REALAPPFONT
is the unscaled variant.
but *head in hands*, it's not really that either because if the font was
considered "too narrow" then the average char width is recalculated in terms of
the average char height.
*clenches teeth*, add a approximate_char_width and use it directly. It can be
considered the rough equivalent of
pango_font_metrics_get_approximate_char_width albeit that it retains the same
crude 1/8 of the width of "aemnnxEM"
Change-Id: I4c135ca03467447dddf279ac0c187b13371acadb
|