Age | Commit message (Collapse) | Author |
|
Change-Id: Ibe78c7164c989b7010ee96bbbd728218c58daad9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95961
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
i.e. in the calc autofilter menu-alike popups
Change-Id: I93fc74325b8d39807e5126fc694addd3d0a50d53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96127
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If20de104a058ef3bb5642cb4ecdb7c5c6f931efe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96126
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
We don't seem to need this anymore, probably
commit ea1182c8c2c42c0c527e232f7e392196796940d7
Author: Caolán McNamara <caolanm@redhat.com>
Date: Wed Jun 10 12:16:17 2020 +0100
grab focus to style combobox when parent gets focus
was the right fix
Change-Id: If5d966bfb3fcb47ba09f81b1e786df76a7561bf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96071
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If18c5c1de40a4f93d062265d41a2bff72555d6c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95964
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4ab4a0fb8fc343ee9a4c66c58e20583482958f37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95951
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ifde87738710406fb9f28008fa96241d59c52f450
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95808
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
cause this assumption is baked into the vcl one making it hard
to adapt remaining cases
Change-Id: I75dd5264c65b1ffbf4d26c9a86f6d4d08b400d90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95622
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id348d1c25df57c9f18249990bd6c00bdf23dfa71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95805
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
g-lo-CellIndex is the internal view, adjust that for
signal_toggled
Change-Id: I9ad0cf2e63c2bb03463650a84a9145cf3760ae4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95621
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic07709a864620c6146616c8e0a1417343c0937de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95590
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I11a85090bd14d8655efb95433417764dd1f79052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95592
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1949a9596d37009e8585dfd2181cc96c03d6e4b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95522
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
and clarify that g-lo-CellIndex is the index from the external pov
Change-Id: Id747acaeabab50755188732637a72c1fce8a97dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95519
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I537d123f1c127301d66de06c8cac76f8fe7427c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95535
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
which all users already do, and drop unused auto-pick of default
text column if not set
Change-Id: Ibf8d8fb8295ebd10d89b2096b85dd08314aff3f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95503
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0c0331e3cf2aa76bca3aabacf06dcf5aebcb55a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95520
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3361b0c35965133747c502c5bd81359915507ebd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95518
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
to look for the
x.get() != null
pattern, which can be simplified to
x
I'll do the
x.get() == nullptr
pattern in a separate patch, to reduce the chances of a mistake
Change-Id: I45e0d178e75359857cdf50d712039cb526016555
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so gtk's desire for one can be satisfied
Change-Id: I486331bdc1778f07c02d0249f239c8d14fc4f5e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95371
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5e49913dfac82c1243d16ed0a0267a3647f51311
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95270
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I315fe2dd2e40c976edd802c1e87b7ccdb0c298fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95221
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib611780816d170daa40f394b9798640ff6284d68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95056
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.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: I280e1a49e938f45402f373896669fd6f7e8a66fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94876
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...after 5bfa8b8d5e1cf3cb572dbd91bf3b0cfcf29fb65a "tdf#118314 Code clean up on
imestatuswindow" had removed the sole consumer of aText.
(It is unclear to me whether the use of StatusDrawCallback in the
SalI18N_InputContext in vcl/unx/generic/app/i18n_ic.cxx is still necessary when
StatusDrawCallback does not do anything. But StatusStartCallback and
StatusDoneCallback do not do anything, either, and are used exactly the same way
there, so lets keep all that, at least for now.)
Change-Id: Ic2a61819c6bb8ed192231ca309f03b6c29768f29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94760
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and thus SystemFontData
Change-Id: I563a6b7c251194cd73c6b0026d4ae8485a057b28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94740
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...that would no longer compile since 2f5f45921b05904a4be1ff633be09c62cb44ff08
"support O(U)String::number() for fast string concatenation", anyway:
> vcl/unx/generic/app/i18n_cb.cxx:508:56: error: incompatible operand types ('const char [14]' and 'OStringNumber<int>')
> << ((call_data->type == XIMBitmapType) ?
> ^
Change-Id: Id7818ed6228ff317e1bee4efd53f15a2786689d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94758
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Idddba2f3fd05265b08dbc88edb6152d34a166052
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7beecd8f9579d5ae4b60a839f4a71c3238e0666d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94645
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iffd7306517ceca94eb6db5360c7d5069c8958acc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94664
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
the FreetypeFont only makes sense in the context of the FreetypeFontInstance it
belongs to so remove the faux "garbage collection" and just have FreetypeFontInstance
own the FreetypeFont and keep it simple.
Setting a value low enough to make the garbage collection kick in just crasheed
libreoffice by pulling FreetypeFont out from under living FreetypeFontInstance
seeing as the Cache/Uncache was by the FreeTypeTextRenderImpl not the
FreetypeFontInstance which had HarfBuff faces which continued to point to the
removed FreetypeFont
There is still a cache at the LogicalFontInstance level, so this aligns the
libfreetype platforms with windows, mac etc.
Change-Id: Iac669fae8dc1df81a5bc10d2943d84a2ff623180
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94546
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
FmXListBoxCell implements css::awt::XListBox but none of that functionality is
needed locally where it is used to pick a value in a cell when edited
interactively.
As an XInterface a FmXListBoxCell does fall into the
script::XEventAttacherManager attach/detach sink-hole so its very difficult to
determine if it (and any of its siblings) really need to implement the amount
of uno interfaces they actually implement, so this is a little speculative.
See https://ask.libreoffice.org/en/question/152691/how-to-populate-combo-box-within-table-control-in-form/
for an example of the ComboBox interaction case which is similar to this ListBox case.
The exotic "multiselection" option definitely isn't shown as an option in the property browser
for a listbox column in the table control.
Change-Id: I7bdc351e615c9df708a30e4396f6f352fabaed36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94584
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5a8c7d68e4c147eb938b0217dc6368c832e465c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94154
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
as seen in tdf#133098 example
Change-Id: I58bf5c5c931cbd1f002ff28f6844d0bebcdd1913
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94440
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I280777c1524de2b640564183461903fd80d345be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94387
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib2b637c8a6d5af04256bfd9631e43d334343b610
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94265
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
As explained at <https://bugzilla.redhat.com/show_bug.cgi?id=1377293#c12>
"[Wayland] When typing fast at high CPU load, LibreOffice breaks key (letter)
order": "with a local LO master --with-lang=ALL ASan+UBSan build (i.e., which
executes somewhat slowly): When typing 'file' in Writer right after it started
up (but no longer after more typing), that gets garbled as 'fiel'." The reason
for that (but probably not for the original issue reported in that rhbz#1377293)
apparently was:
Two GDK_KEY_PRESS events (A and B) were in the GTK event queue.
GtkInstance::AnyInput consumed only A, because it broke from the first while
loop as soon as it saw the first event of appropriate type. In the second while
loop it put A back on the end of the GTK event loop, so that it now followed B.
GtkSalFrame::signalKey (vcl/unx/gtk3/gtk3gtkframe.cxx) thus received the events
in the wrong order.
Dropping the "break" also reveals that GtkInstance::AnyInput should obviously
use a queue (i.e., deque) rather than a stack to hold the events it consumed and
needs to re-enqueue.
This appears to be a regression introduced with
658954e8b50fc264428402dc5a95b0d6f690d191 "Resolves: fdo#48011 writer
idle-callbacks are halting when events pending".
Change-Id: I87d601df118a20ea3dd59e9cebbcf5176db04be8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94202
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Jenkins
|
|
cause the toplevel may not be a GtkWindow
Change-Id: Iceb1fc9a5d0054a7a2aefa5ba2ad7a2572dbb4c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94134
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4f84ccdc4490ae6190d02aca206f87133497bff9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94122
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idb8bca730d4c8d8da0d4689961cf1468051159d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94062
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5da0125a8f76d201e8dab2892b1f205c759599b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94045
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Icfc7d17f289bb94896e5e770c61809cb473d35a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93943
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
so a repeated weld will result in the same layout each time
Change-Id: I9ba41e70c29046b84392280d4bd95f8141b24251
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93953
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
for clarity as to what each chunk does
Change-Id: Ia58d19dfe162631d0ba67975eb2b9546d7afa2cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93952
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
mostly done using
git grep -wl namespace
| xargs -P 8 perl -i -pe 's/namespace\s*([\w:]+)\s*\{\s*namespace\s*/namespace \1::/g'
Change-Id: Ic53dbaf443cf81fb8940155f2582a7128d829e6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93406
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9bfe6ecd3490d9c6d12c21f8c8a7074e611f0eb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93784
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If009f0456a9e4d070b8a20fa1c63b1262b98d3df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93719
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
gtk_drag_cancel gave trouble as previously described and GDK_KEY_Escape was a
placebo which didn't do anything seeing as it wasn't applied by
gtk_main_do_event to the drag GDK_KEY_Escape handler
Change-Id: I66f6e04ded12144a33a38504f5bfc1cad7807bb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93673
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|