and SmSymDefineDialog
There's a whole bunch of interrelated stuff which needs to work at the same
time.
add menu support, keyboard support, better mouse support,
a gtk scrollable adaptor to support pseudo scrolling drawing bodge,
plugable uitest support for custom widgets, plugable a11y support
for custom widgets via the existing atk_object_wrapper_new wrapper
for XAccessible
In this specific case, change SvxCharacterMap from something that has an
internal scrollbar to a scrolledwindow where the scrollbar is external, which
drops the need for the a11y impl of SvxCharacterMap to emulate being a scrolled
window and internal table and just needs the table a11y impl
Change-Id: Ia2743d6958021c525a1900154dcbb69ae33fc400
Reviewed-on: https://gerrit.libreoffice.org/52084
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
I happened to come across a SEGV caused by a null ToolBox::mpData once, as
below. Interestingly, some ToolBox member functions like GetItemPos and
GetItemCount do take a potential null mpData (after a call to dispose) into
account.
> #0 0x00007fffebc1b93c in std::__cxx1998::vector<ImplToolItem, std::allocator<ImplToolItem> >::size() const (this=0x20) at /usr/include/c++/7/bits/stl_vector.h:671
> #1 0x00007fffebc172ce in ToolBox::SetItemBits(unsigned short, ToolBoxItemBits) (this=0x7ffec6449230, nItemId=16, nBits=ToolBoxItemBits::DROPDOWN) at /data/sbergman/lo-ro/source/vcl/source/window/toolbox2.cxx:889
> #2 0x00007ffff07ccc42 in SvxClipBoardControl::StateChanged(unsigned short, SfxItemState, SfxPoolItem const*) (this=0x7ffec6420390, nSID=5312, eState=SfxItemState::DEFAULT, pState=0xad4cf60) at /data/sbergman/lo-ro/source/svx/source/mnuctrls/clipboardctl.cxx:116
> #3 0x00007ffff1d69c4f in SfxToolBoxControl::statusChanged(com::sun::star::frame::FeatureStateEvent const&) (this=0x7ffec6420390, rEvent=...) at /data/sbergman/lo-ro/source/sfx2/source/toolbox/tbxitem.cxx:521
> #4 0x00007ffff193e163 in SfxDispatchController_Impl::addStatusListener(com::sun::star::uno::Reference<com::sun::star::frame::XStatusListener> const&, com::sun::star::util::URL const&) (this=0xaa3da80, aListener=uno::Reference to (SvxClipBoardControl *) 0x7ffec64203b8, aURL=...) at /data/sbergman/lo-ro/source/sfx2/source/control/unoctitm.cxx:865
> #5 0x00007ffff193ddfc in SfxOfficeDispatch::addStatusListener(com::sun::star::uno::Reference<com::sun::star::frame::XStatusListener> const&, com::sun::star::util::URL const&) (this=0xaffa990, aListener=uno::Reference to (SvxClipBoardControl *) 0x7ffec64203b8, aURL=...) at /data/sbergman/lo-ro/source/sfx2/source/control/unoctitm.cxx:250
> #6 0x00007fffee75c7e4 in svt::ToolboxController::bindListener() (this=0x7ffec6420390) at /data/sbergman/lo-ro/source/svtools/source/uno/toolboxcontroller.cxx:529
> #7 0x00007fffee75c056 in svt::ToolboxController::update() (this=0x7ffec6420390) at /data/sbergman/lo-ro/source/svtools/source/uno/toolboxcontroller.cxx:227
> #8 0x00007fffc11ddef6 in framework::ToolBarManager::UpdateControllers() (this=0x7ffec6142930) at /data/sbergman/lo-ro/source/framework/source/uielement/toolbarmanager.cxx:364
> #9 0x00007fffc11e995e in framework::ToolBarManager::AsyncUpdateControllersHdl(Timer*) (this=0x7ffec6142930) at /data/sbergman/lo-ro/source/framework/source/uielement/toolbarmanager.cxx:1852
> #10 0x00007fffc11dc748 in framework::ToolBarManager::LinkStubAsyncUpdateControllersHdl(void*, Timer*) (instance=0x7ffec6142930, data=0x7ffec6142b00) at /data/sbergman/lo-ro/source/framework/source/uielement/toolbarmanager.cxx:1839
> #11 0x00007fffec264928 in Link<Timer*, void>::Call(Timer*) const (this=0x7ffec6142b20, data=0x7ffec6142b00) at /data/sbergman/lo-ro/source/include/tools/link.hxx:84
> #12 0x00007fffec264787 in Timer::Invoke() (this=0x7ffec6142b00) at /data/sbergman/lo-ro/source/vcl/source/app/timer.cxx:76
> #13 0x00007fffec21cdd2 in Scheduler::ProcessTaskScheduling() () at /data/sbergman/lo-ro/source/vcl/source/app/scheduler.cxx:448
> #14 0x00007fffec21bfed in Scheduler::CallbackTaskScheduling() () at /data/sbergman/lo-ro/source/vcl/source/app/scheduler.cxx:270
> #15 0x00007fffcdfaa036 in SalTimer::CallCallback() (this=0x199ae40) at /data/sbergman/lo-ro/source/vcl/inc/saltimer.hxx:55
> #16 0x00007fffcdfa920d in sal_gtk_timeout_dispatch(_GSource*, int (*)(void*), void*) (pSource=0x7e1abe0) at /data/sbergman/lo-ro/source/vcl/unx/gtk3/gtk3gtkdata.cxx:692
> #17 0x00007ffff5aa7b77 in g_main_dispatch (context=0x63d8d0) at /usr/src/debug/glib2-2.54.3-2.fc27.x86_64/glib/gmain.c:3142
> #18 0x00007ffff5aa7b77 in g_main_context_dispatch (context=context@entry=0x63d8d0) at /usr/src/debug/glib2-2.54.3-2.fc27.x86_64/glib/gmain.c:3795
> #19 0x00007ffff5aa7f20 in g_main_context_iterate (context=context@entry=0x63d8d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /usr/src/debug/glib2-2.54.3-2.fc27.x86_64/glib/gmain.c:3868
> #20 0x00007ffff5aa7fac in g_main_context_iteration (context=0x63d8d0, may_block=1) at /usr/src/debug/glib2-2.54.3-2.fc27.x86_64/glib/gmain.c:3929
> #21 0x00007fffcdfa78f4 in GtkSalData::Yield(bool, bool) (this=0x63ae70, bWait=true, bHandleAllCurrentEvents=false) at /data/sbergman/lo-ro/source/vcl/unx/gtk3/gtk3gtkdata.cxx:459
> #22 0x00007fffcdfabf07 in GtkInstance::DoYield(bool, bool) (this=0x6e6a90, bWait=true, bHandleAllCurrentEvents=false) at /data/sbergman/lo-ro/source/vcl/unx/gtk/gtkinst.cxx:412
> #23 0x00007fffec2515ca in ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at /data/sbergman/lo-ro/source/vcl/source/app/svapp.cxx:472
> #24 0x00007fffec24c2c4 in Application::Yield() () at /data/sbergman/lo-ro/source/vcl/source/app/svapp.cxx:537
> #25 0x00007fffec24c24e in Application::Execute() () at /data/sbergman/lo-ro/source/vcl/source/app/svapp.cxx:452
> #26 0x00007ffff774d617 in desktop::Desktop::Main() (this=0x7fffffff2950) at /data/sbergman/lo-ro/source/desktop/source/app/app.cxx:1623
> #27 0x00007fffec260825 in ImplSVMain() () at /data/sbergman/lo-ro/source/vcl/source/app/svmain.cxx:198
> #28 0x00007fffec262498 in SVMain() () at /data/sbergman/lo-ro/source/vcl/source/app/svmain.cxx:236
> #29 0x00007ffff77bba98 in soffice_main() () at /data/sbergman/lo-ro/source/desktop/source/app/sofficemain.cxx:166
> #30 0x000000000040086d in sal_main () at /data/sbergman/lo-ro/source/desktop/source/app/main.c:48
> #31 0x0000000000400847 in main (argc=4, argv=0x7fffffff2c98) at /data/sbergman/lo-ro/source/desktop/source/app/main.c:47
Change-Id: I622b4128de0a6be294b59caf2bb2d6f7b529c349
Reviewed-on: https://gerrit.libreoffice.org/52086
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The intent of the test is to trigger PDF export. On Windows, GDI printing
is used, so no use to run it (and it would provide a sane PDF with 2 white
paths).
Change-Id: I808807ce0d339cccbb3d097f486d2562e7b2819f
Reviewed-on: https://gerrit.libreoffice.org/52072
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
This partially reverts commit bb6a8dce40 and means we need
a different solution for tdf#48300 on X11-based Linux frontends.
Send _NET_ACTIVE_WINDOW signal only if we want to activate window
that has been minimized (ToTopFlags::RestoreWhenMin) or covered by
other windows (ToTopFlags::ForegroundTask).
Change-Id: I529baf6cc1174728b54bae4c658cf95631da19d6
Reviewed-on: https://gerrit.libreoffice.org/51867
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Move the glyph to character(s) mapping to CommonSalLayout where we have
enough information to do this properly. This correctly handles ligatures
at end of run that wasn’t handled before, and also fixes a bug in the
PDF writer code when there is more than one ligature in the run (it
forgot to clear aCodeUnitsPerGlyph vector after each iteration). Also
drop the “temporary” fix for rotated glyph from 2009 that does not seem
to be needed now (the document from that bug exports correctly after this
change).
Change-Id: I5b5b1f4470bbd0ef05cbbc86dfa29d2ff51249ea
Reviewed-on: https://gerrit.libreoffice.org/51617
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This had originally been introduced with
0f61495931 "Make it easier to catch code that
assumes SalBitmaps are created pre-cleared". But it only made it harder to find
the issue reverted with ebe247642d "Revert
'tdf#116213 OS X and OpenGL bitmap scaline sizes are not 32-bit aligned'".
Change-Id: I344e1ab4b390baa8364ade5fd2737a12708facdc
This reverts commit 460f39e687.
For one, it had started to make bitmap checksum equality check in
svx/qa/unit/XTableImportExportTest.cxx, CppunitTest_svx_unit, fail most of the
time in macOS --disable-dbgutil builds, as the bitmap checksum is now computed
also over padding bytes containing random values (but --enable-dbgutil
initializes those bytes). And why would fixing tdf#116213 for Windows require
touching the macOS-specific code, anyway?
For another, tdf#116213 comments 6 and 7 report further problems that are likely
linked to this commit.
Change-Id: I3e158813ab89a1ead3780abbf6b120ec52660231
I (tried to) keep these files consistent locally with astyle in the past,
switching to clang-format makes sure that the recent problem with introducing
inconsistencies in these files doesn't happen again.
(On the flip side, it's great to see that now others also touch this
PDF/pdfium code. :-) )
Change-Id: I6065eab77c584197a82fe48e7d3e81b445106efd
Reviewed-on: https://gerrit.libreoffice.org/51701
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
For DC initialization we check the thread ID to assign a normal
or cached DC to the corresponding WinSalGraphics variable.
The cached DC has a usage count, as there are some limits on
cached DCs count (DCX_CACHE).
But for the WinSalGraphics DC init and release the variable just
matters for the accounting, and generally which thread is doing
the calls: the non-main thread always has to relay them to the
main application thread.
Since we're releasing all WinSalGraphics in ~WinSalFrame and do
all release and re-init in ImplSetParentFrame, there is no way
to correspond the thread ID to the WinSalGraphics variable.
So this drops the wrong assertions based on the WinSalGraphics
variables and renames the GETDC message to GETCACHEDDC to make
usage of a cached DC (DCX_CACHE) more obvious.
As a consequence of the different release DC handling this also
fixes the accounting of the cached DCs, wich was broken in the
initial fix; commit c15ea73f96
Change-Id: I11ce52a1b4005f26567f92588437fa37bf227a2e
Reviewed-on: https://gerrit.libreoffice.org/51318
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Caolán McNamara