Download it now!
Bug 104332 - Thesaurus in the Tools menu causes it to open slowly the first time
Summary: Thesaurus in the Tools menu causes it to open slowly the first time
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: low trivial
Assignee: Not Assigned
Whiteboard: target:6.2.0 target:
Keywords: haveBacktrace, perf
: 105439 108698 (view as bug list)
Depends on:
Blocks: Writer-Menus Thesaurus Too-Much-File-Access
  Show dependency treegraph
Reported: 2016-12-01 21:54 UTC by Aron Budea
Modified: 2018-07-23 13:47 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:

Process Monitor Output LO5400 (213.61 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-02-03 08:58 UTC, Telesto
Xcode Time Profile (56.42 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-02-21 20:45 UTC, Telesto
LLDB backtrace (2.30 MB, text/plain)
2017-02-21 20:47 UTC, Telesto
Xcode instruments allocations and BT (4.82 MB, application/x-zip-compressed)
2017-09-14 13:52 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2016-12-01 21:54:47 UTC
This is a new bug in that only affects Writer. Only tested in Windows 7, (un)confirmation in Linux needed.

Start Writer, open Tools menu. It takes a few seconds to open for the first time.
Other menus come up instantly. Occurs both with default and OpenGL rendering.
Comment 1 Aron Budea 2016-12-02 10:15:35 UTC Comment hidden (obsolete)
Comment 2 Aron Budea 2016-12-06 00:14:26 UTC Comment hidden (bibisection)
Comment 3 Aron Budea 2016-12-06 00:17:42 UTC
As it turns out, this isn't a new issue at all, but only occurs if a lot of dictionary extensions are installed. The reason why I could reproduce in some versions and not others is that the SI-GUI installed pre-release/release versions had all dictionaries, while master builds and normally installed versions didn't (like 5.3beta1 was in my case).

Still a regression, but from 5.1, and from the commit below. Adding Cc: to Yousuf Philips.
Not sure which part of the commit causes the performance issue.
"tdf#91781 Reorganize writer's menu bar"
Comment 4 Yousuf Philips (jay) (retired) 2016-12-08 18:22:29 UTC
No clue Aron what could be the cause, but with my patch i moved a few entries from submenus into the main Tools menu, so try testing deleting those entries below.

Comment 5 Xisco Faulí 2016-12-11 17:25:32 UTC
Moving it to NEW as the problematic commit has been identified
Comment 6 Yousuf Philips (jay) (retired) 2016-12-11 20:18:23 UTC
(In reply to Aron Budea from comment #1)
> Does not occur with 5.4 daily build (2016-12-02_00:57:58), 5.3beta1, 5.3
> daily build (2016-11-17_00:29:08), but occurs with 5.3alpha1 in Windows 7.
> Couldn't reproduce it with 5.3alpha1 / Ubuntu 16.04.

As it doesnt happen in master and 5.3 (fresh), is there something that needs to be fixed?
Comment 7 Aron Budea 2016-12-11 20:54:38 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> As it doesnt happen in master and 5.3 (fresh), is there something that needs
> to be fixed?

It still happens, see the first paragraph in comment 3 for details.
I checked a bit, and it seems Thesaurus is causing the stall (thanks for the hint), but I didn't have the time to further experiment with it. What I did, I tried earlier versions, and the stall happened when I entered that particular submenu.
Comment 8 Telesto 2017-01-21 19:45:40 UTC
*** Bug 105439 has been marked as a duplicate of this bug. ***
Comment 9 Telesto 2017-01-22 08:23:35 UTC
Setting to all. Same issue on MacOS
Build ID: ae0a317c20110ade8b9eaef3ecbd2c5781303649
CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-01-21_01:02:06
Locale: nl-NL (nl_NL.UTF-8); Calc: group

Also the right-click menu is affected (bug 105439)
Comment 10 Telesto 2017-02-03 08:58:28 UTC
Created attachment 130873 [details]
Process Monitor Output LO5400

It's seems to be caused by cycling through lots of directory's (over and over again). I have added a process monitor output when clicking on Menu Tools in Writer immediately after launch.

It's nearly the same as bug 104637 (it actually still exists) and has similarity's with bug 104582

Build ID: 2670ca3fc597decae78499d1397539668eb84e5e
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-31_05:32:46
Locale: nl-NL (nl_NL); Calc: CL
Comment 11 Yousuf Philips (jay) (retired) 2017-02-04 11:21:13 UTC
@Aron: As the thesaurus is available in a submenu prior to 5.1, i would check earlier versions to see if the same problem happens when opening the Tools > Language submenu, as this problem is likely inherited from OOo.

@Maxim, @Michael: Any thoughts?
Comment 12 Telesto 2017-02-21 20:45:45 UTC
Created attachment 131399 [details]
Xcode Time Profile
Comment 13 Telesto 2017-02-21 20:47:28 UTC
Created attachment 131400 [details]
LLDB backtrace

Build ID: 273823de644f2086377795d3afb51a39d30bfeaa
CPU Threads: 4; OS Version: Mac OS X 10.12.4; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 14 Aron Budea 2017-06-22 22:14:56 UTC
*** Bug 108698 has been marked as a duplicate of this bug. ***
Comment 15 Aron Budea 2017-06-22 22:17:53 UTC Comment hidden (obsolete)
Comment 16 Telesto 2017-06-23 07:39:11 UTC
1. Comment 15 is obsolete: A full process Monitor output is already attached
2. There seem to be two issues combined here: 
2.a disk queries related to python (bug 108698 (added as duplicate to this one)
2.b disk queries related to louno.ini (bug 108645) -> probably the main cause of the lag
Comment 17 Aron Budea 2017-09-11 02:52:24 UTC
This seems to be related to bug 108468, as both deal with some kind of language component initialization, though not entirely the same:
- if first the user types, and then opens Tools menu, LO only stalls once,
- if first the user opens Tools menu, and then types, LO stalls both times.

I'd assume preloading the language components would solve this issue as well.
Comment 18 Telesto 2017-09-14 13:52:25 UTC Comment hidden (obsolete)
Comment 19 Michael Meeks 2017-09-14 13:57:42 UTC
Eike is the liblangtag man - and of course, we do read this large file =) I wonder - if we could do that in a thread after startup or something (?)
Comment 20 Telesto 2017-09-16 07:21:00 UTC Comment hidden (obsolete)
Comment 21 Telesto 2018-06-20 12:07:16 UTC

Quote from Tor Lillqvist; Patch Set 6:
The Right Way to fix the problem would of course be to re-work the code path that is taking so long; why does the code insist on initialising (in some sense) stuff for languages not even used at the moment? Adding debugging printout in various places one sees that LngSvcMgr::getAvailableServices() is called for all potential language/locale combinations. Why?  And org.libreoffice.comp.pyuno.Lightproof.pt_BR, org.libreoffice.comp.pyuno.Lightproof.ru_RU, etc even if no document with text in Brazi.ian Portuguese or Rssian os nowhere open. Etc. My God, it's full of crap.
Comment 22 Tor Lillqvist 2018-06-20 15:38:34 UTC
I have been looking at the delay after typing the first character in Writer in a LO session. Seeing this requires having a LO built with --with-myspell-dicts (for typical developers, no idea what it requires for people using end-user packages).

It is the LightProof Python code that causes most of the slowness.

Here is the "Heaviest Stack Trace" from the TimeProfiler tool in Intruments on macOS, slightly edited. The number after the dylib name is in milliseconds. One can see that the first call to pyuno::Adapter::invoke() takes about 300 ms. (And some temporary SAL_DEBUG output confirms.)

> libdyld.dylib 803.0  start
> soffice 803.0  main /Users/tml/lo/xxx/desktop/source/app/main.c:47
> libsofficeapp.dylib 803.0  soffice_main /Users/tml/lo/xxx/desktop/source/app/sofficemain.cxx:167
> libvcllo.dylib 803.0  SVMain() /Users/tml/lo/xxx/vcl/source/app/svmain.cxx:233
> libvcllo.dylib 803.0  ImplSVMainHook(int*) /Users/tml/lo/xxx/vcl/osx/salinst.cxx:225
> AppKit 803.0  NSApplicationMain
> AppKit 803.0  -[NSApplication run]
> libvcllo.dylib 803.0  -[VCL_NSApplication sendEvent:] /Users/tml/lo/xxx/vcl/osx/
> libvcllo.dylib 803.0  AquaSalInstance::handleAppDefinedEvent(NSEvent*) /Users/tml/lo/xxx/vcl/osx/salinst.cxx:463
> libvcllo.dylib 803.0  ImplSVMain() /Users/tml/lo/xxx/vcl/source/app/svmain.cxx:198
> libsofficeapp.dylib 803.0  desktop::Desktop::Main() /Users/tml/lo/xxx/desktop/source/app/app.cxx:1641
> libvcllo.dylib 803.0  Application::Execute() /Users/tml/lo/xxx/vcl/source/app/svapp.cxx:449
> libvcllo.dylib 803.0  ImplYield(bool, bool) /Users/tml/lo/xxx/vcl/source/app/svapp.cxx:469
> libvcllo.dylib 803.0  AquaSalInstance::DoYield(bool, bool) /Users/tml/lo/xxx/vcl/osx/salinst.cxx:628
> libvcllo.dylib 601.0  AquaSalTimer::callTimerCallback() /Users/tml/lo/xxx/vcl/osx/saltimer.cxx:146
> libvcllo.dylib 601.0  Scheduler::ProcessTaskScheduling() /Users/tml/lo/xxx/vcl/source/app/scheduler.cxx:447
> libswlo.dylib 597.0  sw::DocumentTimerManager::DoIdleJobs(Timer*) /Users/tml/lo/xxx/sw/source/core/doc/DocumentTimerManager.cxx:146
> libswlo.dylib 597.0  SwViewShell::LayoutIdle() /Users/tml/lo/xxx/sw/source/core/view/viewsh.cxx:711
> libswlo.dylib 597.0  SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) /Users/tml/lo/xxx/sw/source/core/layout/layact.cxx:2097
> libswlo.dylib 597.0  SwLayIdle::DoIdleJob(SwLayIdle::IdleJobType, bool) /Users/tml/lo/xxx/sw/source/core/layout/layact.cxx:2009
> libswlo.dylib 597.0  SwLayIdle::DoIdleJob_(SwContentFrame const*, SwLayIdle::IdleJobType) /Users/tml/lo/xxx/sw/source/core/layout/layact.cxx:1891
> libswlo.dylib 595.0  SwTextFrame::AutoSpell_(SwContentNode const*, int) /Users/tml/lo/xxx/sw/source/core/txtnode/txtedt.cxx:1330
> libswlo.dylib 533.0  SwModule::CreateLngSvcEvtListener() /Users/tml/lo/xxx/sw/source/uibase/app/swmodule.cxx:233
> libswlo.dylib 533.0  SwLinguServiceEventListener::SwLinguServiceEventListener() /Users/tml/lo/xxx/sw/source/uibase/uno/dlelstnr.cxx:51
> libswlo.dylib 533.0  com::sun::star::linguistic2::LinguServiceManager::create(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/linguistic2/LinguServiceManager.hpp:38
> libuno_cppuhelpergcc3.dylib.3 533.0  non-virtual thunk to cppuhelper::ServiceManager::createInstanceWithContext(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:0
> libuno_cppuhelpergcc3.dylib.3 533.0  cppuhelper::ServiceManager::createInstanceWithContext(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:991
> libuno_cppuhelpergcc3.dylib.3 533.0  cppuhelper::ServiceManager::Data::Implementation::createInstance(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:667
> libuno_cppuhelpergcc3.dylib.3 533.0  non-virtual thunk to cppu::OFactoryComponentHelper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/factory.cxx:0
> libuno_cppuhelpergcc3.dylib.3 533.0  cppu::OFactoryComponentHelper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/factory.cxx:374
> libuno_cppuhelpergcc3.dylib.3 533.0  cppu::OSingleFactoryHelper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/factory.cxx:175
> libuno_cppuhelpergcc3.dylib.3 533.0  cppu::OSingleFactoryHelper::createInstanceEveryTime(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/factory.cxx:149
> liblnglo.dylib 533.0  LngSvcMgr_CreateInstance(com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const&) /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:1980
> liblnglo.dylib 533.0  LngSvcMgr::LngSvcMgr() /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:438
> liblnglo.dylib 533.0  LngSvcMgr::UpdateAll() /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:664
> liblnglo.dylib 414.0  LngSvcMgr::getAvailableServices(rtl::OUString const&, com::sun::star::lang::Locale const&) /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:1500
> liblnglo.dylib 313.0  LngSvcMgr::GetAvailableGrammarSvcs_Impl() /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:1088
> libuno_cppuhelpergcc3.dylib.3 311.0  non-virtual thunk to (anonymous namespace)::ImplementationWrapper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:0
> libuno_cppuhelpergcc3.dylib.3 311.0  (anonymous namespace)::ImplementationWrapper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:587
> libuno_cppuhelpergcc3.dylib.3 306.0  cppuhelper::ServiceManager::loadImplementation(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, std::__1::shared_ptr<cppuhelper::ServiceManager::Data::Implementation> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:815
> libgcc3_uno.dylib 306.0  privateSnippetExecutor /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/call.cxx:27
> libgcc3_uno.dylib 306.0  cpp_vtable_call /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/cpp2uno.cxx:374
> libgcc3_uno.dylib 306.0  cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/cpp2uno.cxx:187
> libinvocadaptlo.dylib 306.0  stoc_invadp::AdapterImpl::invoke(_typelib_TypeDescription const*, void*, void**, _uno_Any**) /Users/tml/lo/xxx/stoc/source/invocation_adapterfactory/iafactory.cxx:466
> libgcc3_uno.dylib 306.0  bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/uno2cpp.cxx:0
> libgcc3_uno.dylib 306.0  cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/uno2cpp.cxx:233
> libgcc3_uno.dylib 306.0  gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/callvirtualmethod.cxx:77
> libpyuno.dylib 306.0  non-virtual thunk to pyuno::Adapter::invoke(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Sequence<short>&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /Users/tml/lo/xxx/pyuno/source/module/pyuno_adapter.cxx:0
> libpyuno.dylib 306.0  pyuno::Adapter::invoke(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Sequence<short>&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /Users/tml/lo/xxx/pyuno/source/module/pyuno_adapter.cxx:250
Comment 23 Tor Lillqvist 2018-06-20 15:47:09 UTC
Corresponding SAL_DEBUG output, not from the exact same run, so the timing is a bit different, here the interesting bit takes over half a second, probably because I had a build ongoing at the same time:

> 0.000:debug:29870:36165630: >> pyuno::Adapter::invoke(activate,4)
> 0.020:debug:29870:36165630: << pyuno::Adapter::invoke()
> 0.020:debug:29870:36165630: >> pyuno::Adapter::invoke(createInstanceWithContext,1)
> 0.045:debug:29870:36165630: << pyuno::Adapter::invoke()
> 0.046:debug:29870:36165630: >> pyuno::Adapter::invoke(hasLocale,1)
> 0.046:debug:29870:36165630: << pyuno::Adapter::invoke()
> 0.046:debug:29870:36165630: >> pyuno::Adapter::invoke(doProofreading,6)
> 0.101:debug:29870:36165630: << pyuno::Adapter::invoke()
> 0.741:debug:29870:36165479: >> LngSvcMgr::UpdateAll()
> 0.742:debug:29870:36165479:    LngSvcMgr::UpdateAll() 697 '' nNodeNames=140
> 0.820:debug:29870:36165479: >> MacSpellChecker::getLocales()
> 0.840:debug:29870:36165479:    MacSpellChecker::getLocales(): count=22
> 0.840:debug:29870:36165479: << MacSpellChecker::getLocales()
> 0.889:debug:29870:36165479: >> MacSpellChecker::getLocales()
> 0.889:debug:29870:36165479: << MacSpellChecker::getLocales()
> 0.889:debug:29870:36165479:    LngSvcMgr::UpdateAll() 717 nAvailLocales=140
> 0.936:debug:29870:36165479:    LngSvcMgr::UpdateAll() 697 '' nNodeNames=19
> 0.937:debug:29870:36165479: >> LngSvcMgr::GetAvailableGrammarSvcs_Impl()
> 0.937:debug:29870:36165479: >> pyuno::Adapter::invoke(activate,4)
> 0.940:debug:29870:36165479: HEAD
> 0.940:debug:29870:36165479: = 2
> 0.940:debug:29870:36165479: = 3
> 1.598:debug:29870:36165479: = 4
> 1.598:debug:29870:36165479: = 5
> 1.599:debug:29870:36165479: = 6
> 1.599:debug:29870:36165479: = 7
> 1.601:debug:29870:36165479: = 8
> 1.602:debug:29870:36165479: << pyuno::Adapter::invoke()

The line and the following lines "== 2" etc are from instdir/, where I added some pyuno.sal_debug() calls (an upcoming enhancement, soon in gerrit):

> # Lightproof grammar checker for LibreOffice and
> # 2009-2012 (c) Laszlo Nemeth (nemeth at numbertext org), license: MPL 1.1 / GPLv3+ / LGPLv3+
> import pyuno
> pyuno.sal_debug(' HEAD')
> pyuno.sal_debug('= 2')
> import uno, unohelper, os, sys, traceback
> pyuno.sal_debug('= 3')
> from lightproof_impl_pt_BR import locales
> pyuno.sal_debug('= 4')
> from lightproof_impl_pt_BR import pkg
> pyuno.sal_debug('= 5')
> import lightproof_impl_pt_BR
> pyuno.sal_debug('= 6')
> import lightproof_handler_pt_BR
> pyuno.sal_debug('= 7')

I.e. it is clear that the thing that takes lots of time is loading the lightproof_impl_pt_BR Python module. Even if what is done at this stage is just getting a list of locales that we have proofreaders for. The lightproof_impl_pt_BR module is *huge* (it has the actual data for pt-BR for Lightproof). And note that there isn't even any document with text in pt-BR open in LibreOffice... So it is totally unnecessary to waste CPU time on loading that data. The Lightproof code needs to be reorganised so that the heavy data modules are loaded only when actually needed.
Comment 24 Telesto 2018-06-20 16:08:08 UTC
@Tor Lillqvist
Is this related to or is there maybe some issue with Python itself? DrMemory (on windows) reported quite some UNADDRESSABLE ACCESS beyond heap bounds errors for python35.dll (bug 108270 comment 7)
Comment 25 László Németh 2018-06-20 17:18:07 UTC
Lightproof uses lazy loading by using __import__ for the compiled rules, but not for the extra Python codes defined in [code] parts of the grammar rule file.
In fact, that I was intended for small extra functions, not a full Python grammar checker, so I didn't optimize it. The good news, that the smaller file is the problem here: :)

laci@nemeth:~/libreoffice/dictionaries/pt_BR/pythonpath$ ls -lS
-rw-rw-r-- 1 laci laci 4805925 nov   23  2017
-rw-rw-r-- 1 laci laci 1491297 nov   23  2017

Thanks for your report and research. I will check it.
Comment 26 Tor Lillqvist 2018-06-20 17:27:22 UTC
Suggested fix in

But if you Lászlo are working on a better fix, even better.
Comment 27 Tor Lillqvist 2018-06-20 17:29:31 UTC
I am not a Python programmer and it probably shows;)
Comment 28 László Németh 2018-06-20 17:48:47 UTC
(In reply to Tor Lillqvist from comment #27)
> I am not a Python programmer and it probably shows;)

Tor, you are a better Python programmer, than me. :)

Many thanks for solving this issue! I will port your solution to the Lightproof framework (, too.
Comment 29 Tor Lillqvist 2018-06-20 20:11:22 UTC
I must confess I have no idea how to check whether the pt-BR Lightproof works any longer after my change... Anybody? The and files are rather hard to understand.

(I did try an equivalent change to the en and that didn't break it. But it would be nice to be able to double-check for pt-BR.)
Comment 30 László Németh 2018-06-20 22:38:12 UTC
(In reply to Tor Lillqvist from comment #29)
> I must confess I have no idea how to check whether the pt-BR Lightproof
> works any longer after my change... Anybody? The
> and files are rather hard to understand.
> (I did try an equivalent change to the en and that didn't
> break it. But it would be nice to be able to double-check for pt-BR.)

It seems, a lower case sentence starting word, ie. "uno" will be underlined by the pt-BR grammar checker. I started to check, there is a problem with the patch yet. I will fix tomorrow, if it's ok:

Python exception: <class 'AttributeError'>: module 'lightproof_impl_pt_BR' has no attribute 'SMGR', traceback follows
  File "/home/laci/libreoffice/instdir/share/extensions/dict-pt-BR/", line 67, in doProofreading
    if lightproof_impl_pt_BR.SMGR == None:
Comment 31 Tor Lillqvist 2018-06-21 05:00:59 UTC
Ah! Yes, I forgot that thing. I guess in , there needs to be:

>  calcfunc = None
> +SMGR = None
>  # check settings

That's what I did when I first experimented with the smaller lightproof for en, but I forgot with pt_BR.

I also now see that in pt_BR/ I accidentally use  lightproof_impl_en.SMGR.createInstanceWithContext("", currentContext) ...

Will fix.
Comment 32 Tor Lillqvist 2018-06-21 05:11:51 UTC should fix it.
Comment 33 László Németh 2018-06-21 07:51:01 UTC
(In reply to Tor Lillqvist from comment #32)
> should fix it.

I've checked it, it did. Thanks, Tor!
Comment 34 Tor Lillqvist 2018-06-24 06:22:26 UTC
Could somebody please check if the fix to the pt-BR Lightproof helped also for the thing the initial comment actually is about?
Comment 35 Tor Lillqvist 2018-07-19 10:48:49 UTC
Aron, do you think this is fixed now?
Comment 36 Telesto 2018-07-19 11:23:26 UTC
No repro for me :-) 
Build ID: e7d3976cb80f7e7401be071f905a764dd6cb4d6e
CPU threads: 4; OS: Windows 6.3; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-29_04:46:32
Locale: nl-NL (nl_NL); Calc: CL
Comment 37 Aron Budea 2018-07-20 12:59:40 UTC
I checked with, and the Tools menu opens a lot quicker, albeit still not instantly (for the first time) like the other menus.

I'd say that's fine, but to be sure, I'll check again with, and also with dictionaries copied to a daily build (I don't have a complete master build including dictionaries, but all relevant dictionary changes have been cherry-picked to 6.1, anyway).

Thanks for the fixes, Tor!

Commits in master:

In 6.1 (one of them contains the changes from two master commits):
Comment 38 Aron Budea 2018-07-20 23:27:51 UTC
And the missing piece is this commit, also by Tor:

Tor, would it be possible to get this into libreoffice-6-1 and libreoffice-6-1-0?
Comment 39 Tor Lillqvist 2018-07-23 07:00:55 UTC
Is the commit you refer to important enough to get into 6.1? I thought only clear bug fixes were supposed to be cherry-picked. That commit is not a such.
Comment 40 Michael Meeks 2018-07-23 13:47:11 UTC
Depends how big and risky it is I guess.