summaryrefslogtreecommitdiff
path: root/extensions
AgeCommit message (Collapse)Author
2013-11-05convert xub_StrLen to sal_Int32Noel Grandin
Converts code that calls comphelper::string::getTokenCount() to use sal_Int32 to store the return value. Change-Id: I439605a39d29b1309649e30f3ff40dfa412efcde
2013-11-04remove redundant calls to OUString constructor in if expressionNoel Grandin
Convert code like: if( aStr == OUString("xxxx") ) to this: if( aStr == "xxxx" ) Change-Id: I8d201f048477731eff590fb988259ef0935c080c
2013-11-04Convert code that calls OUString::getStr()[] to use the [] operatorNoel Grandin
This also means that this code now gets bounds checked in debug builds. Change-Id: Id777f85eaee6a737bbcb84625e6e110abe0e0f27
2013-10-31Convert indexOf->startsWith and lastIndexOf->endsWithNoel Grandin
This is both an optimisation and a cleanup. This converts code like aStr.indexOf("XX") == 0 to aStr.startsWith("XX") and converts code like aStr.lastIndexOf("XXX") == aStr.getLength() - 3 to aStr.endsWith("XXX") Note that in general aStr.lastIndexOf("X") == aStr.getLength() - 1 converts to aStr.isEmpty() || aStr.endsWith("X") so I used the surrounding context to determine if aStr could be empty when modifying the code. Change-Id: I22cb8ca7c2a4d0288b001f72adb27fd63af87669
2013-10-28gbuild: set Package default target to INSTDIRMichael Stahl
Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186
2013-10-24Disallow --without-system-cairo combined with (implicit) --enable-gtkStephan Bergmann
As the system gtk libraries may depend on later versions of libcairo.so.2 and its bring-along libpixman-1.so.0 with the same SONAMEs. So if it would ever happen at runtime that our bundled libcairo.so.2 and/or libpixman-1.so.0 get loaded before the system ones, the system gtk would probably not work correctly. Ultimately, the bundled cairo can probably go completely. This reverts 122a137672d761418a549568ad8cad623dd2b4b5 "extensions: crude hack for mysterious cairo link failure." As discussed at #libreoffice-dev: Oct 24 10:10:15 <mst__> sberg, caolan, dtardon any idea what the proper fix is for pluginapp.bin? 122a137672d761418a549568ad8cad623dd2b4b5 breaks on RHEL5 tinderbox... Oct 24 10:10:17 <IZBot> core - extensions: crude hack for mysterious cairo link failure - http://cgit.freedesktop.org/libreoffice/core/commit/?id=122a137672d761418a549568ad8cad623dd2b4b5 Oct 24 10:12:53 <dtardon> mst__, i'd try gb_Executable_use_external,pluginapp.bin,cairo Oct 24 10:13:58 <mst__> dtardon, i'm not sure if that is the intent - the -lcairo comes from the gtk external so we should use same cairo as gtk i.e. system one? but id on't understand why linker won't find the pixman library Oct 24 10:16:35 <sberg> mst__, I get no build failures in "make extensions.clean && make extensions" when I comment out that FIXME in extensions/Executable_pluginapp.bin.mk Oct 24 10:18:59 <mst__> sberg, it only started to fail for me when i removed libcairo.so from solver, probably you still have a stale one Oct 24 10:19:42 <sberg> mst__, in solver/*/lib/? no Oct 24 10:20:48 <sberg> mst__, but turns out I'm using --with-system-cairo (as required by --enable-gtk3), so ignore me Oct 24 10:22:53 <mst__> sberg, so if i rm solver/unxlngx6/lib/*cairo* solver/unxlngx6/lib/*pixman* it still fails for me, how could system-cairo work then? Oct 24 10:24:13 <sberg> mst__, in that /usr/lib64/libcairo.so has a DT_NEEDED on libpixman-1.so.0 (which "our" libcairo.so is missing, I'd assume) Oct 24 10:24:44 <sberg> mst__, erm Oct 24 10:41:18 <mst__> sberg, so if i filter out -lcairo in gb_LinkTarget__use_gtk then it magically works - are there any problems with that approach? Oct 24 10:47:19 <sberg> mst__, so the root of the problem is that there's two different libcairo involved? (just doing a local build --wihtout-system-cairo here, to see what's going on) Oct 24 10:47:55 <mst__> sberg, i don't think so since i get same problem after removing all cairo libs from solver Oct 24 11:12:11 <sberg> mst__, so the link line for pluginapp.bin contains -lcairo twice, apparently dragged in indirectly (via _use_externals gthread and gtk, likely), and does not contain "our" -L.../cairo/src/.libs (as it doesn't _use_externals cairo), but does contain -Lsolver/*/lib. Now, /usr/lib64/libcairo.so needs libpixman-1.so.0 and there happens to be one in solver/*/lib that lacks syms compared to /usr/lib64/libpixman-1.so.0 Oct 24 11:13:43 <sberg> mst__, so this was nicely hidden when all the external libs were delivered to solver/*/lib, but in the end I think the bug is to combine system gtk with non-system cairo and/or pixman Oct 24 11:14:49 <sberg> mst__, as long as our cairo and/or pixman have the same SONAMEs or exported symbol names as system ones, all hell can happen at runtime anyway Oct 24 11:15:32 <mst__> sberg, but... why then does it fail for me if i don't have the cairo/pixman libs in solver? Oct 24 11:15:57 <mst__> ahhh -Wl,-rpath-link,$S/instdir/unxlngx6/program <- taht must be why Oct 24 11:17:40 <mst__> is it normal that -Wl,--trace does not print out what libraries were found via -Wl,-rpath-link? it only appears to print explicit -lfoo Oct 24 11:18:27 <sberg> mst__, because of -Linstdir/*/program Oct 24 11:20:27 <mst__> sberg, so we need -Wl,-rpath-link,$S/instdir/unxlngx6/program obviously; Oct 24 11:22:08 <mst__> sberg, apparently everything builds successfully when filtering out -lcairo from GTK_LIBS, do you think that is the best workaround for this? Oct 24 11:22:14 <sberg> mst__, no, we need to change configure.ac to disallow --enable-gtk --without-system-{ciaro,pixman} Oct 24 11:22:39 <sberg> mst__, similarly to how we already disallow --enable-gtk3 --without-system-cairo Oct 24 11:24:48 <mst__> sberg, that would be sort of pointless, since linux is afaik the only platfrom where cairo is used at all - effectvely we could remove bundled caior then? Oct 24 11:27:04 <sberg> mst__, effectively yes, unless it would still be useful for some --disable-gtk scenario Oct 24 11:33:41 <mst__> caolan, cloph does RHEL5 have a sufficiently recent system cairo? Oct 24 11:34:43 <cloph> cairo 1.2.4 on the CentOS 5.9 (well, more like 5.10 now) system Oct 24 11:37:08 <jcorrius> my RHEL6 build uses internal cairo Oct 24 11:37:47 <caolan> rhel-5 cairo is 1.2.4 Oct 24 11:37:54 <mst__> caolan, the other option i can see is to do $(call gb_LinkTarget_add_libs,$(1),$(filter-out -lcairo,$(GTK_LIBS))) in gb_LinkTarget__use_gtk which works-for-me(TM) Oct 24 11:38:30 <sberg> jcorrius, not for very much longer ,) (it typically happens to work by luck to combine system GTK with bundled cairo) Oct 24 11:38:59 <mst__> thorsten, are you aware of any reason why we must bundle cairo on linux? Oct 24 11:40:05 <sberg> mst__, "<caolan> rhel-5 cairo is 1.2.4" and we only check for "cairo >= 1.0.2" in cofingure.ac, so all should be good Oct 24 11:40:35 <sberg> mst__, "works-for-me(TM)" just by luck Oct 24 11:41:33 <mst__> sberg, well perhaps guess the real problem is that pkg-config spits out a spurious -lcairo for gtk+-2.0 so... Oct 24 11:42:19 <mst__> ... but of course if a sufficiently good cairo is available everywhere we don't have reason to bundle it anyway Oct 24 11:45:45 <sberg> mst__, at least my /usr/lib64/libgtk-x11-2.0.so.0 does have a DT_NEEDED on libcairo.so.2, so even if pkg-config wouldn't spit it out we would still be in trouble at runtime Oct 24 11:47:05 <mst__> sberg, at runtime we have this problem for a lot more libraries than just cairo Oct 24 11:47:43 <sberg> mst__, but why refuse to fix the problem, at least for cairo, where there is apparently no good reason to bundle it anyway? Oct 24 11:48:36 <jcorrius> is cairo used on Windows for anything? Oct 24 11:48:42 <mst__> sberg, since there is no good reason to bundle it anyway i don't object to removing the bundled cairo Oct 24 11:49:38 <mst__> sberg, ... but i can still hold the opinion that gtk shouldn't put -lcairo in its pkgconfig :) Oct 24 11:53:12 <sberg> mst__, since "pkg-config --cflags gtk+-2.0" includes "-I/usr/include/cairo", one could argue that cairo is a "re-exported" part of that, so should also appear in pkg-config --libs output; one could likely argue either way Oct 24 11:55:27 <mst__> sberg, well but if you're calling functions from cairo then you're using cairo directly whereas if you just call gtk functions you have no need to link cario Oct 24 11:56:47 <sberg> mst__, sure, my argumentation depends on that "re-exports" argument (which might be thin); anyway, are you going to remove bundled cairo Oct 24 11:56:54 <sberg> ? Oct 24 11:57:34 <mst__> sberg, i'm going to force it to system in configure for now Oct 24 11:58:13 <sberg> mst__, I have a patch for exactly that already locally here, so could push that if you've not done that too already anyway Oct 24 11:59:00 <mst__> sberg, i havent' finished my freetype patch yet because people always distract me on irc so you can push Oct 24 11:59:01 <sberg> mst__, or, rather, my patch just errors out in the --enable-gtk --without-system-cairo combination, so if you have a better one, go ahead Change-Id: I071e759a55f46338b36c3cf8ac7cd5591bd9e376
2013-10-24extensions: crude hack for mysterious cairo link failureMichael Stahl
Why is /usr/lib64/libpixman-1.so not found automatically? Change-Id: Ide3929b53d130aee44ff6b01dcf2f7491a61a09b
2013-10-23fdo#54938: Replace existsValue for cppu::supportsServiceMarcos Paulo de Souza
As now ::comphelper::existsValue is not used anymore, we're removing this too. Change-Id: I9bd2544a9c378f5a18746255133f5684867e0114 Reviewed-on: https://gerrit.libreoffice.org/6378 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2013-10-23Fix build of ldapbe in UbuntuMarcos Paulo de Souza
Change-Id: I6e3e64a0e9a0510401f9b8ddbf9e18e2d6caba3e Reviewed-on: https://gerrit.libreoffice.org/6400 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2013-10-22Bin comments that claim to say why some header is includedTor Lillqvist
They are practically always useless, often misleading or obsolete. Change-Id: I2d32182a31349c9fb3b982498fd22d93e84c0c0c
2013-10-22extensions: try to fix WNT StringMichael Stahl
Change-Id: I17ec25a836eda7bb023c440db1f40186b6156067
2013-10-22stray String in extensionsCaolán McNamara
Change-Id: Iea98e52fd026d93f68ab9916ccb583b156d5c9a7
2013-10-22vcl: mark more Image constructors as "explicit"Michael Stahl
Change-Id: If59d7c75c89a102a573738d15d8593cb8ac5c486
2013-10-22Resolves: fdo#38838 remove UniStringCaolán McNamara
hammer silver nails into coffin and bury in concrete Change-Id: I3fda2ff47738bb33793adab97faba2d439ac9a28
2013-10-20drop unnecessary tools/string includesCaolán McNamara
Change-Id: I4278999b9b7d184c26036bbe9e3b98420f461e8c
2013-10-18fdo#36964 Wording change: "Remove Filter" -> "Reset Filter"Samuel Mehrbrodt
As discussed in the bug report. I changed all occurrences, not only the one in the Calc menu. Change-Id: Ia652cb10ec0123b0a79a719dda59e6d2f54f0680 Reviewed-on: https://gerrit.libreoffice.org/6123 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2013-10-15Some string clean-upStephan Bergmann
Change-Id: Ic046150605c599746ed3235c04bcbc981e18e589
2013-10-15Use OUString::replaceAllStephan Bergmann
Change-Id: Ide87f07a97a51d924947f7959016164b98ab43f9
2013-10-07fdo#54938: Adapt supportsService implementations to cppu::supportsServiceMarcos Paulo de Souza
Change-Id: I683c0d30c3286ed5d725d4eefe8b3977b82ee316 Reviewed-on: https://gerrit.libreoffice.org/6035 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2013-10-04fdo#46374 replace stardiv in comments where applicableThomas Arnhold
Change-Id: Icd07fba84735325408741ad10864c63ea32a6481
2013-10-03CID#705646 leak on error pathCaolán McNamara
Change-Id: I3b701f47bbd4141127e209673a4ce9335d68ca2a
2013-10-03CID#705647 leak on error pathCaolán McNamara
Change-Id: I6e52bfb34e7c4be0d17dfa7849d4a96248aa49b4
2013-10-02Spell "indices" correctlyTor Lillqvist
Change-Id: I63b1de195bf2f3f8bfd185181f48b1520cdd849f
2013-10-02-Werror,-Wunused-variableStephan Bergmann
Change-Id: I57cb3540cb94dcf39252a87b56cba3856cba9c01
2013-10-01extensions: kill StarOffice/StarSuite branding in browser pluginMichael Stahl
Change-Id: Ia4c291936ad0b31e67d8edb046424d29462171b5
2013-10-01extensions: fix swapped "insert" parametersMichael Stahl
Change-Id: If9667cad9fcc0ff3b1cc8d36c0619d80d7f3e2b9
2013-10-01convert extensions module from String to OUStringNoel Grandin
Change-Id: Ia0cb9fe1eaebdd295fb1742074fe2c48be61c077
2013-09-26typo fixes in commentsAndras Timar
Change-Id: Iaadec33715f8e0e0c6595c5e684606905274fdab
2013-09-25Related: fdo#38838 remove UniString::EqualsIgnoreCaseAsciiCaolán McNamara
Change-Id: Ib5c3a2daa4a48bc286b14fa2cebb3306ea0012bc
2013-09-23Try to fix cross-compilationTor Lillqvist
Add more FOO_FOR_BUILD variables and some gb_Foo_for_build functions. Get rid of gb_INSTROOT and gb_DEVINSTALLROOT, just use INSTROOT. Change-Id: Iee531b02d14fae41edb68ad589a5dec829a60255
2013-09-22gbuild: remove libraries from OUTDIR and WORKDIRMichael Stahl
Refactor everything to find and link libraries directly in INSTDIR. - add gb_LinkTarget_get_linksearchpath_for_layer, and use it to set up -L paths for T_LDFLAGS in such a way that only allowed libraries can be linked against; i.e. it's not possible to link URE linktargets against OOO or not-installed libraries - gb_Library_get_target is now same as the gb_LinkTarget_get_target (TODO: this needs cleanup) - since a pattern rule won't work for linking libraries in INSTDIR, add a separate per-file rule for every INSTDIR lib - pattern rule can't find link target in the clean target any more so add a LINKTARGET variable - disable gb_Library_add_auxtarget, no auxtargets need to be copied - tweak the call to gb_Library_Library_platform to pass in a path in sdk/lib for the versioned URE libs - fix the Library clean target - add LAYER parameter to gb_LinkTarget_LinkTarget - adjust platform link commands - MSVC link command now uses explicit -manifestfile and -pdb parameters to keep misc. files out of INSTDIR - remove gb_Helper_OUTDIR_FOR_BUILDLIBDIR - adjust Extension, CppunitTest, JunitTest, PythonTest, Gallery, various CustomTargets to search INSTDIR - remove SDK library symlinks and import libs from odk/Package_lib - on Mac OS X, put .dylib symlinks into sdk/lib even though those are not packaged and would be created by the SDK configury; we need these to be somewhere for linking anyway - add a (unfortunately cyclic) dependency on Package ure_install to sal Change-Id: I70d88742f8c8232ad7b9521416275c67b64fe6cf
2013-09-19WaE: cast to 'void *' from smaller integer typeTor Lillqvist
Change-Id: I85d4a4c3c7bf708daa85dbe7f3af54311c4d7e2e
2013-09-17drop unused hidsCaolán McNamara
Change-Id: I504e2abd967476f2346095fea23c8cd8fbf9ebfc
2013-09-17move uiconfig stuff into the same toplevel source dirCaolán McNamara
Change-Id: I5cbb4d2cd367cb62af3d6ddde24e7e2d3598b75b
2013-09-17Convert tab order dialog to widget UIManal Alhassoun
Change-Id: I2aebcf6486b80af31f1a06e9ae38e5610bee0cb4 Reviewed-on: https://gerrit.libreoffice.org/5970 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2013-09-11Towards a working instdir for Mac OS XStephan Bergmann
Introduced gb_INSTROOT, which is the same as $(INSTDIR) except for Mac OS X, where it is $(INSTDIR)/LibreOffice.app/Contents. Most stuff ends up there (so most occurrences of $(INSTDIR) have been replaced with $(gb_INSTROOT)), but SDK- related stuff goes to $(INSTDIR)/$(gb_Package_SDKDIRNAME). (And GeneratedPackage needed to be made more flexible, to allow for packages that go into either of those two places.) For Android and iOS, gb_INSTROOT probably still needs to be set. The most obvious missing thing yet to make instdir work for Mac OS X is the instdir/*/LibreOffice.app/Contents/ure/ vs. instdir/*/LibreOffice.app/Contents/ure-link/ split. Change-Id: I4478edd27b14c92c96d92d5169bdca3ec50d78f5
2013-09-04WaE: use number() instead of valueOf()Tor Lillqvist
Change-Id: I7a57a8c60c07909018280e52d2da70fbf22857a7
2013-08-31fdo#62475 - remove visual noisePhilipp Riemer
Change-Id: I7409f7a58796c9bf7542b6a7904ad40581637eeb
2013-08-31fdo#62475 - remove visual noisePhilipp Riemer
This is a follow up commit to - 22d1beb78a475e4846af945afde1c4d6c263b5d6 - 1c7af455ab9345304a7ac48ce2e0310de2ac8a75 Change-Id: I102685391125f3b4f7bdf838f8bd17a2283d558d
2013-08-30ENABLE_NPAPI_* Harmonize ENABLE_* variable to TRUE/<nothing>Norbert Thiebaud
Change-Id: Ia7575f0f51bc3ba355ec01d937bd155adb287572 Reviewed-on: https://gerrit.libreoffice.org/5684 Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org> Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
2013-08-24build on higher debug levelsCaolán McNamara
Change-Id: I7f4d85f3e26ab8b19dae05c6907840b97a8af1d6
2013-08-21valueOf() -> number()Luboš Luňák
Change-Id: I2832229b01de0cc5a725fd5fe1574a775d0bf12a
2013-08-21finish deprecation of O(U)String::valueOf()Luboš Luňák
Compiler plugin to replace with matching number(), boolean() or OUString ctor, ran it, few manual tweaks, mark as really deprecated. Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
2013-08-21osl_getThreadIdentifier(0) -> osl::Thread::getCurrentIdentifier()Stephan Bergmann
Change-Id: Ida9785c4b9fda0459769957734952e69d7a9de44
2013-08-20Re-work 8bit characters in source code, or remove them.Michael Meeks
Change-Id: I93e14d4936c0ffbe03425d4a54bb0e09bc62b3e3 Reviewed-on: https://gerrit.libreoffice.org/5550 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@suse.com> Tested-by: Michael Meeks <michael.meeks@suse.com>
2013-08-19fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecifiedStephan Bergmann
...it looks like it used to be the order the constants appeared in the .idl file, while now it happens to be the lexicographical order of the constant's names. For all the constant groups in com.sun.star.report the order expected by the code appears to be the order of the constant's numeric values (which happens to coincide with the order of appearance in the .idl files), so explicitly sort them that way. Change-Id: I550401b2742fffb7c96a7787498967a7cd78fff8
2013-08-19Rename SOLAR_JAVA to ENABLE_JAVA and HAVE_FEATURE_JAVATor Lillqvist
Change-Id: Ib451bdb3c1c2ca42347abfde44651d5cf5eef4f3
2013-08-18Use subfolder names from <config_folders.h>Tor Lillqvist
Change all instances of hardcoded "program", "share" etc subfolder names to use those from <config_folders.h> instead. In normal builds, the end result will not change. Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
2013-08-15i121946 - Use enums to identify WebDAV/HTTP methodsAriel Constenla-Haile
(cherry picked from commit 122e10cfd23b379b97e2d8ec002e7f0562ebd6f7) Conflicts: extensions/source/update/feed/updatefeed.cxx offapi/com/sun/star/ucb/makefile.mk offapi/type_reference/typelibrary_history.txt offapi/type_reference/types.rdb ucb/source/ucp/webdav/DAVResourceAccess.cxx ucb/source/ucp/webdav/DAVResourceAccess.hxx plus headerize.pl (Would be an incompatible API CHANGE if we had not unpublished XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert publishing of lots of UNO types.") Change-Id: I153e394a194d0fcad29d3e3b27d5b24f7c259fc4
2013-08-15i121945 - WebDAV ucp: return StringPair instead of NamedValueAriel Constenla-Haile
Make css::ucb::XWebDAVCommandEnvironment::getUserRequestHeaders() return a sequence of css::beans::StringPair; this avoids all the any overhead, and is much more simple and intuitive. (cherry picked from commit 80199136d0d84b51b3d0529fb313b8f20f5cf851) Conflicts: extensions/source/update/feed/updatefeed.cxx offapi/type_reference/typelibrary_history.txt offapi/type_reference/types.rdb ucb/source/ucp/webdav/DAVResourceAccess.cxx (Would be an incompatible API CHANGE if we had not unpublished XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert publishing of lots of UNO types.") Change-Id: I1c5d0a0b225fe86aca6ba6d6c8903985005387c2
generated by cgit (git 2.34.1) at 2024-06-02 10:51:20 +0000