Stop implementing the XServiceInfo interface in chart2 a11y implementations as the info provided by that interface isn't needed anywhere, see also Change-Id: Id306320710a1718ff10536127427f3a5daf68559 Author: Michael Weghorn Date: Fri Jun 20 11:14:19 2025 +0200 svtools ruler a11y: No longer implement XServiceInfo for more background. Related to that, drop the unpublished AccessibleChartElement service.
See also QtBuilder::insertMenuObject. This will be needed e.g.
Finally, add the comment id to SwPostItField too, so that undo actions can recreate the comment with the same id.
Change-Id: I9e7731b696e3e45903820dd2747ec958c2075e1b Reviewed-on:
This was requested by users of `vf_libplacebo`, to mirror the existing option on the other `vf_scale_*` family of filters.
When it is enabled, most of the editing commands in a read-only view are disabled, as usual; but the commands to manage tracked changes are enabled, and allow user to accept / reject / comment on changes.
our policy is that "mute works on outputs", which means that mute should have no effect on what an instrument plugin does.
This is a subtask of tdf#165742: Chartex charts are lost on input from OOXML and re-export. Fix chartex parsing so as to properly handle series.
- posix/glob.
Refactor the generic implementation to use math_config.h definitions, and add an alternative one if the ABI supports truncf instructions (gated through math-use-builtins-trunc.h).
Refactor the generic implementation to use math_config.h definitions, and add an alternative one if the ABI supports truncf instructions (gated through math-use-builtins-trunc.h).
Reworke SVE FP64 hyperbolics to use the SVE FEXPA instruction.
this is internal to sd, no need to use UNO here
revert commit 39f2c62847b890b6b354bdbc39b9b7aa40542f3d simplify TaskCreatorService and commit 96b6d13c9ad73f946efcb7cfa7ccee3d91b8649c.
For handling transparency for tiled bitmaps correctly in metafiles the newly added linear transparency is too much and leading to many single transprent bitmnaps.
...as seen after 528cdd6573748d01c9d99ca3710a808866281921 "python3: upgrade to 3.12.11 (master only)" at <
so I can remove the overly complex and unnecessary drawing::framework stuff.
which are unnecessary, we already instantiate and use these classes directly.
- Py_DontWriteBytecodeFlag is deprecated now, replace it with PyConfig.write_bytecode - setuptools and pip are no longer available by default on mac.
in order to simplify code.
Filter name is "trackchanges".
All the replaced code did the same repeatedly.
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.
Linux has supported arbitrary speeds and split speeds in the kernel since 2008 on all platforms except Alpha (fixed in 2020), but glibc was never updated to match.
The generic implementaion of cfsetspeed() had an internal table of permitted baud rates, which was enforced even on an implementation supporting arbitrary baud rates.
POSIX requires that speed_t is an unsigned integer type, so change the generic speed_t definition to be an unsigned int instead of a plain int.
Now all platforms unconditionally use the "sane" definitions of the termios baud constants.
Add an explicitly numeric interface for baudrate setting.
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
Only enable the proresdsp check when the prores decoder is enabled.
since the console code is now inside sd/, we dont need this anymore.
Change-Id: Ie86ba52ab2e8df66cabe75acaf440b2ca076f4c7 Reviewed-on:
now that the slide console is not a separate component anymore.
Looks like it could be the other way round, using GetPoint/GetMark.
The bugdoc has <ins>AABBCC</ins> in it, selecting BB, marking the selection as e.g.
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.
...so that CppunitTest_services wouldn't fail with
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.
It was left no-op in commit 7ab51def766ad6bfdcf5111e7b751bbc2bbf1d73 (sw: implement "Theme" property for the XDrawPage in Writer, 2023-02-01).
Change-Id: I81386e6b6f3052c07be3271cac31eb4194ef0bc0 Reviewed-on:
The comment is similar to extended capabilities in the function below.
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.