Age | Commit message (Collapse) | Author |
|
Change-Id: Ida0d3179726896b32b0876b1855b1f0be12d3b48
|
|
Start test with use_vcl_non_headless_with_windows instead
Change-Id: Id6ff9c6f15ec927e1cbe2c599c526857982a76d2
|
|
For simple TabDialogs with minimal interface. That works, but found out
that for SD it's using a TabDialog with two TabPages with the same *.ui
file. To avoid problems for now, adapted to use PageIDs again, marked in
the code as to-be-changed.
Change-Id: I30af6367f4d3c1e9097b1fe3d2b230ab4eab5ed7
|
|
Change-Id: Icc219fd6d2d8fc555f8e54d1fd0116e5976c5f7b
|
|
TabPabe Identification to UI-File names. Isolated some data
initialization constructs. Added more dialogs to dump. Should dump on
all systems now
Change-Id: I7ee07309e0bf88064f789c13bcbff93c17370f77
|
|
Change-Id: I1886d832bb9474371ea27d4d36f0446b221246d0
|
|
Fixes build breakage on Linux with a system cairo.
Change-Id: I4ef52fbd4a95f72c78433038654571d59efe8996
|
|
I think it's best to not use cairo on iOS, even if we do use it on
Android. We probably want to use native APIs for the functionality
that cairo would provide. Just like we do on OS X.
No idea whether the resulting TiledLibreOffice will still work like it
used to in May last year, when I last tried.
Change-Id: Ie15cad6918d7a66e2aff7faabfcade7f3246b060
|
|
+ New container: sfxlo-BigToolBox
+ Writer: Paste button with dropdown menu
Change-Id: I8fa9ff2cbf594078cc2347bef790b8647ce4e6ea
Reviewed-on: https://gerrit.libreoffice.org/28156
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|
|
that are better declared as OUStringLiteral
Change-Id: Ifb5d9a12bb31a68641940bec16971a8181a46567
Reviewed-on: https://gerrit.libreoffice.org/27377
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ic660ba53b450071ad222a3c1adb13e908dbf0023
|
|
The show after hide is seen as "InitShow" which find the optimal size for its
contents. That's ok if it was a toplevel dialog, but its not in this
circumstance of a docked docking window and has to live with the given size.
This seems to have basically come unstuck with
commit 05d4077b724f91fca736d3c3fd64f28e304d7172
Author: Caolán McNamara <caolanm@redhat.com>
Date: Mon Sep 1 07:17:09 2014 +0100
rearrange matters to get FloatingWindows working loaded from .ui
Change-Id: If47bb392c8235d946bb2fd07448c6f48479a5163
|
|
Change-Id: Id7ddc0fc1f57c5e8e7fb002e31d54fb8e9f8ffab
Reviewed-on: https://gerrit.libreoffice.org/28050
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I78513a531f93f6578290107b1d71977820dac965
|
|
Add a flag to the OpenCLZone indicating whether we are performing the
first-start OpenCL functionality verification, so that if we run into
a crash that is caught by the VCL VCLExceptionSignal_impl() handler,
we terminate the process with the EXITHELPER_NORMAL_RESTART
status after first having disabled OpenCL use. The wrapper process will
then restart soffice.bin. This is for Windows only so far.
This matches what we do if OpenGL fails early during start of
LibreOffice.
Change-Id: Ibb9bf3a86b7521bf16728de2a118ad4323be674b
Reviewed-on: https://gerrit.libreoffice.org/28086
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
after commit 500a3be0 "loplugin:countusersofdefaultparams in vcl..xmlsecurity"
Change-Id: I09b07f241dc45f2d23370addfb1bc10aa2caedc4
|
|
Change-Id: I538596a99e632178d928ff7e66ad45c71b73c6fd
Reviewed-on: https://gerrit.libreoffice.org/28018
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I48e26b775337809759f8a76be7a9c457c94cd5c9
|
|
Change-Id: Ia06b9b189033b9409d7a59a211866f66a0614886
Reviewed-on: https://gerrit.libreoffice.org/28016
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Just to get this one file to compile. More errors come later. I just
spent a short time on this while waiting for something else.
Actually I have no idea what we should do on iOS nowadays. Do we want
to use cairo? Do we want to use OpenGL? Would it make sense to mimic
what we do on Android as much as possible? (But what do we do on
Android, and is that by choice or accident?) Even if that might mean
not using APIs native to iOS, but slower (not HW accelerated) FLOSS
alternatives that perform the same functionality, broadly speaking?
Change-Id: Id88a895b90f753417eced744141376656bcf72c3
|
|
Change-Id: Iede85fc847b330b5586b95facafb690df7209d1b
|
|
Change-Id: I5e248ed670502a2702f08e31739a8c82c29d5302
|
|
Change-Id: I55223078e189416c4181141a7a904e93d5c6a01e
|
|
Change-Id: I4b4c7c22482ca0ee45a114798fcab65a9dc69789
|
|
Change-Id: Icdf2a908d131ff05a1c00b7305686edba26d4b24
|
|
Needed to manage https certificates and authentication whenever
needed.
Change-Id: If20b85a9b349b203a8c46d453afa823629d114cb
Reviewed-on: https://gerrit.libreoffice.org/27927
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Giuseppe Castagno <giuseppe.castagno@acca-esse.eu>
|
|
Change-Id: I34fc490407f2bdac036dced5360b438ffb1cb4e2
|
|
Change-Id: I90d280dd041051d8d8433519a7ad7fc17117fd74
|
|
See e.g.
http://crashreport.libreoffice.org/stats/crash_details/2218a489-b64c-4193-a7d4-cd01c6a607cb
Change-Id: I6c123d3e9e5c6dbcb7756a686503904cbfd944a4
Reviewed-on: https://gerrit.libreoffice.org/27948
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I5710ce91e804641d4c997bc3d06970a5ed0cb5b1
Reviewed-on: https://gerrit.libreoffice.org/27890
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
There is no <QuickTime/QuickTime.h> in the 10.12 SDK anyway.
Change-Id: I0d937d4b036d118fcb503543a516e55f859a3718
|
|
Change-Id: Ia4491a8659c8e6532681f7fca83b432e311d79d6
Reviewed-on: https://gerrit.libreoffice.org/27881
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <eszkadev@gmail.com>
|
|
for tdf#99446 and rhbz#1283420 there is a hackaround which ended up in 5.1.5,
which is not in 5.1.4, for corrupt glyphs under X. I can still reproduce the
problem if I drop the CAIRO_OPERATOR_DIFFERENCE usage here with master and
gtk2.
This alternative hackaround to force a read of the underlying surface works
just as well (help->license information is the reproducer).
Change-Id: Ie3c5b07409537a1734226b4ce034620351297e25
|
|
Change-Id: I425b1005297b20ace85181edce72ab5829006a0e
|
|
Change-Id: I5b17103e838f221cf3815002979c6b8c9c443300
|
|
regression apparently since
commit 825b3df7f1d987021ec4a08ff8e7ed78e5772c97
Date: Thu Oct 22 19:03:01 2015 +0200
tdf#94138 fix printing of edit form fields
revert the GetDrawPixelFont part of that so the font is pulled
from the control and not the device its printed to, this makes
tdf#97120 and tdf#97120 work properly again
then revert
commit 6c41727484a04ab89005ffb052937dae5d7dc223
Date: Tue Dec 1 17:44:23 2015 +0100
tdf#94138 Use correct fonts for multiline edit when printing
because that replicates the original GetDrawPixelFont behaviour
so its not needed after the other revert.
Then, to solve the original tdf#94138, in the edit StateChanged handler call
ApplySettings(*this); like FixedText::StateChanged does to merge in the
controlfont setting to the underlying OutputDevice of the control, which
presumably is what is then retrieved from GetDrawPixelFont
Change-Id: I992a0e2011ffce7748d39f7f2bc49fbf6b8eaa79
|
|
Change-Id: Ied73966633e5ffd56faccea7ec1408bd83642b58
Reviewed-on: https://gerrit.libreoffice.org/27862
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
ENABLE_OPENGL means whether to enable the OpenGL slideshow transition
code. It does not mean whether to enable use of OpenGL in general. So
rename it to ENABLE_OPENGL_TRANSITIONS while at it.
ENABLE_HEADLESS means whether to disable use of X11 and OpenGL on X11
(and Wayland) platforms, I think, meaning Linux and maybe Solaris and
the BSDs. Maybe it should be renamed to DISABLE_X11_AND_OPENGL.
Change-Id: Ibb30f51646b1bcc477fe691a3fa38c7a1e3944ae
|
|
this is closer to how I seem to see the gtk menubars work
(gtk3 is native now so this doesn't affect that)
Change-Id: Ie5225d2ccda698946f26408aae95d2a50cbb928b
|
|
keyboard not used yet.
The gtk2/3 menus appear to work this way. (And when not in gtk2/3
it shouldn't disable the accelerators for other platforms anyway)
Change-Id: Ib7a99bd9039cd07120b3b77380f810b5b028fd57
|
|
this returns things to passing the alt to the thing with the focus
and depends on ::Command handlers passing the alt-press/release back
up through the Command hierarchy to get to the default top-level
handler eventually
Change-Id: I869120f43810adfa2fac4670c2db143b790a1f9b
|
|
Apparently in some remote desktop situations the device string uses
"RDPDD" and not "RDPUDD". No idea what the semantic difference is.
Change-Id: I85532b90d759d02fffb73d0f3d22166aefd4edab
|
|
Client code in sw, sd, sc and svx is adapted, the rest is just a
placeholder for now.
With this, e.g. the undo item for Writer's insert comment properly
tracks which window was used for the insertion.
Change-Id: Idad587e6ca07ba69bf59aa7013b251af8bf95bab
Reviewed-on: https://gerrit.libreoffice.org/27781
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Iddb0d84b6dbfeb263a68ddc3b8b5c39bbdcf46f6
|
|
Surround ImplHandleIMEQueryCharPosition() by
ImplSalYieldMutexAcquireWithWait() and ImplSalYieldMutexRelease().
Change-Id: I3843ad351f3b92801cd1e0066a3c73f2a52c44bd
Reviewed-on: https://gerrit.libreoffice.org/27117
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>
|
|
so it could be used from things that aren't dialogs
Change-Id: I649c5a05ad9c0634be9cef2bbe16a4643e58fc12
|
|
Change-Id: Ia4ce895d3562b29db648a7b568121a2867088493
|
|
on wayland I'm getting a GDK_MOD1_MASK and a GDK_META_MASK
on pressing the left alt. The check for KEY_MOD2 in
Window::KeyInput trips up with the extra KEY_MOD3 bit set
so the auto mnemonic underlines don't appear on pressing
left alt under wayland
Lets map only GDK_SUPER_MASK to KEY_MOD3
Change-Id: I1e9cc9fc095f5edfa7ad7c71440232c6de1ecf04
|
|
Change-Id: Id260c776241cfa5af35c51ccee7ba6942a353f8d
|
|
Change-Id: I4c8dabbd2eeac2e3edb72a426687af8692c77497
|