of
commit afeddaf7e0
Author: Caolán McNamara <caolanm@redhat.com>
Date: Wed Dec 16 10:46:10 2015 +0000
Related: rhbz#1281906 set a min size on un-resizeable non-layout dialogs
and using a mixture of gtk_window_set_default_size before its visible, and
gtk_window_set_default_size + gtk_window_resize after its shown now works for
me under wayland so the original problem can be solved that way
Change-Id: Iaf8fd3019a7e902ad07b6825f919c6f25288e9b7
OutDev mapmode takes shortcuts for 'simple' mappings, so clear that flag
once we set scale/origin away from defaults.
Change-Id: I00321e27322d9cb8b86e6cc8400f6396d03328cc
Reviewed-on: https://gerrit.libreoffice.org/30855
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
of
commit afeddaf7e0
Author: Caolán McNamara <caolanm@redhat.com>
Date: Wed Dec 16 10:46:10 2015 +0000
Related: rhbz#1281906 set a min size on un-resizeable non-layout dialogs
and setting a size-request seems to do the right thing for me now under wayland
so the original problem can be solved that way
Change-Id: Ie2dd71c5a32131a60729448f0665d5cae2a83692
* Create IDWriteFont from LOGFONT instead of HDC, as it seems the later
will discard the font width. Without font width, GDI/DirectWrite will
not scale the font horizontally.
Does not seem to work with all Windows versions (at least not
Windows 10 Anniversary Update), seems like this undocumented behaviour
have been dropped :(
* Adjusting font width on Windows during layout, see the inline comment.
Change-Id: I19b788460b6b6ca2c83d75bbf09a0601a250c289
Reviewed-on: https://gerrit.libreoffice.org/30847
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
Tested-by: Khaled Hosny <khaledhosny@eglug.org>
Help for Fit To Frame says "Resizes the text to fit the entire area
of the drawing or text object".
reverts commit b7628798ec
and partially addresses the problem of "Shrink font automatically
when text overflows" by treating text as "Autofit" while it is being
edited.
It's not WYSIWYG, but good enough, and maybe better.
Since that part of the change prevents any way of setting ::Autofit,
I also changed the default setting to Autofit instead of NONE, since there
is no good reason why text should be allowed to spill outside of a textbox.
For those who REALLY want that odd behaviour, they can use
.uno:TextFitToSize (Ctrl-Shift-F8) to toggle between "stretch" and "none".
Change-Id: I8313a82cbea82f11fad0f50d966fc77874977da9
Reviewed-on: https://gerrit.libreoffice.org/30727
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...to check that loplugin produces warnings/errors as expected:
* Clang has a -verify switch that makes it easy to write test input .cxx files
that list in comments all the warnings/errors that are expected, and let Clang
check those expectations instead of generating object code. See
include/clang/Frontend/VerifyDiagnosticConsumer.h in the Clang source tree for
documentation.
* Introduce a CompilerTest gbuild class that uses the existing LinkTarget class
as much as possible. Checking the input files is implicitly phony, as the
compilation step doesn't generate any object files, and the link step does
nothing because there is no gb_LinkTarget_set_targettype for CompilerTest.
The setup at least works for Clang on Linux (will need adaptions for Clang on
Windows; compilers other than Clang are not relevant for now given this is
used to check compilerplugins).
* Definition of gb_CFLAGS_WERROR in solenv/gbuild/platform/com_GCC_defs.mk needs
to be lazy ('=' vs. ':=') so that CompilerTest can override it: The Clang
-verify mode wants the input files to specify whether the loplugin diagnostics
are warnings or errros, so they consistently need to be errors independent of
--enable-werror configuration.
* A first (example) test is in compilerplugins/clang/test/salbool.cxx. The
corresponding gbuild CompilerTest instance is in
solenv/CompilerTest_compilerplugins_clang.mk for now. The reason for that odd
split across compilerplugins/ and solenv/ is that there is no
compilerplugins/Modules_compilerplugins.mk file, so this setup is the easiest
hack for now (to be cleaned up). (Another area that could be improved is that
all test files need to be listed explicitly in the CompilerTest_*.mk file,
instead of, say, using all .c/.cxx/.m/.mm files in a specified directory.)
* The test is run somewhat late during a top-level 'make', after loplugin has
already been used in compilation. But it can be run manually (e.g., 'make
solenv') when making changes to loplugin during development.
Change-Id: I01e12fb84887d264ac03ef2484807458c2075af4
The anchor type of embedded object was simply not handled, we always
assumed that it's as-char.
When it's at-char set the anchor type accordingly, and also set the
usual 6 properties determining the position of the anchored object.
Change-Id: I3f8bede33c6f1a0bdc4f4d4ea59c4fc805802291
Reviewed-on: https://gerrit.libreoffice.org/30860
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
double-thin borders are available in the UI starting from 0.5pt.
The actual minumum (as seen in a round-trip), is 1.10pt.
(Each thin line is ~ .50pt, the gap is ~ .05pt, and then some
approximations and rounding show it as 1.10 - at least that is how I
understood it). 1.15pt is the first point at which the gap is larger
than the minimum - and double_thins with a minimum gap were considered
invalid, and thus were not imported.
With this fix, double-thin borders created with a size less than 1.15pt
are valid and visible on import.
Change-Id: I6da2a40d13ed83281de403b22b3acbea4288ac60
Reviewed-on: https://gerrit.libreoffice.org/30857
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
SfxItemPool::GetItemState() can already return a pointer to a set item so that
doesn't need to be obtained again through SfxItemPool::Get()
tdf#103493 'LotroPlan 3.8.ods'
https://bugs.documentfoundation.org/attachment.cgi?id=128252
Incl. Self Called
Before:
10,210,820,257 1,162,295,513 34,670,201
After:
9,887,701,235 1,384,985,151 34,670,201
Only ~3% and 0.5% of the overall load time, but..
Change-Id: Icbed8a7982a27472fdfb1dbe4fd2061ab1e601bd
When e.g. inserting a Writer doc in a Calc doc ("Insert - Object - OLE Object...
- Create new - LibreOffice 5.3 Text" in Calc), the resulting .ods contains the
size of the embedded Writer doc in two places. First as
<draw:frame svg:width=... svg:height=... ...>
in content.xml, where the size is apparently the original rectangle's size,
before it got aligned in SetVisArea. And a second time as
<config:config-item config:name="ViewAreaWidth" config:type="long">...</config:config-item>
<config:config-item config:name="ViewAreaHeight" config:type="long">...</config:config-item>
in Object 1/settings.xml, where the size is apparently the aligned size.
When the document is loaded again, at first the first size is used to display
the inner Writer doc. But when the inner Writer doc is double-clicked (to make
it editable), now the second size is used, and because they don't match, the
whole document is erroneously considered modified
(ScTabViewShell::ActivateObject -> SfxInPlaceClient::SetObjArea ->
SfxInPlaceClient::Invalidate -> ScClient::ViewChanged ->
ScDocShell::SetDrawModified -> ScDocShell::SetModified ->
SfxObjectShell::SetModified), causing e.g. the "Save" icon to become "active".
It is unclear to me whether these calls to AlignToPixel still serve any real
purpose; lets see whether removing them causes any issues...
Change-Id: I755dd9e8b2406f0b4b41d0f3d1281d6ad4b1b238
...as reported by -fsanitize=vptr when doing "Format - Page..." in Writer
(though both types have a Size member at the same location, so didn't cause any
real problems):
> sw/source/ui/misc/pgfnote.cxx:283:32: runtime error: downcast of address 0x604000e23f50 which does not point to an object of type 'const SvxSizeItem'
> 0x604000e23f50: note: object is of type 'SwFormatFrameSize'
> 94 01 00 3d 90 ae ee 90 ff 7e 00 00 06 00 00 00 58 00 00 be d0 2f 00 00 00 00 00 00 e0 3d 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'SwFormatFrameSize'
> #0 0x7efd1c8d01e2 in SwFootNotePage::ActivatePage(SfxItemSet const&) sw/source/ui/misc/pgfnote.cxx:283:32
> #1 0x7efd1c8cbf07 in SwFootNotePage::Reset(SfxItemSet const*) sw/source/ui/misc/pgfnote.cxx:230:5
> #2 0x7f002e149560 in SfxTabDialog::ActivatePageHdl(TabControl*) sfx2/source/dialog/tabdlg.cxx:1117:19
> #3 0x7f002e1400e3 in SfxTabDialog::LinkStubActivatePageHdl(void*, TabControl*) sfx2/source/dialog/tabdlg.cxx:1035:1
> #4 0x7f0008248f37 in Link<TabControl*, void>::Call(TabControl*) const include/tools/link.hxx:84:45
> #5 0x7f0008204caa in TabControl::ActivatePage() vcl/source/control/tabctrl.cxx:1601:19
Change-Id: I73df2438565a7069153b22140197897df810b2aa
...during CppunitTest_filter_dialogs_test:
> filter/source/xsltdialog/xmlfiltersettingsdialog.cxx:1398:20: runtime error: reference binding to null pointer of type 'ResMgr'
> #0 0x7f144bf5ab10 in XMLFilterListBox::XMLFilterListBox(vcl::Window*, SvxPathControl*) filter/source/xsltdialog/xmlfiltersettingsdialog.cxx:1398:20
> #1 0x7f144bf7abb8 in VclPtr<XMLFilterListBox> VclPtr<XMLFilterListBox>::Create<VclPtr<VclVBox>&, SvxPathControl*>(VclPtr<VclVBox>&, SvxPathControl*&&) include/vcl/vclptr.hxx:138:46
> #2 0x7f144bf50df8 in SvxPathControl::SvxPathControl(vcl::Window*) filter/source/xsltdialog/xmlfiltersettingsdialog.cxx:1312:20
> #3 0x7f144bf7d487 in VclPtr<SvxPathControl> VclPtr<SvxPathControl>::Create<VclPtr<vcl::Window>&>(VclPtr<vcl::Window>&) include/vcl/vclptr.hxx:138:46
> #4 0x7f144bf56a2f in makeSvxPathControl filter/source/xsltdialog/xmlfiltersettingsdialog.cxx:1378:1
> #5 0x7f14d2060a04 in VclBuilder::makeObject(vcl::Window*, rtl::OString const&, rtl::OString const&, std::__debug::map<rtl::OString, rtl::OString, std::less<rtl::OString>, std::allocator<std::pair<rtl::OString const, rtl::OString> > >&) vcl/source/window/builder.cxx:1793:17
> #6 0x7f14d2078ddb in VclBuilder::insertObject(vcl::Window*, rtl::OString const&, rtl::OString const&, std::__debug::map<rtl::OString, rtl::OString, std::less<rtl::OString>, std::allocator<std::pair<rtl::OString const, rtl::OString> > >&, std::__debug::map<rtl::OString, rtl::OString, std::less<rtl::OString>, std::allocator<std::pair<rtl::OString const, rtl::OString> > >&, std::__debug::map<rtl::OString, rtl::OString, std::less<rtl::OString>, std::allocator<std::pair<rtl::OString const, rtl::OString> > >&) vcl/source/window/builder.cxx:1887:25
> #7 0x7f14d208790a in VclBuilder::handleObject(vcl::Window*, xmlreader::XmlReader&) vcl/source/window/builder.cxx:2856:37
> #8 0x7f14d20215bc in VclBuilder::handleChild(vcl::Window*, xmlreader::XmlReader&) vcl/source/window/builder.cxx:2114:33
> #9 0x7f14d2087bea in VclBuilder::handleObject(vcl::Window*, xmlreader::XmlReader&) vcl/source/window/builder.cxx:2859:17
> #10 0x7f14d20215bc in VclBuilder::handleChild(vcl::Window*, xmlreader::XmlReader&) vcl/source/window/builder.cxx:2114:33
> #11 0x7f14d2087bea in VclBuilder::handleObject(vcl::Window*, xmlreader::XmlReader&) vcl/source/window/builder.cxx:2859:17
> #12 0x7f14d20215bc in VclBuilder::handleChild(vcl::Window*, xmlreader::XmlReader&) vcl/source/window/builder.cxx:2114:33
> #13 0x7f14d200c59a in VclBuilder::VclBuilder(vcl::Window*, rtl::OUString const&, rtl::OUString const&, rtl::OString const&, com::sun:⭐:uno::Reference<com::sun:⭐:frame::XFrame> const&) vcl/source/window/builder.cxx:206:9
> #14 0x7f1492275862 in ScreenshotTest::dumpDialogToPath(rtl::OString const&) test/source/screenshot_test.cxx:177:24
The existing code apparently depended on any calls to getXSLTDialogResMgr in
xmlfiltersettingsdialog.cxx only happening after pXSLTResMgr had been set up in
the outer XMLFilterDialogComponent::execute in xmlfilterdialogcomponent.cxx.
That is not true when each dialog is opened independently in the screenshot
test, so instead just call CreateResMgr on demand wherever needed.
Change-Id: I9f6dc7c66d4999137352a8d91665b954f4088085
...when doing "Format - Page..." in Writer:
> vcl/source/control/field.cxx:621:20: runtime error: signed integer overflow: 9223372036854775807 * 100 cannot be represented in type 'long'
> #0 0x7f57787c4868 in NumericFormatter::Normalize(long) const vcl/source/control/field.cxx:621:20
> #1 0x7f578a4608dc in SetFieldUnit(MetricField&, FieldUnit, bool) svtools/source/misc/unitconv.cxx:75:32
> #2 0x7f5488952648 in SvxPageDescPage::SvxPageDescPage(vcl::Window*, SfxItemSet const&) cui/source/tabpages/page.cxx:275:5
> #3 0x7f54889c3ea4 in VclPtr<SvxPageDescPage> VclPtr<SvxPageDescPage>::Create<vcl::Window*&, SfxItemSet const&>(vcl::Window*&, SfxItemSet const&) include/vcl/vclptr.hxx:138:46
> #4 0x7f5488925d27 in SvxPageDescPage::Create(vcl::Window*, SfxItemSet const*) cui/source/tabpages/page.cxx:162:12
> #5 0x7f579ea86df4 in SfxTabDialog::ActivatePageHdl(TabControl*) sfx2/source/dialog/tabdlg.cxx:1085:24
> #6 0x7f579ea800e3 in SfxTabDialog::LinkStubActivatePageHdl(void*, TabControl*) sfx2/source/dialog/tabdlg.cxx:1035:1
> #7 0x7f5778b88f37 in Link<TabControl*, void>::Call(TabControl*) const include/tools/link.hxx:84:45
> #8 0x7f5778b44caa in TabControl::ActivatePage() vcl/source/control/tabctrl.cxx:1601:19
and NumericFormatter::mnMax is still SAL_MAX_INT64 (but will be set to a smaller
value a few lines futher down in the SvxPageDescPage ctor). So initialize mnMax
to a substantially smaller value (that is still "large", but avoids this kind of
overflow), and hope that no code relies on the exact initial value.
Change-Id: If3b4db1d20bc59418d1769e9690bc7ecdbf29a50
...when doing "Format - Page..." in Writer:
> cui/source/tabpages/tparea.cxx:268:12: runtime error: load of value 4294967295, which is not a valid value for type 'FillType'
> #0 0x7f89ff653a41 in SvxAreaTabPage::Reset(SfxItemSet const*) cui/source/tabpages/tparea.cxx:268:12
> #1 0x7f8d15524560 in SfxTabDialog::ActivatePageHdl(TabControl*) sfx2/source/dialog/tabdlg.cxx:1117:19
> #2 0x7f8d1551b0e3 in SfxTabDialog::LinkStubActivatePageHdl(void*, TabControl*) sfx2/source/dialog/tabdlg.cxx:1035:1
> #3 0x7f8cef623f37 in Link<TabControl*, void>::Call(TabControl*) const include/tools/link.hxx:84:45
> #4 0x7f8cef5dfcaa in TabControl::ActivatePage() vcl/source/control/tabctrl.cxx:1601:19
Change-Id: I19dd3ed9d362132daa3f3be9fb0e9702a62bdeb0
The sparse chart import moved from assuming that the number of elements
in the list parsed from ooxml is the same as the real number of
elements. For this, the patch relies on a new member that was not always
initialized. This patch fixes a missing initialization. According to
'grep' this should be the last one.
Change-Id: I31d8a653f227100436360deef4a53c9418de9d93
Reviewed-on: https://gerrit.libreoffice.org/30838
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
...after 6e32e57582 "Resolves: tdf#103915 when
global dark theme is set fall back to breeze_dark". No idea whether
bDarkIconTheme=false is the right choice in all three cases, but at least the
test succeeds that way.
Change-Id: I633c4ebff19a1d441baa8270d681a73c8f6c4aa0
When client side request special character, it is very useful to send a
preview of the rendered font character
Conflicts:
desktop/source/lib/init.cxx
Change-Id: I1f5727163dfcc861add121e616bdb17881c28197
Reviewed-on: https://gerrit.libreoffice.org/30784
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
regression from
commit 96e9ffa647 (patch)
loplogin:singlevalfields in include/
I did not notice that the mnItemPadding field was shadowing a
declaration in a superclass
Change-Id: I52cf9945da43fa3d1049b624a6b24bc6d974d445
In the normal course of events, the menu, or its children, has focus when its
popped down, in this case continue to restored the focus to the previous focus
window which had it when the menu appeared.
If some other non-child window of the menu has focus as popdown time, leave
the focus where it is.
Change-Id: Ia860f90350653ad4d8056738dacbc434fb364989
This way when printing documents with odd number of pages
and collated printing is selected the first page of the
second copy is not printed to the empty last page of the firs copy.
Change-Id: Ie4d9f6952e39581690c396665a9894970be54b6b
Reviewed-on: https://gerrit.libreoffice.org/30774
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
