for a in `git ls-files '*.ui'`; do sed -i 's/^\( *\)\(<object class="GtkGrid".*\)/\1<!-- n-columns=1 n-rows=1 -->\n\1\2/' $a; done
so we get the same behavior in glade as before 3.38 in that the grid preview
don't show any unoccupied grid squares
replace all existing n-columns=X n-rows=Y lines because they are
all wrong, except for
cui/uiconfig/ui/additionsfragment.ui
sw/uiconfig/swriter/ui/pageheaderpanel.ui
sw/uiconfig/swriter/ui/pagefooterpanel.ui
which are correct.
Change-Id: I401bbe8e098c26e7f57d6a872d3b70fc1ce85a00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105846
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...to "Find functions that take rtl::O[U]String parameters that can be
generalized to take std::[u16]string_view instead." (Which in turn can avoid
costly O[U]String constructions, see e.g. loplugin:stringview and subView.)
Some of those functions' call sites, passing plain char string literals, needed
to be adapted when converting them.
Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which was added in
commit 331e2e5ed3
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Sep 14 08:49:52 2017 +0200
long->sal_Int32 in Fraction
presumably to make the change impact less code.
Instead, update the call sites to reflect the actual bitwidth
of the data we will be receiving.
Change-Id: If2a678b1cf534f39cb8cb249757462be53658309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105607
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
with unique values so that, e.g.
if (pObj->GetObjIdentifier() == OBJ_LINE)
is only true if pObj is a SdrPathObj and not a E3dScene
Change-Id: I30c91e57eb27141390c644dec42e2a4bee96edf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105374
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
and update the version mentioned in our min req in the readme.xrm
follow up to
commit 0c9ccc7dbf
Author: Caolán McNamara <caolanm@redhat.com>
Date: Fri Oct 2 21:21:45 2020 +0100
raise min version of gtk to 3.20.0
Change-Id: Ibae55c97e1ee577f4b7435d124cda6a21005ad0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104692
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
do more like
commit 121771e37f
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The user now has the possibility to sort the entries in various macro
dialogs either alphabetically or in document order using a context menu.
Change-Id: I064947daa9f9bca05cb28e4b2f65ff1c92689ae9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98783
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Maybe I'm missing something, but its usage -
"if ( !GetExport() && !GetHidden() )" seems like expects
it to be true and false at the same time. Anyway, there's
no diff in workdir/SdiTarget after this change, so should
be safe to remove.
Change-Id: I6db508ff40c05dc828ffa91bb41a37c17b697503
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102345
Tested-by: Jenkins
Tested-by: Maxim Monastirsky <momonasmon@gmail.com>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
so we can differentiate the case of embedded welded widgets co-sharing the
tab-cycle sequence with vcl widgets vs the case its all welded widgets
Change-Id: I5c57b4e98d2f5c543522a72e31d554a67c259307
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101485
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
These extended tips are extracted from <ahelp> in Help files
Only for ui files, where dialogs/widget pair could be determined.
Other forms of <ahelp hid=".."> such as .uno:.. and *HID* ... will
be addressed elswhere.
Change#1 Removed extended tips from GtkMenu of
svx/.../acceptrejectchangesdialog.ui
Change#2 Some empty ET's slipped in cui/macroselectdialog.ui
Change-Id: Ic8dc62734143f621fcd3c4156fc004f585630277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101186
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Just store the last used menu id, and consistently get all the
information (command name, image id, target frame etc.) from the menu
instance. Also implement the XSubToolbarController interface, so we get
a chance to update the image on icon size or theme change.
The initial action and icon of the button are based on the url passed
by the .uno:AddDirect status update, given that there is a corresponding
menu item. The only defined fallback now is to .uno:AddDirect itself for
both executing and getting the icon, but this shouldn't happen normally,
as I fixed all the affected cases I found so far, namely Base (including
windows like table design etc.) and the Basic IDE.
Actually these cases were partially broken anyway, and as a result now
completely fixed:
- In Base main app window, the button used to default to a new Writer
document, although its tooltip advertises Ctrl+N as the kb shortcut, and
pressing that shortcut actually opens the database creation wizard (as
expected).
- In the Basic IDE, the button was working, but not the Ctrl+N shortcut.
Change-Id: I6537b3f38e7d7001ec1b39d78285445464fd8cbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99514
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
leaving a dangling reference to m_aName. Hold a reference until
ExecuteCommand is finished.
Change-Id: I82ac5cc73427a945c78b9317dee9edf6129bb975
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98214
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>
Caolán McNamara