Age | Commit message (Collapse) | Author |
|
Change-Id: Id980f09c198ca976c88b11030f5db9d6f010add1
Reviewed-on: https://gerrit.libreoffice.org/32274
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0aae6774ee0b42d32838b9010ddddaa33324c6c6
|
|
Change-Id: I4cf82ca8530f8b244be593e10976965be2ef2b60
|
|
Change-Id: Ibb1430d2b6c7994b2425d686cf206d168530faef
|
|
Change-Id: If68637fe49b5d252ad4ec5d63d56261113be6a7c
|
|
Change-Id: I16ec63beb801073e5d604d852892c2fd6e8d8fc3
Reviewed-on: https://gerrit.libreoffice.org/32272
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which had served since d441fa1f8cc0a17a2bc166bf2f2a44f76b83a773;
we now have polymorhpic std::abs.
Change-Id: Ibe48ac51508f7d9f5a44d712550237db7f553df3
Reviewed-on: https://gerrit.libreoffice.org/32225
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia289a7b63bf8797085315218785e2a2a4c45d232
Reviewed-on: https://gerrit.libreoffice.org/32230
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
SfxTemplateManagerDlg now overrides behaviour of ModalDialog on
EventNotify by checking if the pressed key was esc and
the searchFilter is not empty and it was focused. In this case
instead of letting ModalDialog close the modal
it clears the searchFilter
Change-Id: I90d91a3b152f68b6c8780963d1b95258d9ccf23a
Reviewed-on: https://gerrit.libreoffice.org/31736
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
ComboBox just uses ListBox internally
Change-Id: Ieed279160db1c9918bd9f3e37102b59ea62f0581
|
|
The custom shape popup toolbars used their own drawing code for
the drag handle. This was dropped in favour of the default toolbox
drag handle code.
This also drops the drag highlighting in favour of a move mouse
cursor as the drag indicator. The drag handle is currently always
drawn on the top, like a window title.
Change-Id: I08cbf715f1e240c2eb6d9a61fad2b705f9bd8014
|
|
Change-Id: I405160743609aae92a37b2359bea5aa42ee66519
|
|
It seems unused in the first place.
Change-Id: I556ae97b86498c63315f1f1bbe8d55fdbb10c1aa
Reviewed-on: https://gerrit.libreoffice.org/32218
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6c7b508eae23cf6046ba07fb00ae5e63d5efc57f
|
|
Change-Id: Ia56bd463c83c0aedcc7f4e9cf1b65c57104d78f2
|
|
SFX_EVENT_CLOSEAPP and SFX_EVENT_TOGGLEFULLSCREENMODE are never
generated,
so remove them and delete the code that receives them
Change-Id: I2d003ba73fff0b02120ba29ff58e1d2399dedf00
Reviewed-on: https://gerrit.libreoffice.org/32168
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...at least with --disable-pch it complained
> [build CXX] canvas/source/directx/dx_bitmapcanvashelper.cxx
> C:/lo/core/include\vcl/vclptr.hxx(98): error C2027: use of undefined type 'OutputDevice'
> c:\lo\core\canvas\source\directx\dx_devicehelper.hxx(33): note: see declaration of 'OutputDevice'
> c:\lo\core\canvas\source\directx\dx_devicehelper.hxx(109): note: see reference to class template instantiation 'VclPtr<OutputDevice>' being compiled
Change-Id: I3ba90acdb632fc209b8137818e30fb771ba0807c
|
|
ImplImageTree was used outside of VCL which is not consistent with
the name and the header also contains a lot of implementation
detail. This separates the implementation to ImplImageTree and
the public interface and singleton to ImageTree only.
Change-Id: I3a26444f0f6971a6b1d83472e9cef19c93192d3e
Reviewed-on: https://gerrit.libreoffice.org/32134
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
no point in having a template and a virtual base class when it's only
used for one type
Change-Id: Idb1a1a551064cc10896eff33652038eb5be0297e
Reviewed-on: https://gerrit.libreoffice.org/32041
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...by:
* making the OUStringLiteral ctor non-explicit (to be exploited in a follow-up
commit)
* adding (LIBO_INTERNAL_ONLY) overloads to OUString/OUStringBuffer functions
that can now take OUStringLiteral in addition to taking "real" string literals
(Keeping the number of overloads smaller by replacing the ConstCharArrayDetector
overloads with ones taking OUStringLiteral (for LIBO_INTERNAL_ONLY, at least)
and relying on the now-implicit conversion from "real" string literals to
OUStringLiteral unfortunately would not work: Both OUString and OUStringLiteral
argubably need implicit conversions from "real" string literals, so any function
overloaded for OUString and OUStringLiteral would be ambinguous when called with
a "real" string literal. And removing the OUString ctor taking a "real" string
literal and relying on an implicit conversion chain from "real" string literal
to OUStringLiteral to OUString doesn't work because it would involve two user-
provided conversions.)
Change-Id: I14433fc1605b048807f60b3a3e14f92221d3a226
Reviewed-on: https://gerrit.libreoffice.org/32097
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I18b052cadb061535d7552f2ec1eac4b932489d22
|
|
Change-Id: I65ab9176b39a436afce23e6bd4423ebf76219166
|
|
Change-Id: I24a0e495b64a1db8b7c45f3c68e06ad3301bd9c4
|
|
Change-Id: Ie74d4f3258ef553b4febcc544204080d8c6e0f40
Reviewed-on: https://gerrit.libreoffice.org/32046
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
|
|
But function definition uses "pSFrom" instead anyway, so consistently use param
names from definition in declaration.
Change-Id: I03fb8dd0fbab5c84f89c7276849d62f9a17cbfea
|
|
Change-Id: I1beafff257e968a62184f8b1d8cf2a3a24e7c945
Reviewed-on: https://gerrit.libreoffice.org/32039
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
...that were apparently meant to flag cases where conversion from old tools
strings to rtl strings was done wrongly. But that flagging is probably of no
use: SAL_INFOs are usually disabled, so won't be noticed; and SAL_WARN or assert
would not be acceptable, as cases like 'nLen == 0x0FFFF' can legitimately
happen with long strings. I did a successful 'make check' with these SAL_INFOs
temporarily turned into assert, so there seems to be at least no gross
conversion error remaining.
Change-Id: I57f11db9119fb12555e3bfef17c077ee5eef3844
|
|
...deriving from VclReferenceBase. Complicated by the fact that the argument
type may be incomplete at the time of template instantiation. So this approach
may be less precise than the change to loplugin:vclwidgets from
cbf5b21f2a65bbb342295200f6ad93a00f90733e "Catch some misuses of VclPtr
construction" when the argument type becomes complete later in the comilation
unit. However, this approach would also catch the two misuses in UnoControls
found by cbf5b21f2a65bbb342295200f6ad93a00f90733e, so go with this approach for
now and revert the change to loplugin:vclwdigets.
Change-Id: I7888f23d2b9e2db81ae2ce4bf4c8277912317685
Reviewed-on: https://gerrit.libreoffice.org/31966
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Ito probably made sense only with bitmap fonts which we no longer
support, and if we don’t need the fallback for printer devices then we
don’t need it on screen either (that whole printer/screen distinction
needs to die someday).
Change-Id: Icf77cd70f0f1b2c186a3c856900295caba72e903
Reviewed-on: https://gerrit.libreoffice.org/31914
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Change-Id: I2d2cb285d8a5cb2f61aa9b8bd9bec0716b1f4c7a
|
|
... because that now is what it is about, it's just used in page numbering as well.
Change-Id: I5516b6babcd5438b6505d189943c21abfbe35a7e
|
|
This reverts the following commits:
commit 722f4e1d86710f2facd37d7e040df9e1fd585e26
tdf#104573 - Assertion failed: SolarMutex not locked
commit f04ec99f5e6a543b8191ced61db4710c3c0de356
tdf#104573 - Assertion failed: SolarMutex not locked
commit 71b1e3ff6374c23e65200d3bcafca387d29af04f
tdf#104573 - Assertion failed: SolarMutex not locked when trying
commit e794ce1eef6730e5a46d5fb0aa6db2895ede85e7
verify that we hold the SolarMutex when ref-counting VclPtr
IRC discussion:
<noelgrandin> sberg, maybe I should revert this whole "VclPtr assert" series, I don't have mental bandwidth to sort this out properly now
<sberg> noelgrandin, what I fear is that you'll end up adding lots of SolarMutex locks to small places, where the proper fix would be to add it further out; and once such a dreaded recursive SolarMutex lock is in place (but needlessly so, once the proper fix is done), it's hard to clean that up again
<noelgrandin> sberg, yeah, in that case I'll just remove all of this, leave it for another day
Change-Id: Ie4f84b72b79a1b7e80164b5c7693af398c2c569a
Reviewed-on: https://gerrit.libreoffice.org/31946
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
all of them work, except "Fall" doesn't look right, but it has
the exact same problem under gtk2/gen to.
Change-Id: I73cb9c0fb8211f727198be78d90d4f80a4f8c7c8
Reviewed-on: https://gerrit.libreoffice.org/31214
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
because that works under wayland out of the box and gtk3 uses it already
Change-Id: Iefaac31e325534a81a5389f752804af917c1baef
Reviewed-on: https://gerrit.libreoffice.org/31213
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib1fc80c79355322489b7ebd37cbbbbb6614ec67a
|
|
Change-Id: Ie46f0e2b60b99aea1c322c7891a41a2e7603c9e9
|
|
Looks like the XRestartManager keeps all command line arguments when
restarting, so it also keeps --safe-mode.
Solution is to add a flag file when restarting from safe mode,
to prevent going into safe mode again.
Change-Id: I9820d3ccbddf98b0bf6132f254c989f52ea5e808
Reviewed-on: https://gerrit.libreoffice.org/31913
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I133a6441824bfbefcfcda130119b5c5d706f86b2
Reviewed-on: https://gerrit.libreoffice.org/31907
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9a897af88aa9f6f7ca98ce521c69b5a4ee8462e9
Reviewed-on: https://gerrit.libreoffice.org/31903
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
sal_Bool and sal_uInt8 are typedefs for the same underlying type, so any use of
ORowSetValue with sal_Bool instead of bool, apparently intending to treat the
value as a boolean, actually treated it as a TINYINT. (See e.g. recent
7b0c57b2faec875c790051d233d1e9abaed2a3bc "some compilers don't like implicit
bool-to-ORowSetValue conversion".)
Now that there's no way to create a sal_uInt8 ORowSetValue, getUInt8 and the
m_uInt8 union member can probably go away, too.
Change-Id: Ia27554f76e7e9edce6410284b578064573e54fd3
Reviewed-on: https://gerrit.libreoffice.org/31909
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6b224fa890dc96aada7140af27078da5e25c3ff8
Reviewed-on: https://gerrit.libreoffice.org/31898
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5b7c6992e92e4d096b8230774ed8f4bfaaad5831
|
|
Looks like it was introduced by
commit 19b34c0039c6293f9b37aa70f8055aa2be28ba09
loplugin:passstuffbyref in svtools
and since it's windows only, probably some subtle mis-compilation.
Aron Budea tracked this one down.
Change-Id: I77e65ea8a1fb0003d6ff0f3b0f8019f275ff3462
Reviewed-on: https://gerrit.libreoffice.org/31893
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There was a race condition that the OpenGL code was initialized before
the old report has been uploaded. Therefore the OpenGL setting was
overwritten by the new start and we were not getting the old value.
Now we store any value that wants to be added before the dump.ini is
ready in a temporary map and will write them as soon as we write all the
common information.
This problem was introduced by the dialog requesting permission to
upload the crash report.
Change-Id: I29391a1ff56bac6381218c5a4aefb58c2c03f024
Reviewed-on: https://gerrit.libreoffice.org/31846
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
There is no such thing as simple text layout in this brave new world.
Change-Id: I641b7efa5ec8fdd9839c291e7f2fdb736361ef1e
Reviewed-on: https://gerrit.libreoffice.org/31824
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
MultiLineEdit is a special control which can have
more text portions with different text attributes.
Change-Id: Iab51dba0d0344fad4358f4961c968c031b1660b6
Reviewed-on: https://gerrit.libreoffice.org/31813
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
For markers (resize markers, anchors,...) we contain them all in
one image atlas. This was generally done because of resource
limitiations in Windows 95/98 which aren't a problem anymore in
present systems.
This is however problematic in HiDPI as we scale the image and
the coordinates of aren't correct anymore. Another problem is
that it uses its own cache instead of common cache in
ImplImageTree. So this commit extracts all the markers into its
own images for galaxy theme and uses them when we scale.
In the future when we extracted all the markers to its own
images for all icon themes we can remvoe the old code with the
image atlas.
Change-Id: Ibee181b529d30e20050df8cd396d338bd53532c0
|
|
Change-Id: Ieb58ed113c6a3e85a806ec57a6557e2d37bf9b06
|
|
Change-Id: I7bdd15a93e728ef7e98a53001c6eb6b56f761a6d
|
|
Change-Id: Ifacff75f80bc8401ccff2a4d4dc90e56e3b4aa84
Reviewed-on: https://gerrit.libreoffice.org/31801
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|