summaryrefslogtreecommitdiff
path: root/solenv
AgeCommit message (Collapse)Author
2018-12-13Add more missing constructors from chart2/source/chartcore.componentTor Lillqvist
I think it would be better if native-code.py parsed the .component files it is interested in and just copied the constructor names from them to its output? Or are there many cases where it is a carefully manually selected subset of constructors from some .component file that should be put in the generated native-code.h, not all? But even in that case, if some constructor should not be linked in to a mobile app, that could be handled by adding some specific attribute in the .component file. Change-Id: Ib947279610f6755f112d3571512406c5d0cd620d
2018-12-13We need CartesianCoordinateSystem2d for chartsTor Lillqvist
Change-Id: I3edccbe29129f6d60a4ac4627a0ab646e4e42458
2018-12-13loplugin:unusedfields improve write-only logicNoel Grandin
when dealing with modifications to container classes (e.g. std::vector) Change-Id: Ic30043631007355ee9a3d9e3f9b6488b435182d6 Reviewed-on: https://gerrit.libreoffice.org/65050 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-13Switch Android armeabi-v7a to libc++/libc++abi/libunwind tooStephan Bergmann
It had been left out in 4082a18406c18af7b4fcef7bd501c3679c3be56b "android: use unified headers and llvm-c++ STL (x86) with NDK 16" because "arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix that later". Making armeabi-v7a work with libc++ etc. required a number of changes, listed below, in this commit and in preceding ones. At least 32-bit x86 already worked with libc++ etc. prior to these changes in view mode, though it crashed in the experimental editing mode (enabled with strippedUIEditing in android/soruce/Makefile) as soon as one types in something, But it is not entirely clear to me why 32-bit x86 view mode didn't also fail similar to how I saw armeabi-v7a fail. (On 32-bit x86, these changes appear to neither improve nor worsen the current state, view mode still appears to work fine while editing still crashes upon typing anything. With these changes, editing mode on armeabi-v7a appears to work fine. But I tested armeabi-v7a only with a real device and 32-bit x86 only with an emulator, in case that might make a difference.) * Preceding <https://gerrit.libreoffice.org/#/c/64964/> "Move NSSLIBS to a more sensible place on the linker command line" plus this change's addition of -lunwind to the liblo-native-code.so linker command line make sure that liblo-native-code.so uses _Unwind_* functions from libunwind.a, instead of erroneously picking up the ones from libgcc.a that happen to be included in NSSLIB's nspr4 (-lgcc is automatically added to the end of the linker command line by the invoking compiler, that's how libgcc.a's _Unwind_* end up in NSSLIB's nspr4; it is neither clear to me why NSSLIB's nspr4, being a pure C library, uses _Unwind_* functions, nor why exception handling in liblo-native-code.so fails when using _Unwind_* functions from libgcc.a instead of from libunwind on armeabi-v7a, nor why that would work on 32-bit x86, but that's what I observed: ModuleManager::identify (framework/source/services/modulemanager.cxx) throws a css::lang::IllegalArgumentException, which calls __cxa_throw -> _Unwind_RaiseException, which ultimately lead to odd misbehavior and std::abort during stack unwinding when using _Unwind_RaiseException from libgcc.a instead of from libunwind). (There is no libunwind.* in android-ndk-r16b for 32-bit x86 at least, so is presumably using _Unwind_* functions from libgcc.a. It doesn't appear to make a difference if it indirectly uses those _Unwind_* functions from NSSLIB's nspr4, or directly from libgcc.a included in liblo-native-code.so if the $(if $(filter armeabi-v7a,$(ANDROID_APP_ABI)),-lunwind) had a ",-lgcc" else branch.) * Preceding <https://gerrit.libreoffice.org/#/c/64965/> "Export RTTI symbols from liblo-native-code.so, for binary UNO bridge" makes sure that excpetions thrown from the binary UNO bridge can be caught by compiled catch clauses. Not sure why the corresponding state of bridges/source/cpp_uno/gcc3_linux_intel shouldn't have run into the same issue. * Preceding <https://gerrit.libreoffice.org/#/c/64966/> "Adapt gcc3_linux_arm __cxa_exception to NDK 18 libc++abi" makes sure that our version of __cxa_exception matches the version from libc++abi. This is clearly not relevant for 32-bit x86. (The comment there android-ndk-r18b, but the additional member is already present in android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/src/cxa_exception.hpp, too.) The remainder of this change just drops old armeabi-v7a--specific workarounds that are no longer needed/no longer work. Change-Id: Ief4c2d562c5032abe6c3b94ca3b3394be6fcd4d3 Reviewed-on: https://gerrit.libreoffice.org/64973 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-12weld SwCaptionDialogCaolán McNamara
Change-Id: I5babfbf3489f88c5d6cdeffbd514d86368f04fa9 Reviewed-on: https://gerrit.libreoffice.org/65014 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-12weld SwCaptionOptPageCaolán McNamara
Change-Id: I3373a39d6d8b39717b7aec69544a9d2957db15d8 Reviewed-on: https://gerrit.libreoffice.org/65010 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-11mythes is included in org.freedesktop.Sdk//18.08Stephan Bergmann
Change-Id: I9980f60ebe4cef26348fc26af6b56245260abcca Reviewed-on: https://gerrit.libreoffice.org/64937 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-11tdf#121685: also apply DeclareDPIAware manifest to console applicationsMike Kaganski
There's no reason not to; and now soffice.bin itself is built as a console application. Change-Id: Iba080498b02af04780fdfe1053fb00f584eaae81 Reviewed-on: https://gerrit.libreoffice.org/64915 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-07Revert "In flatpak build, disable problematic test using gpg for now"Stephan Bergmann
This reverts commit 23339ec77e38ebdae86eb05a2a3d9a3f5609df64, which is no longer needed after TODO.
2018-12-07Upgrade flatpak to org.freedesktop.Sdk//18.08Stephan Bergmann
...fixing <https://github.com/flathub/org.libreoffice.LibreOffice/issues/54> "Build against org.freedesktop.Platform 18.08" Change-Id: I70448277ce326075435932c75a837bd7be3d4508
2018-12-07Drop obsolete font sources from flatpak manifestStephan Bergmann
...which are no longer used by the LO build since 0ce173b50fd12342979cf3f8f9b2d92267552060 "tdf#103080 Dont package Open Sans and PT_Serif fonts" Change-Id: I9ece7a85fe0003711eb23f332e617b780e6701cd
2018-12-07Upgrade external/postgresql to postgresql-9.2.24Stephan Bergmann
...which is the latest 9.2.x currently listed at <https://www.postgresql.org/ftp/source/>. 9.2.1 doesn't build against OpenSSL 1.1 which dropped SSL_library_init (cf. <https://wiki.openssl.org/ index.php/Library_Initialization#libssl_Initialization>), and 9.2.24 apparently has that covered. (Ran into this when trying to upgrade the LibreOffice flatpak build to org.freedesktop.Sdk//18.08, which has OpenSSL 1.1.) On Windows, the new tarball as-is fails with > ..\..\port\chklocale.c(214): error C2037: left of 'lc_codepage' specifies undefined struct/union '__crt_locale_data' because at least in Windows Kits/10/Include/10.0.17763.0/ucrt/corecrt.h (included from Windows Kits/10/Include/10.0.17763.0/ucrt/locale.h), the relevant definitions are now > typedef struct __crt_locale_data_public > { > unsigned short const* _locale_pctype; > _Field_range_(1, 2) int _locale_mb_cur_max; > unsigned int _locale_lc_codepage; > } __crt_locale_data_public; > > typedef struct __crt_locale_pointers > { > struct __crt_locale_data* locinfo; > struct __crt_multibyte_data* mbcinfo; > } __crt_locale_pointers; > > typedef __crt_locale_pointers* _locale_t; which presumably has changed from a past state where that lc_codepage member was directly publicly accessible. <https://dev-www.libreoffice.org/src/postgresql-9.2.24.tar.bz2> is a copy of <https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.bz2>; `sha256sum postgresql-9.2.24.tar.bz2` reports the same a754c02f7051c2f21e52f8669a421b50485afcde9a581674d6106326b189d126 as recorded in <https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.bz2.sha256> Change-Id: I196dd93aa03471042efba57ea639e1bb6655de98 Reviewed-on: https://gerrit.libreoffice.org/64730 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Remove obsolete GCC version checksStephan Bergmann
...after <https://gerrit.libreoffice.org/63951> "Bump (Linux) GCC baseline to 7.0.0". (In some cases, those checks now need to check for __clang__, which was implicitly covered in the past by Clang consistently reporting to be GCC 4.2.1.) Change-Id: I860fef8c4ca41c22a7541f0fb2d34b37d1d69bed Reviewed-on: https://gerrit.libreoffice.org/63952 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Default all tests to run with the svp pluginJan-Marek Glogowski
Otherwise a test can already require a windowed VCL plugin by calling gb_CppunitTest_use_vcl_non_headless(_with_windows)?. For compatibility on unix --headless still implies the use of the svp plugin, but now a SAL_USE_VCLPLUGIN will override it. All the explicit SAL_USE_VCLPLUGIN=svp are not needed, as this is now included in the gb_TEST_ENV_VARS variable and gengal already calls Application::EnableConsoleOnly(). Change-Id: I6b4e75282aa88d747db87d60ffe6c8f282187c5f Reviewed-on: https://gerrit.libreoffice.org/64052 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-12-06Drop juh.jar dependency from Java UNO testsJan-Marek Glogowski
Since upstream Java reverted the strict classpath checks, it's not needed anymore. See discussion in https://gerrit.libreoffice.org/#/c/63118 and http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8513ac27b651 Change-Id: Iff863702b1aeda157c8e230ab36372a71dcfb4bb Todo: tdf#121925 Reviewed-on: https://gerrit.libreoffice.org/64634 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-12-06No need to bundle gst-libav in the flatpak any moreStephan Bergmann
756c9f2317605e39d9cb058e650962acd2d81739 "Merge upstream fixes into solenv/flatpak-manifest.in" had introduced it (via <https://github.com/flathub/ org.libreoffice.LibreOffice/commit/7d69e505165d4bbf5fa0b34b5fb2cbff9dfaf9bd> "For now, bundle gst-libav to be able to play mp4 videos in impress" to fix <https://github.com/flathub/org.libreoffice.LibreOffice/issues/20> "Impress don't insert a video" back when the LO flatpak was based on org.gnome.Platform//3.26 which doesn't contain /usr/lib/gstreamer-1.0/libgstlibav.so. (And /app/lib/gstreamer-1.0/libgstlibav.so is apparently the only file that the gst-libav module contributes to the LO flatpak.) When 727bfa2c87db170483c1e4ae895174295b070c77 "Merge in Flatpak improvements" switched the runtime to org.freedesktop.Platform//1.6 (via <https://github.com/flathub/org.libreoffice.LibreOffice/commit/ 7a2393f5fcab8c6938180c4718f2c61acd495528> "port to freedesktop.org 1.6 runtime") it kept the gst-libav module even though org.freedesktop.Platform//1.6 contains /usr/lib/gstreamer-1.0/libgstlibav.so. Lets assume it was kept by accident and can be removed. (At least the scenario from <https://github.com/flathub/ org.libreoffice.LibreOffice/issues/20#issuecomment-368543622> "Impress don't insert a video" still works with this change.) Change-Id: I692d01bfe5882c05d63124db7cdfa6390540e69f Reviewed-on: https://gerrit.libreoffice.org/64703 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-06Format and document combobox classes of BasicIDEtagezi
Change-Id: Ie4f9c142d221b16072748c9c2deaa96c4704b90d Reviewed-on: https://gerrit.libreoffice.org/64422 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-04In flatpak build, disable problematic test using gpg for nowStephan Bergmann
...which fails as documented in solenv/flatpak-disable-gpgconf-socketdir-test.patch, presumably because the gpg software in org.freedesktop.Sdk//1.6 (which has e.g. "gpgconf (GnuPG) 2.1.14-unknown") doesn't shut down a started gpg daemon again. Lets see if this will get fixed by <https://github.com/flathub/org.libreoffice.LibreOffice/issues/54> "Build against org.freedesktop.Platform 18.08" (where org.freedesktop.Sdk//18.08 has e.g. "gpgconf (GnuPG) 2.2.9"). Change-Id: I9c7ad326ff8f2278ec58ee484d088f6fba97694d
2018-12-04Building LibreOffice needs gperf 3.1 nowStephan Bergmann
...since e8e3b00bafefffa1b8a35c5721988fb3bf1f817c "Require at least gperf 3.1, which no longer emits 'register'", but org.freedesktop.Sdk//1.6 only has "GNU gperf 3.0.4" (and org.freedesktop.Sdk//18.08 also only has that version, so this fix will remain relevant even when <https://github.com/flathub/org.libreoffice.LibreOffice/issues/54> "Build against org.freedesktop.Platform 18.08" eventually gets addressed). Change-Id: I5a4fc6692aa077c989348903a3ed1f178922cfcb
2018-12-04Adapt solenv/flatpak-manifest.in to recent download.lst changesStephan Bergmann
Change-Id: Idffd274a18df14a96e61bf61ba09f837fdbbf9c7
2018-12-04weld OfaAutoCorrDlgCaolán McNamara
Change-Id: Iba217a2998de57bf963872f9b8c1cf38694eb935 Reviewed-on: https://gerrit.libreoffice.org/64476 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-03add ASAN suppression file for multiple static linkage of graphiteStephan Bergmann
ASAN_OPTIONS=...:suppressions=.../solenv/sanitizers/asan-suppressions:... Change-Id: Ibe86fd0bfa0ff9bba45ad6828457195ca9ce46a5
2018-12-03Add AnyCompareFactory_get_implementation and...Tor Lillqvist
... com_sun_star_comp_util_OfficeInstallationDirectories. Needed when loading a .ott document. Change-Id: I6074869074b47d2fb679132975520b18659b5c67
2018-12-03test: enable clang-format for xindexaccessJens Carl
Accidentally formatted the files with commit d0a6f8a8e862bede67989cd3fac105d7c8231eb0. Might just enable them. Change-Id: I2f017a17d29f63721be10eb3bff388ed1a5a49bb Reviewed-on: https://gerrit.libreoffice.org/64418 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
2018-12-02loplugin:intvsfloat get this working reliablyNoel Grandin
Change-Id: Ifdf1a152f6bc2e2f6edae97a5191120f630f7e49 Reviewed-on: https://gerrit.libreoffice.org/64374 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-02weld SwGlossaryGroupDlgCaolán McNamara
Change-Id: I142123b474e0e35f6da375977e33d40e0ad39054 Reviewed-on: https://gerrit.libreoffice.org/64324 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-01weld OfaAutoCompleteTabPageCaolán McNamara
Change-Id: I84f051fd1dc127663fd510c81addb0fd0cdc2c26 Reviewed-on: https://gerrit.libreoffice.org/64278 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-01sc: turn on clang-format for scarealinksobjJens Carl
I accidentally formatted the file with commit 20533db9eaafac18b02c81c64b583c76a5ca66a6, so it can be enabled. Change-Id: I36fb6e9107f4f5b2ac708890184bb4981a703474 Reviewed-on: https://gerrit.libreoffice.org/64401 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
2018-12-01weld OfaAutocorrExceptPageCaolán McNamara
Change-Id: I735ca7d70045b278d6b885cc2de35bf76885b487 Reviewed-on: https://gerrit.libreoffice.org/64258 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-01Enable XElementAccess test casesJens Carl
The class XElementAccess was missing the macro OOO_DLLPUBLIC_TEST, and so it wasn't possible to use these test cases. Change-Id: I358bb840c6088ea25b60ee57b8c69f31ab71ddbb Reviewed-on: https://gerrit.libreoffice.org/64363 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
2018-11-30starmath: create XMLOasisSettingsImporter instances with an uno constructorMiklos Vajna
Change-Id: I92c8991baf10fde574d06ab0870bbb26a7632e65 Reviewed-on: https://gerrit.libreoffice.org/64284 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-11-29GalleryPreview is goneTor Lillqvist
Change-Id: I0bcf2f78bf38db8180da76c6dd2c5d39ab1bfce5
2018-11-29We need svt, too, in the iOS app, for the image insertion featureTor Lillqvist
Change-Id: I058af7ba2d6a7c8851cf0da97793d053d6390f07
2018-11-29Rename Mac OS X to official name macOS in comments and documentationBartosz Kosiorek
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95 Reviewed-on: https://gerrit.libreoffice.org/64102 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2018-11-29Reformat and documentation of ObjectCatalogtagezi
This improves the Doxygen-generated documentation for the class at https://docs.libreoffice.org. Also remove objdlg.cxx and objdlg.hxx files from clang-format blacklist. Change-Id: I2299e225892a4d5db638a519bdab51a5d0c72c4d Reviewed-on: https://gerrit.libreoffice.org/63610 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-11-27Refactor calc non-linear ViewToDevice transformArmin Le Grand
This change solves the non-linear World-To-View trans- formation that calc uses due to it's screen rendering as good as currently possible (AFAIK). Calcv view is layouted on pixel base (due to better homogen distances and full pixel lines between cells), but this leads to having a non-linear transformation between discrete units (pixels, view) and model coordinates (World). In principle, each cell has it's own (so called) ViewTransformation -> the position on screen depends on the mappings of all cells top/left from it. This is obvioulsly non-linear and can sometimes be seen by producing 'offset' errors when many cells (small and thin) are shown in low zoom stages. No better solution for this comes to mind easily. The extremes are - on the one hand AntiAliasing the whole calc edit view and accept 'unsharp/AAed' lines - on the other hand what we have now. Maybe a future solution could find a mapping that gets close to linear mapping for the full view. On the long run this state is hard to keep correct. Even with this extended solution the mapping of SdrObjects spawning mutiple cells is assumed 'linear' in that area - which is in reality currently not the case (!) Note: This is only true for the screen visualization, print and/or PDF export do not do that pixel-based layouting. Note2: This mechanism is general in DrawingLayer (look for '.*GridOffset.*'. If it is deactivated by providing no offsets, the result is the unchanged, linear mapping. First step: Add interfaces to get a possible GridOffset at ViewObjectContact. There it belongs, we have a view- dependent offset per object and view. Add mechanisms to create on-demand and reach back to the view (aka calc's derivation of it). Second step: Implement the on-demand creation, adapt to use it in ViewObjectContact::getPrimitive2DSequence, add stuff to reset on zoom change, disable temporarily old mechanism -> paint already works. Need to adapt the places from old mechanism where the GridOffset was used, but no longer the geometry creations. Third step: Isolated and disabled old mechanism (by already removing SetGridOffset). Marked all places that possibly need change with '//Z' tag. Main work now will be to adapt in the SdrView implementations in svx to know about having a SdrObject-dependent ViewTransformation at all (currently not known, was hard-coded at some places from the old code, ViewTransformation set as MapMode at a target OutputDevice, not member at SdrView at all...). Fourth step: Adapt the Handles and OverlayObjects to use an evtl. existing GridOffset. The mechanism is that the SdrHdl(s) can be seen as 'Model-Objects', these get converted to OverlayObjects in the ::CreateB2dIAObject() implementations, for all SdrMarkView and SdrPageView, so this is the place where the ObjectContact is known (the SdrPageWindow *is* a ObjectContact) and the view- dependent GridOffset can be calculated per SdrObject. I modified OverlayObject to be able to work with a set Offset that embeds the created visualization using this additionally. Handles get now correctly set and have a working HitTest (due to that already using the primitives). Some inter- action stuff already working, some will need more adaption. We simply have no concept for this stuff... Refactored to not get dependencies to SdrObject in ObjectContact. Fifth Step: Make HitTest work by adding the View-And- Object dependent GridOffset in the View when HitTest is triggered. This is in SdrMarkView::CheckSingleSdrObjectHit where pObj->GetCurrentBoundRect() is used that gets the view-independent form. To make HitTest work, add a possible GridOffset. Since this will be necessary more often in SdrView hierarchy, added a tooling method (getPossibleGridOffsetForSdrObject) at that level after checking that at that level will be reachable at all potential spots. Inside that method the correct ObjectContact will be identified and the object-specific offset requested there. Sixth Step: Adaptions and started some cleanups. Still some adaptions needed: - After creation of new object, need to relocate from used GridOffset setting to WorldCoordinates - Interactions, e.g. start with dragging handles or full object/points Seventh Step: React on EndCreateObj. Here, the created SdrObject is in model coordinates and needs to be adapted to evtl. GridOffset. This is 'tricky' due to calculating the possible offset based on new coordinates 'close' to the target position, but may be in the wrong cell. Nonetheless this is the best we can do here. Last (hopefully) missing are now all interaction viszualizations. They already work and are applied correctly, but wrong visualized. Have taken the time to unify adding OverlayObjects for selection visualization to OverlayManager, see handleNewOverlayObject. This does all needed when adding OverlayObjects in one place where the GridOffset can also be handled. It makles things more safe - not possible to forget one of the three steps for others. Eighth Step: Do the same unification for creating the OverlayGeometry, also rename methods to make usage more clear. We now have SdrHdl::insertNewlyCreatedOverlayObjectForSdrHdl SdrDragMethod::insertNewlyCreatedOverlayObjectForSdrDragMethod which can do the needed GridOffset changes centralized. Needed to get a ObjectContact for this at SdrDragMethod, so adapted ::CreateOverlayGeometry implementations accordingly. Missing is now the implementation in insertNewlyCreatedOverlayObjectForSdrDragMethod to add the GridOffset - if used. This has no SdrObject at this time, so we will need a fallback to do the same using a Range (Rectangle). The stuff doing this for SdrObject already has a fallback and is based on using the Rectangle from the SdrObject anyways, so this will be possible. Ninth Step: Cleanup of old stuff (no more //Z), adapted some usages of OverlayObject creations to use getViewIndependentPrimitive2DContainer instead of the view dependent parts so that offset applied to drag-overlays is correct and not already added. Adapted insertNewlyCreatedOverlayObjectForSdrDragMethod to use calculateGridOffsetForB2DRange. Use now that instead of SdrObject-based approach in calc - is more generic. Getting closer, but still not complete - there is an error with dragging the grepped handle somehow - the offset for drag is somehow wrong. Tenth Step: Corrected that offset error. Of course at interaction start and progress (move) the coordinates are in GrifOffset coordinates and need to be corrected to Model coordinates. Done that at ::BegDragObj and ::MovDragObj, works well. Of course there are exceptions for the crop-handles, so needed to add setting the correct parameters at SdrHdl when these got created, then all works as expected. The strategy is to *not* change the model data itself in any way, instead do all changes/adaptions in the view-only code. This has minimal impact and is needed due to having a 1:n relationship between model and views anyways. There are two directions: All visualizations are adapted to take the GridOffset into account (SdrObjects, overlay, handles, InteractionObjects, ...). In the other direction input like MousePosition is in principle in calc EditView in 'GridOffset'-coordinates and needs to be mapped back before usage. Change-Id: I2ecdd409def96a7248a26a65a22e59eb962880a0 Reviewed-on: https://gerrit.libreoffice.org/64057 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-11-27gbuild: MacOSX: use tr instead of sed for newlinesMichael Stahl
At least on tinderbox MacOSX-x86_64@49-TDF the sed appears to ignore the literal newline character, which is unfortunate, particularly since it worked on the Jenkins builder. Blind fix to replace this with a tr invocation that already appears to work in Zip.mk. Change-Id: I7a77e69774b050a018b12c73ddd9eff849c33a86
2018-11-26weld DataSourceTabPageCaolán McNamara
Change-Id: I99b7c2ec397829c2f7ceb7ec18ae24195b9781e2 Reviewed-on: https://gerrit.libreoffice.org/61800 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-26Use -filelist with macOS linkerAlyssa Ross
macOS's linker can take a -filelist argument, in place of taking the list of object files to link on the command line. This is a more limited version of "response files" as used elsewhere in the code base, and by using it we make it far less likely that a linker invocation will hit ARG_MAX. A standard LibreOffice build probably won't hit ARG_MAX on macOS just yet, but it's not far off - some LDFLAGS are enough to tip it over the edge, which is what prompted me to fix the issue. If not fixed, a few more object files will probably break LibreOffice builds on macOS! An example of another large program that has encountered this issue is Thunderbird, which implemented the same fix[1]. The changes I've made to use -filelist are adapted from the code elsewhere in gbuild that creates response files, but this is slightly different because -filelist files are a bit different - they can only contain object files, as opposed to arbitrary linker arguments, and arguments are separated by newlines rather than spaces. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=837618 Change-Id: I01b9126aad95056c3dc82f941dea4fd43f95d0f2 Reviewed-on: https://gerrit.libreoffice.org/64010 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-11-25Generally set CCACHE_CPP2 for --enable-werror GCCStephan Bergmann
This obsoletes <https://gerrit.libreoffice.org/plugins/gitiles/lode/+/ b82e0a9d26ef4c81046c053ff831dccfc84c56be%5E!> "For linux_gcc_release_64, don't let ccache strip comments" and fixes ccache for all builds using (recent) GCC. Change-Id: I5fd20b2565f57073c545fe5d3a9639c2c0583a74 Reviewed-on: https://gerrit.libreoffice.org/63979 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-23Revert "Do use -O1 for Apple Clang older than 9.1.0"Stephan Bergmann
This reverts commit 55b9706bea5aa9b654ab39bc7d56339422e17087, which is obsoleted by b4f666f2e677b05cab8395fe7972b45b15f60c3f "Bump Xcode baseline to 9.3". Change-Id: Id2240351ed9495e311d55887b8e34f2aa776ae06 Reviewed-on: https://gerrit.libreoffice.org/63896 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-22weld SwFramePageCaolán McNamara
Change-Id: I12f868611860867df26bd29474aa19189c2b9a96 Reviewed-on: https://gerrit.libreoffice.org/63818 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-22python tests: fix user config for autotext functionsThorsten Behrens
Seems that the code in SwGlossaries::GetGlosDoc() expects subdirs to exist in user config, and would otherwise fail miserably. Change-Id: I2da6bca46ae5e0d9d90bc23eb710396dbede37f4 Reviewed-on: https://gerrit.libreoffice.org/63798 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-11-22Pass some env vars into all kinds of testsStephan Bergmann
...not only CppunitTests, as had been changed with d5ed903618f200456feed9b410b7bd1ed8daeb62 "Set CppunitTest-related env vars only during CppunitTest". Despite those env vars having been deceptively set up in solenv/gbuild/CppunitTest.mk, at least some of them may also be useful during other tests, and may actually have been relied upon by other tests in the past. Change-Id: I854dfb1786bb5e9e2de5fd77cb6323299320b544 Reviewed-on: https://gerrit.libreoffice.org/63784 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-21weld SwCondCollPageCaolán McNamara
and put back original SvTreeListBox a11y factory use Change-Id: I4ad8ce29d8fed6ec5d44e9a1d641919a89226b79 Reviewed-on: https://gerrit.libreoffice.org/63501 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-20Set CppunitTest-related env vars only during CppunitTestStephan Bergmann
...and not for every target's recipe, once solenv/gbuild/CppunitTest.mk is included Change-Id: I710160def23fae5f93c5a67ab25e03fdaa008e00 Reviewed-on: https://gerrit.libreoffice.org/63655 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-20loplugin:unusedenumconstants improvementsNoel Grandin
add some unit tests, and improve the heuristics Change-Id: I95aa97a87e178ce8d506bd245710d0ae66ad08a4 Reviewed-on: https://gerrit.libreoffice.org/63647 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-20Fix loplugin:staticconstfieldStephan Bergmann
...(ExprWithCleanups around the CXXConstructExpr in initializers for members of O[U]String type, with older Clang, as used in compilerplugins/clang/test/staticconstfield.cxx), and thus revert e3e8d52625c2dc7a277a955d4ae2ad10c60c5f1b "Temporarily disable compilerplugins/clang/test/staticconstfield" again. Change-Id: Ic5fcdd1a26e4a6810369e4f9d909200d25feb12e Reviewed-on: https://gerrit.libreoffice.org/63628 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-20Drop some headless mode variantsJan-Marek Glogowski
This fixes OSX "make debugrun" by dropping VCL_HIDE_WINDOWS handling and removing the internal GetPseudoHeadless() API. While at it moves the DialogCancelMode enum out of Application. Change-Id: I4876e752ddbfc39dd44faa673fb0e97810089a75 Reviewed-on: https://gerrit.libreoffice.org/61598 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-11-19Temporarily disable compilerplugins/clang/test/staticconstfieldStephan Bergmann
Of the "Gerrit Linux clang/dbgutil" build nodes, one (tb79-pollux) has done the lode update to use Clang 3.9.1, while the other two nodes (tb75-lilith and tb76-maggie) are still at the old Clang 3.8.0. When building Gerrit changes for master, tb79-pollux started to fail in compilerplugins/clang/test/staticconstfield now (<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/20247/> and <https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/20252/>) while such builds on the other two nodes still succeed. So it looks like Clang 3.9.1 has some issue with that loplugin, which will need further inspection. For now, to not break Gerrit/Jenkins builds, disable that test. Change-Id: I1bd380fb98d3b9a411dd04578a5620cdb27cd35b
generated by cgit (git 2.34.1) at 2025-01-22 14:55:40 +0000