Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Id25d5e3dbf84dea1f9aca5a6ec921d30cbe84bf7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165524
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
This fixes the JSDialog layout of the sheet protection dialog.
This was introduced for 24.02 to provide password strength indication
of the sheet password.
Defined a new WindowType of PROGRESSBAR.
The type property in JSDialog JSON will be "progressbar".
Change-Id: I202528a81706943e1838f3c37fb555f4a1bf889e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165236
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Starting with commit bfa21ce5fa08f2c634ccb6162914be55aef9f3c2,
horizontal swiping in Calc moved in the wrong direction scrollbars
were drawn mirrored.
So, revert parts of commit bfa21ce5fa08f2c634ccb6162914be55aef9f3c2
so that we are using Calc's previous "negative scrollbar range"
implementation for RTL UIs, but only for horizontal scrollbars since
vertical scrollbars are the same in LTR and RTL UIs.
Also, always disable RTL for scrollbars. Enabling RTL causes the
following bugs when clicking or dragging the mouse in scrollbars in
Calc's RTL UI:
- Click or drag events get mirrored so you must click or drag in
unexpected locations to move the scrollbar thumb in the desired
direction
- Repeatedly dragging the scrollbar thumb leftward can only move
no highter than the R, S, or T columns
Note: even though RTL is always disabled for Calc scrollbars, the arrows
must still be swapped in vcl's ScrollBar class.
Change-Id: I85aac94ffaf7df2eeb251a3ff150cc0363b5d770
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164959
Reviewed-by: Stéphane Guillou <stephane.guillou@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
|
|
This reverts the following commits:
d408fe5cd45c9594feecec727ab2f73c66e361d0 "unnecessary LogicToPixel in CheckBox::Draw"
7441aaa4c5b2215e369c62e22af098184e8ce807 "unnecessary LogicToPixel in RadioButton::Draw"
a2dacae0c8acfad8a5e5a16c766ee740ec202c5e "unnecessary LogicToPixel in ComboBox::Draw"
f73e8c895e24fda10931ecf344a1a0dd8bcdf92c "unnecessary LogicToPixel in TabPage::Draw"
I am fairly sure this code that I am restoring is dodgy,
and I am just papering over some other bug somewhere, but
I can't seem to see where that is.
Change-Id: I0f9088e43b0e3af74fd5ff9d297008ee23a3facb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164313
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:/lo/core/sw/source/ui/dbui/addresslistdialog.cxx(426): warning C4312: 'reinterpret_cast': conversion from 'int' to 'void *' of greater size
Change-Id: Idbfbe8add89c8e219bdabcf28b741e2e31a5e345
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163781
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Idf7613b9141c55372e19199b5641719ba42e43ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162598
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 2de4572fdff7364c98fd7c9440c4cf132206031d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162713
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Add .uno:NumberFormatCurrency item to .ui
Use weld:: way of widgets creation so we can inject
jsdialog code and popup will be correctly registered.
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: Ib57e1cad617ca5c7198d67e107441ba062580f06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162623
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162710
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
and
cid#1546154 COPY_INSTEAD_OF_MOVE
cid#1546120 COPY_INSTEAD_OF_MOVE
cid#1546115 COPY_INSTEAD_OF_MOVE
cid#1546111 COPY_INSTEAD_OF_MOVE
cid#1546096 COPY_INSTEAD_OF_MOVE
cid#1546016 COPY_INSTEAD_OF_MOVE
cid#1545980 COPY_INSTEAD_OF_MOVE
cid#1545942 COPY_INSTEAD_OF_MOVE
cid#1545902 COPY_INSTEAD_OF_MOVE
cid#1545869 COPY_INSTEAD_OF_MOVE
cid#1545853 COPY_INSTEAD_OF_MOVE
cid#1545769 COPY_INSTEAD_OF_MOVE
cid#1545742 COPY_INSTEAD_OF_MOVE
cid#1545735 COPY_INSTEAD_OF_MOVE
cid#1545689 COPY_INSTEAD_OF_MOVE
Change-Id: If93debe8b00991761cf1876b3fce27b09906749e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161966
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Task::SetPriority() expects the timer to be stopped while
changing the timer's priority.
Change-Id: Ib025cc1451bf6fa959284d202d29dbb1489beb0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161272
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
|
|
By default, the layout idle timer in the InterimWindowItem
class is set to TaskPriority::RESIZE. That is too high of
a priority as it appears that other timers are drawing
after the scrollbar has been redrawn.
As a result, when swiping, the content moves fluidly but
the scrollbar thumb does not move until after swiping
stops or pauses. Then, after a short lag, the scrollbar
thumb finally "jumps" to the expected position.
So, to fix this scrollbar "stickiness" when swiping,
setting the priority to TaskPriority::POST_PAINT causes
the scrollbar to be redrawn after any competing timers.
Change-Id: I8c0772fc40ddc690ee59c6267c1c50971f4ff238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161184
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
|
|
Change-Id: I4f79c30b9ab997d01e59a0dec76986e74abfc11f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161053
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic97a2b313c6f7d9da540a8867f01362c2fe7b0d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161052
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
2 problems here
1) Regression on test of "pThrobber" since 51e97b2ffd8f0ae0591d1880d621cba4596583b7
toolkit: first cut at switching to VclPtr.
2) as the author of the bug "Jurassik Pork" indicated,
"mnStepTime" wasn't used after having been used in ctr of Throbber
Thank you to him for the suggestion!
Change-Id: I0d1a53738035c3e822ea84d5972363dd9d0b5d8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160771
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
As described in tdf#158548, it's unexpected that listbox/
combobox entries change when using the mouse wheel while the
listbox/combobox has keyboard focus, but the mouse cursor
is positioned somewhere else
Therefore, only do that for the VCL ListBox when the mouse cursor
is currently positioned above it, which also matches what
e.g. native Qt applications do.
(When using the gtk3 VCL plugin that uses a native GtkComboBox,
nothing changes on scroll independent of the position.)
Change-Id: I8a69628471c1cd4258194627b95145d6b8fb686a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160459
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Wizard dialog help button's response is not initialized if we don't run
any other dialogs. It should be initialized in RoadmapWizard itself.
response_help function can not detect wizard dialog's Help button. So we
should handle this case in function too.
Signed-off-by: Gülşah Köse <gulsah.kose@collabora.com>
Change-Id: If80a2e54dcbf5eaa3d0e07347d12296ace5c9569
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159282
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ie9bb9ce20f27162bcb7d7d25dcad99107675e2be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159709
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
It was fixed only on Wayland previously.
Follow-up to commit 15cdee0d846854b50dd04626b73499bef9305e00
"Resolves: tdf#152155 use gtk's knowledge of relative widget positions".
Change-Id: I7a8b17189b319146142a2193ec4b5ec41e2c2d27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159020
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Introduces LevelBar that shares implementation with
Progress(Bar).
LevelBar is to be as a level indicator, e.g. password strength
level. Currently with native backends for gtk and Windows.
Currently, except on gtk - the colors of the bar at different
levels are hardcoded and not dependent on any kind of themeing.
On Windows it follows the styling of progress bar of type "Meter"
according to the uxguide:
https://learn.microsoft.com/en-us/windows/win32/uxguide/progress-bars#meters
Change-Id: Id772cda23615e9582463bf589e4674fd4588c864
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157826
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
Change-Id: Iaeacacbbb0eec907d884219aa2bcfe7a86f00a2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158291
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Call the base class implementation `Control::GetFocus()`
(which currently is just `Window::GetFocus`) before doing
anything else, not at the end. This ensures that
a focused event is sent to the a11y layer before e.g.
adapting text selection. Assistive tooling
handles the currently focused object with
special interest (and announces events on that
object much more likely than for any other objects).
This e.g. makes Orca announce the labels for the
spinboxes (like "Width", "Height", "Left", "Right")
in Writer's "Format" -> "Page Style" dialog -> "Page"
page when using the qt6 VCL plugin.
Previously, only the current value
of the spinboxes was announced without the label
when moving focus into one of them
using the Tab key.
The following 2 Orca commits [1] [2] in the
LibreOffice-specific Orca code look related:
commit c4c5d11656ec7221e4aa4b980e51c010dcc62674
Author: Joanmarie Diggs <jdiggs@igalia.com>
Date: Mon Aug 7 13:53:41 2017 -0400
Work around event-ordering issue in LibreOffice
commit 38b995d9bacc55bb455c4464b01c82b885ed5549
Author: Joanmarie Diggs <jdiggs@igalia.com>
Date: Fri Feb 15 09:40:07 2019 -0500
Don't present locusOfFocus changes due to text-selection-changed events
(The first one makes the object sending a
text-selection-changed event the focus object in Orca,
the second one then causes this implicit focus object
to no longer be announced. And when LO itself sends
the focused event for the object, the object is already
considered as the focus object, i.e. not announced
either because the assumption is that the focus hasn't
changed.)
If the new event order causes any issues elsewhere because
other places depend on the previous order, that will have to
be looked into individually, s.a. the discussion in the
Gerrit change for some thoughts on that [3].
[1] https://gitlab.gnome.org/GNOME/orca/-/commit/c4c5d11656ec7221e4aa4b980e51c010dcc62674
[2] https://gitlab.gnome.org/GNOME/orca/-/commit/38b995d9bacc55bb455c4464b01c82b885ed5549
[3] https://gerrit.libreoffice.org/c/core/+/156679
Change-Id: Ib0188fe206a49c9052ec9694bafd451586ff0b9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156679
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Updated scrolling related variables to double from sal_uLong
Change-Id: Ibf4bb3d55b074b5d2e369e4bc708b87bdfa302b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155644
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: I6241961db2e0fa676289ce50873a2aae7ec18282
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155937
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156236
Tested-by: Jenkins
|
|
Change-Id: I673199dfd7e95bfdb748791db094e7a1c3e74dba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155759
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Attila Szűcs <attila.szucs@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156158
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I8fbe02547d5045cfdb5021720b10ddd10106209a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155750
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Don't request focus for the color window
before the menu button popup opens.
Doing so would prevent properly restoring focus to the
menu button itself after the popup closes again.
Without this change in place, the call to
`MenuButton::Activate` in `MenuButton::ExecuteMenu (s. frame 14/15
in below backtrace) would already set focus to the "Automatic" button
in the color window:
1 PushButton::GetFocus button.cxx 1490 0x7f4acfdc83b6
2 vcl::Window::CompatGetFocus window.cxx 3888 0x7f4acfd9d26d
3 vcl::Window::ImplGrabFocus mouse.cxx 384 0x7f4acfcd5215
4 vcl::Window::GrabFocus window.cxx 2979 0x7f4acfd988e9
5 SalInstanceWidget::grab_focus salvtables.cxx 390 0x7f4ad046f505
6 ColorWindow::GrabFocus tbcontrl.cxx 2127 0x7f4ad3f21af1
7 ColorListBox::ToggleHdl tbcontrl.cxx 4291 0x7f4ad3f313d6
8 ColorListBox::LinkStubToggleHdl tbcontrl.cxx 4285 0x7f4ad3f31369
9 Link<weld::Toggleable&, void>::Call link.hxx 111 0x7f4ad04aec71
10 weld::Toggleable::signal_toggled weld.hxx 1539 0x7f4ad04a77a3
11 SalInstanceMenuButton::ActivateHdl salvtables.cxx 3075 0x7f4ad0483086
12 SalInstanceMenuButton::LinkStubActivateHdl salvtables.cxx 3071 0x7f4ad0483043
13 Link<MenuButton *, void>::Call link.hxx 111 0x7f4acfe9e9c1
14 MenuButton::Activate menubtn.cxx 237 0x7f4acfe9e136
15 MenuButton::ExecuteMenu menubtn.cxx 61 0x7f4acfe9cca1
16 MenuButton::KeyInput menubtn.cxx 226 0x7f4acfe9e092
17 ImplHandleKey winproc.cxx 1211 0x7f4acfdb0962
18 ImplWindowFrameProc winproc.cxx 2724 0x7f4acfdb6fcf
19 SalFrame::CallCallback salframe.hxx 310 0x7f4ac5aa3dfa
20 QtFrame::CallCallback QtFrame.hxx 229 0x7f4ac5aa5336
... <More>
As a consequence, this "Automatic" button inside of the color window
would be the UI element remembered as the the one to which focus
focus should be restored when closing the popup, see the
mxPrevFocusWin = Window::SaveFocus();
in `FloatingWindow::StartPopupMode`, which gets called like this:
1 FloatingWindow::StartPopupMode floatwin.cxx 824 0x7f4acfc61a61
2 ImplDockingWindowWrapper::StartPopupMode dockmgr.cxx 846 0x7f4acfc43bd3
3 DockingManager::StartPopupMode dockmgr.cxx 341 0x7f4acfc412c3
4 MenuButton::ExecuteMenu menubtn.cxx 94 0x7f4acfe9cfa9
5 MenuButton::KeyInput menubtn.cxx 226 0x7f4acfe9e092
6 ImplHandleKey winproc.cxx 1211 0x7f4acfdb0962
7 ImplWindowFrameProc winproc.cxx 2724 0x7f4acfdb6fcf
8 SalFrame::CallCallback salframe.hxx 310 0x7f4ac5aa3dfa
9 QtFrame::CallCallback QtFrame.hxx 229 0x7f4ac5aa5336
10 QtWidget::handleKeyEvent QtWidget.cxx 671 0x7f4ac5af9f38
11 QtWidget::handleEvent QtWidget.cxx 707 0x7f4ac5afa094
12 QtWidget::event QtWidget.cxx 730 0x7f4ac5afa1f7
13 QApplicationPrivate::notify_helper qapplication.cpp 3287 0x7f4ac37a2414
14 QApplication::notify qapplication.cpp 2715 0x7f4ac379fd5b
15 QCoreApplication::notifyInternal2 qcoreapplication.cpp 1123 0x7f4ac51a3c34
16 QCoreApplication::forwardEvent qcoreapplication.cpp 1138 0x7f4ac51a3cac
17 QWidgetWindow::handleKeyEvent qwidgetwindow.cpp 669 0x7f4ac38567b1
18 QWidgetWindow::event qwidgetwindow.cpp 234 0x7f4ac3854924
19 QApplicationPrivate::notify_helper qapplication.cpp 3287 0x7f4ac37a2414
20 QApplication::notify qapplication.cpp 3238 0x7f4ac37a2224
... <More>
and then properly restoring focus fails in
`FloatingWindow::EndPopupMode`.
Move the call to `Activate` to after showing the
popup instead. This makes sure that the actual
widget that had focus *before* the popup opened
is remembered and focus is correctly restored
on close.
The handler for the toggled signal had been added in
commit e55a1dc163165cb79fc9113101d16ee8d3db7298
Date: Wed Nov 27 14:58:00 2019 +0000
don't put focus into unmapped windows
defer until the color selectors are activated to grab focus, otherwise
esc doesn't work to close a dialog under gtk3 until focus is put
into some visible widget
which apparently already moved the focus request to later than it was
before.
With this change in place, the NVDA screen reader announces the
menu button again once the color popup closes (tdf#141101) and it also
makes opening the popup menu again right away work
by pressing Alt+Down button again on Windows or with the
gen or qt6 VCL plugins on Linux, which didn't work beforehand,
but required either using the mouse or tabbing to another UI
element and back before that keyboard shortcut would work again.
The same is true for the border line style popup (tdf#101886).
Setting the focus only when the popup shows also
makes the focus correctly be on the previously
selected color for the non-gtk3 case when opening
the popup again. (Previously, the "Automatic" button
would always have focus.)
Ensure that the required preparations for showing the
popup in the `ManagedMenuButton` subclass are still
done before executing the menu by doing what's
needed in the newly named `ManagedMenuButton::PrepareExecute`
method rather than in `Activate` and call that
one before showing the menu.
Change-Id: I82fbfea2ae8b9064979796da279750350deb742d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155891
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
translation exists so doesn't require additional translation
Change-Id: Ibc5df15b9b8442307195d79c862c69e0506c4057
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155733
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This reverts commit 69972719542cd686687ddd91f2b5284483513608.
There are some odd things gone in with some of these changes that I do understand. Reverting until I have worked it out.
Change-Id: If5316654c16a697a2aff5eccdffaa5b2a6e0052d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155598
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I270bb35f577cc1ee56233c585665478cbaab9085
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155616
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
not a logic rectangle
Since
commit 7adfecb0f5947ae258226c8d1652546f81577026
Author: Marco Cecchetti <marco.cecchetti@collabora.com>
Date: Sun Feb 5 17:47:34 2023 +0100
lok: form controls: rendering and mouse event forwarding
Change-Id: Ibbc0ea03d014ac2141bd59858f0a73e74ffe1144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154895
Tested-by: Jenkins
Tested-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Reviewed-by: Marco Cecchetti <marco.cecchetti@collabora.com>
|
|
Re-implement GetCaretPositions() on top of GetCharWidths() so it can
benefit from our code that handles cursor insertion in middle of
ligatures.
Change-Id: I2b76b3b0125f2454f78cb6779d88617dc29386fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154660
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
|
|
sometimes it returns a relative position, sometimes an absolute
position.
Rather have two different methods with names that match what
they return.
Change-Id: Ie1e73c6be1c797fd59934c96866d1fef1f972b35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154653
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I51d5e553c5ec1ba9fa5fd63844621368f3cedbd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154133
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
(cherry picked from commit b61b6fa6ee97a735ba30a4b725075b4c0fffbdd5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154314
Tested-by: Jenkins
|
|
avoiding some precision loss
Change-Id: I946f4f820321f76fb7634c722a28035600bac359
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154157
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which is what DrawText wants
Change-Id: I5dd98314f84f25f65e199444af87e4f34f7bfbce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154145
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ever since
commit 3fbae5dc7e7b200776bbc8a7c2a43e1e04f15a2b
Author: Caolán McNamara <caolanm@redhat.com>
Date: Thu Aug 5 14:57:59 2021 +0100
gtk is the only case auto-accel is true, and the menubar is native
gtk there
Change-Id: I209a410a231952dcbbb587ed6034fcfec77eaead
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154059
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
we are already using logical pixels here, and Draw wants logical pixels
Change-Id: I5409abccef4473cbca4d38654a27a677e68d82f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153968
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
we are already using logical pixels here, and ImplDraw wants logical
pixels
Change-Id: I0edc990c9943d68228600a15ccadca62127b02bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153967
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
we are already in logical pixels here, and the ImplDraw call expects
logical pixels
Change-Id: I7eab69b92998fd36c811fc7ac3949adb2f4fff7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153966
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8d3402a69237b665462e04440ad73fe29e2133db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153807
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Tabbed pane titles are currently incredibly cramped,
increase the space a little to make them match better
with current OS layouts (all of the different OSes
we support use quite a lot of space around the
titles)
Change-Id: If9c7b4df81f8d206556e7c75097650ae21508384
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153733
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I removed the code in ImplDrawItem that added data to them,
because ImplDrawItem was only ever called with bLayout with false,
and removing the bLayout param removed that code.
That removal happened in:
commit f0f973da8560e16cba85d2c9465c3a8c4c0ebbb3
Author: Noel Grandin <noel@peralex.com>
Date: Wed Mar 16 08:49:35 2016 +0200
loplugin:constantparams in vcl/
And that happened because....
I noticed that ImplPaint was only ever called with bLayout==false,
which meant I removed that param and passed bLayout==false to
ImplDrawItem,
in:
commit 911ae0aeca443fb4b5e400ae0f939567b580e443
Author: Noel Grandin <noel@peralex.com>
Date: Fri Feb 26 09:36:26 2016 +0200
loplugin:unuseddefaultparams in /include/vcl
which was because the last call to ImplPaint with bLayout == true
was removed in:
commit a6b9d9a19fb8c5c9f166682f52941aee25b89c94
Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Date: Wed May 6 13:00:13 2015 +0900
refactor "TabControl" to use RenderContext
Change-Id: Id234257201726de95e2c10bfacb30670123ca8a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153713
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
they can be inside the .cxx file
Also rename slightly and document.
Change-Id: Iffd46e9ed6c02aad597a616ac1c583ae657fab40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153711
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... instead of tools::Time
Change-Id: I8e49de43a1870541d75add34089eec67b7a8be31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153533
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
The user was forced on the HOME page at almost any
context change.
Instead, this should only happen if:
-there is a special context tab
-there is no special tab, and some "random" tab is needed.
This helps in a lot of cases, but there are still plenty
of cases where TWO context changes are emitted for one logical event.
For example, in Calc a new comment switches to special DRAW tab,
and then immediately to DrawText which has no tab -> home tab.
So further fixes are needed to prevent machine-gun fire context events.
Change-Id: Ibaf18fa823c613b4d11d33284842e439d3689542
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153476
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
I noticed that SetCurPageId was running multiple times
for the HomeLabel page.
Plus, let's flatten this a bit more.
It has always been like since, since
commit d7da58ae362b661c03fc754e4e8f4a89798b0127
Author: Szymon Kłos on Fri Jul 22 11:50:57 2016 +0200
GSoC notebookbar: better default page handling
Change-Id: Ied13ea5019df7cce2afe38d5d5d3615168338f0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153475
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Unfortunately SVG export is based on metafiles and thus there
is (in principle) no way to get the BGradient/ColorStop/MCGR
data transfered as needed. For that, using UNO API to read the
model or using B2DPrimitives would help - as is better for the
export respectively.
Since there is not the time to re-design SVG export I added
this 'compromize' as a fix. It gets the needed data transported
over the metafile (that part is the compromize). It then
exports the MCGR data to SVG (at least - as was already there -
if it's a linear/axial gradient). This happens now with all
Gradient Stops when there is a MCGR gradient. That part is/will
hopefully be re-usable if SVG export gets redesigned.
I also added a handling for StepCount feature, so when used (in
LO, others do not have that) 'hard' color stops get generated
to make the gradient look identical for SVG export.
Had to make adding of that extra-information in metafiles
dependent on exporting really to SVG. There are 51 cases which
use 'MetaActionType::COMMENT' which would potentially have
to be adapted.
Also added code to solve the problem for TransparencePrimitive2D
at VclMetafileProcessor2D::processTransparencePrimitive2D. This
will now - also only for SVG export - directly create the needed
MetaFloatTransparentAction and add additional MCGR information.
This will be used on SVG export to write a 'Mask' as was done
before. This is now capable of creating fill MCGR-Masks in
the sense that any number of TransparencyStops will be supported.
Change-Id: Ic6d022714eae96b8fbc09e60652851ac5799b757
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152623
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
a5084d15e1b72e303e1628fbff84432036b014a9 "loplugin:stringadd in vcl" had dropped
the intermediary sTemp, but which caused JunitTest_forms_unoapi_1 to fail for me
once with
> ==2657124==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x50c00086ca58,0x50c00086ca6a) and [0x50c00086ca48, 0x50c00086ca5a) overlap
> #0 in __asan_memcpy at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
> #1 in char16_t* rtl::addDataHelper<char16_t>(char16_t*, char16_t const*, unsigned long) at include/rtl/stringconcat.hxx:80:9
> #2 in rtl::ToStringHelper<rtl::OUStringBuffer>::operator()(char16_t*, rtl::OUStringBuffer const&) const at include/rtl/ustrbuf.hxx:1765:14
> #3 in rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>::addData(char16_t*) const at include/rtl/stringconcat.hxx:195:64
> #4 in rtl::ToStringHelper<rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>>::operator()(char16_t*, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0> const&) const at include/rtl/stringconcat.hxx:207:101
> #5 in rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>::addData(char16_t*) const at include/rtl/stringconcat.hxx:195:88
> #6 in rtl::ToStringHelper<rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>>::operator()(char16_t*, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0> const&) const at include/rtl/stringconcat.hxx:207:101
> #7 in rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0>::addData(char16_t*) const at include/rtl/stringconcat.hxx:195:88
> #8 in rtl::ToStringHelper<rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0>>::operator()(char16_t*, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0> const&) const at include/rtl/stringconcat.hxx:207:101
> #9 in rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0>, char const [4], 0>::addData(char16_t*) const at include/rtl/stringconcat.hxx:195:88
> #10 in rtl::ToStringHelper<rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0>, char const [4], 0>>::operator()(char16_t*, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0>, char const [4], 0> const&) const at include/rtl/stringconcat.hxx:207:101
> #11 in rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0>, char const [4], 0>, rtl::OUStringBuffer, 0>::addData(char16_t*) const at include/rtl/stringconcat.hxx:195:88
> #12 in rtl::OUStringBuffer& rtl::OUStringBuffer::operator=<rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0>, char const [4], 0>, rtl::OUStringBuffer>(rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, rtl::StringConcat<char16_t, char const [3], rtl::OUString, 0>, char const [3], 0>, rtl::OUStringBuffer, 0>, char const [4], 0>, rtl::OUString, 0>, char const [4], 0>, rtl::OUStringBuffer, 0>&&) at include/rtl/ustrbuf.hxx:378:17
> #13 in DoubleCurrencyField::UpdateCurrencyFormat() at vcl/source/control/fmtfield.cxx:1120:20
and e.g.
> OUStringBuffer b("a");
> b = "b" + b;
> CPPUNIT_ASSERT_EQUAL(OUString("ba"), b.makeStringAndClear());
would indeed easily fail with
> equality assertion failed
> - Expected: ba
> - Actual : bb
Change-Id: I3108c18b7c941953a73b5731d9973914b7ba1fbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152495
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
AFAICS, the code was non-sensical before.
Hopefully now it is logical.
Apparently returning the correct width doesn't mean much,
but that is the only thing that should be changing in this patch.
I would assume that returning an accurate width
is the proper thing to do for this function...
Change-Id: Iab26ac7fd8cd00127d2646f792fa552ec148dc74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152126
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|