Age | Commit message (Collapse) | Author |
|
a) give it a default implementation based on the current one
b) re-use code introduced for WeldEditView::DeleteSurroundingText
for the EditView containing vcl::Window in impress/draw and
various similar Annotation windows
Change-Id: I55547c70e90ee394795b5545450cf8131538fad8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104781
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
from InvalidateStyle.idl, so I don't have to keep jumping around to
figure out what this means
Change-Id: Iee7d5f2a83afba075f15c44a36a5b4a8def04724
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102160
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0cdb7b74487f2338d16eca85616f840d921dad5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101874
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4abfab9a413e3e43e23839f2cf3b0c26dcdea3a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101853
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4225ce786b83f44178a477ac034d8f8f5198159e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101852
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I031c42cd85395a777c20bdd052da4233bc2fedab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101414
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Make gtk3's 'GtkSalGraphics::drawNativeControl'
take into account a control's background color,
if any is explicitly set:
Set background/fill color (in 'Edit::ApplySettings')
also for the case where the control is drawn "natively",
but don't draw the background in the generic 'Window::Erase'
method for the case of native drawing; instead handle it when
drawing the control itself.
This adds an additional parameter to pass the background color to the
relevant '{d,D}rawNativeControl' methods (defaulting to 'COL_AUTO')
and implements the required handling to apply the background color
for the gtk3 case.
qt5/kf5 will probably be handled in an upcoming commit as well.
Windows as well as the "gen" VCL plugin were not affected by the
issue, so remain unchanged and just ignore the new parameter.
In a quick test on on macOS, the rendering of the controls
in the sample doc was broken beyond just the missing background
colors (s. screenshot attached to tdf#136094); the behavior there
also remains unchanged by this patch, the new parameter is ignored
for now.
Change-Id: I01923a504fea2367ae96032104f09099e35f410e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101284
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: I4116a3532b21f6066468bd3905efef1020ace101
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99233
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibc1ec64cba8eb083aaff28848a42337cc597ea19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98857
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8f55af19ba10b71bd621e69b27000ab7cb565309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96677
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib724da1f07be9e8f4d0d505f7f2886990cab661f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97022
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie624f0d57aea4d72c69f6cd73508d129e53721d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94722
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
in the document, looks like only the calc one actually works, and when
it works on large quantities of results calc grinds to a complete halt
This was introduced with:
commit b41332475783c31136673fb44cf4c411bb0148f8
Date: Mon Dec 2 15:54:29 2013 +0000
Integrate branch of IAccessible2
and has been a problem on and off with calc's potentially ~infinite grid
There is the on-by-default search results dialog in calc (which has a limit on
how many it shows) which provides an alternative route to iterate through the
results
Change-Id: I2685e480d2d15220be0bddbc83baad3992e7d5d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95006
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I45ce895ac67be9aaf137e0e4c79954488f23a6a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94637
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
90% of cases pass GetSizePixel as the Size arg already
and this aligns Window::Draw with how Window::PaintToDevice
works
Change-Id: If5b024179a4b7a3b099177c2f6d4b1fb006b95ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94644
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The check for source device's mpGraphics is moved into drawOutDevDirect,
since failing it must result in immediate return from the function.
Check for this->mpGraphics also moved into drawOutDevDirect, since it's
dereferenced in DrawOutDevDirectProcess, unclear why was it skipped in
some cases previously.
Removed unreachable warning.
Change-Id: I4ad882f8f60d6543786aef2ec1651e499d47874d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94463
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ifa90e9721edeacd4fd78fde968b81aab873e2061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94497
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icc1b53f068b94ff3b3f26b144f366344dcbff2ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94345
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I52187eccf6170f64d38c673a86dc80818813efa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94328
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
excluding the UDK headers of course
Change-Id: Iac7ab83d60265f7d362c860776f1de9d5e444ec0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93268
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To make the code easier to read.
Change-Id: Iebc648150391939fba5d1cd815c72dbcf02ceec6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90378
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so https://cgit.freedesktop.org/libreoffice/online/commit/?id=08d6c3fdf9bac4ad8318151ab1402690eb950f52
isn't needed
Change-Id: I8836969ae064342835287a63065e591f083f2220
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88433
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Extracted DrawOutDevDirectCheck and DrawOutDevDirectProcess. DrawoutDevDirectCheck checks OutputDeviceType and define pSrcGraphics according to its type. DrawOutDevDirectProcess perform some operations about drawing out according to its type and checks some pointers for avoiding NULL pointer.
Change-Id: I24247ee42d2dd686dbd13bb5f6b24bbe8fab43ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86229
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
All changes are formatted using clang-format utility.
Change-Id: Icfa7ae22bc06e57c7f7cb512813966dcefd4fc40
Signed-off-by: Adrien Ollier <adr.ollier@hotmail.fr>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/83601
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I53129ed6b57eb13898a426de0a2ba72c7d6674de
Signed-off-by: Adrien Ollier <adr.ollier@hotmail.fr>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/83825
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
In the tiled rendering case the dialogs, run asynchronous due
to multiple user access. In order to send the messages
to the client side, the dialog has to hook
a LOKNotifier in the constructor of the SfxViewShell.
However, the new weld wrapper classes use the Frame Window,
(i.e. Window::GetFarmeWeld()), as a parent of the dialogs.
On the other hand, in order to avoid getting the interface
implementation inside implementation classes, it has been
created a new method Window::GetFrameWindow(), otherwise
I have to do a bureaucratic conversion between Interfaces
to Implementations ( i.e. UnoWrapperBase::GetUnoWrapper() )
Change-Id: I32c34d82a89211a025250e65a05ce47d30efa0b8
Reviewed-on: https://gerrit.libreoffice.org/84215
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
It has defined a map container for every LOK windows assigned
a notifier to the client side. However the map container has elements
with VclPtr (reference counter) and it is a global data, so when global
data are disposing, the VclPtr will destroy the Window when the VCL
framework was destroyed that will lead to undefined behavior.
So this commit adds an assert inside DeInitVCL to ensure, if
someone forgot to Release the LOK Notifier.
Change-Id: Ib7f20751af2931f7b0ba3e3d526e734ffc33f171
Reviewed-on: https://gerrit.libreoffice.org/84792
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/84909
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
Change-Id: I65354c7476dfaede1a607441d7c1b0c7ad038df4
Reviewed-on: https://gerrit.libreoffice.org/82186
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The boost/property_tree/ptree.hpp added in commit
75b8db7fa7344a679d3c5dbdc8c5bd4228cdbc7c
turns out to be rather expensive: it adds about 900 kB per
compilation unit and window.hxx is included in about 2600 compilation units
Replacing it with forward declaration header has reduced total includebloat
from 26.1 Gb to about 22.7
Change-Id: I797608b54a62a5838c7a5d47355fb6bd736ad36c
Reviewed-on: https://gerrit.libreoffice.org/81500
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I5fd081780d46fd30864830eea2956bad6dc3e222
Reviewed-on: https://gerrit.libreoffice.org/81360
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Otherwise, we can emit events on a different view's window, causing
problems, and cross-user interference. Also emit the key-event on
the focused sub-window so event bubbling works.
Change-Id: I9dd16c2a256bae58d754f94c6d94a1f3fcdb800b
Reviewed-on: https://gerrit.libreoffice.org/80659
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
It was passed in as aArg[1] ever since d551190e8311242eadda4a3e82efff160175cb04
"INTEGRATION: CWS canvas05", but I can't find any current use of that specific
argument in canvas/source/ (assuming that all the factories are implemented
there), nor can I find any trace in the git history of it ever havig been used.
That means that Window::GetSystemDataAny is unused now and can be removed.
Change-Id: I16efe548afb5cc3e0606cffea135f7e6674d5def
Reviewed-on: https://gerrit.libreoffice.org/80295
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie3267e1f888df371d281e81ead437a150aa8dc1c
Reviewed-on: https://gerrit.libreoffice.org/79796
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I20545527b117c9562b91076b748fb3e2659d2497
Reviewed-on: https://gerrit.libreoffice.org/77944
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Apply the Liskov substitution principle to OutputDevice::GetBackgroundColor().
This helps in SmTmpDevice::Impl_GetColor() because it no longer needs to know
about what type of OutputDevice it is calling to get the background color.
This forced a rename of basctl::ModulWindowLayout::GetBackgroundColor() to be
GetSyntaxBackgroundColor(), but this is a happy coincidence as it makes the
function intent clearer anyway.
Change-Id: I11298a63cb01c187f3a8a4a2c9e90eacda6c3e6b
Reviewed-on: https://gerrit.libreoffice.org/75521
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I8a51afe0979d83862bbe384e6d67702f4687072d
Signed-off-by: Adrien Ollier <adr.ollier@hotmail.fr>
Reviewed-on: https://gerrit.libreoffice.org/75068
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I3e8775845e471517945876a48696747a46e5270a
Reviewed-on: https://gerrit.libreoffice.org/75616
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I92b36874879f89ef4dc862d61da58edd64867e92
Reviewed-on: https://gerrit.libreoffice.org/76450
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iae9a832b1a198a02c916c1e5eab893c166cdf615
Reviewed-on: https://gerrit.libreoffice.org/76387
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
I have done a spot of refactoring - it turns out that the bits where we
save and reset the map mode during background saves should probably be
done in Window::SaveBackground(). As Window::SaveBackground() doesn't
need the animation size (maSzPix) I have rarrange the parameter order
so the Window function can ignore the parameter.
OutputDevice::SaveBackground() has been introduced as a virtual function
and now is overridden by Window for its own purposes - OutputDevice just
does a DrawOutDev(...) operation on the background.
Change-Id: Ifeffe9536c01d8e4737f6e39a4f3dd14ba418f4d
Reviewed-on: https://gerrit.libreoffice.org/76399
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: Icefd5a9e2a8bd929caa486c4cf3283925237d707
Reviewed-on: https://gerrit.libreoffice.org/75980
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
makes OutputDevice::ImplClearFontData clean
Change-Id: Iee0683bd4567f85e20d5017b8eaa8a46490678db
Signed-off-by: Adrien Ollier <adr.ollier@hotmail.fr>
Reviewed-on: https://gerrit.libreoffice.org/72084
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Traditionally when a modal dialog is active, the quit menu entry of all
LibreOffice toplevel frames, not just those which are themselves modal, is get
disabled.
This has come unstuck because its implemented by dialogs emitting
MouseNotifyEvent::[END]EXECUTEDIALOG on its parent, and SfxFrameWindow_Impl
listening for that event. But if the dialog parent is the toplevel parent of
SfxFrameWindow_Impl then it doesn't get seen by the SfxFrameWindow_Impl child.
Change-Id: I0c4a5472d16d9169e68f6b0c230d039f1119489a
Reviewed-on: https://gerrit.libreoffice.org/73975
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I821ee682bf5b65774a609227811365b94ae2063e
Reviewed-on: https://gerrit.libreoffice.org/71547
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
I have to use the other way to specify an a11y role, both are implemented in
the vcl parser, but in my gtk3-3.24.7 the role tag crashes the gtk parser,
while the other route works fine.
The CONTENT_FLOWS_TO accessibility relation is another additional complexity
over the norm
Change-Id: Ia096bcbe9f00f9944e4e4d5ad9bb1a52d19c7b3f
Reviewed-on: https://gerrit.libreoffice.org/69569
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
* Introduce a editing frame with a button for drop-down form field.
** The frame is mouse transparent.
** Pushing the button opens the popup window with the items of the field.
* The button is visible when the cursor is inside the field.
Change-Id: I5c7db138d14380899fee046c95a5afe14cfea213
Reviewed-on: https://gerrit.libreoffice.org/68961
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
since it is just a wrapper around PointerStyle
Change-Id: I51f065e0d4ad8bd91f5c84c5819048c720a19267
Reviewed-on: https://gerrit.libreoffice.org/67711
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I98f49765c6b74808dcbd692e0f375dd2848fcfd4
Reviewed-on: https://gerrit.libreoffice.org/65614
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I5b241e35af90cc5c0a2df15e596bb5d45f110e52
Reviewed-on: https://gerrit.libreoffice.org/64560
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|