| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Id4bf243276f16a7e840df0cacf2ca4151b49ca46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173052
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
When autosize (a frame property) is enabled, then the (text) frame
manages it's height/width based on the content such that all the text
is visible. The user cannot decrease the height/width to be less than
the content height/width, but the resize handles show up, and clicking and
dragging is enabled, which shows a blue virtual resize frame.
This patch adds UI feedback mechanism such that if the drag leads
to some change in any dimention of the original frame, then the
frame color will remain blue, otherwise it turns red.
Change-Id: Id4b3e3ae2c9864154e6028ca03008261bbc3e1b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165817
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: I6d98aab59799365c9a0052f259cd5c8208d995bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164961
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Adds new expert configuration option DragThresholdPixels for
Impress and Draw under Misc/DragThresholdPixels.
Also bumps up the previous hardcoded default
value from 2 to 6.
Assuming this value was set when 640x480 resolution was the
most common resolution, currently scaling the hardcoded
default by 3 makes sense.
(eg. GTK uses 8 pixels as the default)
Change-Id: I35c0eed3ce477685c759f517471ce0bdc8315864
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154379
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: I3eb1949c0024ab0241a26c7dec410c774b91cdcb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135793
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I8ff465d5755dae7098293702115ab08055814754
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103403
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Using SVX_DLLPUBLIC for both Library_svxcore and Library_svx had started to
cause failures with clang-cl on Windows now, presumably due to devirtualization:
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::DataChanged(class DataChangedEvent const &)" (?DataChanged@SvxMetricField@@MEAAXAEBVDataChangedEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::PreNotify(class NotifyEvent &)" (?PreNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::EventNotify(class NotifyEvent &)" (?EventNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::Modify(void)" (?Modify@SvxMetricField@@MEAAXXZ)
> linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::PreNotify(class NotifyEvent &)" (?PreNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z)
> linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::EventNotify(class NotifyEvent &)" (?EventNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z)
> C:\lo-clang\core\instdir\program\svxcorelo.dll : fatal error LNK1120: 6 unresolved externals
Replacing certain uses of SVX_DLLPUBLIC with the newly introduced
SVXCORE_DLLPUBLIC (include/svx/svxdllapi.h) has been done on Linux as follows:
> git grep -w --line-number -e SVX_DLLPUBLIC --and --not -e '#define SVX_DLLPUBLIC' >LINES
to produce a file LINES containing all 640 uses. (Conveniently, all uses
happen to be on different lines.) Manually create a file TOKENS
with 640 corresponding lines, each containing the (class or function) name that
is made SVX_DLLPUBLIC by in the corresponding line in LINES. Then
> nm -D --def instdir/program/libsvxcorelo.so | grep -ivw '[vw]' | c++filt >SVXCORESYMS
> nm -D --def instdir/program/libsvxlo.so | grep -ivw '[vw]' | c++filt >SVXSYMS
> n=$(cat TOKENS | wc -l)
> for ((i=1;i<="$n";++i)); do
> tok=$(head -n "$i" TOKENS | tail -1)
> printf @
> grep -Fw "$tok" SVXCORESYMS >/dev/null && printf svxcore
> printf @
> grep -Fw "$tok" SVXSYMS >/dev/null && printf svx
> printf '@ '
> head -n "$i" LINES | tail -1
> done
to generate 640 output lines detailing for each SVX_DLLPUBLIC name occurrene
whether it is mentioned in exports from neither (@@@), only from svx (@@svx@),
only from svxcore (@svxcore@@), or from both libraries (@svxcore@svx@). The
numbers that gives is
10 @@@
180 @@svx@
424 @svxcore@@
26 @svxcore@svx@
The 10 @@@ ask for follow-up clean up, but most of them are just left as
SVX_DLLPUBLIC for now. The exceptions are sxv::ITextProvider
(include/svx/itextprovider.hxx) and SdrCustomShapeGeometryItem::PropertyPairHash
(include/svx/sdasitm.hxx, where PropertyPairHash is a member struct of
SVXCORE_DLLPUBLIC SdrCustomShapeGeometryItem). Keeping them as SVX_DLLPUBLIC
would cause "unresolved externals" errors when linking Library_svxcore on
Windows.
The 180 @@svx@ are fine to keep as-is, and the 424 @svxcore@@ need rewriting.
The 26 @svxcore@svx@ needed manual inspection to decide (in some cases, the
chosen name in TOKENS was a too generic function name like Fill, in other cases
it was the name of a class exported from one library but also mentioned in the
arguments of a function exported from the other).
And for sdr::table::SdrTableObj the class itself is defined in svxcore while the
static member functions ExportAsRTF and ImportAsRTF are defined in svx. But
MSVC does not allow to mark the class as SVXCORE_DLLPUBLIC and the two static
member functions as SVX_DLLPLUBIC, so move the two functions out of the class.
(There appears to be no real necessity that they were static member functions in
the first place; they don't even need to be friends of the class. Nevertheless,
this mixture of functionality from svxcore and svx in include/svx/svdotable.hxx
may ask for follow-up clean up, one way or another.)
All the output lines that need rewriting (all the @svxcore@@ ones, and the
manually picked subset of @@@ and @svxcore@svx@ ones) are copied into a new file
CHANGE (containing 451 lines). Then
> sed -E -e 's|^@.*@.*@ ([^:]+):([0-9]+):.*$|sed -i -e "\2 s/SVX_DLLPUBLIC/SVXCORE_DLLPUBLIC/" \1|' <CHANGE >COMMANDS
> . COMMANDS
to do the changes.
Change-Id: If9b6dd1c9e9ba2eb883dbdac4385d28c6fc8a203
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87794
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Mainly fixing '....' and '..'
Change-Id: Ic928701b319868671b826d757dd94c296fd5e942
Reviewed-on: https://gerrit.libreoffice.org/78668
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|