Age | Commit message (Collapse) | Author |
|
This allows to use the username as a placeholder in the config paths (Autotext, Gallery, etc)
Change-Id: I76434e980cd8ec8785a5587d0bc5fdd67dc42de2
Reviewed-on: https://gerrit.libreoffice.org/22901
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
to catch calling params with defaults like "= OUSString()"
Change-Id: Iad060e318ed492c22f8be44e326174fe6d28fff9
Reviewed-on: https://gerrit.libreoffice.org/22932
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
when using native gtk3 menubars.
The issue is that MenuBarManager does not own its MenuBar.
And in this embedded menubar situation a new menubar is newed and passed to
m_pInplaceMenuBar but nothing destroys it.
Now with native gtk3 menubars this becomes obvious as the native menubar stays
behind, while in the non-native case the old menubar is replaced by
the new one so while it still leaks the menubar you don't see it.
Change-Id: Id732cb66664a71efc471d7bad35f4de890e1017e
|
|
Change-Id: I4c5baa6f524e3382794c4844b7444904cc38584a
|
|
When toolbar buttons have no icon, the text is displayed instead.
In this case the shortcut should not be displayed (only in the tooltip).
Change-Id: I42ac855c8f9bbbad5114b77a29927003b8ca095e
|
|
Change-Id: Icc16860d8b47a3724838fdb3dcb72dfb4398167d
Reviewed-on: https://gerrit.libreoffice.org/22779
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
is always disabled/empty since...
commit a6e8910a3c5d33e671a13559438b7228596b8bca
Date: Wed Feb 17 12:07:59 2016 +0100
allow disabling file/new, wizards, recent documents menu entries
disabling the dispatches '.uno:AutoPilotMenu' and '.uno:AddDirect' and
.uno:RecentFileList via UNO API now results in disabled
menu entries as expected
Change-Id: Id99be9374306ff8c0cea919ea94ed96f715a8058
Reviewed-on: https://gerrit.libreoffice.org/22422
reverting this hunk restores them again
Change-Id: I029c9c3f25fb593127ee8371b278cee102c65882
Reviewed-on: https://gerrit.libreoffice.org/22749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
We already can use different labels for commands, based on
whether they're in a menu, context menu or a toolbar. But in
some cases we need different labels for the same type of UI
element, or even different icons.
One example is page/slide commands in Draw/Impress, as they
share same commands, but need different icons/labels.
Creating full-fledged duplicate slots just to satisfy the
need of UI representation seems like overkill, and isn't
flexible enough.
The proposed solution is to allow creation of command entries,
that do not correspond to real application slots, but instead
link to another existing commands. The "real" commands will be
used for controller factory and dispatch (execute/status) APIs,
thus fully retaining functionality.
This can be useful also for giving icons to complex commands
(i.e. commands with arguments).
Change-Id: I9b261b406ec8fc781cae06cf283963386379d4ad
|
|
Change-Id: I1e81c8d637e738f536f7efad8b67d0c9183e6483
|
|
Change-Id: I44f249a17d0a510ec63a488b656d57a1a392f821
|
|
Change-Id: I6e428222bfb3045b6a379716586aa5e37a3cae35
Reviewed-on: https://gerrit.libreoffice.org/22052
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
disabling the dispatches '.uno:AutoPilotMenu' and '.uno:AddDirect' and
.uno:RecentFileList via UNO API now results in disabled
menu entries as expected
Change-Id: Id99be9374306ff8c0cea919ea94ed96f715a8058
Reviewed-on: https://gerrit.libreoffice.org/22422
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
Tested-by: Oliver Specht <oliver.specht@cib.de>
|
|
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Iedab5e5be5358f7716a2b33de3f0db582a401155
|
|
Added freezepanesfirstcolumn and freezepanesfirstrow commands.
FreezePanes button became a split button that includes this two new
uno commands. And this new commands added to menu.
Change-Id: Ic6958067cc98b3df50bcd06a1eac220bd9a61473
Reviewed-on: https://gerrit.libreoffice.org/21604
Signed-off-by: Gulsah Kose <gulsah.1004@gmail.com>
|
|
Change-Id: I6ba411d2e07240821518281996d543f71acf3259
Reviewed-on: https://gerrit.libreoffice.org/22378
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
- MenuBarManager::Activate has a check for duplicate activation,
which makes the second activation attempt fail. Removing this
check or deactivating after each activation will likely affect
performance even more, but on the other hand should solve
lp#1296715, which was the main reason of the over activation
in the first place. So let's activate only one menu at a time,
and do full activation only on the initial update.
- Unfortunately the HUD activation callback doesn't work, so
we still have to keep active status listener for all menu
items. (Which is BTW against the recommendation in
XPopupMenuController::updatePopupMenu IDL doc. Fortunately
the performance problem hardly noticeable on modern hw.)
Change-Id: I96affa72412f3f38160fdca4b6efd20ca68d059f
Reviewed-on: https://gerrit.libreoffice.org/22369
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: Icab7dea3cf63f3932b7759acec339b498a8ac9c5
Reviewed-on: https://gerrit.libreoffice.org/22233
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
The change caused failures in some Java unit tests.
This reverts commit 882d27fce20ee0537f785a619be1dd065ea6bbca.
|
|
Change-Id: Icab7dea3cf63f3932b7759acec339b498a8ac9c5
Reviewed-on: https://gerrit.libreoffice.org/22233
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I77b30f28ae5a6fad360d7cada9acfaa9c324408b
Reviewed-on: https://gerrit.libreoffice.org/22216
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
using an idea from dtardon:
<dtardon> noelgrandin, hi. could you try to run the unusedmethods clang
plugin with "make build-nocheck"? that would catch functions that are
only used in tests. e.g., i just removed the whole o3tl::range class,
which has not been used in many years, but htere was a test for it...
<noelgrandin> dtardon, interesting idea! Sure, I can do that.
Change-Id: I5653953a426a2186a1e43017212d87ffce520387
Reviewed-on: https://gerrit.libreoffice.org/22041
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Having them in the file apptypes.hxx isn't necessary helpful, IMO so
I've split the types into inputtypes.hxx and exceptiontypes.hxx
Change-Id: I89a1ff168c3ae276b2f5486669d4ec2dda062d57
|
|
Change-Id: Ice72f8d9971e15dd6ef365e64cd567b8581a92d3
Reviewed-on: https://gerrit.libreoffice.org/21797
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: If965ad91e771c84e89c6690a4e1b733d4e70f1b4
|
|
Change-Id: I27a0fa8318fa50ef6e3ccd3a736c5fcbc36bbaa0
|
|
Change-Id: I3bee504b5a3dce7d89af77c8fcf2f9e24d5119ca
Reviewed-on: https://gerrit.libreoffice.org/22105
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I1b79a39a9d709184cc72a905647f73dbf85eef27
Signed-off-by: Berk Gureken <berkgureken@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/21991
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
I'm changing the Font class function names:
- SetSize -> SetFontSize
- GetSize -> GetFontSize
- SetHeight -> SetFontHeight
- GetHeight -> GetFontHeight
- SetWidth -> SetAverageFontWidth
- GetWidth -> GetAverageFontWidth
That's because it really makes no sense to say that there is a
single constant font width because obviously proportional fonts
don't have one - the best we can do is an average font width,
which is what folks like Microsoft sort of do already. On a fixed
font, the average is still accurate, for obvious reasons :-)
I'm also not a fan of GetSize/SetSize as I find it a might too
generic.
Change-Id: Ib80a604ba62d6883fd6cbc7994da763976be5c70
Reviewed-on: https://gerrit.libreoffice.org/22069
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I66857f640e2e4c397b4f9baf7903356a0510c0b7
Reviewed-on: https://gerrit.libreoffice.org/22035
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: If4d1e4071995f07212fad958b0226d5824d168f8
Reviewed-on: https://gerrit.libreoffice.org/21989
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
as a direct drop in I guess
Change-Id: I3add63f1459f4e659019bd6db54da2f5431958ce
Reviewed-on: https://gerrit.libreoffice.org/21941
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idd31b0a53c8318af69bbcd32f6798721ec8eb8e1
Reviewed-on: https://gerrit.libreoffice.org/21945
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
No need for yet another controller that does similar things.
Change-Id: I4ad79d82ea34a90a43e36082d1fb834201dba3a1
|
|
Change-Id: Ib41952dae6bcca80436355fa5a0707e671fd3698
|
|
Change-Id: I97886c8dbd7b56d155ad9598ca127df0c7420d2c
|
|
Change-Id: I734b1bf07a4c964c738b24d5145720cb502f624c
|
|
Change-Id: Ia5a3a94ce03af23c44485aedc5ae1c088f1a2d85
|
|
Change-Id: Ib0570622ac2853c83d701c207ff3aa0a3781d689
|
|
Change-Id: I2ff6462472292de7cdeb5c7ed748299e58399bdb
|
|
When destroying the static vcl::CommandInfoProvider aProvider from
vcl::CommandInfoProvider::Instance (vcl/source/helper/commandinfoprovider.cxx)
during exit, it releases its mxCachedGlobalAcceleratorConfiguration reference on
GlobalAcceleratorConfiguration
(framework/source/accelerators/globalacceleratorconfiguration.cxx), which may
get destroyed, whose base class framework::XCUBasedAcceleratorConfiguration
(framework/source/inc/accelerators/acceleratorconfiguration.hxx) has a
salhelper::SingletonRef<framework::KeyMapping> member, whose destructor
(include/salhelper/singletonref.hxx) uses
salhelper::SingletonRef<framework::KeyMapping>::SingletonLockInit::operator ()'s
static osl::Mutex aInstance.
If, during construction, the instantiation of
salhelper::SingletonRef<framework::KeyMapping>::SingletonLockInit::operator ()'s
static osl::Mutex aInstance finishes before the instantiation of
vcl::CommandInfoProvider::Instance's static vcl::CommandInfoProvider aProvider,
the corresponding atexit cleanup actions will be recorded in the right order,
causing the above chain of calls to find the static Mutex still alive when used
from within the static CommandInfoProvider's destruction.
However, vcl::CommandInfoProvider's mxCachedGlobalAcceleratorConfiguration is
only set to css::ui::GlobalAcceleratorConfiguration::create in
vcl::CommandInfoProvider::GetGlobalAcceleratorConfiguration, so the
instantiation of the static Mutex instance can finish after the instantiation of
the static CommandInfoProvider instance, recording the atexit cleanup actions in
the wrong order, causing the static Mutex to be used after destruction.
This occasionally caused PythonTest_sfx2_python to hang during exit for me on
Linux, where trying to lock a destroyed pthread mutex can apparently deadlock.
rtl::Static does away with the need to do anything in the destructor, at the
expense of always keeping the instance alive until exit (and not being able to
recreate an already destroyed instance during exit, but code that would require
that behavior would probably already be broken to begin with), so the order of
creation of the CommandInfoProvider and GlobalAcceleratorConfiguration instances
becomes less of a concern.
Change-Id: Id6e3860ad9e5b7045980a0b9bf9eaef2e24129bb
|
|
create an InterfaceContainer2 class to replace InterfaceContainer.
It uses a std::vector instead of a Sequence for the mutable listener
list, which provides far better performance.
Switch all our internal use-sites to the new class.
Change-Id: I6b56cfa511ded2395faa22e68fab3b2f16c3cb88
|
|
Change-Id: I681054715e943791bddb4b33f01c903c78b717d7
|
|
Change-Id: I942f42bbc43e041a7dae1e83663171c0f2978378
|
|
Code like:
if( aCommandURL.copy(5) != ".uno:" )
is obviously wrong, as OUString::copy(sal_Int32) takes the _beginning_
index, so for this condition to be false the command URL must have
".uno:" in the _middle_ of the string. This created some weird things
like an empty label attribute added to any submenu item. Moreover, the
command URL can be easily shorter than 5 (like when a custom submenu
added by the user). Using copy(5) in such case officially considered as
"undefined behavior" and will trigger an assert in debug build (that's
how I discovered this code actually).
Most likely the original intent was to check whether the command URL
doesn't start with ".uno:", and so should be changed to use
OUString::startsWith. But doing that will create a regression, as it
won't be possible anymore to change labels of commands that start with
".uno:". Simply dropping this check seems to be better solution here.
Change-Id: I2f88807eceae1006066a14750f2003e235f49ad4
|
|
Change-Id: I9c61a46c57894bc63a57740206c0bcb4a16553af
Reviewed-on: https://gerrit.libreoffice.org/21571
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Iad6195ea8b082ca5e6c1a7e9fa48742ff2b495a6
|
|
unused code
Remove global static variable "m_bPreferrFirstInterceptor" which is always true,
and remove the ifs where it is false.
Change-Id: I54dcea7a6010c825a66020ec3f7448bb32d120b8
Reviewed-on: https://gerrit.libreoffice.org/21519
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: Ie1a5c11c7ae8c2288bba7e2ef228d85479d7808e
|