Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
This fixes a 7.1 regression from 53d73d532281b6734a7d4614bb74fc6cc15510f0
where notebookbar controls were being hidden (and then shown
after a refresh of the toolbar), leaving big empty gaps.
I don't know anything about vcl or window layout idiosyncracies,
so I just read through this code looking for some way to fix
the problem of the notebookbar not using all of its available space.
The problem was that GetOutputSizePixel was returning zero.
Why that would be I don't know. Perhaps because it had never
actually been displayed on screen yet? (This was occurring
on simply loading Calc.)
Substituting a small DUMMY_WIDTH didn't give a very accurate
reduction, so there was no space to add back in any items later on.
When adding it back, it adds using a legitimate-seeming width,
with an (unused this time) fallback to DUMMY_WIDTH.
So, unless getLayoutRequisition cannot be depended upon for
returning an accurate size, this should be a nice fix.
It will no longer hide too many controls from the notebookbar.
Change-Id: I1c39fe3532dad501c16f53612f8e26835b72638a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152125
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I0f13c9ae25c1788924fd81ed77307e96400f6220
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151677
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
suggested by mike kaganski
Change-Id: I5f5f254142767aca45a6101abdd84a0163ca6a34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150936
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
idea from mike kaganski
Change-Id: I0ecb9cad091d7a048d2ddae73165bf22748f3872
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I38f3410c0b25ff579879b9de1f266af4d8fd51e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150256
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which prevents constructing unnecessary temporaries via getStr()
Change-Id: I9ca70893a10e954b5ee0e6ad6098660ee24c2bef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150170
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I449ae3f8cf294e2ab81a5b47862278e325f2cb1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148937
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150041
Tested-by: Jenkins
|
|
Standardize on OUString, which is the main internal string class.
Convert from/to OUString only when communicating with respective
external APIs.
Removes about 200 conversions from the code.
Change-Id: I96ecee7c6fd271bb76639220e96d69d2964bed26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149930
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Rather than using it's superclass XWindowPeer and implicitly relying on it being XVclWindowPeer and casting it everywhere.
Change-Id: Icfb46f3b920d00f4a167a31803a71bbb0368d05c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149894
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
when applying my upcoming patch to also consider O[U]StringBuffer
Change-Id: I44ce7183e4b292269fac1e3d2217286bf5abe823
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149752
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
For other than gtk vcl backend the tabbed compact toolbar tabs do not
repaint correctly when the 'Table' tab is active and the cursor is move
outside of the table. This patch adds a Resize after the context is set
to make the tabs always show as expected.
Change-Id: Iedf8a6eea52c3c55e9c1266b7aa79bc0f34deb22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149593
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
Change-Id: Ia51621902ea8e1cff8c3813739b9d9c655477d51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148663
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
This patch fixes a regression for commit:
"lok: form controls: rendering and mouse event forwarding"
Change-Id: Iffb0757834a884a6c86206221660da2a24bdff17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148564
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 7ed760c4564834ec61ceb91f681dfc6daa1be4bd)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148621
Tested-by: Jenkins
Reviewed-by: Marco Cecchetti <marco.cecchetti@collabora.com>
|
|
What we got
- Most controls rendered on Writer and Impress (on Calc already
implemented by Tomaž Vajngerl)
- Text labels rendered correctly
- Mouse events forwarded to controls
- Control state changed on click for Writer and Calc
- Control invalidation for all apps
- Fixed broken LOK_CALLBACK_MOUSE_POINTER msg
- Correct pointer style when mouse is hovering over a control
Need to be improved
- in impress click method for a control is not executed even if the
mouse event is forwarded correctly
- avoid not needed control invalidations (as the one occurring on
document autosaving)
Change-Id: I4d5012af7f90a2c726b6b6b5b068e2be1ed5568a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146569
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147320
Tested-by: Jenkins
Reviewed-by: Marco Cecchetti <marco.cecchetti@collabora.com>
|
|
regression from:
commit 6e7e19d9c300dbdd279789b09f94781e946fad52
Date: Wed Jul 15 12:10:32 2020 +0100
weld DateControl
Change-Id: I74bc01383f04fd4e54a45058fbbc3bc082eef0e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148359
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I21408f7344f7e100373c368036f81503302b93ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148240
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: Id9837c208653311608bf39d6066cbf1345efc565
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148214
Tested-by: Jenkins
|
|
In the wizard initially we show only the first page.
Change-Id: I18ff5362f9ceb9989bfba2d9fddebf95230331e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148108
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
for the purpose of notification of loss of focus from the control
Change-Id: I9191b413978549c6f8e1775dc96a696059150e4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147398
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9f8946acbcf593e9adf6d31631b82cdafcd3f472
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147327
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Before
commit 4cb11d8a6682fecd661b926a417ae7f26f76e7db
Date: Fri Oct 7 16:40:23 2022 +0100
Related: tdf#98067 do RollOver for Edit as well as SpinButton
, the check whether the mouse is over a control
was only checking the control's child windows.
The above commit introduced a check for the control's
window as well in `ImplSmallBorderWindowView::DrawWindow`.
When moving the mouse inside or outside a `ListBox` control,
the invalidation of the corresponding border window happened
when the mouse cursor would enter or leave the `ListBox`'s
`ImplWin` child (in `ImplWin::PreNotify`).
The `ImplWin` only covers a part of the `ListBox` area. As
a consequence, when moving the mouse out of the `ImplWin`
area, the mouse would still be over the parent `ListBox` area,
so the `ControlState::ROLLOVER` state would still be set
in `ImplSmallBorderWindowView::DrawWindow` from the above
commit on.
Since there was no additional invalidation when the mouse
moved out of the `ListBox` area, the `ROLLOVER` state would
remain set even when the mouse left the `ListBox` area as well.
Move the invalidation from `ImplWin` to `ListBox` so
this gets processed when the mouse cursor actually enters or
leaves the `ListBox`, not just the `ImplWin` child.
Also align the mouse over check in
`ImplWin::ImplDraw` with the one in
`ImplSmallBorderWindowView::DrawWindow` again.
(Take the parent into account there as well.)
Change-Id: I8974e370819719489e3d9f091d96b3353888d26b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147018
Tested-by: Jenkins
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
|
|
background isn't "bright" or "dark" enough to be considered one or the
other. This is only used for the infobars, so black text is good enough
for the current bg colors in use.
Change-Id: I4c2c4fadac72cc35aebeadec417186c6358c0a77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146667
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia67b90d05bccbd4d2c2553109ea7372574ee21d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146584
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Groupedbar compact UI"
This reverts commit 801e6272dc299d4468ec094ce11b66494eb5018b.
Revert it for now, until a better solution for tdf#141684
is found
Change-Id: I6c9fd7fb12149b67fe572d64cf00e6a3ec98611f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146504
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
The combobox described in 148109 is indeed a listbox.
If drop down list is not open and only the selected item
is shown without having the focus, the background color
will be paint either it's defined as native control
or not.
Change-Id: I210916fbe07f74aaa5835bf2c88e764b010c6d61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131904
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
If a user pastes a string to an input field that has a maximum length restriction and no text is selected in the input field, extend the selection to the respective length of the pasted string or the maximum text length of the input field in order to prevent a text truncation warning. If the user selects some text in the input field, just replace the currently selected text and show the text truncation warning as before.
Change-Id: I2115f8c6672c9c66770abfa6918cf327a7eece17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144784
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
These are the buttons in infobars where the infobar has a custom
background color and on these platforms the buttons blend with their
background. On other platforms the buttons typically are opaque
and the issue doesn't arise.
Change-Id: Idfc4bbf291953bbf27e73cd5dd7654fd1ce4b051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144104
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I70685a74ebed465771473ce885f4f29af209cda6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143737
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
do it like this to avoid adding another mapmode and to keep things
"the same" as much as possible
Change-Id: I1965aa545646f2d27b950d6335b2f608c3e4e04b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143475
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
to avoid collision with Window::ImplScroll
Change-Id: I16e72ff842054979733b5149cd220a7a77f79351
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143187
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Previously this assumed page ids were sequential
if a page is removed then its id returns an empty
page. Fetching window child also worked based on
iterations and not comparing actual ids so another
possibility for empty pages.
Signed-off-by: NickWingate <nick.wingate@collabora.com>
Change-Id: I908f58665a9429ca4b66f346108030926a599d7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138181
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142976
Tested-by: Jenkins
|
|
This patch fixes tdf#152012 which caused an assertion failure on opening
date picker field in a DOCX file
The assertion was:
include/o3tl/span.hxx:83: constexpr o3tl::span<T>::value_type& o3tl::
span<T>::operator[](o3tl::span<T>::size_type) const [with T = const
int; o3tl::span<T>::reference = const int&; o3tl::span<T>::size_type
= long unsigned int]: Assertion `pos < size()' failed.
And the backtrace was:
1 __pthread_kill_implementation pthread_kill.c:44
2 __pthread_kill_internal pthread_kill.c:78
3 __GI___pthread_kill pthread_kill.c:89
4 __GI_raise raise.c:26
5 __GI_abort abort.c:79
6 __assert_fail_base assert.c:92
7 __GI___assert_fail assert.c:101
8 o3tl::span<int const>::operator[] span.hxx:83
9 OutputDevice::ImplLayout text.cxx:1396
10 OutputDevice::DrawTextArray text.cxx:948
11 Calendar::ImplDraw calendar.cxx:71
12 Calendar::Paint calendar.cxx:1133
The problem was caused by an out of bound access to a vector of integers
which was created for rendering calendar header consisting of the first
letters of 7 days of week, when you clicked on the down arrow on the
date field.
The function OutputDevice::DrawTextArray() takes an 'rStr' string to
draw, and 'pDXAry' array for the exact position of the the individual
characters. It also takes 'nIndex' as the first index, and 'nLen' as the
length of the array. 'nLen' has the default value of -1. In this case,
the length is calculated from the size of the string passed to the
function. This works well if the one who uses the function makes sure
that the size of the array and the length of string are equal.
Previously, for the 7 days of the week, a 7 letter string "smtwtfs"
(depending on the week start day this can be different, but length is
always 7) was sent to this method without providing the length, thus
the string length: 7 was used. In this case, positions of the letters
were calculated and used from other array named mnDayOfWeekAry[7].
mnDayOfWeekAry[k+1] was used as the position of letter k (k=0..5).
In this case, there was 7 letters for 7 days, and only 6 positions
provided by the array. This caused assertion failure in span.hxx:83
when trying to accesss mnDayOfWeekAry[7] via o3tl::span<T>::operator[].
Value of mnDayOfWeekAry[0] was used in other calculations, therefore to
fix this problem, mnDayOfWeekAry was extended from 7 to 8, and the last
position was set to the end of drawing rectangle.
The other thing that is done in this patch to avoid this problem in the
future is removing the default value from the function prototype, so
that the use should always be done by providing the length of array and
starting index. After removing these defaults, it became necessary to
provide empty arrays for 'pKashidaAry' which provides the kashida
positions, if needed.
With this fix in place, the assertion failure no longer happens.
A UI test is added to make sure the crash will not happen again. The
test can be run by invoking:
cd sw && make -srj1 UITest_writer_tests5 \
UITEST_TEST_NAME="DateFormFieldPropertiesDialog.dateFormFieldDialog.test_date_picker_drop_down" \
SAL_USE_VCLPLUGIN=gen
Change-Id: I347afb358fbc4956524f7f0a0abc3a221bf42992
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142642
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Change-Id: I878603e18c2c0ac8b1e9a9ff7995b6c640e455b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141619
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142471
Tested-by: Jenkins
|
|
Change-Id: I3f0e5edd196420c8c51b19cd1ceee8caba7f7fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141612
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
we already have support for double underline so that's an easy add
Change-Id: I1bba5620038e396765bd79050ff6a520096f9476
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142223
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idf0a645bee9b2fc80bdf152c0703c3d25e3b330f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142189
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: Ief8d3f8152ccc23bd65afb4e9e92cf4190f6bb37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141968
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
so we can pass in the required area for the macOS case
Change-Id: Ibb170e773a57ad0d5d0a591810e4039591337303
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141911
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I98938855876f8f7d821bacd8ba135053c92683a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141887
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibc2605261de84337f4880f07a5ecb25e934c0251
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141759
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
As mentioned in commit 510bca3d3ab0b2fd21f0083b4e0fe14ff8c903c3,
over the time these functions were changed; now they don't take
logical coordinates, but pixels, so became true duplicates of
corresponding Mouse* functions.
The calls to SetLastMousePos are now made from LOKPostAsyncEvent
uniformly.
Change-Id: I2c8a9095719c0c8e21cf81342a286b00c1d1a41c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141693
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I058cc965a9b0d85e5491191e2ac712c01f700043
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141086
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
which gives a border which indicates if the Edit has focus
or not. In High Contrast Black this is a bright yellow and I see
it in notepad and visual studio, so lets do that too.
MultilineEdit left alone for now
Change-Id: I6785e3cdef7d563509a3a6ea8617ab5f89602a6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141085
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idf98c5bb96e5646e25b1ccd70b3774c7de479d18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140979
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3ab2ec91f3317dbd5a7e011e5b81d0a5141b1348
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140978
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I66f96a305bb095716023ae1e565950971826bce0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140242
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The highlight and highlighttext colors can be set for some
controls. So as example a selected item in a listbox can now
be paint with anothers colors then the standard blue. Controls
are: listbox, combobox, edit field and some special edit
fields like date, currency and others.
Change-Id: Iace2dd9a1a61abb7819b6c81eb0b8030912db32b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136691
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Also contains keyboard and focus events, not only mouse events
Change-Id: Iec1d6c341b01a489ba80fe9634ea3579afb02ea9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139970
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
This reverts commit b20594f2fc8f6f9fdbf0b257b4e74d95a8d90139.
Reason for revert: Further testing has shown some errors in other ways of displaying the data
Change-Id: Ic4909f8571c8730ab3ba622c7fad99f2646616ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139566
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|