summaryrefslogtreecommitdiff
path: root/framework
AgeCommit message (Collapse)AuthorFilesLines
2016-12-24unused Image in framework, luckily because uses GetImage on pos not idCaolán McNamara1-1/+0
Change-Id: I97dab3bc1025cd4804910c228235b49216f3afe7
2016-12-22tdf#104818 Show the right label when a11y enabledMaxim Monastirsky1-5/+5
Change-Id: If4da5b9435e96e3830bac3d01e06f7ddc87754eb
2016-12-21convert EnumContext::Application to scoped enumNoel Grandin2-14/+14
Change-Id: Ia289a7b63bf8797085315218785e2a2a4c45d232 Reviewed-on: https://gerrit.libreoffice.org/32230 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-15tdf#104621 framework: Redo commit 84f2ff67a7e404febf710b1dc7f66d06745c503fMichael Stahl1-1/+10
The fix was silly and wrong, need to check m_xUIElement, not m_aName, which may be set independently, see the confusing code in ToolbarLayoutManager::requestToolbar(). Change-Id: I279088cb2516b0a19619b5647f15f738a2624edf
2016-12-15teach sallogareas plugin to catch inconsistenciesNoel Grandin5-38/+38
Change-Id: I8bcea5ffc74d48148bea78da8c17744e288c069a Reviewed-on: https://gerrit.libreoffice.org/32004 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-13Revert "verify SolarMutex when ref-counting VclPtr" seriesNoel Grandin5-9/+0
This reverts the following commits: commit 722f4e1d86710f2facd37d7e040df9e1fd585e26 tdf#104573 - Assertion failed: SolarMutex not locked commit f04ec99f5e6a543b8191ced61db4710c3c0de356 tdf#104573 - Assertion failed: SolarMutex not locked commit 71b1e3ff6374c23e65200d3bcafca387d29af04f tdf#104573 - Assertion failed: SolarMutex not locked when trying commit e794ce1eef6730e5a46d5fb0aa6db2895ede85e7 verify that we hold the SolarMutex when ref-counting VclPtr IRC discussion: <noelgrandin> sberg, maybe I should revert this whole "VclPtr assert" series, I don't have mental bandwidth to sort this out properly now <sberg> noelgrandin, what I fear is that you'll end up adding lots of SolarMutex locks to small places, where the proper fix would be to add it further out; and once such a dreaded recursive SolarMutex lock is in place (but needlessly so, once the proper fix is done), it's hard to clean that up again <noelgrandin> sberg, yeah, in that case I'll just remove all of this, leave it for another day Change-Id: Ie4f84b72b79a1b7e80164b5c7693af398c2c569a Reviewed-on: https://gerrit.libreoffice.org/31946 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-13OSL_TRACE->SAL in framework..salNoel Grandin3-6/+0
Change-Id: I9a897af88aa9f6f7ca98ce521c69b5a4ee8462e9 Reviewed-on: https://gerrit.libreoffice.org/31903 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-10framework: fix race in ToolBarManager creationMichael Stahl2-7/+9
ToolbarLayoutManager::createToolbar() may be called concurrently on different threads, and then it can happen that both threads want to create the same toolbar URL, see that it does not exist in line 457, then both release the SolarMutex and create a new ToolBarManager and the first inserts it and then the second overwrites it on line 514 without disposing the first one. The non-disposed extra ToolBarManager is kept alive because it is registered as a listener on the Frame. When the Frame::close() is called, the ToolbarLayoutManager is disposed, and that disposes all the ToolBarManagers it knows about, but not the extra one, which is then un-ref'd and then has a live VclPtr m_pToolBar, which asserts because the SolarMutex is not locked since commit e794ce1eef6730e5a46d5fb0aa6db2895ede85e7. (This commit is thanks to rr, which recorded the JunitTest_framework_complex execution and allowed debugging this.) Change-Id: I8f5333e8e36ac8ea347ef545e014ffc10501aebb
2016-12-09vcl: set toolbox size correctly when using 32px iconsTomaž Vajngerl1-1/+1
Change-Id: Ifacff75f80bc8401ccff2a4d4dc90e56e3b4aa84 Reviewed-on: https://gerrit.libreoffice.org/31801 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2016-12-08verify that we hold the SolarMutex when ref-counting VclPtrNoel Grandin5-0/+9
Change-Id: If0c5a8c99f0f853c9ecad0f1a4a7299d69805b34 Reviewed-on: https://gerrit.libreoffice.org/31755 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-07Monkey business: Fix typo in comments: et -> ed :)Mike Kaganski1-1/+1
Change-Id: I91440e8582108b9121ac6525c8ac88ad6f218a60 Reviewed-on: https://gerrit.libreoffice.org/31721 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2016-12-07convert VCLEVENT constants to scoped enumNoel Grandin2-4/+4
Change-Id: Ic8ccb0a9715ec05182dacddab2c015b0de6a0fba Reviewed-on: https://gerrit.libreoffice.org/31675 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-05convert FSysStyle to o3tl::typed_flagsNoel Grandin2-2/+2
Change-Id: I58a63a0e6f619442f21827064644ecd8ca57b8ff
2016-12-05convert DecodeMechanism to scoped enumNoel Grandin6-22/+22
Change-Id: I5c56634b1bca8e37fa73d02d2428645301b6c547
2016-12-05convert INetURLObject::EncodeMechanism to scoped enumNoel Grandin2-2/+2
Change-Id: I50ea17c7779c7b5cacddf548f1773fd7d6c8bade
2016-12-05loplugin:unnecessaryoverride (dtors) in frameworkStephan Bergmann19-90/+0
Change-Id: I52b12e390b97f15f9af07edd511fa36288f31fbd
2016-11-29loplugin:vclwidgets check for assigning from VclPt<T> to T*Noel Grandin4-12/+12
Inspired by a recent bug report where we were assigning the result of VclPtr<T>::Create to a raw pointer. As a consequence, we also need to change various methods that were returning newly created Window subclasses via raw pointer, to instead return those via VclPtr Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b Reviewed-on: https://gerrit.libreoffice.org/31318 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-28orcus is mandatory nowMarkus Mohrhard1-13/+0
We use it as a json parser, for calc cell styles and tests. Making it optional is just making the code more complex and introduces more sources for errors. Change-Id: I8769628a4ab9519cafc3d43db7c0007e0aa265dc Reviewed-on: https://gerrit.libreoffice.org/31307 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-11-22Revert "Timer::Start must be called with SolarMutex locked"Stephan Bergmann1-5/+4
This reverts commit 1c3e88a4ffd927d4dda8bb9e0d05cddc6cd685c0; the static AutoRecovery instance is only destroyed during exit, but wants to use SolarMutex; that causes crashes at least in CppunitTest_services. Apparently needs more thought.
2016-11-22Timer::Start must be called with SolarMutex lockedStephan Bergmann1-4/+5
cf. DBG_TESTSOLARMUTEX added to Scheduler::Start in c00d8271ba443c4f0acf657c226eea4824597f95 "vcl: assert solar mutex is held for various timer / scheduler ops." So cover operations on AutoRecovery::m_aTimer with SolarMutexGuard instead of AutoRecovery's own mutex. Is it safe to split guarding like that here? Hopefully. Would it be better to exclusively use SolarMutexGuard? Maybe. The DBG_TESTSOLARMUTEX assert fired at least on macOS when opening some .odb file: > frame #19: 0x00007fffc80e5893 libsystem_c.dylib`__assert_rtn + 320 > frame #20: 0x000000010f5e4dae libvcllo.dylib`ImplDbgTestSolarMutex() + 110 at vcl/source/app/dbggui.cxx:47 > frame #21: 0x000000010e6a5d62 libtllo.dylib`DbgTestSolarMutex() + 130 at tools/source/debug/debug.cxx:74 > frame #22: 0x000000010f5eeb3a libvcllo.dylib`Scheduler::Start(this=0x00000001489233a8) + 58 at vcl/source/app/scheduler.cxx:287 > frame #23: 0x000000010f62f03f libvcllo.dylib`Timer::Start(this=0x00000001489233a8) + 31 at vcl/source/app/timer.cxx:93 > frame #24: 0x00000001481b7483 libfwklo.dylib`(anonymous namespace)::AutoRecovery::implts_updateTimer(this=0x00000001489232a0) + 259 at framework/source/services/autorecovery.cxx:2274 > frame #25: 0x00000001481b3009 libfwklo.dylib`(anonymous namespace)::AutoRecovery::changesOccurred(this=0x00000001489232a0, aEvent=0x00007f92d87d0ec8) + 649 at framework/source/services/autorecovery.cxx:1678 > frame #26: 0x000000014807e04b libfwklo.dylib`framework::WeakChangesListener::changesOccurred(this=0x0000000148c42488, rEvent=0x00007f92d87d0ec8) + 155 at framework/inc/helper/mischelper.hxx:222 > frame #27: 0x000000011c13f29e libconfigmgrlo.dylib`configmgr::Broadcaster::send(this=0x00007000082f9e70) + 5694 at configmgr/source/broadcaster.cxx:187 > frame #28: 0x000000011c0fd9bc libconfigmgrlo.dylib`configmgr::Access::insertByName(this=0x0000000148c118e0, aName=0x00007000082fa258, aElement=0x00007000082fa118) + 3196 at configmgr/source/access.cxx:1232 > frame #29: 0x00000001481bdd23 libfwklo.dylib`(anonymous namespace)::AutoRecovery::implts_flushConfigItem(this=0x00000001489232a0, rInfo=0x00007000082fa600, bRemoveIt=false)::AutoRecovery::TDocumentInfo const&, bool) + 2483 at framework/source/services/autorecovery.cxx:2092 > frame #30: 0x00000001481bb09d libfwklo.dylib`(anonymous namespace)::AutoRecovery::implts_registerDocument(this=0x00000001489232a0, xDocument=0x00007000082fa790) + 3597 at framework/source/services/autorecovery.cxx:2519 > frame #31: 0x00000001481b2a35 libfwklo.dylib`(anonymous namespace)::AutoRecovery::documentEventOccured(this=0x00000001489232a0, aEvent=0x00007f92db3d8620) + 165 at framework/source/services/autorecovery.cxx:1571 > frame #32: 0x00000001481d025b libfwklo.dylib`framework::WeakDocumentEventListener::documentEventOccured(this=0x0000000148c42548, rEvent=0x00007f92db3d8620) + 155 at framework/inc/helper/mischelper.hxx:258 > frame #33: 0x0000000109fca69e libsfxlo.dylib`comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>::operator(this=0x00007000082fa910, listener=0x00007000082fa880)(com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener> const&) const + 126 at include/comphelper/interfacecontainer2.hxx:272 > frame #34: 0x0000000109fca4a3 libsfxlo.dylib`void comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::document::XDocumentEventListener, comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent> >(this=0x00000001489186b8, func=0x00007000082fa910) + 163 at include/comphelper/interfacecontainer2.hxx:285 > frame #35: 0x0000000109fca0de libsfxlo.dylib`void comphelper::OInterfaceContainerHelper2::notifyEach<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>(this=0x00000001489186b8, NotificationMethod=21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00, Event=0x00007f92db3d8620)(com::sun::star::document::DocumentEvent const&), com::sun::star::document::DocumentEvent const&) + 126 at include/comphelper/interfacecontainer2.hxx:298 > frame #36: 0x0000000109fc9f08 libsfxlo.dylib`(anonymous namespace)::SfxGlobalEvents_Impl::implts_notifyListener(this=0x0000000148918628, aEvent=0x00007f92db3d8620) + 168 at sfx2/source/notify/globalevents.cxx:438 > frame #37: 0x0000000109fc6874 libsfxlo.dylib`(anonymous namespace)::SfxGlobalEvents_Impl::documentEventOccured(this=0x0000000148918628, Event=0x00007f92db3d8620) + 132 at sfx2/source/notify/globalevents.cxx:243 > frame #38: 0x000000014957597e libdbalo.dylib`comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>::operator(this=0x00007000082fab30, listener=0x00007000082faaa0)(com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener> const&) const + 126 at include/comphelper/interfacecontainer2.hxx:272 > frame #39: 0x0000000149575753 libdbalo.dylib`void comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::document::XDocumentEventListener, comphelper::OInterfaceContainerHelper2::NotifySingleListener<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent> >(this=0x00007f92db0965f0, func=0x00007000082fab30) + 163 at include/comphelper/interfacecontainer2.hxx:285 > frame #40: 0x000000014957407e libdbalo.dylib`void comphelper::OInterfaceContainerHelper2::notifyEach<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>(this=0x00007f92db0965f0, NotificationMethod=21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00, Event=0x00007f92db3d8620)(com::sun::star::document::DocumentEvent const&), com::sun::star::document::DocumentEvent const&) + 126 at include/comphelper/interfacecontainer2.hxx:298 > frame #41: 0x0000000149573dfb libdbalo.dylib`dbaccess::DocumentEventNotifier_Impl::impl_notifyEvent_nothrow(this=0x00007f92db0965a0, _rEvent=0x00007f92db3d8620) + 379 at dbaccess/source/core/dataaccess/documenteventnotifier.cxx:196 > frame #42: 0x0000000149574580 libdbalo.dylib`dbaccess::DocumentEventNotifier_Impl::processEvent(this=0x00007f92db0965a0, _rEvent=0x00007f92db3d8610) + 224 at dbaccess/source/core/dataaccess/documenteventnotifier.cxx:229 > frame #43: 0x000000010832ba30 libcomphelper.dylib`comphelper::AsyncEventNotifierBase::execute(this=0x000000014df32dd0) + 1184 at comphelper/source/misc/asyncnotification.cxx:163 > frame #44: 0x000000010832e28a libcomphelper.dylib`comphelper::AsyncEventNotifierAutoJoin::run(this=0x000000014df32dd0) + 90 at comphelper/source/misc/asyncnotification.cxx:263 > frame #45: 0x000000010832f23e libcomphelper.dylib`::threadFunc(param=0x000000014df32dd0) + 30 at include/osl/thread.hxx:185 > frame #46: 0x0000000107e9bc27 libuno_sal.dylib.3`osl_thread_start_Impl(pData=0x00007f92db351d30) + 295 at sal/osl/unx/thread.cxx:240 > frame #47: 0x00007fffc82a1aab libsystem_pthread.dylib`_pthread_body + 180 > frame #48: 0x00007fffc82a19f7 libsystem_pthread.dylib`_pthread_start + 286 > frame #49: 0x00007fffc82a1221 libsystem_pthread.dylib`thread_start + 13 Change-Id: I58fe8d61bfc491fa635b75d471a221bbb55c0f6e
2016-11-22Resolves: rhbz#1397181 toolbar layout manager not respecting drag cancelCaolán McNamara1-0/+3
plus restore original mbDockCanceled state after wayland-enforced cancel otherwise next drag won't work Change-Id: Idefed25b925b36d0bf72b77609c4fc2eb47f71b9
2016-11-18includes should be at the top of the fileNoel Grandin1-1/+1
not randomly scattered through the code found with something like: git ls-files *.cpp | xargs grep -Pzl "(?s){.*#include" Change-Id: I9c242fa4ef99e8677f2800d7ec9f16d16e488351 Reviewed-on: https://gerrit.libreoffice.org/30952 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-16new loplugin finalprotectedNoel Grandin4-4/+4
look for final classes, and make sure they don't have protected members Change-Id: I1fa810659bba02b61a5160dbfd8e24185ec9abf4 Reviewed-on: https://gerrit.libreoffice.org/30895 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-11Type detection can handle empty doc service just fineMaxim Monastirsky1-9/+4
But actually I can't imagine why the doc service could be empty here, esp. since 8655fa318c1924994eb659b4bb60074c86ad70c1 ("Fix property name: ModuleName -> ModuleIdentifier"). Change-Id: I9a39cf0840910069769b4bedd61930aab2155e1b
2016-11-11RecentFile::aTitle is never readMaxim Monastirsky1-18/+9
Change-Id: Ic9f613f10914113af62fe6876e1a837a610a5782
2016-11-11RecentFilesMenuController: Remove duplicate dispatch handlingMaxim Monastirsky1-53/+2
Change-Id: I3f2729bfe82c059bbf934510cb4066a77867f3c8
2016-11-11Resolves: rhbz#1391418 wayland toolbars can't be docked after undockingCaolán McNamara1-0/+4
see gnome#768128 for extra details under wayland, given the misery here I'm going to just disable toggling between docked and undocked under wayland, and throw away user config on toggling docked/undocked away from the defaults. You can still drag docked things around to new docking position, but you can't pull them out of the dock to float. non-wayland is unaffected Change-Id: Iaa859f3420e6d1b103a8b93d1ad8f82dbffe75d4 Reviewed-on: https://gerrit.libreoffice.org/30752 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-11-11update vclwidget loplugin to find ref-dropping assigmentNoel Grandin24-117/+117
Look for places where we are accidentally assigning a returned-by-value VclPtr<T> to a T*, which generally ends up in a use-after-free. Change-Id: I4f361eaca88820cdb7aa3b8340212db61580fdd9 Reviewed-on: https://gerrit.libreoffice.org/30749 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-09Avoid starting m_aAsyncUpdateControllersTimer of disposed ToolBarManagerStephan Bergmann1-1/+1
Seen a Jenkins build fail in JunitTest_framework_complex as below, and the only remotely plausible scenario I can think of is that a call from Frame::contextChanged -> ToolBarManager::frameAction started the timer after Frame::close -> dispose -> ... -> ToolBarManager::dispose had been called but before Frame::close -> dispose -> ... -> ~ToolBarManager had been called. (And tracing the calls to Frame member functions, there indeed appear to be call patterns during JunitTest_framework_complex where Frame::contextChanged is called from within Frame::close -> dispose -> ...) Any other calls to m_aAsyncUpdateControllersTimer.Start() in ToolBarManager appear to already check for !m_bDisposed. <http://ci.libreoffice.org/job/lo_tb_master_linux_dbg/9049/console>: > #7 0x00002b2653546566 in __assert_fail_base () at /lib64/libc.so.6 > #8 0x00002b2653546612 in () at /lib64/libc.so.6 > #9 0x00002b2676f23777 in framework::ToolBarManager::~ToolBarManager() (this=0x3a48710, __in_chrg=<optimized out>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/framework/source/uielement/toolbarmanager.cxx:198 > #10 0x00002b2676f23978 in framework::ToolBarManager::~ToolBarManager() (this=0x3a48710, __in_chrg=<optimized out>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/framework/source/uielement/toolbarmanager.cxx:201 > #11 0x00002b2655fd5328 in cppu::OWeakObject::release() (this=0x3a48710) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/weak.cxx:233 > #12 0x00002b2676ec7138 in cppu::WeakImplHelper<com::sun::star::frame::XFrameActionListener, com::sun::star::lang::XComponent, com::sun::star::ui::XUIConfigurationListener>::release() (this=0x3a48710) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/cppuhelper/implbase.hxx:113 > #13 0x00002b2655ef353a in com::sun::star::uno::cpp_release(void*) (pCppI=0x3a48738) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/com/sun/star/uno/genfunc.hxx:48 > #14 0x00002b2655c5d4ab in cppu::idestructElements(void*, _typelib_TypeDescriptionReference*, int, int, void (*)(void*)) (pElements=0x32c5a28, pElementType=0x1670d90, nStartIndex=0, nStopIndex=5, release=0x2b2655ef3517 <com::sun::star::uno::cpp_release(void*)>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/uno/destr.hxx:238 > p = 0x3a48738 > nPos = 4 > #15 0x00002b2655c5d64f in cppu::idestroySequence(_sal_Sequence*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*)) (pSeq=0x32c5a20, pType=0x24a6cf0, pTypeDescr=0x24a6cf0, release=0x2b2655ef3517 <com::sun::star::uno::cpp_release(void*)>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/uno/destr.hxx:284 > __PRETTY_FUNCTION__ = "void cppu::idestroySequence(uno_Sequence*, typelib_TypeDescriptionReference*, typelib_TypeDescription*, uno_ReleaseFunc)" > #16 0x00002b2655c8952f in uno_type_sequence_destroy(uno_Sequence*, typelib_TypeDescriptionReference*, uno_ReleaseFunc) (sequence=0x32c5a20, type=0x24a6cf0, release=0x2b2655ef3517 <com::sun::star::uno::cpp_release(void*)>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/uno/sequence.cxx:916 > #17 0x00002b2655f31ba6 in com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::uno::XInterface> >::~Sequence() (this=0x2679070, __in_chrg=<optimized out>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/com/sun/star/uno/Sequence.hxx:113 > rType = invalid uno::Type > #18 0x00002b2655f2ef92 in cppu::OInterfaceIteratorHelper::~OInterfaceIteratorHelper() (this=0x2b26785beaf0, __in_chrg=<optimized out>) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/interfacecontainer.cxx:103 > bShared = false > #19 0x00002b2655f2fb98 in cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const&) (this=0x32bd280, rEvt=...) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/interfacecontainer.cxx:288 > aGuard = {pT = 0x0} > aIt = {rCont = @0x32bd280, bIsList = 1 '\001', aData = {pAsSequence = 0x2679070, pAsInterface = 0x2679070}, nRemain = 0} > #20 0x00002b2655f308d7 in cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const&) (this=0x38bc030, rEvt=...) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/interfacecontainer.cxx:477 > i = 0 > nSize = 3 > ppListenerContainers = std::unique_ptr<cppu::OInterfaceContainerHelper *> containing 0x2f7c650 > #21 0x00002b2676e37180 in (anonymous namespace)::Frame::disposing() (this=0x38bbf30) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/framework/source/services/frame.cxx:2242 > parent = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b26785beca0 > xThis = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbfa0 > layoutMgr = uno::Reference to (framework::LayoutManager *) 0x2fa5190 > aEvent = {Source = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbfa0} > xDisposableCtrl = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b26785beca0 > xDisposableComp = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b2676e34200 <(anonymous namespace)::Frame::isActive()+160> > disp = 0x2f7c650 > xDispatchHelper = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b26785bec80 > old = Application::Off > contWin = uno::Reference to (com::sun::star::uno::XInterface *) 0x2b26785bf050 > #22 0x00002b2655f2b262 in cppu::WeakComponentImplHelperBase::dispose() (this=0x38bbf30) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppuhelper/source/implbase.cxx:107 > aEvt = {Source = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbf30} > aGuard2 = {pT = 0x39553a0} > aGuard = {pT = 0x0} > #23 0x00002b2676e3f0a6 in cppu::PartialWeakComponentImplHelper<com::sun::star::lang::XServiceInfo, com::sun::star::frame::XFrame2, com::sun::star::awt::XWindowListener, com::sun::star::awt::XTopWindowListener, com::sun::star::awt::XFocusListener, com::sun::star::document::XActionLockable, com::sun::star::util::XCloseable, com::sun::star::frame::XComponentLoader, com::sun::star::frame::XTitle, com::sun::star::frame::XTitleChangeBroadcaster, com::sun::star::beans::XPropertySet, com::sun::star::beans::XPropertySetInfo>::dispose() (this=0x38bbf30) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/cppuhelper/compbase.hxx:94 > #24 0x00002b2676e34edb in (anonymous namespace)::Frame::close(sal_Bool) (this=0x38bbf30, bDeliverOwnership=0 '\000') at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/framework/source/services/frame.cxx:1829 > xSelfHold = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbf30 > aSource = {Source = uno::Reference to ((anonymous namespace)::Frame *) 0x38bbf30} > pContainer = 0x33c4ba0 > aWriteLock = {m_bCleared = true, m_solarMutex = @0x16529c0} > #25 0x00002b26752971a1 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) (pThis=0x38bbfd0, nVtableIndex=5, pRegisterReturn=0x0, pReturnTypeRef=0x165a1b0, bSimpleReturn=true, pStack=0x2b26785bf1a0, nStack=0, pGPR=0x2b26785bf2c0, pFPR=0x2b26785bf2f0) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:133 > data = {pMethod = 47444203360446, pStack = 0x2b26785bf1a0, nStack = 0, pGPR = 0x2b26785bf2c0, pFPR = 0x2b26785bf2f0, rax = 47444228043088, rdx = 47444228043040, xmm0 = 4.9549649932863477e-314, xmm1 = 2.3440563169523938e-310} > pMethod = 47444209328504 > #26 0x00002b26752960bc in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**) (pThis=0x2f330e0, aVtableSlot=..., pReturnTypeRef=0x165a1b0, nParams=1, pParams=0x3200050, pUnoReturn=0x0, pUnoArgs=0x3a70260, ppUnoExc=0x2b26785bf478) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:245 > pStack = 0x2b26785bf1a0 > pFPR = {2.34405631697769e-310, 2.3440546323697648e-310, 1.0609978954826362e-313, 2.3440563169796168e-310, 2.5903774855902888e-316, -9.6283901862001054e-07, 2.3440563169800615e-310, 0} > __PRETTY_FUNCTION__ = "void cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**)" > pCppArgs = 0x2b26785bf170 > pStackStart = 0x2b26785bf1a0 > pGPR = {59490256, 0, 47444228043568, 47444174450194, 0, 52429824} > nTempIndices = 0 > nFPR = 0 > pAdjustedThisPtr = 0x38bbfd0 > ppTempParamTypeDescr = 0x2b26785bf180 > nGPR = 2 > pReturnTypeDescr = 0x165a1b0 > pCppReturn = 0x0 > bSimpleReturn = true > pTempIndices = 0x2b26785bf178 > #27 0x00002b2675296ada in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) (pUnoI=0x2f330e0, pMemberDescr=0x3200400, pReturn=0x0, pArgs=0x3a70260, ppException=0x2b26785bf478) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:436 > nMemberPos = 5 > aVtableSlot = {offset = 0, index = 5} > pThis = 0x2f330e0 > pTypeDescr = 0x2590e40 > __PRETTY_FUNCTION__ = "void bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, const typelib_TypeDescription*, void*, void**, uno_Any**)" > #28 0x00002b267653517a in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const (this=0x3aba970, returnValue=0x2b26785bf8a0, outArguments=0x2b26785bf920) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/binaryurp/source/incomingrequest.cxx:242 > exc = <error reading variable: Cannot access memory at address 0x3aba87808> > pexc = 0x2b26785bf4a0 > retType = {_pTypeDescr = 0x165a1b0} > nSize = 0 > retBuf = std::__debug::vector of length 0, capacity 0 > outBufs = empty std::__debug::list > args = std::__debug::vector of length 1, capacity 1 = {0x3a331c0} > __PRETTY_FUNCTION__ = "bool binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny>*) const" > isExc = false > #29 0x00002b2676533f7a in binaryurp::IncomingRequest::execute() const (this=0x3aba970) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/binaryurp/source/incomingrequest.cxx:77 > resetCc = true > oldCc = {m_pUnoI = 0x0} > ret = {data_ = _uno_Any(void)} > outArgs = std::__debug::vector of length 0, capacity 0 > isExc = false > #30 0x00002b2676554a88 in binaryurp::(anonymous namespace)::request(void*) (pThreadSpecificData=0x3aba970) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/binaryurp/source/reader.cxx:85 > __PRETTY_FUNCTION__ = "void binaryurp::{anonymous}::request(void*)" > #31 0x00002b2655c27f0b in cppu_threadpool::JobQueue::enter(long, bool) (this=0x398ea80, nDisposeId=39254816, bReturnWhenNoJob=true) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/threadpool/jobqueue.cxx:107 > guard = {pT = 0x398ea80} > job = {pThreadSpecificData = 0x3aba970, doRequest = 0x2b2676554a1f <binaryurp::(anonymous namespace)::request(void*)>} > pReturn = 0x0 > #32 0x00002b2655c2cb57 in cppu_threadpool::ORequestThread::run() (this=0x256fb20) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/threadpool/thread.cxx:168 > #33 0x00002b2655c2d04d in osl::threadFunc(void*) (param=0x256fb30) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/osl/thread.hxx:185 > pObj = 0x256fb30 > #34 0x00002b2652f08340 in osl_thread_start_Impl(void*) (pData=0x2570ac0) at /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/sal/osl/unx/thread.cxx:240 > terminate = false > pImpl = 0x2570ac0 > __PRETTY_FUNCTION__ = "void* osl_thread_start_Impl(void*)" > #35 0x00002b26538e1dc5 in start_thread () at /lib64/libpthread.so.0 > #36 0x00002b265360eced in clone () at /lib64/libc.so.6 Change-Id: I27e15a72f6b96484cb45928eaabae589cf9d7ed7
2016-11-08Return early from double ToolBarManager::disposeStephan Bergmann1-3/+10
...if that should ever happen. Also means that ToolBarManager::RemoveControllers will now only be called with m_bDispose being false. Change-Id: If17d60f291cc8dad19d6f6e33d39e08c7f8ad7aa
2016-11-08Clean up (calls to) ToolBarManager::RemoveControllersStephan Bergmann1-33/+29
...which turns out to be only called with SolarMutex locked Change-Id: I3264b0a043da7111b8ca12c59ee7a590f1a43b8e
2016-11-08Clean up (calls to) StatusBarManger::RemoveControllersStephan Bergmann1-15/+10
...which turns out to be only called with SolarMutex locked and m_bDisposed being false Change-Id: I454e7951ea579fb6d9dc71d0aabebd373380b3e4
2016-11-08There's no derivations from StatusBarManagerStephan Bergmann1-3/+2
Change-Id: Ifa2970cf838209b72e286109f14b98e77f389c0b
2016-11-08loplugin:expandablemethods in frameworkNoel Grandin12-111/+26
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>
2016-11-08loplugin:unnecessaryvirtual in frameworkNoel Grandin16-39/+34
Change-Id: I893bf955e45e661e3ec440dbd530fca22931c23b Reviewed-on: https://gerrit.libreoffice.org/30666 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-07officecfg: add .uno:SignPDF labelMiklos Vajna1-0/+2
And replace the existing .uno:Signature in the File menus with a submenu that contains .uno:Signature and the new .uno:SignPDF. Change-Id: I801b9332c697985446c64dd208c25dea2494350e
2016-11-07loplugin:oncevar in frameworkNoel Grandin19-200/+85
Change-Id: I7528a4afd59a19b069bcad2106ca80f429ef12e0 Reviewed-on: https://gerrit.libreoffice.org/30525 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-11-06NewDocument is now unusedMaxim Monastirsky1-7/+0
Change-Id: Ifce80cec8935b960b14716d09080f76351633c0b
2016-11-06NewMenuController: Fix template manager iconMaxim Monastirsky1-25/+8
The current logic is swapped. MenuAttributes::aImageId can be only handled by SvFileInformationManager, while the menu item command is what might be (in case of .uno command) handled by CommandInfoProvider. This gone wrong in tdf#96059 which wrongly assumed that GetImageFromURL is equivalent to what's provided by CommandInfoProvider (so other places should be checked too). Change-Id: Ia487c602753dde3fb0d0462ef4b3d63209398b36
2016-11-06NewMenuController: Remove duplicate async dispatch handlingMaxim Monastirsky2-44/+7
Change-Id: I881e6781c5ba82b0b998891532f8b7c281567b73
2016-11-03SafeMode: Add indicator to window title when in Safe ModeSamuel Mehrbrodt3-0/+14
Change-Id: I1d8350315768093b4c4af1cd8b732602c5217edb Reviewed-on: https://gerrit.libreoffice.org/30518 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2016-10-30tdf#95014 initial support for 32 px icons in toolbarTomaž Vajngerl9-62/+119
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>
2016-10-30Let Menu dispose submenusMaxim Monastirsky7-59/+24
(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
2016-10-30BmkMenu is dead nowMaxim Monastirsky1-1/+0
Change-Id: I9b6e762fd4c231a5bd54eb546026499da2efa0e6
2016-10-27coverity#1374317 Uncaught exceptionCaolán McNamara2-2/+2
Change-Id: I37a7b2f12cec522e116ccf4b1aa550ad2cba14ea
2016-10-27GenericPopupToolbarController: deal with main command being disabledMaxim Monastirsky1-0/+46
Try to set another command from the dropdown, if there is any enabled. Otherwise give up and disable the button altogether. Change-Id: I7fa46a946826056d04851faee9c7ad85f00c3678
2016-10-27GenericPopupToolbarController: Support replacing the main commandMaxim Monastirsky1-5/+35
If a second arg is passed in the "Value" property, it will be treated as boolean. If true - the button will be ToolBoxItemBits::DROPDOWN, and will keep replacing the main command with the last selected one from the dropdown. It will also respond to status updates of that command, currently for enabled/disabled and boolean (true treated as pressed) states. Change-Id: I09a5c20e6d2a010867037754f036096246749ec4
2016-10-27MenuBarManager should pass the menubar flag downMaxim Monastirsky1-9/+5
... to popup menu controllers it creates, similar to what is does for child MenuBarManager instances. That way a child ResourceMenuController placed inside a popup menu won't mistakenly think it's inside the main menu. Change-Id: I75eea28eeb38f16bfaaa5526752a957859ef0d32
2016-10-26coverity#1374282 Uncaught exceptionCaolán McNamara2-2/+4
Change-Id: I1b31825ec27d2395ca030ca79b6c932b7814d901
2016-10-20Open menu: Simplify inserting menu entriesSamuel Mehrbrodt3-23/+5
Change-Id: Ia75f2fe349580003b16735fccf429392d0cf8363 Reviewed-on: https://gerrit.libreoffice.org/30082 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-06 12:28:43 +0000