as part of a longer-term goal of doing our
widget rendering only inside a top-level render-
context.
I moved all of the OutputDevice-related code that existed in vcl::Window
into a new subclass of OutputDevice called WindowOutputDevice.
Notes for further work
(*) not sure why we are getting an 1x1 surface in
SvpSalGraphics::releaseCairoContext, but to fix it I clamp
the size there
(*) might have to dump VCLXDevice, and move it's code down into VCLXWindow and VCLXVirtualDevice
(*) can we remove use of VCLXDevice in other places, in favour of just talking to the VCL code?
Change-Id: I105946377f5322677d6f7d0c1c23847178a720b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113204
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
regression from
commit 5aa60be574
fix leak in VCLXWindow
it's too dangerous to dump the Impl during dispose(), because if I do,
the Impl is removed while we are iterating over listeners.
So just be check mbIsDisposing more heavily to prevent new references to
the VCLXWindow being added after it is disposed.
Change-Id: Ibb00a289440d24f531072ef5809613d5e8a0a98f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115598
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...in 197bcde5c4 "loplugin:refcounting in
svtools", see UBSan
> toolkit/source/awt/vclxtoolkit.cxx:1912:22: runtime error: call to function CreateWindow through pointer to incorrect function type 'vcl::Window *(*)(VCLXWindow **, const com::sun::star::awt::WindowDescriptor *, vcl::Window *, long)'
> svtools/source/uno/unoiface.cxx:29: note: CreateWindow defined here
> #0 in (anonymous namespace)::VCLXToolkit::ImplCreateWindow(com::sun::star::awt::WindowDescriptor const&, MessBoxStyle) at toolkit/source/awt/vclxtoolkit.cxx:1912:22
during CppunitTest_toolkit
Change-Id: I1fdf977ed8f0ae67c09ba1e1565499db3f9f1af3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111305
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
because of the side effects
using a bare GtkGrid as m_pSocket in vcl/unx/gtk3/gtk3gtkobject.cxx
is perhaps a poor choice, getting its xid causes poor side effects
wrt events belonging to its child widgets getting delivered to
the SalFrame widget, so duplicate scrolling after showing a opengl
slide and/or showing a video and lots of flickering
we're (generally at least) not using the xid under gtk3 so don't set it
unless it's explicitly asked for. Happily the gtk Player::createPlayerWindow
doesn't use its arg[0] xid in any case, so don't bother setting it for
that backend.
Change-Id: I1c59a607a332635091782c3b49de10647558f301
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109941
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
to reduce the churn, we leave the existing constructor in place,
and add a clang plugin to detect when the value passed to the
existing constructor may contain transparency/alpha data.
i.e. we leave expressions like Color(0xffffff) alone, but
warn about any non-constant expression, and any expression
like Color(0xff000000)
Change-Id: Id2ce58e08882d9b7bd0b9f88eca97359dcdbcc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109362
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
It looks like handling the click by opening the URL
was added directly to 'FixedHyperlink' in
commit f0006e79c4
Date: Thu Oct 20 10:49:24 2016 +0200
Handle link click directly in FixedHyperlink
to deduplicate the handling done explicitly in various
dialogs by themselves.
The handling in 'VCLXFixedHyperlink::ProcessWindowEvent',
which did the same for the case where no action listeners
exist, there since
commit ea665e6fe7
Date: Tue Jan 29 14:05:57 2008 +0000
INTEGRATION: CWS fwk80_SRC680 (1.64.12); FILE MERGED
2008/01/24 12:27:38 pb 1.64.12.6: fix: #i83756# VCLXFixedHyperlink::ImplGetPropertyIds() added
2008/01/24 07:50:51 pb 1.64.12.5: RESYNC: (1.64-1.64.18.1); FILE MERGED
2008/01/15 09:14:01 mav 1.64.12.4: adopt for gcc
2008/01/15 08:13:04 pb 1.64.12.3: fix: #i83756# open the hyperlink if there are no action listeners
2008/01/14 09:48:30 pb 1.64.12.2: fix: #i83756# VCLXFixedHyperlink::get/setProperty() added
2008/01/11 15:04:28 pb 1.64.12.1: fix: #i83756# class VCLXFixedHyperlink
remained, though, so clicking a UNO hyperlink control
resulted in the corresponding URL being opened twice.
Drop the extra handling from there so this only
happens once.
(I couldn't quickly double-check that the URL is
only opened once before f0006e79c4
since opening the dialog from the sample file fails in
such old versions in the bibisect repo.)
Change-Id: I32eace51bf8f14e968a939398c2bf2fd6f83de28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105793
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
UNO dialogs since LibreOffice 4.0 permitted setting HScroll /
VScroll properties to enable scrolling for too large a content.
Conceptually clone this code over to TabPage as well, and register
necessary UNO properties in the toolkit UNO wrappers.
Add missing API documentation also to UnoControlDialogModel,
plus the new properties to the UnoControlTabPageModel
Layout code really doesn't like any extra controls it didn't create
itself - so create scrollbars only on demand.
Change-Id: I67894597ac104320e67ad7989ebf9a7955d99103
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105573
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel Grandin