Age | Commit message (Collapse) | Author |
|
checking for casting to void* turns out to mask useful stuff, so
remove that and just deal with a few extra false+
Change-Id: Id9700d7ceda90ba8fdb38aa870f13a7ca3acb668
Reviewed-on: https://gerrit.libreoffice.org/63145
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which seem to have snuck back in since the great rounds of removals.
Change-Id: I85f7f5f4801c0b48dae8b50f51f83595b286d6a1
Reviewed-on: https://gerrit.libreoffice.org/62229
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: Ib420e9216b8313f5ed7634ec375e39ceb741fd45
Reviewed-on: https://gerrit.libreoffice.org/59297
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Iffdd62e8af5fa31caecc6ea01bd5e21de950862c
Reviewed-on: https://gerrit.libreoffice.org/59021
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id3009a4b038175625cf8be419deb5ef8a9998850
Reviewed-on: https://gerrit.libreoffice.org/58110
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...by removing explicitly user-provided functions that do the same as their
implicitly-defined counterparts, but may prevent implicitly declared copy
functions from being defined as non-deleted in the future. (Even if such a
user-provided function was declared non-inline in an include file, the
apparently-used implicitly-defined copy functions are already inline, so why
bother with non-inline functions.)
Change-Id: Ia4c3442642a2db3ca365a35e56a203a955a415c4
Reviewed-on: https://gerrit.libreoffice.org/58080
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9fbfa6163c1d4650c52b00dc911972f07fe7c0e5
Reviewed-on: https://gerrit.libreoffice.org/56778
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6c03a7e99b31251eb0fe1c197d565e85bec419df
Reviewed-on: https://gerrit.libreoffice.org/52279
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jens Carl <j.carl43@gmx.de>
|
|
...after 5c573a2f7473bae7bb965ca36557cd1b0bf7b9c9 "tdf#115131 made a common
submenu for toolbars and notebookbars"
Change-Id: Ic1713fa1173a8dbb1bcc971c30d0df4549c825a9
Reviewed-on: https://gerrit.libreoffice.org/52331
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3ce653c0d9e517229dbbe32cc8d3ec3c206e364d
Reviewed-on: https://gerrit.libreoffice.org/51273
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
"Indirect" calls to isSallCallFunction (for canonic and overridden
FunctionDecls) already needed to handle many cases of FunctionDecls spanning
macros, so it isn't that much more work to make that also work for cases called
directly from VisitFunctionDecl.
Change-Id: I529f148c8872b86aa1ef082c6cb73db8ab1866e7
Reviewed-on: https://gerrit.libreoffice.org/46367
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
first, since those are safer to change than virtual methods
Change-Id: Ie3b624019d75ee2b793cee33b3c5f64e994e8bfe
Reviewed-on: https://gerrit.libreoffice.org/45798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic060a8ec60c1209511c376f31e2dc45a48973294
Reviewed-on: https://gerrit.libreoffice.org/44166
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib5eaab06ff0cc1b44db9e4057ab349a0990af14d
|
|
no need to explicitly specify it anymore
Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec
Reviewed-on: https://gerrit.libreoffice.org/43567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1f8260fd148b694337ea0440eb2edde4753b34c1
|
|
since
commit 5298b1b32d90002be8d09fe82955550c18eae8bc
Date: Mon Aug 8 11:48:55 2011 +0100
callcatcher: ditch some more methods
Change-Id: I123081cbe7fe351ce6613a5e7491b11e133d1d29
|
|
had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis
Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iecd19a0cbb3cc78158c17bfa064cc23bafc44b18
Reviewed-on: https://gerrit.libreoffice.org/40206
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibb602e037bcee518c31dfe9734a5c5773cff23ab
Reviewed-on: https://gerrit.libreoffice.org/39492
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If250ff47c1f375fe24c61b5bf271da9a9c330822
Reviewed-on: https://gerrit.libreoffice.org/39133
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I173a29fd1ee889127369d2bc2fce8e010b89ca65
Reviewed-on: https://gerrit.libreoffice.org/38633
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I66b27e623e411c9ba9c5ba17c46c052336d031b8
Reviewed-on: https://gerrit.libreoffice.org/38503
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
|
|
LayoutManager uses macro impl from comphelper, so use declarations
from comphelper too.
Change-Id: I638492849742782d48c3bb5439c2255e72f9f694
Reviewed-on: https://gerrit.libreoffice.org/38496
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifd4b495f965f948d37557d83a03a38df9322039a
Reviewed-on: https://gerrit.libreoffice.org/38109
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
make it a little smarter in dealing with fields that are smart pointers
Change-Id: I44072105170882dc29fb19558f1065cffc7e5f11
Reviewed-on: https://gerrit.libreoffice.org/37751
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia0c47186f5f266d512c02e92d7983872e207f878
|
|
Change-Id: I3022d609e813d90e52990b570aa471540c9e2c18
|
|
by whitelisting a couple of methods we know only write to their
parameters
Change-Id: Id7aef9c03c23d10c27707b21eb9a0db4a6c2757c
Reviewed-on: https://gerrit.libreoffice.org/37647
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
MenuBarManager overwrites the item URL with the parsed
version. This causes the keyboard shortcuts of style
commands to no longer be found on subsequent opening of
the menu, because they have spaces, which in the parsed
version were replaced with "%20".
Change-Id: I80b559203742922f70b7cec54b5a5ae57d3ef7dd
|
|
The .uno:StyleApply command takes some arguments, which make
it possible to apply any style of any type. The problem is
that it doesn't provide toggle state to be used when placing
such commands on a toolbar or a menubar. The reason is that
sfx2, by design, can provide status updates only for the
.uno:StyleApply command as a whole, ignoring any arguments
that might be specified in the UI element description. This
behavior is even documented in the XDispatch idl.
wrt solution, changing the generic UI code to handle the
specifics of an individual command can never be a good idea.
The usual approach in such cases is to create separate
commands which will handle the status updates correctly. This
is however not possible in our case because styles can be
created by users, and we can't predict their names and create
separate commands for all of them (given that now it's easy to
add style commands to toolbars and menus - see tdf#106681).
One possible solution is to create a toolbar button controller
on top of .uno:StyleApply, which will be able to translate its
status update to a state compatible with the toolbar. The downside
is that it won't work when placing such command inside a menu, and
in general the menu code in framework doesn't provide any way to
control individual menu items, only a whole sub-menus via a
popup menu controller.
To fix the menu use-case too, this commit introduces a "proxy"
dispatch implementation, which can be used by MenuBarManager
in a transparent way, as if it was the "real" application-level
dispatcher. This means that the changes needed in MenuBarManager
are minimal and do not over-complicate the code, which is a good
thing (Alternatively, such dispatcher could be registered via
the dispatch interception mechanism, but it will add no gain,
given the current requirements, and just add more complexity).
And to make it easier to reuse the code, the new dispatcher
is also used for the toolbar solution.
Change-Id: Ia73b0fa70fd4d1d59360b255aa8fd19570b971ee
Reviewed-on: https://gerrit.libreoffice.org/37590
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: I963159550da9d735bb70636917ecc290744298b4
Reviewed-on: https://gerrit.libreoffice.org/37142
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
this modifies codemaker so that, for an UNO enum, we generate code
that effectively looks like:
#ifdef LIBO_INTERNAL_ONLY && HAVE_CX11_CONSTEXPR
enum class XXX {
ONE = 1
};
constexpr auto ONE = XXX_ONE;
#else
...the old normal way..
#endif
which means that for LO internal code, the enums are scoped.
The "constexpr auto" trick acts like an alias so we don't have to
use scoped naming everywhere.
Change-Id: I3054ecb230e8666ce98b4a9cb87b384df5f64fb4
Reviewed-on: https://gerrit.libreoffice.org/34546
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6ec50033a452493852729dc8efe78da2708cbd96
|
|
(vs. uses of sal_uInt16 representing such items' IDs). APPEND and ITEM_NOTFOUND
are members of ToolBox now (and have been bumped to the corresponding type's
max). The payload of VclEventIds
ToolboxButtonStateChanged
ToolboxClick
ToolboxHighlightOff
ToolboxItemAdded
ToolboxItemDisabled
ToolboxItemEnabled
ToolboxItemRemoved
ToolboxItemTextChanged
ToolboxItemUpdated
ToolboxItemWindowChanged
ToolboxSelect
has been changed too (note that reading/writing of those payloads isn't very
consistent, though: for some of these, values are written that are never read,
while for some others no values are ever written but the reading code would like
to receive some value if the payload wasn't a nullptr).
Change-Id: I4856ffb3637404b8d866621a3503d7922b1b8141
|
|
Change-Id: I3a30bc86796a7ad24616cb11ae10b6886e09c1e9
|
|
Change-Id: I6b366f115258ef8497807163179d3e08ab3d5e6f
Reviewed-on: https://gerrit.libreoffice.org/34180
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
- Make it self-contained, instead of having its code
spread across ToolBarManager.
- Base it on svt::ToolboxController directly, since it
uses nothing from GenericToolbarController.
- Move the code from dtor to dispose method.
- Call ToolBox::SetItemDown to make the button work on
a second click.
Change-Id: I5b38ef532ba40ef0ac31bc53de5b6be4ccd1a118
Reviewed-on: https://gerrit.libreoffice.org/33982
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Convert EProtocol to scoped enum and drop E_UNKNOWN_PROTOCOL.
Convert ToggleButtonToolbarController::Style to scoped enum and drop
STYLE_TOGGLEBUTTON.
Convert TargetHelper::ESpecialTarget to scoped enum and drop
E_NOT_SPECIAL.
Change-Id: I412adacac15192cf6563ce4d5e5b74bfffff4737
Reviewed-on: https://gerrit.libreoffice.org/33949
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I19a4517449be3defe97fe0d78dd1a16b08b79247
|
|
Change-Id: I4300a13f455148b7156ac3f444c7102d63ae6db3
Reviewed-on: https://gerrit.libreoffice.org/33164
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifa2970cf838209b72e286109f14b98e77f389c0b
|
|
Change-Id: I444f31f06d2445392a59879c2d7fb1f8ad1c24c6
Reviewed-on: https://gerrit.libreoffice.org/30684
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifce80cec8935b960b14716d09080f76351633c0b
|
|
Change-Id: I881e6781c5ba82b0b998891532f8b7c281567b73
|
|
This adds support for 32 pixel icons - mainly to get them into
the toolbar.
Most changes made are to change the behavior of having only small
and large icons as a boolean choice, but not every code path was
converted to non-boolean choice yet.
Breeze icon theme has the 32px variants so it can be used already.
Change-Id: Iadf832a87826c16b3a83522104dd6c35d61a0f87
Reviewed-on: https://gerrit.libreoffice.org/30398
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
(I'm not sure about how good are the changes from ScopedVclPtr
to non-scoped, and disposeAndClear to clear. They aren't really
needed, because of the VclReferenceBase::mbDisposed logic. But
at least they should be safe, as long as we have disposeOnce
calls in Menu's dtor.)
See also previous commits:
4433d95b374c13a3501cdf3a6e273f68eb49873a
("MenuItemData now properly disposes the submenu")
89c23b4aaef931b5d6009efaf44ce6e6c976e8d4
("Sub menus no longer need manual disposing")
Change-Id: I9d455a94590f5eec9b097947f6984f1b3e477b52
|
|
Change-Id: I9b6e762fd4c231a5bd54eb546026499da2efa0e6
|