Age | Commit message (Collapse) | Author |
|
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
|
|
and teach the plugin about code that takes the address of a function
Change-Id: Ia9d5afef44520aca236659e8176f1e27135ef4fc
Reviewed-on: https://gerrit.libreoffice.org/22861
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I3e6c84c1f49e9523e881ce12dbb2f7e0d1df956e
|
|
maybe we should be using more precision, but we haven't
been in the past
Change-Id: Icf1e1e95099c783435e04f60d8ade755a8d2d4d5
|
|
Change-Id: I8820d435e2f26d04ac3eccb710383399d050e020
|
|
Change-Id: I2594925cba1f7c9c90178906d9c782024ad1cf4f
|
|
Change-Id: I3f89aca650d31658ce17b3b1496a7babba23bdc6
|
|
Change-Id: I087c4939c19bc5966da45cb848d71e95ac982e33
Reviewed-on: https://gerrit.libreoffice.org/22854
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Consistency is important. (I know that we are wildly inconsistent in
many things, even inside individual source files. Like the spacing of
the expression in an if statement. But putting an opening brace on a
separate line is something we do quite consistently.)
Change-Id: I7c50628653b94a4da0fc4dc8db8869a5f1a64527
|
|
If position and size were loaded from the WindowStateData
structure there's no need to recompute the layout.
As an added benefit if the user previously resized/move the
dialog, the new one will open using the same geometry.
Change-Id: I306504080357f9be8f3e628ba13ca5dc2957dd52
Reviewed-on: https://gerrit.libreoffice.org/21850
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I8a469f73b682e32bbb15a71e5be9b64d8412f3f1
|
|
Change-Id: I921577df6c905e935d05ff0e9d2b2c6e8d22cc89
|
|
Change-Id: I976336d35366b661e402db484820b4dd9a7b0228
Reviewed-on: https://gerrit.libreoffice.org/22821
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I6ddd512afa1e41d2dec7c92f61d65ed5bbfa9ace
|
|
Change-Id: I6d10c7d20f9bc1dfcaa60ad89a9092fe06922074
|
|
Change-Id: I4c86082eca0e7618de30841e6fe7040be7326098
|
|
Change-Id: I2b7dd0ea24794d08557620dda8ca1de71244ec61
|
|
to sync these names with the the .desktop names
Change-Id: I1c4d8943e61b5ae537b865d5a9c3065894f200d7
|
|
Change-Id: Ib3e87d8a07f4e38f8dcb6e1226f91920df53c81c
|
|
Change-Id: Ic102a5a1193a8bc50b460e5897b1ca488f0d4a65
|
|
Change-Id: If851dbdb034384395ba590fda61f3383f5ef791a
|
|
Change-Id: I0605e570022f6eb57d453a3eb8bea5f4314c8229
|
|
Change-Id: I7c4b05cd02dee2b6efb926955759d725428e1dc1
|
|
We already can use different labels for commands, based on
whether they're in a menu, context menu or a toolbar. But in
some cases we need different labels for the same type of UI
element, or even different icons.
One example is page/slide commands in Draw/Impress, as they
share same commands, but need different icons/labels.
Creating full-fledged duplicate slots just to satisfy the
need of UI representation seems like overkill, and isn't
flexible enough.
The proposed solution is to allow creation of command entries,
that do not correspond to real application slots, but instead
link to another existing commands. The "real" commands will be
used for controller factory and dispatch (execute/status) APIs,
thus fully retaining functionality.
This can be useful also for giving icons to complex commands
(i.e. commands with arguments).
Change-Id: I9b261b406ec8fc781cae06cf283963386379d4ad
|
|
Change-Id: I8fd2ffe5908074417aa5cfc00adbc54b6e9ed360
|
|
Change-Id: I5bac3a484b78c68022d2533cbedaf89259b189a9
|
|
Change-Id: I1e0e10d1561e32c5904e0e7352e914bb62b85363
|
|
Change-Id: I2b6c219c95e94cbbee4a7fbe7c2a2ffa45d0e151
|
|
Change-Id: I6be61592a16660d62be583e082ffcf5b1907770f
|
|
the css foo is modeled on the similiar gedit close buttons
in its tabs
Change-Id: I7af32ad0434a49c52eea215f797c502be7f96dac
|
|
Change-Id: Ibb75aa3eae99e499e1c2026c41b0bf51d7f8cf31
|
|
Change-Id: I481fe73256bf0d974c54a6419874fa76ea4beaa6
|
|
Change-Id: I5ef9d7bcff3fcc2b01c0e5578487a293c6e315df
|
|
Change-Id: I0c050396e6b1efa7dd2f003a79a9dc506135197a
Reviewed-on: https://gerrit.libreoffice.org/22555
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
including a fix for a rather glaring bug in BitmapTools.cxx
Change-Id: Id9db990b993cfeea9039c5fbaaa91996adeae22a
Reviewed-on: https://gerrit.libreoffice.org/22713
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|