Age | Commit message (Collapse) | Author | Files | Lines |
|
Align implementation with API contract as spelled out in
offapi/com/sun/star/frame/XDispatchProviderInterception.idl -
no idea why this change happenend in 2003:
Date: Fri Apr 4 16:16:05 2003 +0000
INTEGRATION: CWS fwk01 (1.1.72); FILE MERGED
2003/04/01 12:40:09 as 1.1.72.1: #107642# change order of used interception objects
At any rate, with this change extensions actually get a chance to
see dispatch requests first, and process/ignore at will.
Change-Id: I58876150ee6d67e592f41b3e82a9ffc314e091a3
Reviewed-on: https://gerrit.libreoffice.org/25215
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 08cf2fd01064306eef7fdbb5b62320947c4d1089)
|
|
Make better use of the css::frame::XInterceptorInfo interface, to avoid
calling queryDispatch() pointlessly on interfaces that have explicitely
opted out. Since that already broadcasts which urls we're interested in
- so just don't bother calling entries who are not matching.
Change-Id: Id5e780568fd60c38f4cee4ee800d747d65a31dae
Reviewed-on: https://gerrit.libreoffice.org/25214
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 27b6cdb5ab5af33dbba561923c8db81e144c88b9)
|
|
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>
(cherry picked from commit 5d4f1f6f630d4382679087a4fb0da364c9c9692b)
|
|
Change-Id: I72d9f8b00ba8b2e4e5dc70d7fd77e13ccf9d3bcc
Reviewed-on: https://gerrit.libreoffice.org/24940
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
(cherry picked from commit 1f041bf31e071611a15ffa1559d2f5df05a685f0)
|
|
This should allow remote, eg. URE dispatchers to trivially disable
lots of the UI without requiring a large volume of round-trip IPC.
Reviewed-on: https://gerrit.libreoffice.org/24938
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
(cherry picked from commit 02833c03ee856a62d7185829b7c47bc088e086cc)
Conflicts:
framework/inc/services.h
Change-Id: Ibd0681ac993196f826b4ed411da5ffedb7f85786
|
|
This can occur in some online corner-cases.
Change-Id: Id8b419179d775a21110d682ba76d8a02f45eb828
|
|
(cherry picked from commits 3ff17bda5ba3e627e9b996506dc72b68cf67483b and 398fadca9a82917ed865e328ba454d8015803b66)
This patch differs from the one in master since CommandInfoProvider is not available before 5.1.
Change-Id: Icc16860d8b47a3724838fdb3dcb72dfb4398167d
Reviewed-on: https://gerrit.libreoffice.org/22806
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 4a8a051e1a29c86d29d5064455226c4f11f69f52)
|
|
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/22750
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
Tested-by: Oliver Specht <oliver.specht@cib.de>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit d7955212492009976764d701bf789e76f5fdfa4a)
Reviewed-on: https://gerrit.libreoffice.org/22760
(cherry picked from commit 42ac7f9cdbf66414cf03657470c2f684836184f4)
|
|
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>
Reviewed-on: https://gerrit.libreoffice.org/22461
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 8a50946c2868f196a1f4571e491a5ca7fb12492a)
|
|
Change-Id: Icab7dea3cf63f3932b7759acec339b498a8ac9c5
Reviewed-on: https://gerrit.libreoffice.org/22233
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
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.
(cherry picked from commit 0dbe3d40579d20f4cbce3ce155996ff4b5c32c99)
Conflicts:
framework/source/fwe/xml/menudocumenthandler.cxx
Change-Id: I2f88807eceae1006066a14750f2003e235f49ad4
Reviewed-on: https://gerrit.libreoffice.org/21705
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 23d363f019e8c6911adb5f8b07bdb7ff09d467cc)
|
|
...called from within the signal handler, so any bets are off
Change-Id: Iedb5c7bc8d08350e5f3e3118c6713f5c25b238b6
(cherry picked from commit 9b3ca276dae6f8d4f337c78e64ed6b7f7e7662ef)
Reviewed-on: https://gerrit.libreoffice.org/20282
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
(cherry picked from commit 85a4677c201c3957db55ddd66506526d908e7947)
|
|
Change-Id: I296ce6233287dac5447462faa4b7404c25297f8b
(cherry picked from commit 87297284782adbf1fcb73663ad2d2a38b5ae1872)
|
|
(cherry picked from commit 3080e4c09b7c4894d4f0f52c9beed4298f3fd23f)
(cherry picked from commit fedf965c51a9f57e5cde203a3d15a6c244558002)
(cherry picked from commit 4c2339d8177d610cc23619e787c1517ce8e8afd7)
(cherry picked from commit 1bc911eca173131fdc6e7e3889d128fa03adbf72)
Conflicts:
framework/source/uielement/menubarmanager.cxx
sc/uiconfig/scalc/menubar/menubar.xml
sd/uiconfig/simpress/menubar/menubar.xml
sw/uiconfig/swriter/menubar/menubar.xml
Change-Id: Ib6578ddd7897d9c5d63b5dc8d8465f6107cc24a6
Reviewed-on: https://gerrit.libreoffice.org/19345
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit be6440f4624be4da84ac8b71e66297d3e43ca249)
|
|
Regression of 46666a7720e18238b926531a7082dbb8bc524889.
The code in MenuBarManager::FillMenuManager merges the
addon menu before .uno:WindowList, which doesn't exist
in the start center since that commit.
As a last resort, let's also check for .uno:HelpMenu
(assuming that it's never placed before the Window menu).
Change-Id: If45eebe4351c40d8ed69daba527844ffc02e8458
Reviewed-on: https://gerrit.libreoffice.org/18729
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit f30206f63dcf6fe41a216a3d708dfd05cc2b83a9)
|
|
Also:
- let the unit test set the global LOK flag, as sw code now depends on
that
- in framework, don't return early after emitting the LOK status
indicator callback, otherwise CppunitTest_sw_tiledrendering shows how
sw LOK callbacks are missing
Change-Id: I0c4ac12f2ef5118d29afd131676bcb27d5db7746
(cherry picked from commit 1a83f30ebe2c56b00804ce774537b34f1049be84)
|
|
Need to update the tooltip also on state change.
This partially reverts the fix for tdf#83558, 1fb8724f9834dbc07b741eeed31b31347bc0c2a1
Verified that the fix for tdf#83558 still works.
Change-Id: I023a5e4b101dc91522f19b0d3ed2ed0c4a47e64b
Reviewed-on: https://gerrit.libreoffice.org/18586
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
...after 54f10a9654b617c4c993044e52e7bd40d0151c53 "tdf#93404: Forgot to launch
WakeUpThread," when the WakeUpThread blocks on locking
StatusIndicatorFactory::m_mutex in StatusIndicatorFactory::update() while the
joining thread blocks on StatusIndicatorFactory::impl_stopWakeUpThread() ->
WakeUpThread::stop() -> Thread::join().
Change-Id: I3480014b1f522901064ea9b71ffa2ebf5d74fef5
(cherry picked from commit ded58e062c9e9b8b5f9dc9a18777a1be68359a91)
Reviewed-on: https://gerrit.libreoffice.org/17709
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...in 017f250764ec7b4ecb82ac19f5b3f68cadf1bf56 "Ensure WakeUpThread is joined
before exit"
Change-Id: Iaa5a5772f099b11229bd40c3cc10d863ef0ad5b3
(cherry picked from commit 54f10a9654b617c4c993044e52e7bd40d0151c53)
Reviewed-on: https://gerrit.libreoffice.org/17697
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Decouple the actual window from rendercontext in UserDrawEvent.
Change-Id: Ic440c4e7f59fcffb7800c578146e8eb528cbb7b4
|
|
Now, whatever the size of toolbar icons, the toolbar
context menu always shows small icons.
Change-Id: Id17df15278d74ae75a3e82d54ecf7af310e0ceb4
Reviewed-on: https://gerrit.libreoffice.org/16361
Reviewed-by: Philippe Jung <phil.jung@free.fr>
Tested-by: Philippe Jung <phil.jung@free.fr>
(cherry picked from commit 3090550b5297c86b63ba09ed1aa13bce4c0e5b70)
Reviewed-on: https://gerrit.libreoffice.org/16365
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
|
|
Renames some variable to ease the understanding of what does what
Change-Id: Idd84eb89b7c1fb56dd43d66edfbbeafedc319095
Reviewed-on: https://gerrit.libreoffice.org/16360
Reviewed-by: Philippe Jung <phil.jung@free.fr>
Tested-by: Philippe Jung <phil.jung@free.fr>
(cherry picked from commit 79be3a5e3856593bb759b6e521f06dc99c69c0ae)
Reviewed-on: https://gerrit.libreoffice.org/16363
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
|
|
At least OutputDevice::acquire/release use a plain unguarded int and ++, --, so
apparently rely on the SolarMutex being locked whenever they are called. Fixed
those places that caused "make check" to fail for me when temporarily adding
DBG_TESTSOLARMUTEX() to OutputDevice::acquire/release. (A recurring pattern is
that a class fails to ensure the SolarMutex is locked around the destruction of
non-null VclPtr members.)
Change-Id: I77cba6f3908f2de1b516ce28f1c3c43b3f57a9c5
(cherry picked from commit 8e1ad966262932516b3368d9b5c44becb29524d4)
Signed-off-by: Michael Stahl <mstahl@redhat.com>
|
|
Omit the plugin, and sw's FrameControlsManager for now.
Change-Id: Ifb98a2e6e03a9d099efc1668305b96bd9142ca5f
Reviewed-on: https://gerrit.libreoffice.org/16117
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I3a82423378d3198a25f90ddfbf42af55d85c96fb
(cherry picked from commit 668408fa1c69eaf0f0a37f24e2ec8b4a38fe3db7, w/o the
accidentally included sw/htmlexport-swobjects.patch)
|
|
Change-Id: Id9e8ce7987e055e83b52c7024413570f262e6e8d
|
|
Change-Id: I646677611e46a7e33e977a5afeea9bf831b28733
|
|
Change-Id: I969d99fa8881cc89601696a2d8621905a82b147b
|
|
Change-Id: I4cdaf36581d1e1daa39929e621070d18a9996852
|
|
When Menu::SetText is called, it defines the title of the menu (reuse of
an already defined & not used aTitleText)
Popup-menu with a title defined paint it on top of the popup. Text is bold
with a background slightly darker than the rest of the popup.
Change-Id: Ifca1be60541400f76f562b03f6e3c40dc5fecb29
Reviewed-on: https://gerrit.libreoffice.org/15716
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I43080ab6a4d9530a5cd4e3b8fa7806df41467e51
|
|
Change-Id: Ie8c6547da8210f394df261d8a189a9daba034b6e
|
|
Change-Id: I88e67f89dbbab0646e8f106dfeb32c6ee1bb0b95
Reviewed-on: https://gerrit.libreoffice.org/15671
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia1130431fa5206bd007b6ce05488e4a199323c5b
|
|
Change-Id: I1e24b032bdeea017b0e77c5446e55310899ce752
|
|
Change-Id: Ifb032457d6c1b279c4183282ef2b271c706dd71a
|
|
Change-Id: I2c19d1a0f8ad31cdf384ab301f3dae99a6ea9933
|
|
Gets rid of superfluous sequential callbacks with the same percentage when
loading large documents.
This reverts commit cec72eff99d1d683f2236c8a86a2814b34ad861e.
Change-Id: I70f43f7e3a650c76cbcbbc60ebb2d47efaca06a5
|
|
Change-Id: Ib27854a8470f3ff5b208cb949a7bd02f2a86c969
|
|
Change-Id: I58fffa7345f6b5050b8a1b3ac1022c630e64dbb4
Reviewed-on: https://gerrit.libreoffice.org/15651
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I6736383ad0ec5c9f2ea2281bfdcfa280cd712032
|
|
Change-Id: I47a35813fddcb90497b621a96bafe74969dc90d0
|
|
It can well be that the StatusIndicator code is called for multiple
independent sections while loading some document format, and that the first
progress is not the one that actually takes much time at all, so following
just the progress of that would be misleading, the progress would be "stuck"
at the highest value set by the first progress (forever, if it has gone up to
100%).
For example, when loading the odk/examples/java/DocumentHandling/
test/test1.odt sample document, the code first calls the StatusIndicator while
parsing the styles.xml, going from 0% to 100%. But the styles.xml is typically
rather small. Then the code calls the StatusIndicator *again* while parsing
the much more relevant concent.xml. For that particular document, this time
the progress goes from 0% to 27% only, for some reason. Oh well, GIGO.
Change-Id: I87bfc586a53efcbeb94924f21dd365ca63da88d7
|
|
Change-Id: I06a382917717906a0e5fdee57e296bab407c5348
|
|
The framework bits.
Change-Id: I9cbd649c7766284bfcf8846d2b5e129dd2731ee8
|
|
Change-Id: I00cd35374294ccdcc0ac3223ae81ba8129b9a5d7
|
|
Change-Id: Ia4fe932e765651653e6c534e755a8fc32875ffc3
|
|
Change-Id: I9b574f652e5d999086e32e9c7ede7c68fe5cc99a
|
|
Change-Id: Ieee142ddebb288037647fb77bac6f11b9827c4a8
|
|
Change-Id: Ibc9f88d2588c028cd71aa86c26d970a73025ef22
|