(regression from 0377b99b3f)
* divide PART_SEPARATOR into PART_SEPARATOR_HORZ and PART_SEPARATOR_VERT
* improve separator reduction: now the offset is (height*0.2) instead of 7.
* rename: gVSeparator -> gSeparator
* remove trailing whitespace
Change-Id: I I If144509d7e061bf1b7901cd5418c4d7dbc3aa0d0
Resolves: fdo#48011 writer idle-callbacks are halting when events pending
commit id: 658954e8b5
which isn't to pretend that its definitely the *right* fix
Change-Id: I228cf86b8e5eb0e4918c31e853a8d567831ce5e2
Since they always return sal_Bool values that are not used by any callers, I changed the Region class methods (both versions of each Union, Intersect, Exclude, XOr) from sal_Bool return type to void return type.
...which has the necessary features to support it.
Change a lot of classes to either contain a protected non-virtual dtor
(which is backwards compatible, so even works for cppumaker-generated
UNO headers) or a public virtual one.
cppuhelper/propertysetmixin.hxx still needs to disable the warning, as
the relevant class has a non-virtual dtor but friends, which would still
cause GCC to warn.
Includes a patch for libcmis, intended to be upstreamed.
They pollute not only the global namespace, but all namespaces,
given they're are #define's. I bet they'd eventually all conflict
with the namespaced enum in kdelibs headers.
It's too small to justify standalone existence.
We can accumulate i18n things we link to directly into
i18nutil and rework i18npool uno implementions in terms
of thin wrappers over i18nutil and prefer linking to
i18nutil internally and leave the uno forwarders for
use by external components and scripting
There was a TODO to replace a manually managed array of Glyphs
to use std::list
a GlyphItem is 36 bytes long. the colleciton of GlyphItems is
mostly used in a sequential access. random insert/delete are fairly rare.
using std::list would increase the size by at least 8 to 16 bytes per
element (depending on the size of void*) (25 to 50% overhead)
and would greatly degrade data locality for most iterations loops.
so std::vector seems more appropriate here.
tml reminds us that use a generic and potentially clash-prone word
like HEADLESS as preprocessor defintion is pretty lame.
He suggests to put it under the already used LIBO namespace.
To sum it up let's do a s/HEADLESS/LIBO_HEADLESS/g.
This method seems to be useless. The return value (keyboard name) isn't
used at any point. And I don't see any point in this method where some
implicit call is done to refresh mappings...
getKeysymReplacementName() returned a translated keyname, now
XKeysymToString() is called directly. This change had no negative
effect to me. I tried it with a fixed string as return value for
getKeysymReplacementName() on a german interface. INSRT is still
translated to EINFG as this is done by po files.
Instead of introducing a global variable, use the already existing
saved android_app pointer in lo-bootstrap.c, and just add a function
to retrieve it from there. Store it in the AndroidSalInstance.
Reanme osl/detail/android.h back to android_native_app_glue.h, which
is the name of that file in NDK/sources. "android.h" sounded to me too
grand, as if it was some universal Android header. But if we do start
to modify the android_native_app_glue stuff heavily, then it indeed
makes sense to call it something else. Until then, revert also some
whitespace changes to android_native_app_glue.c for it to be as close
as possible to the "upstream" one in the NDK, for clarity.
Instead of introducing a global variable, use the already existing
saved android_app pointer in lo-bootstrap.c, and just add a function
to rettrieve that.
Reanme osl/detail/android.h back to android_native_app_glue.h, which
is the file from NDK/sources that it is. "android.h" sounded to me too
grand, as if it was some universal Android header. But if we do start
to modify the android_native_app_glue stuff heavily, then it indeed
makes sense to call it something else. Until then, revert also some
whitespace changes to android_native_app_glue.c for it to be as close
as possible to the "upstream" one in the NDK, for clarity.
6a8fd4c76a claims that RescheduleDuringAcquire is
necessary to prevent deadlocks, but fails to explain what those deadlocks look
like (and the cited HH internal issue 163542 is not available for inspection).
It does lead to code erroneously being called with unlocked solar mutex, leading
to crashes like
Thread 1:
0 in com::sun:⭐:uno::BaseReference::is at solver/unxlngx6/inc/com/sun/star/uno/Reference.h:103
1 in sdr::contact::ControlHolder::is at svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:204
2 in sdr::contact::ViewObjectContactOfUnoControl_Impl::hasControl at svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:642
3 in sdr::contact::ViewObjectContactOfUnoControl::isPrimitiveVisible at svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx:1815
4 in sdr::contact::ViewObjectContact::getPrimitive2DSequenceHierarchy at svx/source/sdr/contact/viewobjectcontact.cxx:396
5 in sdr::contact::ViewObjectContact::getPrimitive2DSequenceSubHierarchy at svx/source/sdr/contact/viewobjectcontact.cxx:428
6 in sdr::contact::ViewObjectContactOfPageHierarchy::getPrimitive2DSequenceHierarchy at svx/source/sdr/contact/viewobjectcontactofsdrpage.cxx:450
7 in sdr::contact::ViewObjectContact::getPrimitive2DSequenceSubHierarchy at svx/source/sdr/contact/viewobjectcontact.cxx:428
8 in sdr::contact::ViewObjectContactOfSdrPage::getPrimitive2DSequenceHierarchy at svx/source/sdr/contact/viewobjectcontactofsdrpage.cxx:699
9 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay at svx/source/sdr/contact/objectcontactofpageview.cxx:248
10 in sdr::contact::ObjectContactOfPageView::ProcessDisplay at svx/source/sdr/contact/objectcontactofpageview.cxx:132
11 in SdrPageWindow::RedrawLayer at svx/source/svdraw/sdrpagewindow.cxx:391
12 in SdrPageView::DrawLayer at svx/source/svdraw/svdpagv.cxx:398
13 in SwViewImp::PaintLayer at sw/source/core/view/vdraw.cxx:148
14 in SwRootFrm::Paint at sw/source/core/layout/paintfrm.cxx:2976
15 in ViewShell::Paint at sw/source/core/view/viewsh.cxx:1678
16 in SwCrsrShell::Paint at sw/source/core/crsr/crsrsh.cxx:1165
17 in SwEditWin::Paint at sw/source/ui/docvw/edtwin2.cxx:535
18 in Window::ImplCallPaint at vcl/source/window/window.cxx:2417
19 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
20 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
21 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
22 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
23 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
24 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
25 in Window::ImplCallOverlapPaint at vcl/source/window/window.cxx:2477
26 in Window::ImplHandlePaintHdl at vcl/source/window/window.cxx:2497
27 in Window::LinkStubImplHandlePaintHdl at vcl/source/window/window.cxx:2491
28 in Link::Call at solver/unxlngx6/inc/tools/link.hxx:140
29 in Timer::Timeout at vcl/source/app/timer.cxx:256
30 in Timer::ImplTimerCallbackProc at vcl/source/app/timer.cxx:144
31 in SalTimer::CallCallback at vcl/inc/saltimer.hxx:66
32 in SvpSalInstance::CheckTimeout at vcl/headless/svpinst.cxx:199
33 in SvpSalInstance::Yield at vcl/headless/svpinst.cxx:310
34 in ImplYield at vcl/source/app/svapp.cxx:455
35 in Application::Reschedule at vcl/source/app/svapp.cxx:482
36 in SolarMutexReleaser::~SolarMutexReleaser at solver/unxlngx6/inc/vcl/svapp.hxx:551
37 in VCLXWindowImpl::OnProcessCallbacks at toolkit/source/awt/vclxwindow.cxx:320
38 in VCLXWindowImpl::LinkStubOnProcessCallbacks at toolkit/source/awt/vclxwindow.cxx:291
39 in Link::Call at solver/unxlngx6/inc/tools/link.hxx:140
40 in ImplHandleUserEvent at vcl/source/window/winproc.cxx:1999
41 in ImplWindowFrameProc at vcl/source/window/winproc.cxx:2571
42 in SalFrame::CallCallback at vcl/inc/salframe.hxx:294
43 in SvpSalInstance::Yield at vcl/headless/svpinst.cxx:299
44 in ImplYield at vcl/source/app/svapp.cxx:455
45 in Application::Yield at vcl/source/app/svapp.cxx:489
46 in Application::Execute at vcl/source/app/svapp.cxx:432
47 in desktop::Desktop::Main at desktop/source/app/app.cxx:1824
48 in ImplSVMain at vcl/source/app/svmain.cxx:178
49 in SVMain at vcl/source/app/svmain.cxx:215
50 in soffice_main at desktop/source/app/sofficemain.cxx:67
51 in sal_main at desktop/source/app/main.c:34
52 in main at desktop/source/app/main.c:33
Thread 2:
0 __lll_unlock_wake at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:373
1 in _L_unlock_657 from /lib64/libpthread-2.12.so
2 in __pthread_mutex_unlock_usercnt at pthread_mutex_unlock.c:52
3 __pthread_mutex_unlock at pthread_mutex_unlock.c:290
4 in osl_releaseMutex at sal/osl/unx/mutex.c:179
5 in vcl::SolarMutexObject::release at vcl/source/app/solarmutex.cxx:54
6 in SalYieldMutex::release at vcl/generic/app/geninst.cxx:73
7 in SolarMutexGuard::~SolarMutexGuard at solver/unxlngx6/inc/vcl/svapp.hxx:436
8 in SfxBaseModel::close at sfx2/source/doc/sfxbasemodel.cxx:1500
9 in SwXTextDocument::close at sw/source/ui/uno/unotxdoc.cxx:574
10 in callVirtualMethod at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:155
11 in cpp_call at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:392
12 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:586
13 in binaryurp::IncomingRequest::execute_throw at binaryurp/source/incomingrequest.cxx:263
14 in binaryurp::IncomingRequest::execute at binaryurp/source/incomingrequest.cxx:89
15 in binaryurp::(anonymous namespace)::request at binaryurp/source/reader.cxx:107
16 in cppu_threadpool::JobQueue::enter at cppu/source/threadpool/jobqueue.cxx:121
17 in cppu_threadpool::ORequestThread::run at cppu/source/threadpool/thread.cxx:222
18 in cppu_requestThreadWorker at cppu/source/threadpool/thread.cxx:57
19 in osl_thread_start_Impl at sal/osl/unx/thread.c:292
20 in start_thread at pthread_create.c:301
21 in clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
Looks best to remove that strange feature again and, if deadlocks should
resurface, how to fix them cleanly.
It turns out this new idea of mapping xinerama screens, and xrandr
monitors into a flat integer space is nice, but when we confuse
xrandr monitor 2 (idx 1) with X screen 1 (there is only one screen)
we bit the dust.
Many thanks to Cor Nouws for remote debugging assistance
XLFD support was removed in commit 269f91c (#i110171) except for parsing
fonts.dir and fonts.alias. I don't think this makes much sense in
fontconfig era, and dropping it simplifies the font manager a bit (I
don't even think we use server fonts at all).
- use the same fade in/out values that we use for headers/footers
- clicking on the line opens the menu too
- clicking outside the menu hides the button
- leaving the line or the button hides the button immediately
