Age | Commit message (Collapse) | Author | Files | Lines |
|
* Py_DontWriteBytecodeFlag is deprecated now, replace it with
PyConfig.write_bytecode
* setuptools and pip are no longer available by default on mac.
Get them from the wheel files the same way linux and windows do
Downloaded from https://www.python.org/ftp/python/3.12.11/Python-3.12.11.tar.xz
Change-Id: Id1043671d8fbb6b3bfa39afbf6aedd634c92c5f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181785
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
in order to simplify code.
The flexibility provided by the ConfigurableSettings template
is not really necessary for the simple settings VCL has
Change-Id: I95827072b5c78b8b66d3101b0176d8ed5f85b626
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185172
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
these are only used in a single place
Change-Id: I9aae2331bc22e7ac842870a6b27030fc57c01b08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186591
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
* Update helpcontent2 from branch 'master'
to 816edd055384c3e5549e0d836e79a9d4b4375425
- Enhance visual of keyboard keys in text
Make them italic to differentiate from surrounding text.
Change-Id: Ie95bf8d5c810aa730973b965cb9a52617fed56d5
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/186624
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Jenkins
|
|
* Update helpcontent2 from branch 'master'
to 0b01d11acd9ae23138af0d718b52295e5af682dd
- Revisit Calc shortcut keys
+ Add Ctrl+Shift+X for .uno:CopyDelete command
Change-Id: I7d7de774cd4108f7b46d3a180b8a32b691857b6c
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/186623
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Jenkins
|
|
SwXTextField must for the "SourceName" property convert from ProgName to
UIName on setting and reverse on getting, for consistency with the rest
of the sw UNO services.
This is annoyingly complicated because the "sPar1" of SwGetRefField is
used for numerous other purposes, including a bookmark name.
Revert writerfilter changes of commit 80877c7dc467bf5ad6b28ec1b2662db36fcf7542
but keep the test.
With de_DE locale we now get "Überschrift 1 (user)" cloned style (same
as the reverted fix), and exported to ODF as "Überschrift 1"; the ODT
works when loaded both with the same and a different locale.
Unfortuantely an ODT created by versions on the 24.2 branch >= 24.2.4,
which used to work being loaded in the same locale but not in a
different one, stops working when loaded in the same locale with this,
so add an incredibly ugly flag to SwDoc because no SvXMLImport etc can
be accessed from SwGetRefField.
Move testTdf160402 to the new ooxmlexport26 because it also failed with
de_DE locale.
(regression from commit e45f187870362ed4448f4a9fb96883b8431887fb)
Change-Id: I6b7862f142d602544165d8b5a254bf8af28e527b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186228
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Filter name is "trackchanges". Returned are "TrackChanges.ByIndex.N"
numbered JSON nodes with these fields:
* "type": string ("Delete", "Insert", "Format")
* "datetime": string (ISO datetime stamp)
* "author": string
* "description": string
* "comment": string
* "text_before": string (up to 200 characters)
* "text_after": string (up to 200 characters)
Change-Id: I467bb9989d2eb461c74f50b53e039c1b2260e74c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186579
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186608
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
All the replaced code did the same repeatedly.
Change-Id: Ife04ba174a3c40811c82e7a522205acc513c0d21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186607
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Regression from commit 57d9cc81b058757421cd082e5dbe32a919716807
(tdf#127806: RTF import: use shape dimensions for pib picture,
2022-09-01), open the bugdoc, the icon image inside the shape should be
about 0.37cm x 0.37cm, is about 14.98 cm x 12.66 cm.
What happens is that \pict was assumed to be inside the property value
of a shape, in which case both the shape and the picture can have a
size, and the old use-case requires to ignore the inner size. The new
use-case is two user-visible shapes: an outer text frame and an inner
small icon image, inside shape text. The different sizes are wanted in
this case.
Fix the problem by conditionally going back to the old behavior of not
inheriting size for the inner shape. The name of the destination at the
top of the parser stack is different for the "in property value" and the
"in shape text" cases, so this keeps the old use-case working while
restores the wanted small size for the new use-case.
Here the difference between the old and new size was so large that the
end-user saw this as "the image was not visible previously".
Change-Id: Ife93089b967fc26b7180775db8fc507a896d160b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186602
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Need to remove all elements from entries before building up and populate the
new issues. Otherwise we will have multiple elements.
Change-Id: I3a391b8ccf91f14d8650861c39bc3561af6282ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186571
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
* 0001-parser-Fix-custom-SAX-parsers-without-cdataBlock-han.patch.1
has been fixed upstream
Downloaded from https://download.gnome.org/sources/libxml2/2.14/libxml2-2.14.4.tar.xz
Change-Id: Icd9ab0d96e8d9299716a16a967c424a565264d68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186601
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
We added some improvements for copying the comments along with their replies before. Which is done with commit:
* https://gerrit.libreoffice.org/c/core/+/177396
But it somehow broke docx export, when there are comments in file.
TextNodes are copied while loading the document. And the error seems to occur in this phase.
This commit keeps the previous behaviour while loading the file.
Signed-off-by: Gökay Şatır <gokaysatir@gmail.com>
Change-Id: I80c343cbc4886f4277e38ff23553195cc8b1acfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186043
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186605
Tested-by: Jenkins
|
|
Change-Id: If15f7d7b7fde570914cd9a15a395e5ef272eba4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186589
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Tab labels renamed to align with templatedialog*
Change-Id: I02ad8930b832575bd96e6c1e68932cbad5abc7e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186534
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
ever since
commit bfb8706466b52298def33d47d31b6efffc3ed531
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Jan 25 10:09:55 2023 +0200
no need for sd::ModuleController to load these factories via UNO
Change-Id: I5d912d2bc41e7fd1991d88d1e887d9ee27769bc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186585
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id6616fac101cdcad0c7330b948e209c3905d993d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186590
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It is advertised as a property, but it's not implemented: just avoid the
assert fail on inspecting the UNO wrapper.
Similar to commit 8d7272141f56935a7fbd629706bb4fefb7d3ba84 (sw: add stub
Title impl for SwPostItField, 2024-11-27).
Change-Id: Iecb54aafe93553d968296891c2f4136f9b50ce15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186573
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The user can now pass the available options
for each graphic type to export.
For example:
$ instdir/program/soffice --convert-to 'jpg:calc_jpg_Export:\
{"PixelWidth":{"type":"long","value":"1280"},\
"PixelHeight":{"type":"long","value":"1024"},\
"Quality":{"type":"long","value":"8"}}' --outdir /tmp Calc.ods
Change-Id: I77211805f4fd726da7d5fb0818ac422c3e9b6c96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186287
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
ever since
commit cb32938d572777c9a5d75007cc76ba50c5a698eb
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Fri Jan 20 18:33:34 2023 +0200
[API CHANGE] remove unused SlideSorterService
Change-Id: I1daf8c7dac985810a96b31c9ed5b1ba0f1245899
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186583
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since the console code is now inside sd/, we dont need this
anymore.
Change-Id: Ic663c148a641297b1e935aa7f5e245643ebc1157
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186569
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* Update helpcontent2 from branch 'master'
to b19ed0b137935eef1927fdb040fa783a9fc79df3
- Fix Text Attributes Help for Drawing Objects
Change-Id: I05baf729d82fc4f842208e8e33029248a1c3e27d
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/186581
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Jenkins
|
|
Change-Id: Ie86ba52ab2e8df66cabe75acaf440b2ca076f4c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186580
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
now that the slide console is not a separate component
anymore.
Change-Id: I21641e4157b8af4d44be91b15bc0b5740311472c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If5cb8de60e3ab64f21a57bb4be2f409cd6d26647
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186564
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
...for loplugin:unoany, loplugin:fakebool, and loplugin:refcounting
Change-Id: Ib3278b126c3ea792c93cbf57f2414fd316278b88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186560
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Looks like it could be the other way round, using GetPoint/GetMark.
Change-Id: Iae95470a5877bdb8eaf05a65db18819dacd26ad4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186553
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Based on the discussion in the bug ticket.
Change-Id: Id15ecf21c4cd2d37956b12b1fec3735501571da5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186416
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
|
|
The bugdoc has <ins>AABBCC</ins> in it, selecting BB, marking the
selection as e.g. bold + undo + redo resulted in a plain format redline
for BB instead of a hierarchical insert-then-format redline.
Checking SwUndoAttr, its item set correctly tracks the boldness, also it
tracks the own (format) redline in m_pRedlineData correctly, together
with the pre-existing redline data in m_pRedlineSaveData. Also, checking
how this works in the undo case, SwUndoAttr::UndoImpl() first deletes
all redlines in the interesting text range and then restores the
pre-existing redline using a call to SwUndo::SetSaveData(). In the bad
case, what instead happens is that SwUndoAttr::redoAttribute() calls
sw::DocumentContentOperationsManager::InsertItemSet() with redline
tracking enabled, that creates a format redline, then we try to create
our own format redline, and the last one wins, losing the underlying
insert redline.
Fix the problem by improving SwUndoAttr::redoAttribute() to also call
SwUndo::SetSaveData() to re-create just the pre-existing insert redline:
with this the following AppendRedline() will result in the correct
insert-then-format hierarchical redline.
Change-Id: I1e1a284c017f39c62dcc03b6b49463bac106f21b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186566
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Added in
commit f2e8141fdb80611dd2c27924ece8edd56e11a332
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Mon Jun 16 10:09:12 2025 +0200
tdf#167023, tdf#167018: sw: Add UItest
Kudos to M. Kaganski for flagging it
Change-Id: If4283d2fa91cb5d3d41a7871b624b83b01bed98e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186563
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Now that the UNO abstraction and corresponding services
have been dropped in
commit 0905c23676fe34a5346683ee46568e4d1c58806a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 13 18:27:09 2025 +0200
Stop using UNO abstraction for color picker
and
Change-Id: I9264707df57e46192a393f6736257c413e5d9831
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jun 16 08:01:55 2025 +0200
[API CHANGE] Drop ColorPicker, AsynchronousColorPicker
, no longer pass a sal_Int16 param to the ColorPickerDialog
ctor, but use the vcl::ColorPickerMode enum directly
without casting.
This also means that there is no more need for the
underlying int values of the enum values to have a
specific value, so no longer set these explicitly.
Change-Id: Ife2a7b0672bacc73b3001ef0e2e57f4626837655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186539
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
The unpublished com::sun::star::cui::ColorPicker and
com::sun::star::cui::AsynchronousColorPicker UNO services
were previously used to be able to use ColorPickerDialog
(implemented in cui) from svtools.
That's no longer the case since
commit 0905c23676fe34a5346683ee46568e4d1c58806a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 13 18:27:09 2025 +0200
Stop using UNO abstraction for color picker
, so drop the now unused services and the ColorPicker
class that implemented them.
Change-Id: I9264707df57e46192a393f6736257c413e5d9831
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186538
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
...so that CppunitTest_services wouldn't fail with
> postprocess/qa/services.cxx:341:(anonymous namespace)::Test::test
> assertion failed
> - Expression: info.is()
> - instantiating "org.libreoffice.comp.embindtest.Test" via "org.libreoffice.embindtest.Test" does not provide XServiceInfo
Change-Id: I83721006bfd8b71b488b15c41e81df9c5d0d755e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186559
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I6c529368e58a04949994a0fa3758fd835738d1f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186529
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icb8123dea4d9b0648069d991a80e178089514e60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It turns out, that these are naturally processed twice.
When enumerating paragraph's content, CollectFrameAtNode would find both
the shape and the shape's text frame anchored to the paragraph node.
Then, XMLTextParagraphExport::exportTextContentEnumeration will process
the shape; and in XMLShapeExport::collectShapeAutoStyles, the shape will
be queried for XText, which will return the text frame, which will then
be processed.
And finally, XMLTextParagraphExport::exportTextContentEnumeration will
process the text frame, for the second time - at which point, the frame's
paragraphs will be processed again.
I don't know if it's possible to avoid the repeated processing; here I
only add a debug check for this, and skip adding duplicate node index.
Change-Id: I84275f233554a6b4923ddaabc336bec7a94ec2fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186546
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
It was left no-op in commit 7ab51def766ad6bfdcf5111e7b751bbc2bbf1d73
(sw: implement "Theme" property for the XDrawPage in Writer, 2023-02-01).
This resulted in the request for the property returning an empty Any;
then export code throwed with this stack:
xolo.dll!cppu::any2bool(const com::sun::star::uno::Any & rAny) Line 105
xolo.dll!XMLNamedBoolPropertyHdl::exportXML(rtl::OUString & rStrExpValue, const com::sun::star::uno::Any & rValue, const SvXMLUnitConverter & __formal) Line 55
xolo.dll!XMLPropertySetMapper::exportXML(rtl::OUString & rStrExpValue, const XMLPropertyState & rProperty, const SvXMLUnitConverter & rUnitConverter) Line 215
xolo.dll!SvXMLExportPropertyMapper::_exportXML(comphelper::AttributeList & rAttrList, const XMLPropertyState & rProperty, const SvXMLUnitConverter & rUnitConverter, const SvXMLNamespaceMap & rNamespaceMap, const std::vector<XMLPropertyState,std::allocator<XMLPropertyState>> * pProperties, unsigned long nIdx) Line 1079
xolo.dll!SvXMLExportPropertyMapper::_exportXML(unsigned short nPropType, unsigned short & rPropTypeFlags, comphelper::AttributeList & rAttrList, const std::vector<XMLPropertyState,std::allocator<XMLPropertyState>> & rProperties, const SvXMLUnitConverter & rUnitConverter, const SvXMLNamespaceMap & rNamespaceMap, std::vector<unsigned short,std::allocator<unsigned short>> * pIndexArray, long nPropMapStartIdx, long nPropMapEndIdx) Line 919
xolo.dll!SvXMLExportPropertyMapper::exportXML(SvXMLExport & rExport, const std::vector<XMLPropertyState,std::allocator<XMLPropertyState>> & rProperties, long nPropMapStartIdx, long nPropMapEndIdx, SvXmlExportFlags nFlags, bool bUseExtensionNamespaceForGraphicProperties) Line 823
xolo.dll!SvXMLAutoStylePoolP_Impl::exportXML(XmlStyleFamily nFamily, const SvXMLAutoStylePoolP * pAntiImpl) Line 683
xolo.dll!SvXMLAutoStylePoolP::exportXML(XmlStyleFamily nFamily) Line 369
xolo.dll!SdXMLExport::ExportAutoStyles_() Line 2207
xolo.dll!SvXMLExport::ImplExportAutoStyles() Line 1122
xolo.dll!SvXMLExport::exportDoc(xmloff::token::XMLTokenEnum eClass) Line 1390
xolo.dll!SvXMLExport::filter(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aDescriptor) Line 814
svxcorelo.dll!SvxDrawingLayerExport(SdrModel * pModel, const com::sun::star::uno::Reference<com::sun::star::io::XOutputStream> & xOut, const com::sun::star::uno::Reference<com::sun::star::lang::XComponent> & xComponent, const char * pExportService) Line 108
svxcorelo.dll!SvxDrawingLayerExport(SdrModel * pModel, const com::sun::star::uno::Reference<com::sun::star::io::XOutputStream> & xOut, const com::sun::star::uno::Reference<com::sun::star::lang::XComponent> & xComponent) Line 43
svxcorelo.dll!SvxDrawingLayerExport(SdrModel * pModel, const com::sun::star::uno::Reference<com::sun::star::io::XOutputStream> & xOut) Line 133
swlo.dll!SwTransferable::WriteObject(SvStream & rOStream, void * pObject, unsigned long nObjectType, const com::sun::star::datatransfer::DataFlavor & __formal) Line 738
vcllo.dll!TransferableHelper::SetObject(void * pUserObject, unsigned long nUserObjectId, const com::sun::star::datatransfer::DataFlavor & rFlavor) Line 912
swlo.dll!SwTransferable::GetData(const com::sun::star::datatransfer::DataFlavor & rFlavor, const rtl::OUString & rDestDoc) Line 612
vcllo.dll!TransferableHelper::getTransferData2(const com::sun::star::datatransfer::DataFlavor & rFlavor, const rtl::OUString & rDestDoc) Line 456
vcllo.dll!TransferableHelper::getTransferData(const com::sun::star::datatransfer::DataFlavor & rFlavor) Line 321
vclplug_winlo.dll!CXTDataObject::renderAnyDataAndSetupStgMedium(tagFORMATETC & fetc, tagSTGMEDIUM & stgmedium) Line 341
vclplug_winlo.dll!CXTDataObject::GetData(tagFORMATETC * pFormatetc, tagSTGMEDIUM * pmedium) Line 261
vclplug_winlo.dll!CXNotifyingDataObject::GetData(tagFORMATETC * pFormatetc, tagSTGMEDIUM * pmedium) Line 102
ole32.dll!HandleFromHandle(IDataObject * pDataObj, tagFORMATETC * pformatetc, tagSTGMEDIUM * pmedium) Line 2049
ole32.dll!RenderCurrentFormat(HWND__ * hClipWnd, unsigned int cf, tagSTGMEDIUM * pmedium, IDataObject * pDataObj) Line 4062
ole32.dll!RenderFormat(HWND__ * hClipWnd, unsigned int cf, IDataObject * pDataObj, void * pvMTADataObject) Line 4196
when trying to export this property as a boolean.
I don't know if there needs to be some change to handle the empty Any
case properly here; but now SwFmDrawPage provides the wanted value.
Change-Id: Id4fa7ff989697aa4329c6c36e0927d95eae8e6e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186533
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I81386e6b6f3052c07be3271cac31eb4194ef0bc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186551
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
|
|
Change-Id: I14d12f6c577be7a47cead8c12c6db8d360e78867
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The error may come not only from stream.
Change-Id: I71f050502381459bc0ee6fc8048790a51b0e1d0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186532
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
See tdf#94879 for motivation.
Change-Id: Ic5df0feeaa57bd4ac34fa6b6bc3e13c5e6145e11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186535
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Not all kind of shape objects were checked for "No alt text",
but only a few one. Let's extend it with the other possible
shape types in this patch.
Change-Id: Id3bcf4992fc8f281ee4a32c569cba3590ae6c002
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186413
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
Change-Id: I2a6576d2d853dd6b34c0ea69287690b462f194e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186504
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Adjust naming following
Change-Id: Iebc3c1172dfd12dbbe72c3a56eeb6eb333d799c5
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 13 18:45:11 2025 +0200
Move SvColorDialog from svtools to vcl
* Rename SvColorChooserDialog -> ColorChooserDialog,
now that the class is no longer in svtools
* Move ColorPickerMode from svtools namespace to vcl
Change-Id: I27e84d6c6e7f7cde35dea31159b01dd1e0d312cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186482
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Now after
Change-Id: I3b9997b73a9a6bcce4c5b3ae3bd7d57816a4419b
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 13 18:27:09 2025 +0200
Stop using UNO abstraction for color picker
, SvColorDialog no longer depends on anything
above vcl, so move it there, which will
help in implementing support for platform/toolkit-native
alternatives for the color picker instead of using
the LO-internal one.
The "Sv" naming prefix will be dropped in a separate commit,
to keep the diff clearer.
Change-Id: Iebc3c1172dfd12dbbe72c3a56eeb6eb333d799c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186481
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
SvColorDialog is using an instance of
ColorPickerDialog under the hood.
So far, the ColorPickerDialog instance was
created and used via UNO abstraction, by
calling either
css::cui::ColorPicker::createWithParent (for the
synchronous case) or
css::cui::AsynchronousColorPicker::createWithParent
(for the async case), which would end up calling
the UNO service ctor,
com_sun_star_cui_ColorPicker_get_implementation
(and creating an instance of ColorPickerDialog
in both cases, just with a reference to a different
UNO interface as a return value for both cases).
Further interaction would then happen via the
XExecutableDialog or XAsynchronousExecutableDialog
UNO interfaces and by setting/reading properties.
Stop using that UNO abstraction and instead
introduce AbstractColorPickerDialog as a new
VclAbstractDialog subclass, which allows to
interact with the the ColorPickerDialog more
directly while still avoiding a direct dependency
on (the higher-level module) cui in svtools.
This also implies that SvColorDialog now no longer
depends on svt::DialogClosedListener for the async
case, which means that SvColorDialog can be moved
from svtools to vcl in the future. That in turn will
help in implementing support for platform/toolkit-native
alternatives for the color picker instead of using
the LO-internal one.
No change in user-observable behavior intended
or seen in a quick test in Writer (open dropdown for
"Font Color" toolbar item, then select "Custom Color"
to open the dialog).
Change-Id: I3b9997b73a9a6bcce4c5b3ae3bd7d57816a4419b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186468
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Move declaration of ColorPickerDialog and related
classes and enums from the .cxx to a new header file.
This is in preparation of creating an instance of
the class without having to go through the UNO
abstraction by creating a service using
com_sun_star_cui_ColorPicker_get_implementation
as SvColorDialog currently does by calling
css::cui::ColorPicker::createWithParent and
css::cui::AsynchronousColorPicker::createWithParent.
Change-Id: I797ab75f5393ceeff65235864b4aca48281a9744
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186467
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Drop SvColorDialog::SetMode and instead pass the
mode in the ctor with a default mode of
svtools::ColorPickerMode::Select, i.e. leaving
behavior unchanged when none is explicitly passed.
This aligns SvColorDialog further with
ColorPickerDialog, which is used under the hood.
Change-Id: I67cc5f0874758e6d0f081666b32290a1d4726b46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186466
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Extract logic to set a color from the ctor to a new
public method ColorPickerDialog::SetColor.
This aligns the ColorPickerDialog API further with
the one that SvColorDialog has, which uses the
ColorPickerDialog under the hood - currently still with
some UNO interface abstraction in between.
Change-Id: I82fb33a86ca8a9c9ec53c18e6fd87a631fae1860
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186465
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Change-Id: I172b37fb05bb9907188653cce32424941a37feca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186464
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
... instead of as a param to SvColorDialog::Execute or
SvColorDialog::ExecuteAsync.
Passing a dialog or widget parent in the ctor is
typical for UI toolkits.
While SvColorDialog currently only creates the actual color
picker dialog in its Execute{,Async} methods, this will change
in an upcoming commit, for which this one prepares.
Change-Id: Ib1ea41cc986577a3e3f1dddfd93a04c2e69bc15f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186463
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|