Age | Commit message (Collapse) | Author |
|
Change-Id: Id70f9e55fb4ad7d3a501399b055208ea10369c82
Reviewed-on: https://gerrit.libreoffice.org/23131
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I67e6076d65b90fb386ab439c5716820a6322af38
Reviewed-on: https://gerrit.libreoffice.org/23130
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0a3f17d43917d05734980329231ef6e7cadfd58a
Reviewed-on: https://gerrit.libreoffice.org/23129
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2dfce92ef98ca18ac0fe2c415240216228b4ee0a
|
|
Change-Id: I554fde45000114dd19f117d93ef5c7a780231594
|
|
Change-Id: Ie62bbf64a9cdb74725fd48a8f8dcc1ab76d97219
|
|
Change-Id: I6c0aaac10b2244271f3cdf45f4eceb6d685b213c
|
|
Change-Id: I751e75e0b63e95cc92be7b61a77ed21eeb52bc1f
|
|
for wayland
Dragging toolbars around to move them (starting with an undocked toolbar, not
the moving outline fake thing) doesn't work under wayland (as far as I can see)
without using gtk_window_begin_move_drag i.e. gtk_window_move doesn't work.
But this is supposed to be used from the initial mouse click (while it works
under wayland from a move, it doesn't work under X from a move) so rework the
last attempt to occur right at the initial click to drag.
Change-Id: I612f188b3e8482307bc816f5aa775530e6092eda
|
|
Change-Id: I80a2d935d92c8330f3815b6e79ccc58bc39541b0
|
|
cause wayland is sticking a title bar into the toolbars otherwise, sigh
Change-Id: Id012e9508cc0dfafbda344974a96d8a038c6c9f4
|
|
Change-Id: Icb135c12b2bc159e0542994bb496b45bf1fdb9e2
|
|
They were all in fact doing exactly the same, so do it at the call
site instead.
Change-Id: Id61cf9f5881411ddb7df5c3fd98c83252637e4d7
|
|
(as some tests derive from the latter only for the Directories part, not for the
setUp/tearDown overrides: those tests will be cleaned up next)
Change-Id: Ib6b78eea868b8bc21d4cc6e8fd9e1d025deca05f
Reviewed-on: https://gerrit.libreoffice.org/23078
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iba02e6a142b52d00c824eeddb1970546f7aba3e9
|
|
Change-Id: Ieaebacd43fa27b91b1ab3e6704bb591488954492
|
|
Change-Id: Ica19aef9b94e0c11e014f48b7801ecb0c110c44b
|
|
Change-Id: I0357af933795aad10db8ab23ae9ef0373e73287f
|
|
Change-Id: I7015bd2e13d5bf08cb9181dc9470372f0b3002c0
|
|
It used to render just black boxes.
The change in DrawTextImpl() semantics from
61085083e4a5060ba7e2135818264d63c6da13c2 was not properly implemented
in the new Graphite code. The return value is not some kind of
"success" indicator, but tells the caller whether to continue the loop
at that level.
We do need to call FillRect() to fill the requested rectangle of the
HDC with white. On the other hand, the call to Clear() is not needed
and in fact makes no text show up.
(I now see that that same code snippet that calls FillRect() is used
in all the DrawTextImpl() implementations, so it should be factored
out to the call site in WinLayout::DrawText().)
Change-Id: If0533ea1edf065b06ae888c6e57c026f447bcf78
|
|
signalIMDelete and Retrieve Surrounding Text search for the accessible
context that has the focus. When a context with the FOCUSED state was
found it was automatically returned, assuming that the reference was valid.
In Draw tables, especially when using the arrow keys to move between
cells, that often was not true. So, instead of returning a broken
reference, keep searching through the children until a valid
AccessibleEditableText item that is marked as FOCUSED is found.
Change-Id: I71e3e9bfda56d1dfbdbd93945882560a39e40714
Reviewed-on: https://gerrit.libreoffice.org/22263
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Merge in some interesting font / unicode combinations from bugs.
Change-Id: I2c89cf505a7850fcc482826328e1cdb8e37508aa
Reviewed-on: https://gerrit.libreoffice.org/23056
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
when deciding if a popup needs to be placed up or down to stay
visible on screen
Change-Id: I718e0ee4a79152e919ac95841e15d4b53764ac78
|
|
Change-Id: I1a3286b2f967f50fbaef7e3726e48ae82fd145aa
|
|
Change-Id: If3942704602b82bc99ce49a230930ef59cc862da
|
|
These include were needed to compile on Windows, MSVC 14.0 with
clang-cl.
Change-Id: I4ca5cec8314920e90fcca6fa69ec4df87d680f29
Reviewed-on: https://gerrit.libreoffice.org/23044
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
ExTextOut has a bug on Windows 7 and above where it incorrectly
positions certain diacritics, using DirectWrite and Direct2D fixes
this. Implemented on-demand loading of the DLL so the old ExTextOut
based renderer will be used when drwite and d2d1 cannot be found
allowing this work on Windows XP (where this bug doesn't seem to occur)
Change-Id: I767d62c8188511e745373b61ba51e7e2745f7b8b
Reviewed-on: https://gerrit.libreoffice.org/23020
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
|
|
Change-Id: I5725ec23869b295c8021bef0330ee6f69f206351
Reviewed-on: https://gerrit.libreoffice.org/23024
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I4fca1e813eccfeb5185e7a50aa301e7ad1ee61b5
Reviewed-on: https://gerrit.libreoffice.org/23015
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I70eb0e2ff96879d1168b241852a0079f540b0319
|
|
Change-Id: I2114436f4bef3ac71a3035a206186cefaf88bca1
Reviewed-on: https://gerrit.libreoffice.org/23023
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Icbb9e2590f1b8b18c021b978baf7f79c838c4c9c
|
|
Change-Id: I5cac6fb0278e3952e2538f06188ed510644fcaa0
|
|
Change-Id: I343844aca956a1ce05c733f60a28d51115574ef8
|
|
i.e. the position provided is the location where the popover is to be drawn,
not the bounds of the thing to be pointed to, so adapt them so gtk will point
to the desired place.
e.g. the slide names/numbers in the presentation slide view sidebar
Change-Id: I8c87d5dba32e27f9e627b3282f34d87a8ee460ca
|
|
Change-Id: Ic439affbd69532534f5caf82a743786d5975939e
|
|
Change-Id: Ia414f7845425ef73859ed04853378e96cc738795
Reviewed-on: https://gerrit.libreoffice.org/22971
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I39e9fcfdf2203239ac56d1c8195ca7ac07054817
Reviewed-on: https://gerrit.libreoffice.org/22898
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
to catch calling params with defaults like "= OUSString()"
Change-Id: Iad060e318ed492c22f8be44e326174fe6d28fff9
Reviewed-on: https://gerrit.libreoffice.org/22932
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I03d7381aad055cbe9bd905e4082586073f4112e0
Reviewed-on: https://gerrit.libreoffice.org/22900
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
The preamble was inserted into a false position so the shader
could was constructed incorrectly and would fail to compile.
Change-Id: I4c51adde9014a326bbe38a5d2d17dd0047e33195
|
|
Force cast to double to avoid integer division - which gives a
wrong inverse scale value.
Change-Id: I0135e44ef07f3915619f9dfead9aadf50fc03685
|
|
Issue is a regression in commit 09c722873b2d378d2d155f5f1dd7d8f3fb2012e9.
(EMF/WMF: fix rendering of pen styles (dash, dot, dashdot, dashdotdot).
I've looked at how the latest version of Word on the Mac works, and it
turns out that the spacings for the PenStyle enumerations in the LogPen
objects for all the create pen EMF records are as follows:
* PS_DOT - ■ □ ■ □ ■ □ ■ □ ■ □ ■
* PS_DASHDOT - ■ ■ ■ □ ■ □ ■ ■ ■ □ ■
* PS_DASHDOTDOT - ■ ■ ■ □ ■ □ ■ □ ■ ■ ■
(where ■ is the actual filled in area, and □ is the space between the
filled in areas)
In other words, each dash fills in the space of three dots, and there
is the one dot worth of empty space between the dashes and dots. Each
"dot" has a width and height equal to the width specified in the pen.
So basically, we seem to be arbitrarily setting the dot, dash and
distance lengths arbitrarily, which were reasonable guesses but tended
to produce very odd lines at different zoom levels.
Change-Id: Ie8b5fa396e4fb0f480cb3594c8129a59f472c1b8
Reviewed-on: https://gerrit.libreoffice.org/22886
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
In OutputDevice::DrawPolyPolygon when b2dpolygon are used for drawing
the source polygon is not drawn on the alpha device.
Change-Id: I54f4e5a13469d9844866cea61b074420219b836d
Reviewed-on: https://gerrit.libreoffice.org/22892
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I25ca4b8672702095cc04723bc9c6bdf01a06382f
|
|
Change-Id: Ib333ad2880e0a1cbfed2f6a919ca2b92f42dde45
|
|
Change-Id: I0ac1ba124ba452deeeeaa473ccbbf865e490c447
|
|
Change-Id: I1e26a805ac96f1c57d2f7c795b598c4eaa8d2a3e
|
|
Change-Id: I4893f538911449953fadf4cf10f6adb819bc023f
|
|
Where wglChoosePixelFormatARB is defined as a macro expanding to
__wglewChoosePixelFormatARB (as WGLEW_GET_FUN is just expanding to its
argument), and __wglewChoosePixelFormatARB is declared in global scope in
workdir/UnpackedTarball/glew/include/GL/wglew.h.
itself) in workdir/UnpackedTarball/glew/include\GL/wglew.h
Change-Id: I0c4d09e9112c2233d25a262ea1f2b35bdf49645c
|