Re: [Libreoffice] Wanted Presenter Screen
On Wed, Jan 12, 2011 at 02:13:15AM +0100, Rene Engelhard wrote: > My build log says the following in the build: [...] > cat description.tmp | sed s/UPDATED_PLATFORM/linux_x86_64/ > > ../../unxlngx6.pro/misc/PresenterScreen/description.xml > > cat: description.tmp: No such file or directory > ^^^ > cat manifest.xml | sed "s/SHARED_EXTENSION/.so/" > > ../../unxlngx6.pro/misc/PresenterScreen/META-INF/manifest.xml > > I think this is a blocker, isn't it? OK, and this is why - see sdext/source/presenter/makefile.mk: OOo: $(DESCRIPTION) $(PHONYDESC) : $$(@:f) @-$(MKDIRHIER) $(@:d) $(PERL) $(SOLARENV)$/bin$/licinserter.pl description.xml registry/LICENSE_xxx $(DESCRIPTION_TMP) @echo LAST_WITH_LANG=$(WITH_LANG) > $(ZIP1DIR)_lang_track.mk $(TYPE) $(DESCRIPTION_TMP) | sed s/UPDATED_PLATFORM/$(PLATFORMID)/ > $@ @@-$(RM) $(DESCRIPTION_TMP) us: $(DESCRIPTION) $(PHONYDESC) : $$(@:f) @-$(MKDIRHIER) $(@:d) @echo LAST_WITH_LANG=$(WITH_LANG) > $(ZIP1DIR)_lang_track.mk $(TYPE) description.tmp | sed s/UPDATED_PLATFORM/$(PLATFORMID)/ > $@ This commit broke it: commit dffdb2c6d18435360b05a4fbf111fcd86cca4248 Author: Fridrich Štrba Date: Mon Dec 13 21:19:49 2010 +0100 Don't bundle MSVC runtime + don't dupplicate licenses which did (amongst others) the following: @@ -365,19 +365,14 @@ $(ZIP1DIR)$/%.xcs : %.xcs @@-$(MKDIRHIER) $(@:d) $(GNUCOPY) $< $@ -# Temporary file that is used to replace some placeholders in description.xml. -DESCRIPTION_TMP:=$(ZIP1DIR)$/description.xml.tmp - .INCLUDE .IGNORE : $(ZIP1DIR)_lang_track.mk .IF "$(LAST_WITH_LANG)"!="$(WITH_LANG)" PHONYDESC=.PHONY .ENDIF # "$(LAST_WITH_LANG)"!="$(WITH_LANG)" $(DESCRIPTION) $(PHONYDESC) : $$(@:f) @-$(MKDIRHIER) $(@:d) -$(PERL) $(SOLARENV)$/bin$/licinserter.pl description.xml registry/LICENSE_xxx $(DESCRIPTION_TMP) @echo LAST_WITH_LANG=$(WITH_LANG) > $(ZIP1DIR)_lang_track.mk -$(TYPE) $(DESCRIPTION_TMP) | sed s/UPDATED_PLATFORM/$(PLATFORMID)/ > $@ -@@-$(RM) $(DESCRIPTION_TMP) +$(TYPE) description.tmp | sed s/UPDATED_PLATFORM/$(PLATFORMID)/ > $@ This means the description.xml in solver (used for packing up the oxt) doesn't get correctly written because being based on something not existing. Given the above commit was intentional and that we're in deep freeze I don't think we should readd the lines but just do diff --git a/sdext/source/presenter/makefile.mk b/sdext/source/presenter/makefile.mk index 696d0e5..9e25e34 100755 --- a/sdext/source/presenter/makefile.mk +++ b/sdext/source/presenter/makefile.mk @@ -372,7 +372,7 @@ PHONYDESC=.PHONY $(DESCRIPTION) $(PHONYDESC) : $$(@:f) @-$(MKDIRHIER) $(@:d) @echo LAST_WITH_LANG=$(WITH_LANG) > $(ZIP1DIR)_lang_track.mk -$(TYPE) description.tmp | sed s/UPDATED_PLATFORM/$(PLATFORMID)/ > $@ +$(TYPE) description.xml | sed s/UPDATED_PLATFORM/$(PLATFORMID)/ > $@ .ENDIF # "$(ENABLE_PRESENTER_SCREEN)" != "NO" Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] remove dead codes never passed through even in case of MACOSX
Hi Kohei, On Mon, 10 Jan 2011 14:45:01 -0500, Kohei Yoshida wrote: > Sorry it took us this long to reply. I was hoping that someone with Mac > build to verify, but even by looking at the code without run-time > testing it's easy to see your argument, and I agree with what you say. > > Pushed to the master. Thanks a lot. :-) Thank you for your review & pushing! Cheers, -- Takeshi Abe ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Wanted Presenter Screen
Hi, On Tue, Jan 11, 2011 at 02:13:59PM +0100, Jean-Baptiste Faure wrote: > Do you know where Presenter Screen is in rc2 ? > > Under Linux it is installed in /opt/libreoffice/share/extensions but > does not appear in Extensions Manager et seems to not work. ACK. Installed but not in extension manager. And description.xml is empty r...@frodo:~$ cat /usr/lib/libreoffice/share/extensions/presenter-screen/description.xml r...@frodo:~$ which explains why it doesn't appear anywhere. My build log says the following in the build: mkdir -p ../../unxlngx6.pro/misc cd ../../unxlngx6.pro/misc ; zipdep.pl -r -prefix ../../unxlngx6.pro/misc/ ../../unxlngx6.pro/bin/presenter-screen_develop.zip "*/com.sun.PresenterScreen/*.xhp" -x "*CVS*" -x "*.svn*" >> /home/rene/Debian/Pakete/LibreOffice/libreoffice-3.3.0/libreoffice-build/build/libreoffice-3.3.0.3/sdext/source/presenter/../../unxlngx6.pro/misc/presenter-screen_develop.dpzz zipdep -- version: 1.12 Multi Platform Enabled Edition cat ../../unxlngx6.pro/misc/presenter-screen.dpzz ../../unxlngx6.pro/misc/presenter-screen_develop.dpzz /tmp/mkHWfPhM | grep -v "CVS" | grep -v "\.svn" >> ../../unxlngx6.pro/misc/PresenterScreen.dpz cat /home/rene/Debian/Pakete/LibreOffice/libreoffice-3.3.0/libreoffice-build/build/libreoffice-3.3.0.3/solenv/src/version.c | sed s/_version.h/PresenterScreen.uno_version.h/ > ../../unxlngx6.pro/misc/PresenterScreen.uno_version.c cat description.tmp | sed s/UPDATED_PLATFORM/linux_x86_64/ > ../../unxlngx6.pro/misc/PresenterScreen/description.xml cat: description.tmp: No such file or directory ^^^ cat manifest.xml | sed "s/SHARED_EXTENSION/.so/" > ../../unxlngx6.pro/misc/PresenterScreen/META-INF/manifest.xml I think this is a blocker, isn't it? Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Really use BrOffice in the linux desktop files
-- Thorsten pgpZXXbMRns5g.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug triaging - bugs in OOo code base
Wols Lists wrote: > But all this is my personal imho, so don't take this as a guideline > unless nobody else chips in with a more definitive statement ... > Nothing definitive either, but to me, you make perfect sense here. :) Cheers, -- Thorsten pgpmrUCDuAA2e.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Splitting up source/header files for clarity
Soeren Moeller wrote:
> > I have now splitted the implementation of funcdesc.hxx out into a new
> > source file funcdesc.cxx.
>
Hi Soeren,
first off, many thanks for going to clean this up, your work here is
much appreciated! That split so far looks good.
> > In the process I also have extracted two new header files for
> > classes previously defined in global.cxx.
>
That's not necessary - ScResourcePublisher and ScFuncRes are only
used inside global.cxx, thus need no extra header - in fact, this
would not be idiomatic for c++. Simply leave them next to the code
that's using them.
See a few more comments inline of the actual patch:
> diff --git a/sc/inc/funcdesc.hxx b/sc/inc/funcdesc.hxx
> index d94d9b2..5f3ca7e 100644
> --- a/sc/inc/funcdesc.hxx
> +++ b/sc/inc/funcdesc.hxx
> @@ -34,39 +34,161 @@
> * global.cxx
> */
>
> +#include "scfuncs.hrc"
> +
> #include
> -#include
> +//#include
>
Please remove, don't comment out.
> +/**
> + Contains description of a function
> +*/
> class ScFuncDesc : public formula::IFunctionDescription
> {
> public:
> +/**
> + Constructor
> +*/
> +ScFuncDesc();
>
> -virtual ::rtl::OUString getFunctionName() const ;
> +/**
> + Destructor
> +*/
> +virtual ~ScFuncDesc();
>
Those doc-comments don't provide any value. Destructors and nullary
constructors seldomly need any comment at all, and for the class,
I'd suggest something along the lines of "Serves human-language
function descriptions within the calc formula parser framework" - or
somesuch. Did not look too closely, TBH. ;)
Two related golden rules for good comments/documentation:
Good comments don't repeat the code or explain it. They clarify its
intent. Comments should explain, at a higher level of abstraction
than the code, what it does.
or, put bluntly:
Don’t insult the reader’s intelligence ;)
> +/**
> + Resets the object in a clean manner
> +*/
> +void Clear();
>
For one-liners like this, I'd prefer this markup:
/// Resets the object as if it were newly constructed
(well, does clear() perform that? writing good comments usually
involves some detailed code review, or even debugging)
> +/**
> + Returns the category of the function
> +
> + @returnthe category of the function
> +*/
> virtual const formula::IFunctionCategory* getCategory() const ;
>
Since these methods are inherited from the IFunctionDescription
interface, I'd rather document them there (in the formula module).
That way, all derived classes benefit from your documentation (and
doxygen is smart enough to link that).
> +/* Public variables */
>
I'd consider this redundant. If you want to comment on the fact that
this class exposes its data structures, try to reconstruct the
reason why this is so - e.g. a bug number, for which it was added,
e.g. in a hurry before a shipment, to keep changes minimal (and
later cleanup was forgotten). Else, the reason would be "programmer
lazyness / sloppy coding", and that's a default assumption that
needs no comment. ;)
> -USHORTnFIndex;// Unique function index
> -USHORTnCategory; // Function category
> -USHORTnArgCount; // All parameter count,
> suppressed and unsuppressed
> -USHORTnHelpId;// HelpID of function
> +sal_uInt16nFIndex;// Unique function index
> +sal_uInt16nCategory; // Function category
> +sal_uInt16nArgCount; // All parameter count,
> suppressed and unsuppressed
> +sal_uInt16nHelpId;// HelpId of function
>
Ok to change, but I'd then also adapt the other occurences. And
maybe make that a separate patch - makes review easier, and ensures
that uncontroversial changes get in right away. :)
Could you quickly brush this up a bit & resend? As I said, otherwise
good & useful!
Cheers,
-- Thorsten
pgpGWEo7M0tbf.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] new cppcheck cleaning in cppu and cppuhelper + error in compilation
Le 11/01/2011 23:16, Julien Nabet a écrit :
Hello,
Here is a patch for cppcheck cleaning for cppu and cppuhelper
Compiling these modules was ok
I don't if it's a link but I had this in testtools (event after a rm
-rf unxlngi6.pro/ ) :
./constructors.uno.so
register component './bridgetest.uno.so' in registry
'uno_services.rdb' successful!
register component './cppobj.uno.so' in registry 'uno_services.rdb'
successful!
register component './constructors.uno.so' in registry
'uno_services.rdb' successful!
: &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/maryline/libreoffice-source/libo/clone/testing/testtools/unxlngi6.pro/lib:/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/lib
/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin/regcomp
-register -br ../../unxlngi6.pro/lib/uno_types.rdb -r
../../unxlngi6.pro/lib/uno_services.rdb \
-c javaloader.uno.so -c javavm.uno.so
javaloader.uno.so
javavm.uno.so
register component 'javaloader.uno.so' in registry
'../../unxlngi6.pro/lib/uno_services.rdb' successful!
register component 'javavm.uno.so' in registry
'../../unxlngi6.pro/lib/uno_services.rdb' successful!
: &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/maryline/libreoffice-source/libo/clone/testing/testtools/unxlngi6.pro/lib:/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/lib
/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin/regcomp
-register -br ../../unxlngi6.pro/misc/bridgetest/bootstrap.rdb -r
../../unxlngi6.pro/lib/uno_services.rdb -c \
file:///home/maryline/libreoffice-source/libo/clone/testing/testtools/source/bridgetest/../../unxlngi6.pro/class/testComponent.jar
\
-env:URE_INTERNAL_JAVA_DIR=file:///home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin
using loader com.sun.star.loader.Java2
file:///home/maryline/libreoffice-source/libo/clone/testing/testtools/source/bridgetest/../../unxlngi6.pro/class/testComponent.jar
/bin/bash: line 1: 3927 Segmentation fault
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/maryline/libreoffice-source/libo/clone/testing/testtools/unxlngi6.pro/lib:/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/lib
/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin/regcomp
-register -br ../../unxlngi6.pro/misc/bridgetest/bootstrap.rdb -r
../../unxlngi6.pro/lib/uno_services.rdb -c
file:///home/maryline/libreoffice-source/libo/clone/testing/testtools/source/bridgetest/../../unxlngi6.pro/class/testComponent.jar
-env:URE_INTERNAL_JAVA_DIR=file:///home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin
dmake: Error code 139, while making
'../../unxlngi6.pro/lib/uno_services.rdb'
dmake: '../../unxlngi6.pro/lib/uno_services.rdb' removed.
Julien
(LGPLv3+ / MPL)
It's better with the attachments :-)
commit bbb079a22252ad91bf6692628b60be10a17c1ec8
Author: Julien Nabet
Date: Tue Jan 11 22:14:32 2011 +0100
Some cppcheck cleaning
diff --git a/cppu/source/threadpool/jobqueue.cxx
b/cppu/source/threadpool/jobqueue.cxx
index 6db0d68..61b581c 100644
--- a/cppu/source/threadpool/jobqueue.cxx
+++ b/cppu/source/threadpool/jobqueue.cxx
@@ -184,7 +184,7 @@ namespace cppu_threadpool {
return m_lstCallstack.empty();
}
-sal_Bool JobQueue::isBusy()
+sal_Bool JobQueue::isBusy() const
{
return m_nToDo > 0;
}
diff --git a/cppu/source/threadpool/jobqueue.hxx
b/cppu/source/threadpool/jobqueue.hxx
index 7016fc0..9d4a35b 100644
--- a/cppu/source/threadpool/jobqueue.hxx
+++ b/cppu/source/threadpool/jobqueue.hxx
@@ -70,7 +70,7 @@ namespace cppu_threadpool
sal_Bool isEmpty();
sal_Bool isCallstackEmpty();
-sal_Bool isBusy();
+sal_Bool isBusy() const;
private:
::osl::Mutex m_mutex;
diff --git a/cppu/source/uno/lbmap.cxx b/cppu/source/uno/lbmap.cxx
index 12fbb25..b6da0b9 100644
--- a/cppu/source/uno/lbmap.cxx
+++ b/cppu/source/uno/lbmap.cxx
@@ -73,7 +73,7 @@ public:
inline Mapping( const Mapping & rMapping ) SAL_THROW( () );
inline ~Mapping() SAL_THROW( () );
inline Mapping & SAL_CALL operator = ( uno_Mapping * pMapping ) SAL_THROW(
() );
-inline Mapping & SAL_CALL operator = ( const Mapping & rMapping )
SAL_THROW( () )
+inline Mapping & SAL_CALL operator = ( const Mapping & rMapping )
SAL_THROW( () ) const
{ return operator = ( rMapping._pMapping ); }
inline uno_Mapping * SAL_CALL get() const SAL_THROW( () )
{ return _pMapping; }
commit e1c484742761b7e715963462ca5e13b4f70e799a
Author: Julien Nabet
Date: Tue Jan 11 23:10:40 2011 +0100
Some cppcheck cleaning
diff --git a/cppuhelper/qa/ifcontainer/cppu_ifcontainer.cxx
b/cppuhelper/qa/ifcontainer/cppu_ifcontainer.cxx
index 4f47fd4..79d14c1 100644
--- a/cppuhelper/qa/ifcontainer/cppu_ifcontainer.cxx
+++ b/cppuhelper/qa/ifcontainer/cppu_ifcontainer.cxx
@@ -129,7 +129,7 @@ namespac
[Libreoffice] [PATCH] new cppcheck cleaning in cppu and cppuhelper + error in compilation
Hello,
Here is a patch for cppcheck cleaning for cppu and cppuhelper
Compiling these modules was ok
I don't if it's a link but I had this in testtools (event after a rm -rf
unxlngi6.pro/ ) :
./constructors.uno.so
register component './bridgetest.uno.so' in registry 'uno_services.rdb'
successful!
register component './cppobj.uno.so' in registry 'uno_services.rdb'
successful!
register component './constructors.uno.so' in registry
'uno_services.rdb' successful!
: &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/maryline/libreoffice-source/libo/clone/testing/testtools/unxlngi6.pro/lib:/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/lib
/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin/regcomp
-register -br ../../unxlngi6.pro/lib/uno_types.rdb -r
../../unxlngi6.pro/lib/uno_services.rdb \
-c javaloader.uno.so -c javavm.uno.so
javaloader.uno.so
javavm.uno.so
register component 'javaloader.uno.so' in registry
'../../unxlngi6.pro/lib/uno_services.rdb' successful!
register component 'javavm.uno.so' in registry
'../../unxlngi6.pro/lib/uno_services.rdb' successful!
: &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/maryline/libreoffice-source/libo/clone/testing/testtools/unxlngi6.pro/lib:/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/lib
/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin/regcomp
-register -br ../../unxlngi6.pro/misc/bridgetest/bootstrap.rdb -r
../../unxlngi6.pro/lib/uno_services.rdb -c \
file:///home/maryline/libreoffice-source/libo/clone/testing/testtools/source/bridgetest/../../unxlngi6.pro/class/testComponent.jar
\
-env:URE_INTERNAL_JAVA_DIR=file:///home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin
using loader com.sun.star.loader.Java2
file:///home/maryline/libreoffice-source/libo/clone/testing/testtools/source/bridgetest/../../unxlngi6.pro/class/testComponent.jar
/bin/bash: line 1: 3927 Segmentation fault
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/maryline/libreoffice-source/libo/clone/testing/testtools/unxlngi6.pro/lib:/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/lib
/home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin/regcomp
-register -br ../../unxlngi6.pro/misc/bridgetest/bootstrap.rdb -r
../../unxlngi6.pro/lib/uno_services.rdb -c
file:///home/maryline/libreoffice-source/libo/clone/testing/testtools/source/bridgetest/../../unxlngi6.pro/class/testComponent.jar
-env:URE_INTERNAL_JAVA_DIR=file:///home/maryline/libreoffice-source/libo/solver/330/unxlngi6.pro/bin
dmake: Error code 139, while making
'../../unxlngi6.pro/lib/uno_services.rdb'
dmake: '../../unxlngi6.pro/lib/uno_services.rdb' removed.
Julien
(LGPLv3+ / MPL)
__
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités
http://mail.yahoo.fr Yahoo! Mail
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Splitting up source/header files for clarity
I have now splitted the implementation of funcdesc.hxx out into a new source file funcdesc.cxx. In the process I also have extracted two new header files for classes previously defined in global.cxx. I have corrected all includes and the result compiles for me, I have added the new source file to the relevant makefile.mk. Further I have added comments to the first class in funcdesc.hxx, I hope to document the others in a later patch. Please review my patch and apply if ok. Best Regards Sören Möller (LGPLv3+ / MPL) 2011/1/10 Tor Lillqvist : >> - Is it best to make one file for each class, or keep them together >> and make one funcdesc.cxx (containing four classes)? > > I'd say one file, funcdesc.cxx, corresponding to funcdesc.hxx. But that is > just my personal opinion. > >> - Should the license header for the new file(s) be a copy of the >> license header from global.cxx (as the code is copied out), or the new >> Libo header? > > As the code is the same (just rearranged into different files), the license > header should be the same. > >> - Is it enough to add the new file(s) to >> sc/source/core/data/makefile.mk for building, > > Yes, that should be enough for your testing; if/when you then want to make a > patch out of it, you need to git add the new files to your local repository > clone.) > > --tml > > > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Remove unused code
On Tue, 2011-01-11 at 22:23 +0100, Anders Jonsson wrote: > Some more commented code, this time in calc. All code has been commented > out at least since 2005. Looks good, pushed, thanks for this. >From the patch, it seems that means that ScRedlineOptionsTabPage is now an empty function that just returns 0 which suggests a follow up patch to remove it and all references to it, (note IMPL_LINK generally have a matching DECL_LINK somewhere). C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] De-Java-ise flat XML export
Hi Michael, On Tue, 11 Jan 2011 15:28:31 +, Michael Meeks wrote: [...] > > Good work. I believe we had some bug with a missing association > with .fodt .fods and .fodp etc. on Windows (and elsewhere) - since we > could not be confident that the filter would work; now we can. Any > chance you could hunt down and fix those associations ? > I'll have a look into that. Best regards, Peter ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Remove unused code
Some more commented code, this time in calc. All code has been commented
out at least since 2005.
Anders Jonsson,
(LGPLv3+,MPL)
>From 732c13e33612b80ce4e4479698e0710f791de2c4 Mon Sep 17 00:00:00 2001
From: Anders Jonsson
Date: Tue, 11 Jan 2011 22:17:44 +0100
Subject: Remove commented code
---
sc/source/filter/xml/xmlexprt.cxx | 99 -
sc/source/ui/drawfunc/futext.cxx | 67 -
sc/source/ui/optdlg/opredlin.cxx | 48 --
3 files changed, 0 insertions(+), 214 deletions(-)
diff --git a/sc/source/filter/xml/xmlexprt.cxx b/sc/source/filter/xml/xmlexprt.cxx
index 1c62691..9799058 100644
--- a/sc/source/filter/xml/xmlexprt.cxx
+++ b/sc/source/filter/xml/xmlexprt.cxx
@@ -1967,10 +1967,6 @@ void ScXMLExport::_ExportStyles( sal_Bool bUsed )
if (pSharedData->HasShapes())
{
GetShapeExport()->ExportGraphicDefaults();
-/*xInterface = xMultiServiceFactory->createInstance(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.drawing.Defaults")));
-uno::Reference xDrawProperties(xInterface, uno::UNO_QUERY);
-if (xDrawProperties.is())
-aStylesExp.exportDefaultStyle(xDrawProperties, rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(XML_STYLE_FAMILY_SD_GRAPHICS_NAME)), GetShapeExport()->CreateShapePropMapper(*this));*/
}
}
uno::Reference xStyleFamiliesSupplier (GetModel(), uno::UNO_QUERY);
@@ -2849,44 +2845,6 @@ sal_Bool ScXMLExport::IsMatrix (const ScAddress& aCell,
}
return sal_False;
-
-/* uno::Reference xArrayFormulaRange (xCell, uno::UNO_QUERY);
-if (xArrayFormulaRange.is())
-{
-rtl::OUString sArrayFormula(xArrayFormulaRange->getArrayFormula());
-if (sArrayFormula.getLength())
-{
-uno::Reference xMatrixSheetCellRange (xCell, uno::UNO_QUERY);
-if (xMatrixSheetCellRange.is())
-{
-uno::Reference xMatrixSheetCursor(xTable->createCursorByRange(xMatrixSheetCellRange));
-if (xMatrixSheetCursor.is())
-{
-xMatrixSheetCursor->collapseToCurrentArray();
-uno::Reference xMatrixCellAddress (xMatrixSheetCursor, uno::UNO_QUERY);
-if (xMatrixCellAddress.is())
-{
-aCellAddress = xMatrixCellAddress->getRangeAddress();
-if ((aCellAddress.StartColumn == nCol && aCellAddress.StartRow == nRow) &&
-(aCellAddress.EndColumn > nCol || aCellAddress.EndRow > nRow))
-{
-bIsFirst = sal_True;
-return sal_True;
-}
-else if (aCellAddress.StartColumn != nCol || aCellAddress.StartRow != nRow ||
-aCellAddress.EndColumn != nCol || aCellAddress.EndRow != nRow)
-return sal_True;
-else
-{
-bIsFirst = sal_True;
-return sal_True;
-}
-}
-}
-}
-}
-}
-return sal_False;*/
}
sal_Bool ScXMLExport::GetCellText (ScMyCell& rMyCell, const ScAddress& aPos) const
@@ -2895,17 +2853,9 @@ sal_Bool ScXMLExport::GetCellText (ScMyCell& rMyCell, const ScAddress& aPos) con
return sal_True;
else
{
-/* if (!rMyCell.bHasXText)
-{
-rMyCell.xText.set(xCurrentTableCellRange->getCellByPosition(rMyCell.aCellAddress.Column, rMyCell.aCellAddress.Row), uno::UNO_QUERY);
-rMyCell.bHasXText = sal_True;
-}*/
-// if (rMyCell.xText.is())
-// {
rMyCell.sStringValue = ScCellObj::GetOutputString_Impl(pDoc, aPos);
rMyCell.bHasStringValue = sal_True;
return sal_True;
-// }
}
}
@@ -3199,15 +3149,6 @@ void ScXMLExport::ExportShape(const uno::Reference < drawing::XShape >& xShape,
//BM }
//BM }
-/* SchMemChart* pMemChart = pDoc->FindChartData(sName);
-if (pMemChart && pMemChart->GetSeriesAddresses().getLength())
-{
-bMemChart = sal_True;
-rtl::OUString sRanges(pMemChart->getXMLStringForChartRange());
-if (sRanges.getLength())
-AddAttribute(XML_NAMESPACE_DRAW, XML_NOTIFY_ON_UPDATE_OF_RANGES, sRanges);
-GetShapeExport()->exportShape(xShape, SEF_EXPORT_NO_CHART_DATA | SEF_DEFAULT, pPoint);
-}*/
}
}
}
@@ -3403,46 +3344,6 @@ void ScXMLExport::WriteAnnotation(ScMyCell& rMyCell)
{
if( rMyCell.bHasAnnotation && rMyCell.xAnnotation.is())
{
-/* rtl::OUString sAuthor(rMyCell.xAnnotation->getAuthor());
-
[Libreoffice] [PUSHED] Re: [PATCH] Translated comments from German to English / Removed unnecessary comments
On Tue, 2011-01-11 at 21:57 +0100, Christina Roßmanith wrote: > Hi, > > some translations and removed comments. Looks good, pushed, thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] cppcheck cleaning in xmlsecurity
On Tue, 2011-01-11 at 21:45 +0100, Julien Nabet wrote: > Hello, > > Here is a patch for cppcheck cleaning in xmlsecurity > Compiling was ok Looks good to me, mscrypt stuff is windows only, but looks trivial enough that it should build there. Pushed, thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Translated comments from German to English / Removed unnecessary comments
Hi,
some translations and removed comments.
Christina
>From 35effb9535c170a3bedbb55b941d5d59b4aac8cb Mon Sep 17 00:00:00 2001
From: Christina Rossmanith
Date: Tue, 11 Jan 2011 21:53:29 +0100
Subject: [PATCH] Translated comments from German to English / Removed unnecessary comments
---
sc/inc/drwlayer.hxx | 15 +++
sc/inc/editutil.hxx | 18 ++
sc/inc/fielduno.hxx |6 +++---
sc/inc/filter.hxx | 48 ++--
4 files changed, 38 insertions(+), 49 deletions(-)
diff --git a/sc/inc/drwlayer.hxx b/sc/inc/drwlayer.hxx
index 3429f10..baa8098 100644
--- a/sc/inc/drwlayer.hxx
+++ b/sc/inc/drwlayer.hxx
@@ -74,8 +74,8 @@ public:
// ---
//
-// Das Anpassen der Detektiv-UserData muss zusammen mit den Draw-Undo's
-// in der SdrUndoGroup liegen, darum von SdrUndoAction abgeleitet:
+// Adjusting of detective UserData and draw undo's both have to be in SdrUndoGroup;
+// therefore derived from SdrUndoAction
class ScUndoObjData : public SdrUndoObj
{
@@ -133,17 +133,17 @@ public:
void ScRemovePage( SCTAB nTab );
void ScRenamePage( SCTAB nTab, const String& rNewName );
void ScMovePage( USHORT nOldPos, USHORT nNewPos );
-// inkl. Inhalt, bAlloc=FALSE -> nur Inhalt
+// incl. content, bAlloc=FALSE -> only content
void ScCopyPage( USHORT nOldPos, USHORT nNewPos, BOOL bAlloc );
ScDocument* GetDocument() const { return pDoc; }
-void UpdateBasic();// DocShell-Basic in DrawPages setzen
+void UpdateBasic();// set DocShell Basic in DrawPages
void UseHyphenator();
BOOL GetPrintArea( ScRange& rRange, BOOL bSetHor, BOOL bSetVer ) const;
-// automatische Anpassungen
+// automatical adjustments
void EnableAdjust( BOOL bSet = TRUE ) { bAdjustEnabled = bSet; }
@@ -188,11 +188,10 @@ public:
String GetNewGraphicName( long* pnCounter = NULL ) const;
void EnsureGraphicNames();
-// Verankerung setzen und ermitteln
static void SetAnchor( SdrObject*, ScAnchorType );
static ScAnchorType GetAnchor( const SdrObject* );
-// Positionen fuer Detektivlinien
+// positions for detektive lines
static ScDrawObjData* GetObjData( SdrObject* pObj, BOOL bCreate=FALSE );
// The sheet information in ScDrawObjData isn't updated when sheets are inserted/deleted.
@@ -215,7 +214,7 @@ public:
static ScMacroInfo* GetMacroInfo( SdrObject* pObj, BOOL bCreate = FALSE );
private:
-static SfxObjectShell* pGlobalDrawPersist; // fuer AllocModel
+static SfxObjectShell* pGlobalDrawPersist; // for AllocModel
public:
static void SetGlobalDrawPersist(SfxObjectShell* pPersist);
protected:
diff --git a/sc/inc/editutil.hxx b/sc/inc/editutil.hxx
index 2d8c307..e6abedc 100644
--- a/sc/inc/editutil.hxx
+++ b/sc/inc/editutil.hxx
@@ -51,7 +51,7 @@ class ScEditUtil
SCROW nRow;
SCTAB nTab;
Point aScrPos;
-OutputDevice* pDev; // MapMode muss eingestellt sein
+OutputDevice* pDev; // MapMode has to be set
double nPPTX;
double nPPTY;
Fraction aZoomX;
@@ -178,8 +178,6 @@ private:
void Init(const ScPatternAttr& rPattern);
public:
ScTabEditEngine( ScDocument* pDoc ); // Default
-// pEnginePool = ScDocument.GetEnginePool()
-// pTextObjectPool = ScDocument.GetEditPool()
ScTabEditEngine( const ScPatternAttr& rPattern,
SfxItemPool* pEnginePool,
SfxItemPool* pTextObjectPool = NULL );
@@ -188,9 +186,9 @@ public:
struct ScHeaderFieldData
{
-String aTitle;// Titel oder Dateiname wenn kein Titel
-String aLongDocName; // Pfad und Dateiname
-String aShortDocName; // nur Dateiname
+String aTitle;// title or file name (if no title)
+String aLongDocName; // path and file name
+String aShortDocName; // pure file name
String aTabName;
Date aDate;
Time aTime;
@@ -202,15 +200,13 @@ struct ScHeaderFieldData
};
-// fuer Feldbefehle in der Tabelle
+// for field commands (or just fields?) in a table
class SC_DLLPUBLIC ScFieldEditEngine : public ScEditEngineDefaulter
{
private:
BOOL bExecuteURL;
public:
-// pEnginePool = ScDocument.GetEnginePool()
-// pTextObjectPool = ScDocument.GetEditPool()
ScFieldEditEngine( SfxItemPool* pEnginePool,
SfxItemPool* pTextObjectPool = NULL,
BOOL bDeleteEnginePool = FALSE );
@@ -249,15 +245,13 @@ class ScNoteEditEngine : public ScEditEngineDefaulter
{
public:
-// pEnginePool = ScDocument.GetEnginePool()
-// pTextObjectPool = ScDocument.GetEditPool()
ScNoteEditEngine( SfxItemPool* pEnginePool,
SfxItemPool* pTextObjectPool = NULL,
BOOL bDeleteEnginePool = FALSE );
};
[Libreoffice] [PATCH] cppcheck cleaning in xmlsecurity
Hello,
Here is a patch for cppcheck cleaning in xmlsecurity
Compiling was ok
Julien
(LGPLv3+ / MPL)
commit 4258d2cdd4ecfba8dfe76ad19da998777c8056f4
Author: Julien Nabet
Date: Tue Jan 11 21:40:43 2011 +0100
Some cppcheck cleaning
diff --git
a/xmlsecurity/source/xmlsec/mscrypt/securityenvironment_mscryptimpl.cxx
b/xmlsecurity/source/xmlsec/mscrypt/securityenvironment_mscryptimpl.cxx
index be0e1ec..96c8276 100644
--- a/xmlsecurity/source/xmlsec/mscrypt/securityenvironment_mscryptimpl.cxx
+++ b/xmlsecurity/source/xmlsec/mscrypt/securityenvironment_mscryptimpl.cxx
@@ -154,21 +154,21 @@ SecurityEnvironment_MSCryptImpl ::
~SecurityEnvironment_MSCryptImpl() {
if( !m_tSymKeyList.empty() ) {
std::list< HCRYPTKEY >::iterator symKeyIt ;
-for( symKeyIt = m_tSymKeyList.begin() ; symKeyIt !=
m_tSymKeyList.end() ; symKeyIt ++ )
+for( symKeyIt = m_tSymKeyList.begin() ; symKeyIt !=
m_tSymKeyList.end() ; ++symKeyIt )
CryptDestroyKey( *symKeyIt ) ;
}
if( !m_tPubKeyList.empty() ) {
std::list< HCRYPTKEY >::iterator pubKeyIt ;
-for( pubKeyIt = m_tPubKeyList.begin() ; pubKeyIt !=
m_tPubKeyList.end() ; pubKeyIt ++ )
+for( pubKeyIt = m_tPubKeyList.begin() ; pubKeyIt !=
m_tPubKeyList.end() ; ++pubKeyIt )
CryptDestroyKey( *pubKeyIt ) ;
}
if( !m_tPriKeyList.empty() ) {
std::list< HCRYPTKEY >::iterator priKeyIt ;
-for( priKeyIt = m_tPriKeyList.begin() ; priKeyIt !=
m_tPriKeyList.end() ; priKeyIt ++ )
+for( priKeyIt = m_tPriKeyList.begin() ; priKeyIt !=
m_tPriKeyList.end() ; ++priKeyIt )
CryptDestroyKey( *priKeyIt ) ;
}
@@ -266,12 +266,6 @@ void SecurityEnvironment_MSCryptImpl :: setCryptoProvider(
HCRYPTPROV aProv ) th
}
if( aProv != NULL ) {
-/*- Replaced by direct adopt for WINNT support
-if( !CryptContextAddRef( aProv, NULL, NULL ) )
-throw Exception() ;
-else
-m_hProv = aProv ;
-*/
m_hProv = aProv ;
}
}
@@ -322,16 +316,12 @@ void SecurityEnvironment_MSCryptImpl :: adoptSymKey(
HCRYPTKEY aSymKey ) throw(
if( aSymKey != NULL ) {
//First try to find the key in the list
-for( keyIt = m_tSymKeyList.begin() ; keyIt != m_tSymKeyList.end() ;
keyIt ++ ) {
+for( keyIt = m_tSymKeyList.begin() ; keyIt != m_tSymKeyList.end() ;
++keyIt ) {
if( *keyIt == aSymKey )
return ;
}
//If we do not find the key in the list, add a new node
-/*- Replaced with directly adopt for WINNT 4.0 support
-if( !CryptDuplicateKey( aSymKey, NULL, 0, &symkey ) )
-throw RuntimeException() ;
-*/
symkey = aSymKey ;
try {
@@ -347,7 +337,7 @@ void SecurityEnvironment_MSCryptImpl :: rejectSymKey(
HCRYPTKEY aSymKey ) throw(
std::list< HCRYPTKEY >::iterator keyIt ;
if( aSymKey != NULL ) {
-for( keyIt = m_tSymKeyList.begin() ; keyIt != m_tSymKeyList.end() ;
keyIt ++ ) {
+for( keyIt = m_tSymKeyList.begin() ; keyIt != m_tSymKeyList.end() ;
++keyIt ) {
if( *keyIt == aSymKey ) {
symkey = *keyIt ;
CryptDestroyKey( symkey ) ;
@@ -364,7 +354,7 @@ HCRYPTKEY SecurityEnvironment_MSCryptImpl :: getSymKey(
unsigned int position )
unsigned int pos ;
symkey = NULL ;
-for( pos = 0, keyIt = m_tSymKeyList.begin() ; pos < position && keyIt !=
m_tSymKeyList.end() ; pos ++ , keyIt ++ ) ;
+for( pos = 0, keyIt = m_tSymKeyList.begin() ; pos < position && keyIt !=
m_tSymKeyList.end() ; ++pos , ++keyIt ) ;
if( pos == position && keyIt != m_tSymKeyList.end() )
symkey = *keyIt ;
@@ -378,16 +368,12 @@ void SecurityEnvironment_MSCryptImpl :: adoptPubKey(
HCRYPTKEY aPubKey ) throw(
if( aPubKey != NULL ) {
//First try to find the key in the list
-for( keyIt = m_tPubKeyList.begin() ; keyIt != m_tPubKeyList.end() ;
keyIt ++ ) {
+for( keyIt = m_tPubKeyList.begin() ; keyIt != m_tPubKeyList.end() ;
++keyIt ) {
if( *keyIt == aPubKey )
return ;
}
//If we do not find the key in the list, add a new node
-/*- Replaced with directly adopt for WINNT 4.0 support
-if( !CryptDuplicateKey( aPubKey, NULL, 0, &pubkey ) )
-throw RuntimeException() ;
-*/
pubkey = aPubKey ;
try {
@@ -403,7 +389,7 @@ void SecurityEnvironment_MSCryptImpl :: rejectPubKey(
HCRYPTKEY aPubKey ) throw(
std::list< HCRYPTKEY >::iterator keyIt ;
if( aPubKey != NULL ) {
-for( keyIt = m_tPubKeyList.begin() ; keyIt != m_tPubKeyList.end() ;
keyIt ++ ) {
+for( keyIt = m_tPubKeyList.begin() ; keyIt != m_tPubKeyList.end() ;
++keyIt ) {
if( *keyIt == aPubKey ) {
pubkey = *keyIt ;
CryptDestroyKey( pubkey ) ;
Re: [Libreoffice] Localizations of UI and help - what languages does LibO support?
On 06/01/11 11:14, Andras Timar wrote: > * Gaelic (Scots) (gd), Kirghiz (ky), Lao (lo), Malay (ms), Papiamento > (pap), Pushto (ps), ??? (sc), Tigrinya (ti), and Urdu (ur) are included > despite the fact that in the source there are no translations at all in > these languages, so you basically package en-US strings. Gaelic (Scots) > (gd) translation exists at > ftp://ftp.linux.cz/pub/localization/OpenOffice.org/devel/build/Files/OOO330/GSI_gd.sdf.bz2 > - maybe it can be added. Mmm. Be careful describing Gaelic as Scots. Scots is actually a language in its own right - a variant of English! (A bit of history - Scots is the language spoken in the lowlands, where the people are descended from the Angle invaders. These were the Sassenachs. The entire history of this area is well confusing - for example Scotia (from where the Scots take their name) is actually Ireland! And the whole area has changed massively in recent centuries what with mass migration, ethnic cleansing, etc etc) (And English is the language spoken by the Saxons! :-) Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Review request
Hello, I'ld like to get a crasher fix around the enhanced fields into libreoffice-3-3 branch... Could anyone review and cherry-pick this commit? http://cgit.freedesktop.org/libreoffice/writer/commit/?id=0921bd5dc88dfd212fc5a332e0902347377be119 Thanks, -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] development summary: year 2011, week 1
Hi, this time a brief summary of what happened during the 1st week in 2011 on LibreOffice repositories and the living branches. bugfixes---.txt lists all commits that reference a proper bug id from a variety of trackers, i.e. #i... referring to the OpenOffice issuezilla, fdo# to freedesktop, rhbz# to RedHat bugzilla. commit-log---.txt lists all relevant commits on the actual source repositories. Many thanks to all contributors - you make all the difference! Best Regards, Petr + common: + Resolves: fdo#32897 strip out template language tags [Caolán McNamara] + bootstrap: + add de-branded MSI installation artwork, bug#32435 [Christoph Noack] + build: + Updated sdf/pot/po - License Dialog - fdo#32563 [Andras Timar] + calc: + calc64: #i116164# performance of filters with many filtered ranges [Niklas Nebel] + Make more room for Portuguese locale. (fdo#32823) [Kohei Yoshida] + components: + Fixed layout breakage for KDE, X11 and (possibly) Mac. (fdo#32133) [Kohei Yoshida] + impress208: #i115944# fixing large ooxml files [Christian Lippka ORACLE] + Make the Reset help agent button wider for Italian text. (fdo#32133) [Kohei Yoshida] + extensions: + impress208: #164351# patching xpdf to patchlevel 3.02pl5 [Christian Lippka] + extras: + technical.dic: more words from deb#425791 [Rene Engelhard] + filters: + fdo#32600# fix specific core dump on read [Noel Power] + impress208: #164349# small TGAReader improvement [Christian Lippka ORACLE] + ooo33gsl13: #i116085# adjust PageRange handling in writer PDF export [Philipp Lohmann [pl]] + libs-core: + fdo#32840: make unopkg --suppress-license skip license in all cases [Cédric Bosdonnat] + Related: fdo#32840 update help line for unopkg --supress-license [David Tardon] + Show the license information in a separate, localizable dialog; fdo#32563. [Jan Holesovsky] + libs-extern-sys: + fixed a crash - fdo#32850 [Laszlo Nemeth] + impress208: #164350# better xpath handling [Christian Lippka ORACLE] + libs-gui: + Resolves: rhbz#666088 clean up search cache singleton in correct order [Caolán McNamara] + l10n: + Removed mentions of Oracle from translations - fdo#32126 [Andras Timar] + writer: + Resolves: fdo#32633 rearrange title dialog to get translations to fix (cherry picked from commit 049b8e51b06f64fa8b353d65589b55d60ce5b83e) [Caolán McNamara] + Resolves: fdo#32633 stretch title dialog to get translations to fix (cherry picked from commit c75a9e280e3f1282c25d7c1f572cfa4bad3f8ba8) [Caolán McNamara] + We need to move to the next record during mail merge. (fdo#32790) [Kohei Yoshida] + common: + fdo#32869: Added navigation buttons to writer [Maja Djordjevic] + Resolves: fdo#32897 strip out template language tags [Caolán McNamara] + bootstrap: + Resolves: #i113163# drop uninitialized variable warning [Caolán McNamara] + calc: + calc64: #i116164# performance of filters with many filtered ranges [Niklas Nebel] + Make more room for Portuguese locale. (fdo#32823) [Kohei Yoshida] + components: + Fixed layout breakage for KDE, X11 and (possibly) Mac. (fdo#32133) [Kohei Yoshida] + Make the Reset help agent button wider for Italian text. (fdo#32133) [Kohei Yoshida] + filters: + fdo#32600# fix specific core dump on read [Noel Power] + impress: + fix shapes rendering order n#656934 [Radek Doulik] + libs-core: + fdo#32840: make unopkg --suppress-license skip license in all cases [Cédric Bosdonnat] + Related: fdo#32840 update help line for unopkg --supress-license [David Tardon] + Related: rhbz#668057 Only need to know this if pInfo is non-null [Caolán McNamara] + libs-extern-sys: + fixed a crash - fdo#32850 [Laszlo Nemeth] + libs-gui: + Resolves: #i109702# basic editor reads past end of string when line ie just ' [Andreas Bregas] + Resolves: rhbz#666088 clean up search cache singleton in correct order [Caolán McNamara] + writer: + bnc#660816 improve formfield checkbox binary export ( and import ) [Noel Power] + Related: fdo#32463 add cppunit test for SwFileNameFieldType [Caolán McNamara] + Resolves: fdo#32633 stretch title dialog to get translations to fix [Caolán McNamara] + We need to move to the next record during mail merge. (fdo#32790) [Kohei Yoshida] + common: + Croatian (hr) translation update [Robert Sedak] + CWS-TOOLING: integrate CWS impress208 [Kurt Zenker] + CWS-TOOLING: integrate CWS ooo33gsl13 [Kurt Zenker] + Fix distro specific about intro hadling [Petr Mladek] + Merge commit 'ooo/OOO330_m19' into libreoffice-3-3 [Petr Mladek] + New release of Linux Libertine G fonts [Andras Timar] + Resolves: fdo#32897 strip out template language tags [Caolán McNamara] + bootstrap: + add de-branded MSI installation artwork, bug#32435 [Christoph Noack] + Added ast, ca-XV, and id, removed sc (postset.mk) [Andras Timar] + BrOffice branding for windows shortcuts
Re: [Libreoffice] Horizontal glyph adjustments are ignored with ICU layout
On Sat, Jan 08, 2011 at 11:14:49AM +0630, Keith Stribley wrote: > Hi Khaled, Michael, > > On 07/01/2011 8:21 PM, Michael Meeks wrote: > > > > Drat; we took ages to reply. I suspect Thorsten might be able to help, > >but failing that the best text expert I'm aware of is Tim (CC'd) who may > >be able to give some advice. SIL's Graphite integration would > >undoubtedly have fallen over the same sort of problems, and no doubt he > >can give some pointers to how to work around it - Tim ? :-) > > I've been working on the Graphite integration more recently, so I'll > try to make a few comments. > > > >>Anyway, it turned out that the issue is not specific to kerning nor > >>Arabic, but affects all horizontal glyph positioning in the ICU layout > >>path; the problem does not show on Windows nor with Graphite fonts and > >>of course not with con-CTL. > It certainly sounds like it is worth fixing. > >>The X adjustment of glyph widths is simply ignored, and glyphs are drawn > >>stacked after each other baased on their original width, which results in > >>kerning being ignored as well as other forms of glyph positioning like > >>cursive anchors, however vertical glyph positions (in the Y access) are > >>OK. > > It depends on the rendering path, different parts of libo call the > layout methods in different ways. I've noted that at some stage, but after several hair pulling nights I lost track of what is doing what. > >>In source/glyphs/gcach_layout.cxx, ICU's layoutChars() is called and new > >>glyph indices and positions are returned, which is then fed into > >>SalLayout in the form of GlyphItem's. Though GlyphItem has maLinearPos > >>which holds its absolute position, many places in the code re-calculate > >>glyph position from its mnOrigWidth (original glyph width) and mnNewWidth > >>(width after adjustments), but the ICU path simply sets mnNewWidth to > >>mnOrigWidth since ICU layout engine does not return individual glyph > >>widths, resulting in failure of glyph position re-calculation which > >>manifests in this bug. > >> > >>As a prove of concept, the attached patch trays to set mnNewWidth in a > >>very hackish way by subtracting current glyph position from the of next > >>non-diacritic (+ve) glyph. It does indeed fix the problem (see the > >>attached screenshots), but it looks very unreliable to me. > > I think subtracting the glyph positions is a reasonable approach, > something similar is done in the graphite integration code to get > the numbers into a form that works with libo's logic. There are two main issues I'm worried about; combining marks and reordered glyphs. Detection of combining marks currently is just a hack (both on old code and the patch) and I'm not sure how reliable is to assume all combining marks have non +ve width (I've seen fonts having +ve width marks), ideally marks should be marked is such in GDEF table, but ICU don't pass such information to us, nor do I know how +ve width marks are handled. Also glyph reordering can be an issue if ICU is outputting glyphs in logical rather than visual order. > >>May be a > >>cleaner solution is to re-implement all the broken virtual methods to > >>eliminate the re-calculation part. > > Do you mean implement ICU/ServerFontLayout specific versions of the > methods that ServerFontLayout is currently using directly from > GenericSalLayout? I think that would be quite a lot of work and you > may still need something like mnNewWidth calculated in a similar way > to your patch. I admit that GraphiteLayout does reimplement those > methods so if it turns out there is an assumption in > GenericSalLayout which doesn't fit well with ICU then that might > still make sense. I see. > The recalculations are done in several situations such as for > justification, text expansion, text contraction. In writer the text > is rendered once with a small font size and once with a large font > size. It then does some calculations to try to give a more accurate > WYSIWYG positioning of the text on screen which results in small > adjustments being applied to the glyph positions (but the request to > adjust is based on characters). It is probably the later which is > interacting with the incorrect mnNewWidth to give the bad positions. > > Looking more carefully at the patch, there are a few points that may > need more consideration: > > a) It may be possible for glyphs to be out of order, in which case > > nNewWidth = pNextPos->fX - pPos->fX; > > might result in a negative value even when the nominal > nNextGlyphWidth is positive, which could cause problems. I've thought of that too, but shouldn't glyph output be in visual order? > b) The glyphs are resorted a bit later in > IcuLayoutEngine::operator() with a rLayout.SortGlyphItems(); call. > This might upset the new width values. However, it seems to only > reorder diacritics and those are skipped for the width calculation, > so that is probably alright. > > c) For the last glyph in a run, pNextPos wil
[Libreoffice] [PUSHED] De-Java-ise flat XML export
Hi Peter, On Mon, 2011-01-10 at 21:45 +0100, Peter Jentsch wrote: > I'm sending two more patches which aim to replace the xslt based flat > xml filter implementation by a different one directly interfacing with > the xml filter framework. It's actually simply copied from the ODK > example and only slightly modified. Nice :-) I tested it, it is extremely fast and light; the code looks great - so I pushed it :-) Good work. I believe we had some bug with a missing association with .fodt .fods and .fodp etc. on Windows (and elsewhere) - since we could not be confident that the filter would work; now we can. Any chance you could hunt down and fix those associations ? Many thanks, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] De-Java-ise flat XML export
Hi Peter, Jan is on vacation for a week; so you get me instead :-) On Fri, 2011-01-07 at 22:03 +0100, Peter Jentsch wrote: > here's another patch: split-long-lines.xsl seems to be missing from the > list of files in file_xsltfilter.scp. The attached patch should fix > that. Wonderful; thanks - pushed that. ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Remove commented code
Hi Anders, On Tue, 2011-01-11 at 11:36 +0100, Anders Jonsson wrote: > This patch removes unused code from filters. All code has been commented > out at least since 2005. Lovely; pushed, Thanks ! :-) Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] cppcheck: ignore "The class 'X' does not have a constructor"
Ignore those warnings for now, cppcheck 1.47 will fix (probably all/more of) them, see http://sourceforge.net/apps/trac/cppcheck/ticket/2307 for details. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Wanted Presenter Screen
Hi all, Do you know where Presenter Screen is in rc2 ? Under Linux it is installed in /opt/libreoffice/share/extensions but does not appear in Extensions Manager et seems to not work. Had I been missing something ? Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Translations in sw/inc/doc.hxx
On Mon, 2011-01-10 at 16:27 +0100, Christoph Herzog wrote: > Subject: [PATCH] Translations in sw/inc/doc.hxx Looks good to me, all pushed, thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Translations sw/inc: crsrsh.hxx, cshtyp.hxx
On Mon, 2011-01-10 at 16:07 +0100, Christoph Herzog wrote: > Subject: [PATCH] Translations sw/inc: crsrsh.hxx, cshtyp.hxx Excellent, thanks for these, pushed now. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] 3 more translations in writer/sw/inc
On Mon, 2011-01-10 at 15:59 +0100, Christoph Herzog wrote: > Subject: [PATCH] 3 more translations in writer/sw/inc Looks good, thanks for this, pushed. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Minor translations of comments for 3 files in writer/sw/inc
Looks reasonable to me, pushed, thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED, partial] Re: [PATCH] cppcheck changes at writer
Hmm, the first hunk adds a "delete pFmt" fix. I believe that's a false positive from cppcheck, the pFmt comes from MakeSectionFmt and the returned pFmt is placed on pSectionFmtTbl before being returned and pSectionFmtTbl owns it and will release it later on. So I remove that hunk. The itemset from GetCollItemSet might indeed leak under some circumstances, but in others it doesn't, so it doesn't looks safe to unconditionally delete pCollSet; in the last hunk either though it does look dodgy. The other changes to use prefix variants of the ++ and reduce the scope of some variables looks good, so pushed those bits. Thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [REWORKED][PUSHED] Standard-color-palette-updates
Hi Petr, all, Petr Mladek schrieb: Bernhard Dippold píše v Út 11. 01. 2011 v 00:37 +0100: Hi Petr, Kami, all, Petr Mladek schrieb: Kálmán „KAMI” Szalai píše v So 08. 01. 2011 v 15:28 +0100: Hi All, Updated patch, Remove LibreOffice colors from standard, and updates libreoffice.soc with latest colors. I hope it is fine for us. looked fine => pushed Note that the palette name does not include year. Is it OK? I think Christoph called the palette "LibreOffice_Initial_Branding_Colors.soc", because they will change during the next year. His next palette would probably be called "LibreOffice_Community_Branding_Colors.soc". My approach was only a bit different: I added the year in order to allow further changes to the branding colors without the necessity to call the next branding effort by a different name. Hmm, I see libreoffice.soc in the installed system. If you think the file name is too long, we can omit "Initial" (because the year is unique - we should not come up with more than one iteration on the branding colors during one year). "Colors" is superfluous too for a color palette, so my favorite name would be LibreOffice_Branding_2010.soc This would allow to create new Branding palettes every now and then without the problem of visually different documents in different versions of LibreOffice (when a color of the palette has been updated in-between). Well, this should not be a problem. The colors are saved using RGB values and not the color name. I have just used "LibreOffice Green 3" in an .odg document, removed libreoffice.soc from the system and user configuration, opened the file again, the color stayed the same, it was just not named. Thanks for trying out! There might some seldom UX cases, where user don't get the results they look for (like modified colors when working on a document created with an older version of LibO - especially if the changes are only visible in comparison to the old color). But this is not related to the name of the color palette, so I think we can leave this patch as it is now, as the name of the palette is not really important in most cases. If someone stumbles upon a problem, a bug report will probably easy to be handled... Best regards Bernhard. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Remove commented code
This patch removes unused code from filters. All code has been commented
out at least since 2005.
Anders Jonsson,
(LGPLv3+,MPL)
>From 60c2f1e10f45fc0b584df713ff4b269978613580 Mon Sep 17 00:00:00 2001
From: Anders Jonsson
Date: Tue, 11 Jan 2011 11:20:36 +0100
Subject: Remove commented code
---
binfilter/bf_sch/source/core/sch_chtmode7.cxx | 80 ---
binfilter/bf_sfx2/source/appl/sfx2_appbas.cxx | 69 +--
binfilter/bf_svtools/source/items1/svt_nranges.cxx | 57 -
binfilter/bf_svx/source/unoedit/svx_unofield.cxx | 248
binfilter/bf_sw/source/core/unocore/sw_unoobj2.cxx | 121 --
binfilter/bf_sw/source/filter/excel/sw_excread.cxx | 91 ---
.../bf_xmloff/source/draw/xmloff_ximp3dobject.cxx | 60 -
7 files changed, 1 insertions(+), 725 deletions(-)
diff --git a/binfilter/bf_sch/source/core/sch_chtmode7.cxx b/binfilter/bf_sch/source/core/sch_chtmode7.cxx
index 9bb0dee..66cc309 100644
--- a/binfilter/bf_sch/source/core/sch_chtmode7.cxx
+++ b/binfilter/bf_sch/source/core/sch_chtmode7.cxx
@@ -410,55 +410,6 @@ namespace binfilter {
/*N*/ return pOutliner;
/*N*/ }
-/*
-UINT32 ChartModel::ValFor mat () const
-{
-return nValFo rmat;
-}
-
-
-UINT32& ChartModel::ValForm at()
-{
-return nVal Format;
-}
-
-
-UINT32 ChartModel::PercentVa lFormat () const
-{
-return nPercentV alFormat;
-}
-
-
-UINT32& ChartModel::Per centValFormat ()
-{
-return nPercentValFo rmat;
-}
-
-
-UINT32 ChartModel::Des crFormat () const
-{
-return nDescrFor mat;
-}
-
-
-UINT32& ChartModel::Desc rFormat()
-{
-return nDes crFormat;
-}
-
-
-UINT32 ChartModel::PercentD escrFormat () const
-{
-return nPercentDescrFo rmat;
-}
-
-
-UINT32& ChartModel::Percent DescrF ormat ()
-{
-return nPercentDescr Format;
-}
-
-*/
/*N*/ BOOL ChartModel::IsInitialized() const
/*N*/ {
/*N*/ return mbIsInitialized;
@@ -581,37 +532,6 @@ UINT32& ChartModel::Percent DescrF ormat ()
/*N*/ case CHSTYLE_2D_PERCENTCOLUMN :
/*N*/ return FALSE;
-// case CHSTYLE_2D_LINE :
-// case CHSTYLE_2D_STACKEDLINE :
-// case CHSTYLE_2D_PERCENTLINE :
-// case CHSTYLE_2D_LINESYMBOLS :
-// case CHSTYLE_2D_STACKEDLINESYM :
-// case CHSTYLE_2D_PERCENTLINESYM :
-// case CHSTYLE_2D_CUBIC_SPLINE :
-// case CHSTYLE_2D_CUBIC_SPLINE_SYMBOL :
-// case CHSTYLE_2D_B_SPLINE :
-// case CHSTYLE_2D_B_SPLINE_SYMBOL :
-
-// case CHSTYLE_2D_XY :
-// case CHSTYLE_2D_XYSYMBOLS :
-// case CHSTYLE_2D_XY_LINE :
-// case CHSTYLE_2D_CUBIC_SPLINE_XY :
-// case CHSTYLE_2D_CUBIC_SPLINE_SYMBOL_XY :
-// case CHSTYLE_2D_B_SPLINE_XY :
-// case CHSTYLE_2D_B_SPLINE_SYMBOL_XY :
-
-// case CHSTYLE_2D_BAR :
-// case CHSTYLE_2D_STACKEDBAR:
-// case CHSTYLE_2D_PERCENTBAR:
-
-// case CHSTYLE_2D_AREA :
-// case CHSTYLE_2D_PERCENTAREA :
-// case CHSTYLE_2D_STACKEDAREA :
-
-// case CHSTYLE_2D_STOCK_1:
-// case CHSTYLE_2D_STOCK_2:
-// case CHSTYLE_2D_STOCK_3:
-// case CHSTYLE_2D_STOCK_4:
/*N*/ default :
/*N*/ return TRUE;
/*N*/ }
diff --git a/binfilter/bf_sfx2/source/appl/sfx2_appbas.cxx b/binfilter/bf_sfx2/source/appl/sfx2_appbas.cxx
index 2d1701d..0abf450 100644
--- a/binfilter/bf_sfx2/source/appl/sfx2_appbas.cxx
+++ b/binfilter/bf_sfx2/source/appl/sfx2_appbas.cxx
@@ -174,74 +174,7 @@ BasicManager* SfxApplication::GetBasicManager()
/*N*/
/*N*/ // zuerst das BASIC laden
/*N*/ GetBasic();
-/*
-// als erstes SfxShellObject das SbxObject der SfxApplication erzeugen
-SbxObject *pSbx = GetSbxObject();
-DBG_ASSERT( pSbx, "SfxShellObject: can't create SbxObject for SfxApplication" );
-
-// die SbxObjects aller Module erzeugen
-SfxModuleArr_Impl& rArr = GetModules_Impl();
-for ( sal_uInt16 n = 0; n < rArr.Count(); ++n )
-{
-SfxModule *pMod = rArr.GetObject(n);
-if ( pMod->IsLoaded() )
-{
-pSbx = pMod->GetSbxObject();
-DBG_ASSERT( pSbx, "SfxModule: can't create SbxObject" );
-}
-}
-
-// die SbxObjects aller Tasks erzeugen
-for ( SfxTask *pTask = SfxTask::GetFirst(); pTask; pTask = SfxTask::GetNext( *pTask ) )
-pTask->GetSbxObject();
-
-// die SbxObjects aller SfxObjectShells erzeugen (ggf. Frame-los!)
-for ( SfxObjectShell *pObjSh = SfxObjectShell::GetFirst( NULL, sal_False );
- pObjSh;
- pObjSh = SfxObjectShell::GetNext(*pObjSh, NULL, sal_False) )
-{
-// kein IP-Object oder wenn doch dann initialisiert?
-SvStorageRef aStorage;
-if ( !pObjSh->IsHandsOff() )
-aStorage = pObjSh->GetStorage();
-if ( !pObjSh->GetInPlaceObject() || aStorage.Is() )
-{
-DBG( DbgOutf( "SfxShellObject: BASIC-on-demand for %s",
- pObjSh->SfxShell::GetName().GetBuffer() ) );
-pSbx = pObjSh->GetSbxObject(
Re: [Libreoffice] [PATCH] [PUSHED] Changed String to OUString in funcdesc.hxx
Thank you for pushing the patches, and your tidying up of them. My reason for doing the conversion from String to OUString in ResId instead of global.cxx was to move the dependency on String from sc/ to tools/ as I tried to remove all String dependencies in (that part of) global.cxx, and feeling it to be wierd having a implicit use of String in the implementations in global.cxx without it being clear from the code, that String is used, and thinking that it was easier to change the implementation of toString in ResId later on to directly make an OUString from an ResId instead of having to change all uses of toString again, but I now can see, that that wasn't what you suggested. Regards Sören Möller 2011/1/11 Kohei Yoshida : > Forgot to use a [PUSHED] tag in the subject... :-P > > -- > Kohei Yoshida, LibreOffice hacker, Calc > > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [REWORKED][PUSHED] Standard-color-palette-updates
Bernhard Dippold píše v Út 11. 01. 2011 v 00:37 +0100: > Hi Petr, Kami, all, > > Petr Mladek schrieb: > > Kálmán „KAMI” Szalai píše v So 08. 01. 2011 v 15:28 +0100: > >> Hi All, > >> > >> Updated patch, > >> > >> Remove LibreOffice colors from standard, and updates libreoffice.soc > >> with latest colors. I hope it is fine for us. > > > > looked fine => pushed > > > > Note that the palette name does not include year. Is it OK? > > I think Christoph called the palette > "LibreOffice_Initial_Branding_Colors.soc", because they will change > during the next year. > > His next palette would probably be called > "LibreOffice_Community_Branding_Colors.soc". > > My approach was only a bit different: I added the year in order to allow > further changes to the branding colors without the necessity to call the > next branding effort by a different name. Hmm, I see libreoffice.soc in the installed system. > If you think the file name is too long, we can omit "Initial" (because > the year is unique - we should not come up with more than one iteration > on the branding colors during one year). > > "Colors" is superfluous too for a color palette, so my favorite name > would be > > LibreOffice_Branding_2010.soc > > This would allow to create new Branding palettes every now and then > without the problem of visually different documents in different > versions of LibreOffice (when a color of the palette has been updated > in-between). Well, this should not be a problem. The colors are saved using RGB values and not the color name. I have just used "LibreOffice Green 3" in an .odg document, removed libreoffice.soc from the system and user configuration, opened the file again, the color stayed the same, it was just not named. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 --- Comment #59 from Igor Kovalyov 2011-01-11 00:58:12 PST --- (In reply to comment #52) > Removing the bug #31820. The extensions registration fails only in some > strange > circumstances. It does not affect the base function... I have error on 4 computers with libreoffice rc2. And I don't have any workaround to install libreoffice on them, so I can't use "base function". After installation without "Optional components" I can't run any libreoffice application - see comments to #31820. At the same time openoffice 3.2 succesfully setups on all this 4 computers. Nominating bug #31820 to release blockers again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
