summaryrefslogtreecommitdiff
path: root/binaryurp
ModeNameSize
-rw-r--r--CppunitTest_binaryurp_test-cache.mk674logplain
-rw-r--r--CppunitTest_binaryurp_test-unmarshal.mk900logplain
-rw-r--r--Library_binaryurp.mk1122logplain
-rw-r--r--Makefile225logplain
-rw-r--r--Module_binaryurp.mk598logplain
-rw-r--r--README495logplain
d---------qa88logplain
d---------source1318logplain
generated by cgit (git 2.34.1) at 2024-06-26 07:12:03 +0000
ewvc?view=revision&revision=1363727 Patch contributed by Oliver-Rainer Wittmann i#88652: applied patch, remove unicows deps http://svn.apache.org/viewvc?view=revision&revision=1177585 Remove lots of OS2 conditionals, re-extract Rhino Java, unwind cppunit pieces, cleanup Mac image bits, remove coin-mp and re-package lpsolve, Oxygen & Crystal, fixup qstart bits, expand MPLv2 subset checking. Change-Id: Iad5c8a76399620b892671633c0d8c29996db3564 2013-05-17Let's assume nobody needs the sbase, scalc etc scripts on OS XTor Lillqvist It's always possible to run the soffice executable from the same location with a --base, --calc etc command-line option instead. (That is not the normal way for Mac users to open an empty document for the specific aspect of LibreOffice (Calc, Writer, etc) either. Instead, the usual way (says cloph) is to keep a corresponding template document in the Dock and click that.) Change-Id: Iceea270c03a63f674e7dfdfa95117cb3bdd15184 Reviewed-on: https://gerrit.libreoffice.org/3930 Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org> Tested-by: Fridrich Strba <fridrich@documentfoundation.org> 2013-05-04install impress xml config files using filelistsDavid Tardon Change-Id: I072d5283f979b42ffbd359575209c09cf445b6df 2013-04-21fdo#60949: Move more libs to OOOLIBSMarcos Paulo de Souza Change-Id: Ibd45f7004f8eaa151b9a60d7369d396411f60a2b Reviewed-on: https://gerrit.libreoffice.org/3511 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com> 2013-04-15gbuild: deliver help files as packagesDavid Tardon Change-Id: I52904567d0c7434af3f013cad7c3d9a8a67ac9f2 Reviewed-on: https://gerrit.libreoffice.org/3384 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com> 2013-02-28bin PATCH_SO_NAME crackAndras Timar In VersionInfo of Windows executables the FileDescription property originally contained 80 times 'x' character. These executables were marked as PATCH_SO_NAME and later the installer maker perl program replaced the xxxxxxxxxxx to the actual file description which was defined in scp2. WHy was it good, I have no idea. The problem was that it happened after postprocess, where we signed the binaries, thus diigital signature became corrupted. It is better to give file descriptions via makefiles. Change-Id: Id5ad4470bb7a6313b33fbba09d72d9a009163a89 2013-02-17Remove some bits that have been commented out since 2004Tor Lillqvist Change-Id: Ibd95e9ea1c3ab6f24e0a469108191e59b049823e 2012-11-21Turn presenter screen from bundled extension to plain codeStephan Bergmann The immediate trigger was 5e5c11c664f67ff9fd1120905b09a32bea3b2f6c "fdo#42070 Fix RTL support in presenter console" causing build failures on Mac OS X when linking the extension against vcl, but there should be more benefits of going from a bundled-anyway extension to plain code. (Not the least to get rid of the com.sun.star.drawing.XPresenterHelper hack.) To avoid unnecessary confusion between the newly plain code and any instance of the old extension still installed (per-user or shared), I renamed all relevant identifiers as follows: * UNO implementation com.sun.star.comp.Draw.framework.PresenterScreenJob -> org.libreoffice.comp.PresenterScreenJob * UNO implementation com.sun.star.sdext.presenter.PresenterProtocolHandler -> org.libreoffice.comp.PresenterScreenProtocolHandler * protocol handler schema vnd.com.sun.star.comp.PresenterScreen -> vnd.org.libreoffice.presenterscreen * configuration schema /org.openoffice.Office.extension.PresenterScreen -> /org.openoffice.Office.PresenterScreen (it appears this contains little to no user-changeable data anyway, so not migrating it to a new user profile due to the schema name change should not be problematic) * job ID onDocumentOpenedJob -> org.libreoffice.PresenterScreen Even with these precautions, having the presenter screen installed both as plain code and as a (per-user or shared) extension still leads to a crash when activating presentation mode (likely due to how both codes want to take control of the screen). To mitigate this, existing installations of the extension are explicitly not migrated to new user profiles. The sdext/source/presenter/bitmaps/*.png files were moved to icon-themes/galaxy/sd/res/presenterscreen-*.png and are now accessed via SdResId (adding the relevant data to sd/source/ui/inc/res_bmp.hrc and sd/source/ui/app/res_bmp.src; not sure whether these locations are already ideal). The code itself has been left mostly unchanged in sdext/source/presenter/, and it still clumsily communicates with sd core code via XPresenterHelper. There is a lot of room for improvement here. The help data is left untouched at sdext/source/presenter/help/ and needs to be incorporated properly into helpcontent2 in a follow-up commit. The --disable-ext-presenter-console configure switch is gone. Change-Id: I71adb7ae6dcdbd1802151fce6e3871d8a2026332