summaryrefslogtreecommitdiff
path: root/include/basegfx/utils
AgeCommit message (Collapse)Author
2025-01-03Drop unneeded forward declarations from include/Gabor Kelemen
test drive the new bin/find-unneeded-includes --fwdecl mode Change-Id: I507fa2b172ec9e348d1d91066ea241f02187b5ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179321 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-07-16CairoSDPR: Direct support for RGBA Gradients (I)Armin Le Grand (Collabora)
Detect where created when a RGBA gradient could be used directly and create a primitive representing that, a PolyPolygonRGBAGradientPrimitive2D. That primitive decomposes to what was created before, so no primitive renderer has to be touched, all will work as before. NOTE: That helper primitive just holds references to what would be created anyways, so one depth step added but not really any additional data. This is the 1st step for direct support, the 2nd is to then detect and use that primitive in SDPR implementations directly. Change-Id: I4f247636ce58a8a1fd1e0df32dabed0d6cc10d0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170527 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-07-12Make SystemDependentData mechanism type-basedArmin Le Grand (allotropia)
Up to now that genereal buffering mechanism used typeid.*hash_code to identify the class. As we have learned this is not safe. Thus I changed it to use enum'ed SystemDependentDataType definitions Change-Id: I803912ec419290db1d40bae0bc41364fad64cbfd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170385 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-07-02SDPRCairo: enhance CairoPixelProcessor2DArmin Le Grand (Collabora)
Added and corrected quite some stuff to this basic construct provided by Caolan (thanks again!). No detailed descriptions here, but it's getting more complete and faster. May contain errors and is primitive-complete in the sense that all gets rendered, but some basic stuff that should be directly supported is still missing, e.g. text rendering. Adding this to allow people to check it out (speed) also since it's not yet used as default in master, so it's safe and also safes the changes publically. To test it, use TEST_SYSTEM_PRIMITIVE_RENDERER as set EnvVar in linux systems. Change-Id: I25f795c9ea4ad4f3b99591304f8803dffa499436 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168911 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-03-26loplugin:finalmethodsNoel Grandin
create a plugin that finds methods we can mark as final because they are not override in subclasses. Which is useful both as documentation (telling you that you don't need to worry about subclasses changing the implementation under you), and for performance, letting the compiler elide virtual calls in many cases. Apply the results to a subset of stuff in /include Change-Id: I7b5cc893ec2f343bc356bfc338e4cf531ffba1e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165054 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-23tdf#157664 Drop redundant operator != in basegfx moduleRMZeroFour
As part of the efforts in #157664 to remove redundant definitions of operator!=, to upgrade the codebase to C++20, this commit removes the remaining definitions in the basegfx module. Change-Id: I19f2b9ddf42185435313445c8395a851030e2149 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165199 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-02-13fix windows --enable-mergelibs buildNoel Grandin
after commit b663d94cf67a5af4fd89c1ac8bdffd6059f6bf85 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Mon Feb 5 08:50:24 2024 +0200 create --enable-mergelibs=more Change-Id: Ib9f0b3b28df70a9bab10d9bb0aa77a2b2decc616 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163308 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-12use more UNLESS_MERGELIBSNoel Grandin
Change-Id: I351a9127fb26369d8f598b6d6519d7e490fa476b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163190 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-09-21tdf#146619 Recheck include/basegfx with IWYUGabor Kelemen
Change-Id: I08dad6ceeaa9e5470491c09f06d819c4c27ec5f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156983 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-08-21move BGradient to awt::Gradient2 UNO conversion into docmodelTomaž Vajngerl
This is needed because the module dependencies are an issues if the conversion is done in basegfx. The bigger issue will come when the ComplexColor conversion will be done as basegfx can't depend on docmodel because of circular dependencies. The BGradient is also more suitable for docmodel anyway as the previously it was part of the model and is not a basic (gfx) type - however this doesn't move the whole BGradient into docmodel yet. Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-07-13basegfx: replace typedef with a class B2ISize based on Size2DTomaž Vajngerl
Change-Id: Iaf7d02bb236f81a38a67a1430a718b6c3c78efae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139708 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-09MCGR: tdf#155479 repair gradient SVG export for MCGRArmin Le Grand (allotropia)
Unfortunately SVG export is based on metafiles and thus there is (in principle) no way to get the BGradient/ColorStop/MCGR data transfered as needed. For that, using UNO API to read the model or using B2DPrimitives would help - as is better for the export respectively. Since there is not the time to re-design SVG export I added this 'compromize' as a fix. It gets the needed data transported over the metafile (that part is the compromize). It then exports the MCGR data to SVG (at least - as was already there - if it's a linear/axial gradient). This happens now with all Gradient Stops when there is a MCGR gradient. That part is/will hopefully be re-usable if SVG export gets redesigned. I also added a handling for StepCount feature, so when used (in LO, others do not have that) 'hard' color stops get generated to make the gradient look identical for SVG export. Had to make adding of that extra-information in metafiles dependent on exporting really to SVG. There are 51 cases which use 'MetaActionType::COMMENT' which would potentially have to be adapted. Also added code to solve the problem for TransparencePrimitive2D at VclMetafileProcessor2D::processTransparencePrimitive2D. This will now - also only for SVG export - directly create the needed MetaFloatTransparentAction and add additional MCGR information. This will be used on SVG export to write a 'Mask' as was done before. This is now capable of creating fill MCGR-Masks in the sense that any number of TransparencyStops will be supported. Change-Id: Ic6d022714eae96b8fbc09e60652851ac5799b757 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152623 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-05tdf#155549 MCGR: Recreate 'axial' from symmetric 'linear'Regina Henschel
When exporting a shape with an axial gradient fill to OOXML, it is converted to a linear gradient with multiple color stops. Versions before MCGR had recreated it as axial gradient on import from OOXML. But now LO is able to handle multiple color stops and so the linear gradient from OOXML is imported as linear gradient in LO. When such file is then written as ODF, the multiple color stops are in elements in extended namespace and versions before MCGR do not understand them. They show only the first and last color (which are equal) and the gradient is lost. With this patch LO converts the linear gradient back to an axial gradient on export to ODF. The exported axial gradient is rendered in a version with MCGR same as the linear gradient when opening the OOXML file. The difference is, that versions without MCGR now render an axial gradient with two colors. Change-Id: I2b416b4cdca75d8327107a4f259d63c2e6e97ac3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152574 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-05-31MCGR: Use tryToRecreateBorder for better BW comp with LOArmin Le Grand (allotropia)
For better compatibility with LO versions before MCGR, try to re-create a 'border' value based on the existing GradientSteps. With MCGR we do not need 'border' anymore in quite some cases since no Start/EndColor at 0.0 resp. 1.0 is explicitely needed. Since we (unfortunately need to) internally continue to support border anyways it does no harm to fallback to use the border value - if there is an equivalent representation as this helper checks for. For exports that do not support 'border' this will be adapted as needed (see tryToApplyBorder()) Change-Id: If98c64039ff97143d4b5c92ac2a950e70f5bb70a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152395 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-26Fix typoAndrea Gelmini
Change-Id: I7d6dd38b15df7e18775bc94a64aec215d2106c46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152307 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-26MCGR: Border restoration supportArmin Le Grand (allotropia)
Due to tdf#155362 I added code to be able in case we would need it to convert a BGradient using added tooling from having offsets in the GradientSteps and no border to adapted GradientSteps and border. This is preferrable due to our GradientStyle_RECT (and GradientStyle_ELLIPTICAL too) use that 'non- linear' paint aka move-two-pixels-inside, someone else called it 'frame-paint'. This does not bode well with the border being applied 'linear' at the same time (argh). Thus - while in principle all is correct when re-importing a GradientStyle_RECT with a border after export to pptx, it looks slightly better ('correcter') wen doing so. That is because when being able to and restoring a border at least that border part *is* applied linearly. I took the chance to further apply tooling, move it to classes involved and instead of awt::Gradient2 use more basegfx::BGradient since it can and does host tooling. This is also a preparation to be able to adapt (restore) border in case of turn- around in ODF where the importing instance is before MCGR existance and has to handle Start/EndColor. Needed to take more care with using BGradient instead of awt::Gradient2 for initialization, also better dividing/organization of tooling, already preparation to use for other purposes. Change-Id: I2d3a4240a5ac6fff9211b46642ee80366dc09e3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152194 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-19MCGR: Adaptions to WriteGradientFill and BGradientArmin Le Grand (allotropia)
Added code to make WriteGradientFill directly use the available BGradient implementation. The goal is to never directly work on awt::Gradient2, but use BGradient & it's tooling methods. Added constructors and tooling to BGradient and BColorStops to make that easier (single line conversions between uno::Any, basesgfx classes and awt:: incarnations). Directly handle uno::Any and awt:: classes, changed stuff to make use of this. Change-Id: I083a323b9efee8ca4f3becb2966aac0a294b9a60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151842 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-16Fix typoAndrea Gelmini
Change-Id: Ibbf9a267bbfba02c119fa1995c6b2ae90f391031 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151813 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-16Fix typoAndrea Gelmini
Change-Id: Ibb3cbd37e04beed410c61f93f35be51a59bdc10b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151808 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-16Fix typoAndrea Gelmini
Change-Id: I126f38c126c3f541d451cdafa074d2b8c0248d05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151815 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-15MCGR: consolidations/cleanups for changes so farArmin Le Grand (allotropia)
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-19MCGR: 2nd corrections/adaptions to MCGRArmin Le Grand (allotropia)
Adapted handling of 'border' argument from our gradients for oox export, so that it looks the same. Also added quite some cases to peserve in-between GradientStops for current UI implementations to be able to edit the gradients as usual without losing the in-between GradientStops. While we will not be able to modify these, we are at least able to modify all the other gradient attributes, including start/endColor. Done this for TransparencyGradients, too. Also moved more stuff to the gradient tooling in basegfx. Change-Id: I6e94011bbf3715baa1401ab97e5b59811298342f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150577 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-14Fix typoAndrea Gelmini
Change-Id: I59de66225912c4a5ebf257ee47b29d20c23649af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150402 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-14Fix typosAndrea Gelmini
Change-Id: Id3dd5a8386906b0b17a0c5934381782ecb7cd25a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150404 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-14Fix typoAndrea Gelmini
Change-Id: I9ba81b030e6ed0ebb6207a0124a52ec8a38de832 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150405 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-14Fix typosAndrea Gelmini
Change-Id: I2b087d0f97c675cfedd4e2e78c7f827df4605fb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150407 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-14MCGR: Adaptions to oox exportArmin Le Grand (allotropia)
This is a 1st version and might need more fine-tuning, so it is still 'hidden' behind the MCGR_TEST env var being set (as the import is, too). Still, when used, it can now import a MCGR with transparence and export it again. I will now do extended testing/experimenting, fine-tuning where needed and prepare final change/drive forward. The current state in master should not be changed as long as the mentioned env var is not set, but this will need to be checked, too, due to changes to the export api in oox. Corrected an error in GetAlphaFromTransparenceGradient method(s), css::rendering::RGBColor is [0.0 .. 1.0] Corercted an error in WriteSolidFill where transparence gradient gets checked. This should really check if TrGr is used, but only checks for 'empty/unused' color instead (assuming COL_BLACK is 'unused'). All usages of GetAlphaFromTransparenceGradient should be checked and adapted. Change-Id: If59d7a06b9207e2efe9e71f3f8ddeca4476408f3 Change-Id: If97f8abdd0e1597aa1fd865b7e884e06a22b71f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150391 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-04MCGR: Improve performance for texture-mapped MCGR processingArmin Le Grand (allotropia)
Change-Id: I20b32e7c272112c6c3d9f7ee0ef59c6d4d006d94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150020 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-03Fix typoAndrea Gelmini
Change-Id: I49fe9dbdc11291c02be1dd5e41171a987d896008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149997 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-03MCGR: Unify Gradient intensity handling in toolingArmin Le Grand (allotropia)
Moved the Gradient intensity handling to tooling since it is also needed for TransparencyGradients. Added missing use of GradientStepCount for transparency. Change-Id: I63ae6683fa0131be7faadc8572e19f5c43bf27e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149957 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-02MCGR: 1st additions to OOXML MCGR importArmin Le Grand (allotropia)
This change provides 1st changes to get Gradients with muti color stops imported from MSO in the oox import filter. It supports currently multiple ColorStops and transparency. Also 'border'(s) should work, but -remember- this is work in progress. Since it is work in progress it is currently and temporaily secured by ENV VAR "MCGR_TEST=0", so when not using this the master version will not be touched at all. The number defines various ColorStop tests, 0 for none, but some changes are active, e.g. MSO import. You may try 1 or 16 to see all your Gradients hard replaced by something using that feature. I will take care fo cleaning this up again when the feature progresses/gets complete. Change-Id: I92e10d8cd5150733741a6def20a542abf97bd903 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149682 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-21MCGR: Model data changes for ColorSteps (II)Armin Le Grand (allotropia)
The biggest change here is to allow multiple ColorStops with the same Offset. That allows to define gradients with 'hard' color changes at any place using two ColorStops with the same Offset and different Colors. This required quite some adaptions, but works well. Also removed in this context checking for all Colors being the same to not mix up things. Also works well. Also changed the need for having Start/EndColors AKA ColorStops for 0.0 and 1.0 in place, instead 'imply' the 1st ColorStop to also define the StartColor and the last one the EndColor. This allows e.g. Gradient definitions with two GradientStops at the same Offset e.g. 0.5 with different colors to already define a full Gradient. Also added a tooling method to reverse ColorSteps, which changes the order and mirrors the Offsets (what even keeps an existing sort valid). This is useful e.g. for GradientAxial which is the only one where for decomposition the Gradient had to be interpreted 'reverse' since it's defined from center to edge, but for creating correct filled polygons to represent this the inverse order had to be used, creating polygons from edge to center. This led to 'wild' code for this one of six cases and prevented unifications with the other cases (also made your brain flip). Thus I adapted this now to use the reversed ColorSteps consequently, and the same principle loops than the other implementations to make things easier for the future and to use common tooling. Change-Id: If2943348d17d5b9cd165f4d78f22638a1dff5237 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149208 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-19MCGR: Model data changes for ColorStepsArmin Le Grand (allotropia)
Added tooling replaceStart/EndColor to allow simple transition for code that does not immediately adapt to multi color gradients. Also added createColorStepsFromStartEndColor for the same purpose. Adapted XGradient to no longer have Start/EndColor at all, but only use ColorSteps. Adapted all usages of XGradient to no longer use Get/Set/Start/EndColor, but access the ColorSteps instead. Replaced quite some XGradient constructors that used XGradient() as Start/EndColor since this is already the default. Adapted ColorBlending to black AKA Start/EndIntens in XGradient to work now on all ColorSteps in the required linearly-scaled manner. UNO API changes: Added com::sun::star::awt::ColorStep as basic data element that holds a pair of Offset and Color. Added com::sun::star::awt::ColorStepSequence to handle an array of sorted entries. Added com::sun::star::awt::Gradient2 derived from com::sun::star::awt::Gradient, extended by the needed com::sun::star::awt::ColorStepSequence. Added MID_GRADIENT_COLORSTEPSEQUENCE to UNO API to provide access to ColorSteps directly. Adapted XFillGradientItem::QueryValue/PutValue to make use of new UNO API data structures. To do so, added tooling methods for data transition: - fillColorStepSequenceFromColorSteps - fillGradient2FromXGradient - fillColorStepsFromAny - fillXGradientFromAny and adapted - case '0' (all data) - MID_FILLGRADIENT - MID_GRADIENT_COLORSTEPSEQUENCE - MID_GRADIENT_START/ENDCOLOR to make use of these. Tested usage of these in the office. Renamed from GradientStep to GradientStop after discussions with members on the list to make this closer related to other norms/definitions. Also renamed classes and class members to better reflect to GradientStop, so grepping/finding will be easier (e.g. 'Color' just exists pretty often, but 'StopColor' is more precise). Changed the used UNO API class for reprsenting the Color to better reflect to ranges [0.0 .. 1.0] and usage of RGB. Change-Id: I1eeb3e97e81d6785967615d1ff256551fc3b882d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148849 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-05Fix typoAndrea Gelmini
Change-Id: I1392e8e20e42b13a28b13bd611eedccf7b9c088f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148262 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-04MCGR: ColorSteps handling moved to toolingArmin Le Grand (allotropia)
Due to the fact that handling of a vector GradientSteps will get used more often with ongoing changes I moved some handling to tooling, see sortAndCorrectColorSteps. That method sorts and corrects a vector of ColorSteps so that only valid entreis remain in a sorted order, for details please refer to the docu at function definition. I took the occasion to rearrange that to work on the single provided vector which is better for speed & ressources. Also changed the ColorStep constructor to not automatically correct constructed entries: While that is formally correct, it moves an invalid entry to 0.0 or 1.0, thus creating additional wrong Start/EndColor entries. Those may then 'overlay' the correct entry when corrections are applied to the vector of entries which leads to getting the wanted Start/EndColor to be factically deleted, what is an error. Also rearranged FillGradientAttribute to now work initially with ColorSteps, no longer requires the Start/EndColor, also adapted all usages. This securely allows start/end and in-between single-color sections in gradients. Also needed to re-formulate GradientRect & GradientElliptical ::appendTransformationsAndColors method for correct 2D mapping(s) - always incrementing from the start to end conflicts with the adaption of the start value for the inner loop mainly because increment is at start of inner loop (pre-increment). Corrected errors from clang plugin, but also some wrong initialiations for basegfx::ColorSteps. Change-Id: I292592ed9abcfa591f68a680479f4fcdda46cbeb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148196 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-22MCGR: Adapted GradientLinear to make use of MCGRArmin Le Grand (allotropia)
Added to make GradientLinear work using the MCGR as 1st of six types. Had to do quite some tickeling to get it all work, but looks good. Five more to go, already started to put some things to tooling to make re-usable for the other types. Besides adapting this the main change is that the adaption of defined step-count (versus automatic) has to be done in modifyBColor now instead of the back-mapping methods (e.g. getLinearGradientAlpha). It is still 100% backward-compatible, so as long as there is no source using this it will stay invisible - by purpose. I started to do quite some tests (and fixes/ adaptions in consequence), see the static variable nUseGradientSteps. If you want to play with this, you might set it to '1' instead of '0' and use a linear gradient on an object. Change-Id: I9d61934defb0674456247f2879f0a89b6a5e50f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147413 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-15MCGR: Add GradientSteps to GeoTexSvxGradientArmin Le Grand (allotropia)
Move GradientSteps data to GeoTexSvxGradient and adapt interfaces. Also move tooling to more isolated place in gradienttools in basegfx. Keep everything still compatible, the work will be now to adapt all six different derivations of GeoTexSvxGradient to make use of the evtl. given GradientSteps. Change-Id: Iaa212763c603d46de0a94b1b203b979bb7ce359d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147050 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-05Revert all the recent loplugin:unocast changesStephan Bergmann
...as obsoleted by ef533553559fe09b4afab651fc692885d1acf4ed "Rudimentary support for dynamic_cast on UNO proxy objects". This reverts all of: 4cfcc9ac37b90ce64c8402a41eb4638adb185b5c "loplugin:unocast (framework::Desktop)" 03efbf72f4ddf7a84aa8aabef348331bd4b75e8a "loplugin:unocast (vclcanvas::TextLayout)" 80099fdd51a69eaa6c36ca88ef772810e4a777fa "loplugin:unocast (SalGtkXWindow)" cc147f576d8687fb79c77d47d41dc4ba1678a469 "loplugin:unocast (sdext::presenter::CachablePresenterView)" 40db42be1d8fd0f9c6c8c5ba3767ddb9ee2034c2 "loplugin:unocast (vclcanvas::CanvasFont)" 2d1e7995eae29e2826449eb5179f5fae181794a5 "loplugin:unocast (CairoColorSpace)" 4c0bbe4bd97636207cf71a6aa120c67698891da9 "loplugin:unocast (canvas::ParametricPolyPolygon)" 89803666621c07d1b1ac9d3bd883f0ca192a91a0 "loplugin:unocast (vclcanas::CanvasBitmap)" d5e0c2c8db71878d21c2a7255af08cf5f9a6dd04 "loplugin:unocast (sfx2::DigitalSignatures)" c0c4519e0d5b555f59bbc04cc616454edfd1f4ce "loplugin:unocast (VCLXAccessibleComponent)" feb8b833a6245d42400f42a0bc789dc84594ee6f "loplugin:unocast (VCLXDialog)" 1fa58cc6cc9c3849753342a5d9a6ddfa461b5e66 "loplugin:unocast (VCLXMultiPage)" f481f036deb1b1b46f3038074c4659f3a91b9c6c "loplugin:unocast (DocumentSettingsSerializer)" 73df933f5fa5932f94e5a1b338a3eda00a9ce354 "loplugin:unocast (css::embed::EmbeddedUpdate)" 420165ab0ef03c0467f9d17f504de2d2fc78f0e6 "loplugin:unocast (canvas::tools' StandardColorSpace, StandardNoAlphaColorSpace)" 9abe8ee067e6c00f19d8a13346d53c4641c27166 "loplugin:unocast (MutableTreeNode)" 9f3022ceb036f23b4b0994c3e2fbd1001bff225a "loplugin:unocast (VCLXTabPage)" 1be70dda02c12a60778b7607cff2520ae1aa611e "loplugin:unocast (vcl::unotools::VclCanvasBitmap)" d6a70bb641b96e8e5616448c2378131ed62658b4 "loplugin:unocast (basegfx::unotools::UnoPolyPolygon)" 5a14f009e6782c077463c8cbb8e9cea3d7950107 "loplugin:unocast (xmlsecurity::Certificate)" 99009c9535dfa3e0d838989ccc7d84bfa2320ff4 "loplugin:unocast (sd::Annotation)" 0c7585c5fa78887e5459885ed744e8044fd76137 "loplugin:unocast (sd::TextApiObject)" 24e14afd1bfcaed6c200ab081973fba7e47267ca "loplugin:unocast (SignatureVerifierImpl)" 1a7ad0c10d286ce9ae2700ceb2fd50eed1fb43a4 "loplugin:unocast (pcr::PropertyEventTranslation)" a97e2d2702d9a6f37775ccee2c08c4f3b2479c4b "loplugin:unocast (RangePageBreaks)" 19dfdf86ad1f5b08041d8b7a9f196caf881231ab "iloplugin:unocast (pcr::OFormattedNumericControl)" f9785ea595fd8e911f6370e836fa579225b9e571 "loplugin:unocast (frm::OInterfaceContainer)" 5e5f40a4a92a31b0932c690219d002fcf18598cf "loplugin:unocast (ScVbaShapes)" 27b35b2c215b4832d4378ec3a7ecbba926552d06 "loplugin:unocast (ScVbaShapeRange)" cb3108f860065928552a86cf8acc4b3a95718ecf "cid#1517812 Dereference null return value" feba0ddb1521d1142560fe54b7d7696ee910237f "loplugin:unocast (weld::TransportAsXWindow)" 4d6c23216559eb48f9943bb49d6e475a6d64ba15 "loplugin:unocast (oox::ForumlaImExportBase)" 4844c096a8ab6a9a620c410a0949d4499f12a504 "loplugin:unocast (cairocanvas::SurfaceProvider)" 9a0b523e0a84d403b9092176ccec4b3e3efe42d0 "loplugin:unocast (cairocanvas::CanvasBitmap)" 8a5648d8e59b4b007dbbf3824777c19a21efc61e "loplugin:unocast (cairocanvas::TextLayout)" 28c27a0623bc78a0590858f97d03b620985bc84c "loplugin:unocast (cairocanvas::CanvasFont)" 53bc223cb3288e32a417696ee61c29e5f01f209d "loplugin:unocast (cairocanvas::RepaintTarget)" 5f70b0b9f6bc4ab145ddbd9155590ed4a3b1b9ec "loplugin:unocast (SvXMLImport)" 068187a898cdd2e26e9b16c348ecc1ed2dee3f29 "loplugin:unocast (VCLXWindow)" 88b4f966202717cd4ad38a30a8eda22c3e69ed35 "loplugin:unocast (sfx2::sidebar::SidebarController)" f1b7a69b280aefe2f1b3b0f32193494fd765f2bd "loplugin:unocast (SvxLineStyleToolBoxControl)" ba76f0ba7e8de4d2953739c952004b7d9af47197 "loplugin:unocast (i18npool::Calendar_gregorian)" 840154daf934d8df52ead1cb7acd798c4d30f007 "loplugin:unocast (framework::AddonsToolBarWrapper)" b0e9c4c5f063cefa9557810e3349bdb9c7493091 "loplugin:unocast (GrammarCheckingIterator)" 8ee6cfc9655ce9de4617cea1a0d9cb9d7a4fbfac "loplugin:unocast (ucb::ucp::ext::Content)" 5b8cd77c112bc8c0e92b8fec215c3c8e802bbc0a "loplugin:unocast (basic::SfxScriptLibraryContainer)" 9e73ff9fce12e102bb3c3cea8d8bb96c88f2c9ad "loplugin:unocast (sdext::presenter::PresenterNotesView)" a98acca8fbc38d3fd5600ae5056a8e42b6d8a40d "loplugin:unocast (SelectionChangeHandler)" c0b59ad6e35b0cb0dea0821e95f95569739078c1 "Consistently use comphelper::getSomethingImpl<I>(aIdentifier, this)" 276e3ccbdd3259ec3daf8a1a98fa7f406b14e21c "loplugin:unocast (vclcanvas::RepaintTarget)" Change-Id: I37c73e3422a5154bf6cb647640d2d3f23db8bc34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22loplugin:unocast (basegfx::unotools::UnoPolyPolygon)Stephan Bergmann
(See the upcoming commit introducing that loplugin:unocast on why such dynamic_casts from UNO types are dangerous.) Change-Id: I166d8f31a13a98caf0bb7a3b5025a9d942808096 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144746 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-19Allow read-access to CombinedHoldCyclesInSeconds for checksArmin Le Grand (allotropia)
Change-Id: I2685343bd5e0e7c10438274c0a38798e09d813e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141530 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-11basegfx: replace typedef with a class B2DSize based on Size2DTomaž Vajngerl
Change-Id: Id8b3c2bcf0bf4be5aba2812b0edda479bc20c6a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139683 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-07-13basegfx: zoomIn() and zoomOut() should be sal_uInt16Chris Sherlock
All zoom functions use sal_uInt16 values. For some reason, basegfx used long when zoomIn and zoomOut were created in 2012 (see commit 315d2ddc16: "optimized zoom to use more common intervals"), this then got mass converted to tools::Long in commit 387a88fa25: "use tools::Long in basegfx..chart2". So fix is to change zoomIn/Out() to use sal_uInt16. Change-Id: I2a56d6f58e14f77aeb8741d332fe9bc282eb969f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135715 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-05-27clang-tidy modernize-pass-by-value in basegfxNoel Grandin
Change-Id: I1ec34b2f0e9869a82894795f1d6351189ae92d9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135043 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-26Use o3tl::make_unsigned in some placesStephan Bergmann
...where a signed and an unsigned value are compared, and the signed value has just been proven to be non-negative here Change-Id: I9665e6c2c4c5557f2d4cf1bb646f9fffc7bd7d30 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133442 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-12-27use comphelper::WeakComponentImplHelper in UnoPolyPolygonNoel Grandin
Change-Id: I82248cfbb0cbdb765fa2f97f53e8990a9e05a28b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127547 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-01improve the script for reducing symbol exportsNoel Grandin
And apply some of the results Change-Id: If555476fdd951cbc1d01fb3ef3ab1cbca2b64960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124896 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-06loplugin:moveparam in basegfxNoel Grandin
Change-Id: I68d0de099641ae5b2ae92f46e86bdf4a43c468a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123141 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-27clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: Ibeff6e5cbc20ab86b1e9cb96292acb340849ede3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121149 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-09Recheck include/ with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: Ifc253bf800bb1468b5774663a93f4fb30bec81d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113657 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-21tdf#123936 Formatting files in module include with clang-formatPhilipp Hofer
Change-Id: I0507dd797cd5a35e0ae14f4b69ee4e172d08a71a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105681 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
generated by cgit (git 2.34.1) at 2025-01-18 12:08:38 +0000