Re: ccache for windows

2012-09-05 Thread Kohei Yoshida
On Wed, Sep 5, 2012 at 7:35 PM, Kohei Yoshida  wrote:
> On 09/05/2012 06:45 PM, Mat M wrote:
>>
>> Could someone on linux give its ccache stats to compare ?
>
>
> My ccache size on Linux is typically 400Mb per build.  So 3Gb is pretty big
> compared to what I normally see on Linux.

Ah nevermind. I have the compress object option enabled. So if
uncompressed the number would be probably a lot higher (per build).

Kohei
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PATCH] Fix for docking property browser

2012-09-05 Thread Gerrit
>From János Uray :

János Uray has uploaded a new change for review.

Change subject: Fix for docking property browser
..

Fix for docking property browser

This fixes the crash of 'Basic IDE: Docking property browser under
object catalog' commit. The aPropertyBrowser data member was replaced by
a new-allocated pointer. We need this because toolkit releases it by
delete.
When the property browser is closed in the floating state, it tells
DialogWindowLayout to null the pointer. If the user clicks the 'property
browser' button on the toolbar, it is created again.

Change-Id: Ie842a72fe37dfdd2ed5921ffa2f1f41d3f2c51c6
---
M basctl/source/basicide/baside3.cxx
M basctl/source/basicide/layout.cxx
M basctl/source/basicide/layout.hxx
M basctl/source/dlged/dlged.cxx
M basctl/source/dlged/propbrw.cxx
M basctl/source/inc/baside3.hxx
M basctl/source/inc/dlged.hxx
M basctl/source/inc/propbrw.hxx
8 files changed, 144 insertions(+), 28 deletions(-)


  git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/68/568/1
--
To view, visit https://gerrit.libreoffice.org/568
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ie842a72fe37dfdd2ed5921ffa2f1f41d3f2c51c6
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: János Uray 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: ccache for windows

2012-09-05 Thread Tor Lillqvist
>
> But is it normal that ccache on 3.6 branch only uses 3Gb ? I find it very
> low, compared to all binary files produced.
>

ccache of course, over time, fills up the cache space it is allowed to use
(up to approximately 10% below it, it seems). That's the whole point of it.
An under-utilized cache is a wasted cache. ccache doesn't use magic, it
can't know if some cached object file has been "obsoleted" forever, so it
keeps them as long as there is space.

On my Linux box, where I build for Android maybe once a day, with
debugging, and quite occasionally for Linux:

cache directory /home/tml/.ccache
cache hit (direct)368163
cache hit (preprocessed)   94352
cache miss   1121108
called for link93840
multiple source files 93
compile failed 47552
preprocessor error  7596
couldn't find the compiler92
bad compiler arguments  5288
unsupported source language  433
autoconf compile/link  64967
unsupported compiler option   165727
no input file 398434
files in cache 51223
cache size  18.0 Gbytes
max files 50
max cache size  20.0 Gbytes

I have no idea what the age distribution of the cached object files are.
Perhaps ccache -s should tell that too, in some suitable fashion..., like
50% of files are older than N days, 10% older than M days.

On the other hand, on a tinderbox, with dozens of builds per day (for three
cross-compilation targets), without debugging, with cache accumulated for
maybe two weeks, it still hasn't filled up the maximum space of 20 GB I
gave it:

cache directory /home/android/.ccache
cache hit (direct)   9725802
cache hit (preprocessed)   94058
cache miss229024
called for link   492953
multiple source files   1570
compile failed980552
ccache internal error  2
preprocessor error 33103
bad compiler arguments 59830
unsupported source language 7953
autoconf compile/link 531055
unsupported compiler option  1568175
no input file 467468
files in cache197527
cache size  14.8 Gbytes
max cache size  20.0 Gbytes

Actually, the "unsupported compiler option" is a bit high there, isn't it?
Hmm.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [REVIEW-3-6][PUSHED 3-6] better import for old conditional format documents

2012-09-05 Thread Kohei Yoshida

Tagging PUSHED 3-6.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [REVIEW-3-6] better import for old conditional format documents

2012-09-05 Thread Kohei Yoshida

On 09/05/2012 12:06 PM, Markus Mohrhard wrote:


[1] 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=bedbb471c3f49e0860dd63b17c1faeee837096ae


Reviewed it and cherry-picked it to 3-6 with my sign-off.

The change was a little large-ish, and there may be a little risk for 
back-porting this, but I understand the gist of the change, and I 
believe it's worth a little risk to get this one right for 3.6.


Kohei

--
Kohei Yoshida, LibreOffice hacker, Calc
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: Branch 'libreoffice-3-6' - sc/inc sc/source

2012-09-05 Thread Libreoffice Gerrit user
 sc/inc/conditio.hxx   |8 +
 sc/source/core/data/conditio.cxx  |   34 +++-
 sc/source/filter/xml/xmlimprt.cxx |2 
 sc/source/filter/xml/xmlimprt.hxx |3 
 sc/source/filter/xml/xmlstyli.cxx |  259 --
 sc/source/filter/xml/xmlstyli.hxx |   32 
 6 files changed, 155 insertions(+), 183 deletions(-)

New commits:
commit d5e8a98795b5961825d714d420965abc8dd6ad44
Author: Markus Mohrhard 
Date:   Wed Sep 5 22:27:40 2012 -0400

better import of conditional format from old ODF structure

The old ODF storage is style based and so the sam cond format can be
divided up into several single stlyes which resulted in several new
style cond formats.

Now we check for old stlye cond formats if there is a equal cond format
and in this case just extend the area. This should make it easier to
transform old documents into the new range based cond formats.

Conflicts:

sc/inc/conditio.hxx
sc/source/filter/xml/xmlstyli.cxx
sc/source/filter/xml/xmlstyli.hxx

Change-Id: I51a5148922e19e6860de9915abfc59d49b18d96e
Signed-off-by: Kohei Yoshida 

diff --git a/sc/inc/conditio.hxx b/sc/inc/conditio.hxx
index 1b95933..49cfaa0 100644
--- a/sc/inc/conditio.hxx
+++ b/sc/inc/conditio.hxx
@@ -109,6 +109,12 @@ public:
 virtual ScFormatEntry* Clone( ScDocument* pDoc = NULL ) const = 0;
 
 virtual void SetParent( ScConditionalFormat* pNew ) = 0;
+
+bool operator==( const ScFormatEntry& ) const;
+
+#if DUMP_FORMAT_INFO
+virtual void dumpInfo() const = 0;
+#endif
 protected:
 ScDocument* mpDoc;
 
@@ -273,6 +279,8 @@ public:
 voidAddEntry( ScFormatEntry* pNew );
 voidAddRange( const ScRangeList& rRanges );
 const ScRangeList&  GetRange() const  { return maRanges; }
+// don't use the same name as for the const version
+ScRangeList& GetRangeList() { return maRanges; }
 
 bool IsEmpty() const { return maEntries.empty(); }
 size_t size() const   { return maEntries.size(); }
diff --git a/sc/source/core/data/conditio.cxx b/sc/source/core/data/conditio.cxx
index a5e637c..aad6019 100644
--- a/sc/source/core/data/conditio.cxx
+++ b/sc/source/core/data/conditio.cxx
@@ -57,6 +57,27 @@ ScFormatEntry::ScFormatEntry(ScDocument* pDoc):
 {
 }
 
+bool ScFormatEntry::operator==( const ScFormatEntry& r ) const
+{
+if(GetType() != r.GetType())
+return false;
+
+switch(GetType())
+{
+case condformat::CONDITION:
+return static_cast(*this) == 
static_cast(r);
+break;
+default:
+// TODO: implement also this case
+// actually return false for these cases is not that bad
+// as soon as databar and color scale are tested we need
+// to think about the range
+return false;
+}
+
+return true;
+}
+
 bool lcl_HasRelRef( ScDocument* pDoc, ScTokenArray* pFormula, sal_uInt16 
nRecursion = 0 )
 {
 if (pFormula)
@@ -1289,8 +1310,6 @@ int ScCondFormatEntry::operator== ( const 
ScCondFormatEntry& r ) const
 {
 return ScConditionEntry::operator==( r ) &&
 aStyleName == r.aStyleName;
-
-//  Range wird nicht verglichen
 }
 
 ScCondFormatEntry::~ScCondFormatEntry()
@@ -1356,13 +1375,14 @@ bool ScConditionalFormat::EqualEntries( const 
ScConditionalFormat& r ) const
 
 //! auf gleiche Eintraege in anderer Reihenfolge testen ???
 
-/*
-for (sal_uInt16 i=0; iFillPropertySet(xProperties);
+// here needs to be the cond format import method
 sal_Int32 nNumberFormat(pStyle->GetNumberFormat());
 SetType(xProperties, nNumberFormat, nPrevCellType, 
sPrevCurrency);
 
 // store first cell of first range for each style, once per 
sheet
 uno::Sequence 
aAddresses(xSheetCellRanges->getRangeAddresses());
+pStyle->ApplyCondFormat(aAddresses);
 if ( aAddresses.getLength() > 0 )
 {
 const table::CellRangeAddress& rRange = aAddresses[0];
diff --git a/sc/source/filter/xml/xmlimprt.hxx 
b/sc/source/filter/xml/xmlimprt.hxx
index 3e9bd2d..c4a4412 100644
--- a/sc/source/filter/xml/xmlimprt.hxx
+++ b/sc/source/filter/xml/xmlimprt.hxx
@@ -40,6 +40,7 @@
 #include "xmlsubti.hxx"
 #include "global.hxx"
 #include "formula/grammar.hxx"
+#include "rangelst.hxx"
 
 #include "xmlstyle.hxx"
 #include "XMLDetectiveContext.hxx"
@@ -56,7 +57,6 @@
 #include 
 #include 
 
-class ScRangeList;
 class ScMyStyleNumberFormats;
 class XMLNumberFormatAttributesExportHelper;
 
@@ -858,6 +858,7 @@ class ScXMLImport: public SvXMLImport
 com::sun::star::uno::Reference  
xNumberFormats;
 com::sun::star::uno::Reference  
xNumberFormatTypes;
 
+ScRangeList maSheetRanges;
 com::sun::star::uno::Reference 
 xSheetCellRanges;
 
 rtl::OUString   sEmpty;
diff --git a/sc/source/filter/xml/x

Re: ccache for windows

2012-09-05 Thread Norbert Thiebaud
On Wed, Sep 5, 2012 at 5:45 PM, Mat M  wrote:
> Hello
>
> ccache for windows under cygwin is working. That's a fact.
> ccache is provided as a binary in the dev-tools repo.
> As provided by kendy on
> http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-04.html, I
> set it and my config_host.mk confirmed it.
>
> But is it normal that ccache on 3.6 branch only uses 3Gb ? I find it very
> low, compared to all binary files produced.
>
> Could someone on linux give its ccache stats to compare ?

here is my linux tinderbox stats:
$ ccache -s
cache directory /home/n_th/.ccache
cache hit   80679599
cache miss   2662640
called for link  3141612
multiple source files  13767
compile failed   6062048
ccache internal error558
preprocessor error261427
cache file missing   590
not a C/C++ file 1123396
autoconf compile/link5287939
unsupported compiler option  4159126
no input file6913498
files in cache183287
cache size   7.2 Gbytes
max cache size   8.0 Gbytes

but bear in mid that this has been building 20-50 time a days of quite
some times now...

here the stats for a windows buildbot:
$ ccache.exe -s
cache directory C:\\lo/.ccache
cache hit3957024
cache miss387960
compile failed   288
ccache internal error  4
preprocessor error56
no input file   9648
files in cache138363
cache size  18.1 Gbytes
max cache size  20.0 Gbytes

again over time the size tend to creep up to the max allowed, so won't
tell you much...

but comparing the two (that is the average file size of files in
cache), one can expect, all things being equal, the ccache size on
Windows to be roughly 3.5 time bigger on windows than Linux
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: ccache for windows

2012-09-05 Thread Kohei Yoshida

On 09/05/2012 06:45 PM, Mat M wrote:

Could someone on linux give its ccache stats to compare ?


My ccache size on Linux is typically 400Mb per build.  So 3Gb is pretty 
big compared to what I normally see on Linux.


--
Kohei Yoshida, LibreOffice hacker, Calc
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] kill RTL_CONSTASCII_USTRINGPARAM in xmlscript

2012-09-05 Thread Gerrit
>From Olivier Hallot :

Olivier Hallot has submitted this change and it was merged.

Change subject: kill RTL_CONSTASCII_USTRINGPARAM in xmlscript
..


kill RTL_CONSTASCII_USTRINGPARAM in xmlscript

Plus rtl::OUString cleanup
Only on rebased files

Change-Id: Icddaa20742cc45f08e5a48790447fcf8865f4bd6
---
M xmlscript/inc/xmlscript/xml_helper.hxx
M xmlscript/inc/xmlscript/xmllib_imexp.hxx
M xmlscript/inc/xmlscript/xmlmod_imexp.hxx
M xmlscript/source/inc/misc.hxx
M xmlscript/source/xml_helper/xml_impctx.cxx
M xmlscript/source/xmldlg_imexp/exp_share.hxx
M xmlscript/source/xmldlg_imexp/imp_share.hxx
M xmlscript/source/xmldlg_imexp/xmldlg_addfunc.cxx
M xmlscript/source/xmldlg_imexp/xmldlg_expmodels.cxx
M xmlscript/source/xmldlg_imexp/xmldlg_export.cxx
M xmlscript/source/xmldlg_imexp/xmldlg_impmodels.cxx
M xmlscript/source/xmldlg_imexp/xmldlg_import.cxx
M xmlscript/source/xmlflat_imexp/xmlbas_export.cxx
M xmlscript/source/xmlflat_imexp/xmlbas_import.cxx
M xmlscript/source/xmllib_imexp/imp_share.hxx
M xmlscript/source/xmllib_imexp/xmllib_export.cxx
M xmlscript/source/xmllib_imexp/xmllib_import.cxx
M xmlscript/source/xmlmod_imexp/imp_share.hxx
M xmlscript/source/xmlmod_imexp/xmlmod_export.cxx
M xmlscript/source/xmlmod_imexp/xmlmod_import.cxx
M xmlscript/test/imexp.cxx
21 files changed, 1,445 insertions(+), 2,864 deletions(-)

Approvals:
  Olivier Hallot: Verified; Looks good to me, approved


--
To view, visit https://gerrit.libreoffice.org/527
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Icddaa20742cc45f08e5a48790447fcf8865f4bd6
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Olivier Hallot 
Gerrit-Reviewer: Olivier Hallot 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] kill RTL_CONSTASCII_USTRINGPARAM in xmlhelp

2012-09-05 Thread Gerrit
>From Olivier Hallot :

Olivier Hallot has submitted this change and it was merged.

Change subject: kill RTL_CONSTASCII_USTRINGPARAM in xmlhelp
..


kill RTL_CONSTASCII_USTRINGPARAM in xmlhelp

+ ::rtl:: drop
(only on rebased files)

Change-Id: I5a773936ceb012b0655cee8db7250b496e088464
---
M xmlhelp/source/cxxhelp/inc/excep/XmlSearchExceptions.hxx
M xmlhelp/source/cxxhelp/inc/qe/Query.hxx
M xmlhelp/source/cxxhelp/provider/content.hxx
M xmlhelp/source/cxxhelp/provider/contentcaps.cxx
M xmlhelp/source/cxxhelp/provider/inputstream.hxx
M xmlhelp/source/cxxhelp/provider/provider.hxx
M xmlhelp/source/cxxhelp/provider/resultsetbase.hxx
M xmlhelp/source/cxxhelp/test/abidebug.hxx
M xmlhelp/source/cxxhelp/test/searchdemo.cxx
M xmlhelp/source/treeview/tvfactory.hxx
10 files changed, 94 insertions(+), 122 deletions(-)

Approvals:
  Olivier Hallot: Verified; Looks good to me, approved


--
To view, visit https://gerrit.libreoffice.org/525
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I5a773936ceb012b0655cee8db7250b496e088464
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Olivier Hallot 
Gerrit-Reviewer: Olivier Hallot 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: xmlhelp/source

2012-09-05 Thread Libreoffice Gerrit user
 xmlhelp/source/cxxhelp/inc/excep/XmlSearchExceptions.hxx |   14 -
 xmlhelp/source/cxxhelp/inc/qe/Query.hxx  |   10 -
 xmlhelp/source/cxxhelp/provider/content.hxx  |   10 -
 xmlhelp/source/cxxhelp/provider/contentcaps.cxx  |  118 +--
 xmlhelp/source/cxxhelp/provider/inputstream.hxx  |2 
 xmlhelp/source/cxxhelp/provider/provider.hxx |6 
 xmlhelp/source/cxxhelp/provider/resultsetbase.hxx|   20 +-
 xmlhelp/source/cxxhelp/test/abidebug.hxx |2 
 xmlhelp/source/cxxhelp/test/searchdemo.cxx   |   18 +-
 xmlhelp/source/treeview/tvfactory.hxx|   16 +-
 10 files changed, 94 insertions(+), 122 deletions(-)

New commits:
commit 72fa23ba0e13e6cf8a7ffb0476863d4399af0da1
Author: Olivier Hallot 
Date:   Fri Aug 31 22:46:59 2012 -0300

kill RTL_CONSTASCII_USTRINGPARAM in xmlhelp

+ ::rtl:: drop
(only on rebased files)

Change-Id: I5a773936ceb012b0655cee8db7250b496e088464
Reviewed-on: https://gerrit.libreoffice.org/525
Reviewed-by: Olivier Hallot 
Tested-by: Olivier Hallot 

diff --git a/xmlhelp/source/cxxhelp/inc/excep/XmlSearchExceptions.hxx 
b/xmlhelp/source/cxxhelp/inc/excep/XmlSearchExceptions.hxx
index e8c96c5..8c5e089 100644
--- a/xmlhelp/source/cxxhelp/inc/excep/XmlSearchExceptions.hxx
+++ b/xmlhelp/source/cxxhelp/inc/excep/XmlSearchExceptions.hxx
@@ -31,12 +31,12 @@ namespace xmlsearch {
 {
 public:
 
-XmlSearchException( const rtl::OUString& message )
+XmlSearchException( const OUString& message )
 : _message( message )
 {
 }
 
-rtl::OUString getMessage() const
+OUString getMessage() const
 {
 return _message;
 }
@@ -44,7 +44,7 @@ namespace xmlsearch {
 
 private:
 
-rtl::OUString _message;
+OUString _message;
 };
 
 
@@ -53,7 +53,7 @@ namespace xmlsearch {
 {
 public:
 
-IOException( const rtl::OUString& message )
+IOException( const OUString& message )
 : XmlSearchException( message )
 {
 }
@@ -64,7 +64,7 @@ namespace xmlsearch {
 : public virtual XmlSearchException
 {
 public:
-NoFactoryException( const rtl::OUString& message )
+NoFactoryException( const OUString& message )
 : XmlSearchException( message )
 {
 }
@@ -75,7 +75,7 @@ namespace xmlsearch {
 : public virtual XmlSearchException
 {
 public:
-NoSuchBlock( const rtl::OUString& message )
+NoSuchBlock( const OUString& message )
 : XmlSearchException( message )
 {
 }
@@ -86,7 +86,7 @@ namespace xmlsearch {
 : public virtual XmlSearchException
 {
 public:
-IllegalIndexException( const rtl::OUString& message )
+IllegalIndexException( const OUString& message )
 : XmlSearchException( message )
 {
 }
diff --git a/xmlhelp/source/cxxhelp/inc/qe/Query.hxx 
b/xmlhelp/source/cxxhelp/inc/qe/Query.hxx
index b34fa76..d5628f3 100644
--- a/xmlhelp/source/cxxhelp/inc/qe/Query.hxx
+++ b/xmlhelp/source/cxxhelp/inc/qe/Query.hxx
@@ -121,14 +121,14 @@ namespace xmlsearch {
 {
 public:
 
-QueryHitData( double penalty,const rtl::OUString& document, 
rtl::OUString* terms )
+QueryHitData( double penalty,const OUString& document, OUString* 
terms )
 : penalty_( penalty ),
   document_( document ),
   terms_( terms )  { }
 
 ~QueryHitData() { delete[] terms_; }
 
-rtl::OUString getDocument() const { return document_; }
+OUString getDocument() const { return document_; }
 
 double getPenalty() const { return penalty_; }
 
@@ -137,9 +137,9 @@ namespace xmlsearch {
 
 doublepenalty_;
 
-const rtl::OUString document_;
+const OUString document_;
 
-rtl::OUString* terms_;
+OUString* terms_;
 
 };  // end class QueryHitData
 
@@ -148,7 +148,7 @@ namespace xmlsearch {
 {
 public:
 
-static PrefixTranslator* makePrefixTranslator( const 
rtl::OUString*,sal_Int32 )
+static PrefixTranslator* makePrefixTranslator( const 
OUString*,sal_Int32 )
 {
 return 0;
 }
diff --git a/xmlhelp/source/cxxhelp/provider/content.hxx 
b/xmlhelp/source/cxxhelp/provider/content.hxx
index eaf3b04..cd6d113 100644
--- a/xmlhelp/source/cxxhelp/provider/content.hxx
+++ b/xmlhelp/source/cxxhelp/provider/content.hxx
@@ -49,8 +49,8 @@ namespace chelp
 
 struct ContentProperties
 {
-::rtl::OUString aTitle; // Title

ccache for windows

2012-09-05 Thread Mat M

Hello

ccache for windows under cygwin is working. That's a fact.
ccache is provided as a binary in the dev-tools repo.
As provided by kendy on  
http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-04.html,  
I set it and my config_host.mk confirmed it.


But is it normal that ccache on 3.6 branch only uses 3Gb ? I find it very  
low, compared to all binary files produced.


Could someone on linux give its ccache stats to compare ?
Kendy, what's your opinion ?

Thanks all

--
Mat M
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PATCH] offapi: move css.ui.UICommandDescription to css.frame.UIComm...

2012-09-05 Thread Gerrit
>From Michael Stahl :

Michael Stahl has uploaded a new change for review.

Change subject: offapi: move css.ui.UICommandDescription to 
css.frame.UICommandDescription:
..

offapi: move css.ui.UICommandDescription to css.frame.UICommandDescription:

The service implementation used "com.sun.star.frame.UICommandDescription"
since forever, so the IDL file was essentially wrong documentation.
But since 7a464263cc5c2ca2b7128734ff4860e02d662818 converted the service
to new-style, it cannot be instantated any more and e.g. clicking on
Tools->Customize crashes.
(Adapting the implementation instead would be an incompatible change.)

Change-Id: I564bddaf3836827f5b72360a2bde19d6158b7ba5
---
M cui/source/customize/acccfg.cxx
M cui/source/customize/cfg.cxx
M cui/source/customize/cfgutil.cxx
M cui/source/customize/selector.cxx
M dbaccess/source/ui/control/opendoccontrols.cxx
M desktop/source/app/app.cxx
M desktop/source/migration/migration.cxx
M forms/source/helper/commanddescriptionprovider.cxx
M framework/source/lomenubar/FrameHelper.cxx
M offapi/UnoApi_offapi.mk
R offapi/com/sun/star/frame/UICommandDescription.idl
M sd/source/ui/dlg/dlgass.cxx
M sd/source/ui/view/ViewShellBase.cxx
M sfx2/source/dialog/recfloat.cxx
M sfx2/source/dialog/templdlg.cxx
M sfx2/source/view/viewsh.cxx
M svtools/source/uno/contextmenuhelper.cxx
M sw/source/ui/lingu/olmenu.cxx
18 files changed, 51 insertions(+), 36 deletions(-)


  git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/67/567/1
--
To view, visit https://gerrit.libreoffice.org/567
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I564bddaf3836827f5b72360a2bde19d6158b7ba5
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Michael Stahl 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] Cleanup files touched by f5b7fecbc0744e46468d57b8131ea7d768a...

2012-09-05 Thread Gerrit
>From Kohei Yoshida :

Kohei Yoshida has submitted this change and it was merged.

Change subject: Cleanup files touched by 
f5b7fecbc0744e46468d57b8131ea7d768aa96a2
..


Cleanup files touched by f5b7fecbc0744e46468d57b8131ea7d768aa96a2

Change-Id: I00c2ccb0be18bb574b2494b035b48c6f37128c72
---
M sc/source/core/inc/adiasync.hxx
M sc/source/core/inc/ddelink.hxx
M sc/source/core/inc/interpre.hxx
M sc/source/core/tool/ddelink.cxx
4 files changed, 15 insertions(+), 39 deletions(-)

Approvals:
  Kohei Yoshida: Verified; Looks good to me, approved


--
To view, visit https://gerrit.libreoffice.org/494
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I00c2ccb0be18bb574b2494b035b48c6f37128c72
Gerrit-PatchSet: 5
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Philipp Riemer 
Gerrit-Reviewer: Kohei Yoshida 
Gerrit-Reviewer: Philipp Riemer 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: sc/source

2012-09-05 Thread Libreoffice Gerrit user
 sc/source/core/inc/adiasync.hxx |7 ++-
 sc/source/core/inc/ddelink.hxx  |   13 ++---
 sc/source/core/inc/interpre.hxx |   25 +++--
 sc/source/core/tool/ddelink.cxx |9 -
 4 files changed, 15 insertions(+), 39 deletions(-)

New commits:
commit 79874397bbc891939ebd402a4af85fa1406604fd
Author: Philipp Riemer 
Date:   Mon Sep 3 15:37:04 2012 +0200

Cleanup files touched by f5b7fecbc0744e46468d57b8131ea7d768aa96a2

Change-Id: I00c2ccb0be18bb574b2494b035b48c6f37128c72
Reviewed-on: https://gerrit.libreoffice.org/494
Reviewed-by: Kohei Yoshida 
Tested-by: Kohei Yoshida 

diff --git a/sc/source/core/inc/adiasync.hxx b/sc/source/core/inc/adiasync.hxx
index 548f58c..e9f0198 100644
--- a/sc/source/core/inc/adiasync.hxx
+++ b/sc/source/core/inc/adiasync.hxx
@@ -38,7 +38,6 @@ extern "C" {
 void CALLTYPE ScAddInAsyncCallBack( double& nHandle, void* pData );
 }
 
-
 class ScDocument;
 class ScAddInDocs : public std::set {};
 
@@ -56,7 +55,7 @@ private:
 FuncData*   mpFuncData; // Pointer to files in collection
 sal_uLong   nHandle;// is casted from double to sal_uLong
 ParamType   meType; // result of type PTR_DOUBLE or 
PTR_STRING
-sal_BoolbValid; // is value valid?
+boolbValid; // is value valid?
 
 public:
 // cTor only if ScAddInAsync::Get fails.
@@ -68,7 +67,7 @@ public:
 static ScAddInAsync*Get( sal_uLong nHandle );
 static void CallBack( sal_uLong nHandle, void* pData );
 static void RemoveDocument( ScDocument* pDocument );
-sal_BoolIsValid() const { return bValid; }
+boolIsValid() const { return bValid; }
 ParamType   GetType() const { return meType; }
 double  GetValue() const{ return nVal; }
 const String&   GetString() const   { return *pStr; }
@@ -89,8 +88,6 @@ class ScAddInAsyncs : public std::set {};
 
 extern ScAddInAsyncs theAddInAsyncTbl;  // in adiasync.cxx
 
-
-
 #endif
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sc/source/core/inc/ddelink.hxx b/sc/source/core/inc/ddelink.hxx
index 4f3734f..9d347c1 100644
--- a/sc/source/core/inc/ddelink.hxx
+++ b/sc/source/core/inc/ddelink.hxx
@@ -42,7 +42,7 @@ class SvStream;
 class ScDdeLink : public ::sfx2::SvBaseLink, public SvtBroadcaster
 {
 private:
-static sal_Bool bIsInUpdate;
+static bool bIsInUpdate;
 
 ScDocument* pDoc;
 
@@ -51,7 +51,7 @@ static sal_Bool bIsInUpdate;
 String  aItem;
 sal_uInt8   nMode;  // number format mode
 
-sal_BoolbNeedUpdate;// is set, if update was not possible
+boolbNeedUpdate;// is set, if update was not possible
 
 ScMatrixRef pResult;
 
@@ -79,22 +79,21 @@ public:
 const ScMatrix* GetResult() const   { return pResult.get(); }
 voidSetResult( ScMatrixRef pRes ) { pResult = pRes; }
 
-// XML and Excel import after 
NewData()
+// XML and Excel import after NewData()
 ScMatrixRef GetModifiableResult()   { return pResult; }
 
 const String&   GetAppl() const { return aAppl; }
 const String&   GetTopic() const{ return aTopic; }
 const String&   GetItem() const { return aItem; }
-sal_uInt8   GetMode() const { return nMode; }
+sal_uInt8   GetMode() const { return nMode; }
 
 voidTryUpdate();
 
-sal_BoolNeedsUpdate() const { return bNeedUpdate; }
+boolNeedsUpdate() const { return bNeedUpdate; }
 
-static sal_Bool IsInUpdate(){ return bIsInUpdate; }
+static bool IsInUpdate(){ return bIsInUpdate; }
 };
 
-
 #endif
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sc/source/core/inc/interpre.hxx b/sc/source/core/inc/interpre.hxx
index 6ed54c4..b0cfa6a 100644
--- a/sc/source/core/inc/interpre.hxx
+++ b/sc/source/core/inc/interpre.hxx
@@ -40,7 +40,6 @@
 #include "externalrefmgr.hxx"
 #include "calcconfig.hxx"
 
-#include 
 #include 
 
 class ScDocument;
@@ -96,7 +95,6 @@ class ScInterpreter
 friend class ScChiSqDistFunction;
 
 public:
-
 DECL_FIXEDMEMPOOL_NEWDEL( ScInterpreter )
 
 static void SetGlobalConfig(const ScCalcConfig& rConfig);
@@ -162,7 +160,6 @@ private:
 
 VolatileType meVolatileType;
 
-//-Funktionen in interpre.cxx-
 // nMust <= nAct <= nMax ? ok : PushError
 inline bool MustHaveParamCount( short nAct, short nMust );
 inline bool MustHaveParamCount( short nAct, short nMust, short nMax );
@@ -309,7 +306,7 @@ inline void MatrixDoubleRefToMatrix();  // if 
MatrixFormula: PopDoubleRefPus
 inline bool MatrixParameterConversion();
 ScMatrixRef PopMatrix();
 void QueryMatrixType(ScMatrixRef& xMat, short& rRetTypeExpr, sal_uLong& 
rR

[Libreoffice-commits] .: extensions/Library_oleautobridge2.mk extensions/Library_oleautobridge.mk

2012-09-05 Thread Libreoffice Gerrit user
 extensions/Library_oleautobridge.mk  |1 +
 extensions/Library_oleautobridge2.mk |1 +
 2 files changed, 2 insertions(+)

New commits:
commit 68428270b3488b6a15e95fac29c754780641bc49
Author: Michael Stahl 
Date:   Wed Sep 5 21:29:08 2012 +0200

extensions: oleautobridge needs comphelper

Since b679a2a02180c017bd8b596fb2e4f283bad93b75 this oleautobridge seems
to need comphelper.

Change-Id: Idb04b61026e78fd3f726d66ef05d4345aaeb40a6

diff --git a/extensions/Library_oleautobridge.mk 
b/extensions/Library_oleautobridge.mk
index e02f65d..4340450 100644
--- a/extensions/Library_oleautobridge.mk
+++ b/extensions/Library_oleautobridge.mk
@@ -39,6 +39,7 @@ $(eval $(call gb_Library_set_include,oleautobridge,\
 ))
 
 $(eval $(call gb_Library_use_libraries,oleautobridge,\
+   comphelper \
cppuhelper \
cppu \
sal \
diff --git a/extensions/Library_oleautobridge2.mk 
b/extensions/Library_oleautobridge2.mk
index 5bbc832..e258e0f 100644
--- a/extensions/Library_oleautobridge2.mk
+++ b/extensions/Library_oleautobridge2.mk
@@ -43,6 +43,7 @@ $(eval $(call gb_Library_set_include,oleautobridge2,\
 ))
 
 $(eval $(call gb_Library_use_libraries,oleautobridge2,\
+   comphelper \
cppuhelper \
cppu \
sal \
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


Re: [Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

2012-09-05 Thread Bjoern Michaelsen
On Wed, Sep 05, 2012 at 06:30:30PM +0200, Lionel Elie Mamane wrote:
> We can change our opinion on these questions, and then the "intended
> branches" set changes.

Yes, but everytime we change our opinion on this, possibly the bug state would
need to change, which is why Im not too happy with this.

> So if you go to https://bugs.freedesktop.org/show_bug.cgi?id=37361 (LO
> 3.5 MAB), you have to click through on *each* resolved bug to read the
> bug log and try to see if there is a "fixed in 3.5.x" comment (or
> possibly look in whiteboard for a target:3.5", so that you can
> evaluate whether it is still relevant, or if action is needed?
> This makes it IMHO too easy for a bug to "slip under the radar" and be
> forgotten.

Why not just query for target 3.5.x in whiteboard?

> In the ESC call agenda, we have MAB statistics that say e.g.
> 
>  * 3.5 most annoying bugs ...
>  + 81 open (of 269) older 73/258 73/257 76/256 75/253 77/253 73/250  
> 72/249
> 30% 26%28%30% 30%30%29% 29%
>  + 
> https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

While this is also queryable, Im not too happy with the MAB concept in the long
run anyway -- Petr suggested we should try to move to getting the bug
priorities right if we get the manpower for it in QA. That should be a lot
better to query in the end.

> We could consider automoving on RC release rather than final release?

I personally would stick with finals, RCs are prereleases just like daily 
builds.

Best,

Bjoern
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] Re: [PATCH Java cleanup, make various bits of legacy code happier

2012-09-05 Thread Michael Stahl
On 05/09/12 21:07, Michael Stahl wrote:
> thanks, pushed.

adjusting 3 subjects in a row is apparently too difficult for me

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [PATCH Java cleanup, make various bits of legacy code happier

2012-09-05 Thread Michael Stahl
On 03/09/12 17:10, Noel Grandin wrote:
> Hi
> 
> A variety of fairly small patches to cleanup various dusty corners of 
> the java code.
> 
> Passes a full 'make check'.
> Which doesn't mean much, since most of this code is practically unused, 
> but at least I didn't completely stuff anything up.

thanks, pushed.

well i guess it'd be good if the examples shipped in the ODK at least
build :)


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: feature/vs2012: testing needed

2012-09-05 Thread Mat M
Le Wed, 05 Sep 2012 09:10:20 +0200, Noel Grandin  a  
écrit:




On 2012-09-04 23:19, Peter Foley wrote:
See  
http://article.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/35595


Hopefully someone will either agree and upload dbghelp.dll or I'll have  
to come up with another solution.


Norbert very kindly uploaded the file.

BTW, I'm on IRC in #libreoffice-dev if you want faster turnaround -  
username 'noelg'


Now the build is failing with:

$ make check
make -r -f /cygdrive/C/libo/Makefile.top check
make[1]: Entering directory `/cygdrive/C/libo'

*
*   Running the post download checks.
*

checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking for dbghelp.dll... found
Copying /cygdrive/c/Program Files (x86)/Microsoft Visual Studio  
9.0/VC/redist/x86/Microsoft.VC90.CRT/msvcp90.dll to ./external/msvcp90
Copying /cygdrive/c/Program Files (x86)/Microsoft Visual Studio  
9.0/VC/redist/x86/Microsoft.VC90.CRT/msvcr90.dll to ./external/msvcp90
Copying /cygdrive/c/Program Files (x86)/Microsoft Visual Studio  
9.0/VC/redist/x86/Microsoft.VC90.CRT/msvcm90.dll to ./external/msvcp90
Copying /cygdrive/c/Program Files (x86)/Microsoft Visual Studio  
9.0/VC/redist/x86/Microsoft.VC90.CRT/Microsoft.VC90.CRT.manifest to  
./external/msvcp90

MSMDir not found at ./oowintool line 330.
post_download: error: oowintool failed to copy merge modules
make[1]: *** [src.downloaded] Error 1
make[1]: Leaving directory `/cygdrive/C/libo'
make: *** [check] Error 2



Should not we get VC110 dlls instead ?

My 2 cents
--
Mat M
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] Re: [PATCH] move some java files around to make my IDE happier

2012-09-05 Thread Michael Stahl
On 31/08/12 15:28, Noel Grandin wrote:
> Hi
> 
> (Note that this applies on top of my patch from yesterday)
> 
> The point of this patch series is that modern Java IDE's regard it as an 
> error when the package name and the folder name are inconsistent.
> 
> Patches pass a full make check.

thanks, pushed except for one patch that moved stuff in some
foo/qa/unoapi around, making it inconsistent with other qa/unoapis;
investigation revealed that the Test.java that used to be in every
foo/qa/unoapi is obsolete nowadays and can be removed.

also i've converted the extensions/qa/unoapi to gbuild and enabled it,
in case it fails for someone it should be disabled again :)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] Re: [PATCH] Java - move some files to make using IDE easier

2012-09-05 Thread Michael Stahl
On 30/08/12 16:33, Noel Grandin wrote:
> Hi
> 
> Java IDE's get upset if the package does not match the file path, so 
> move some files to make them match.
> 
> This patch passes a full 'make check'

thanks, pushed


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: not delivering cairo on mac os x build

2012-09-05 Thread Riccardo Magliocchetti

Il 05/09/2012 20:24, Michael Meeks ha scritto:

Hi Riccardo,


Hi Michael,


On Wed, 2012-09-05 at 19:20 +0200, Riccardo Magliocchetti wrote:

So this are the minimum switches i need to be able to compile latest
master with --enable-headless, i don't think --without-java is needed
but i don't need java here:

./autogen.sh --without-java --enable-headless --disable-cups
--disable-graphite --disable-gnome-vfs --disable-librsvg

I think all but cups are fixable within configure.in


Sounds good; did you have a patch ? and/or potentially a distro-config/
of LibreOfficeHeadless or something might work ? [ though that's a bit
lame ;-].


I don't think a distro-config is needed, i think that i'll just force
off the desktop tecnologies that are enabled by default on libo, 
gnome-vfs and librsvg at the time of writing.


I think i've fixed all but the graphite issue locally, it's building 
right now so tomorrow morning will deal with graphite and then push to 
master.


I tend to do a clean build after each configure.in changes just to be 
sure and that has the side effect of adding latency :)


thanks,
riccardo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: 2 commits - sc/source

2012-09-05 Thread Libreoffice Gerrit user
 sc/source/filter/xml/xmlimprt.hxx |1 -
 sc/source/filter/xml/xmlstyli.hxx |2 --
 sc/source/ui/docshell/docfunc.cxx |3 +++
 3 files changed, 3 insertions(+), 3 deletions(-)

New commits:
commit 462451a4256d01072c4fface64b590b7be05f718
Author: Markus Mohrhard 
Date:   Wed Sep 5 20:27:56 2012 +0200

remove two useless definitions

Change-Id: Idf804207c2af46dee30d4eff3704b8d61fbe485f

diff --git a/sc/source/filter/xml/xmlimprt.hxx 
b/sc/source/filter/xml/xmlimprt.hxx
index d9d86fc..f3706d9 100644
--- a/sc/source/filter/xml/xmlimprt.hxx
+++ b/sc/source/filter/xml/xmlimprt.hxx
@@ -852,7 +852,6 @@ class ScXMLImport: public SvXMLImport
 com::sun::star::uno::Reference  
xNumberFormats;
 com::sun::star::uno::Reference  
xNumberFormatTypes;
 
-ScRangeList maSheetRanges;
 com::sun::star::uno::Reference 
 xSheetCellRanges;
 
 rtl::OUString   sEmpty;
diff --git a/sc/source/filter/xml/xmlstyli.hxx 
b/sc/source/filter/xml/xmlstyli.hxx
index edc5794..def3509 100644
--- a/sc/source/filter/xml/xmlstyli.hxx
+++ b/sc/source/filter/xml/xmlstyli.hxx
@@ -143,8 +143,6 @@ public:
 
 private:
 using XMLPropStyleContext::SetStyle;
-
-ScConditionalFormat* CreateCondFormat();
 };
 
 class XMLTableStylesContext : public SvXMLStylesContext
commit 5129d01a7fb85390d925c084488493ac19c8b217
Author: Markus Mohrhard 
Date:   Wed Sep 5 20:27:21 2012 +0200

only allow to change conditional formatting if sheet is not protected

Change-Id: I38a812a4d4ce24fb9ad65c438f6e001b376f319e

diff --git a/sc/source/ui/docshell/docfunc.cxx 
b/sc/source/ui/docshell/docfunc.cxx
index 70d2456..0472145 100644
--- a/sc/source/ui/docshell/docfunc.cxx
+++ b/sc/source/ui/docshell/docfunc.cxx
@@ -5063,6 +5063,9 @@ void ScDocFunc::ReplaceConditionalFormat( sal_uLong 
nOldFormat, ScConditionalFor
 {
 ScDocShellModificator aModificator(rDocShell);
 ScDocument* pDoc = rDocShell.GetDocument();
+if(pDoc->IsTabProtected(nTab))
+return;
+
 if(nOldFormat)
 {
 pDoc->DeleteConditionalFormat(nOldFormat, nTab);
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


Re: not delivering cairo on mac os x build

2012-09-05 Thread Michael Meeks
Hi Riccardo,

On Wed, 2012-09-05 at 19:20 +0200, Riccardo Magliocchetti wrote:
> So this are the minimum switches i need to be able to compile latest 
> master with --enable-headless, i don't think --without-java is needed 
> but i don't need java here:
> 
> ./autogen.sh --without-java --enable-headless --disable-cups 
> --disable-graphite --disable-gnome-vfs --disable-librsvg
> 
> I think all but cups are fixable within configure.in

Sounds good; did you have a patch ? and/or potentially a distro-config/
of LibreOfficeHeadless or something might work ? [ though that's a bit
lame ;-].

ATB,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: not delivering cairo on mac os x build

2012-09-05 Thread Riccardo Magliocchetti

Il 05/09/2012 16:03, Riccardo Magliocchetti ha scritto:

Hello,

Il 05/09/2012 15:55, Stephan Bergmann ha scritto:

On 09/05/2012 03:50 PM, Michael Stahl wrote:

On 05/09/12 15:40, Alexander Thurgood wrote:

I'm getting cairo build failure on the Mac, and even when I
specifically
use --disable-cairo-canvas in my configure line, it still gets built ?


that option only disables the cairo canvas but not other cairo using
components such as the SVG filter. if you use --disable-rsvg as well
you may be able to get a cairo-less build.


--disable-librsvg


Yes, i've spent the last few days on chasing down build issues related
to --enable-headless on linux and i'm down to three separate switches
(there is cups for sure and another package) i still need to compile
correctly. I've aready fixed two issues in master and plan to resolve
these issues in before end of week. Last famous words :)


So this are the minimum switches i need to be able to compile latest 
master with --enable-headless, i don't think --without-java is needed 
but i don't need java here:


./autogen.sh --without-java --enable-headless --disable-cups 
--disable-graphite --disable-gnome-vfs --disable-librsvg


I think all but cups are fixable within configure.in

hth,
riccardo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Tinderbox failure, Linux-x86-64@8-SLED11, libreoffice-3-5, last success: 2012-08-29 21:47:46

2012-09-05 Thread Michael Stahl
On 05/09/12 17:28, lio...@mamane.lu wrote:
> On Wed, Sep 05, 2012 at 09:14:10AM +, ke...@suse.cz wrote:
>> Commits since the last success:
> 
>>  core 
>>   8806e6e  fdo#53872: reportdesign: fix section drawpage crash:
>>  binfilter 
>>  dictionaries 
>>  help 
> 
>> In file included from 
>> /local/home/tinderbox/libreoffice-3-5/solver/unxlngx6.pro/inc/sfx2/sfx.hrc:389,
>>  from 
>> /local/home/tinderbox/libreoffice-3-5/sfx2/source/bastyp/fltfnc.src:29:
>> /local/home/tinderbox/libreoffice-3-5/solver/unxlngx6.pro/inc/sfx2/sfxsids.hrc:27:1:
>>  error: unterminated #ifndef
>> In file included from 
>> /local/home/tinderbox/libreoffice-3-5/solver/unxlngx6.pro/inc/sfx2/sfx.hrc:389,
>>  from 
>> /local/home/tinderbox/libreoffice-3-5/sfx2/source/bastyp/bastyp.hrc:28,
>>  from 
>> /local/home/tinderbox/libreoffice-3-5/sfx2/source/bastyp/bastyp.src:27:
>> /local/home/tinderbox/libreoffice-3-5/solver/unxlngx6.pro/inc/sfx2/sfxsids.hrc:27:1:
>>  error: unterminated #ifndef
> 
> Hmm... I don't my commit could have caused that. Kendy, could you just
> "try again"? (AFAIK, the tinderbox won't try again until next commit
> which could be days away.)

iirc this specific tinderbox randomly breaks with this exact error
sometimes, nobody ever found out why.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Closing bugs in bugzilla: fixed in master or fixed everywhere?

2012-09-05 Thread Lionel Elie Mamane
On Wed, Sep 05, 2012 at 12:44:58PM +0200, Bjoern Michaelsen wrote:
> On Wed, Sep 05, 2012 at 11:39:04AM +0200, Stephan Bergmann wrote:
>> On 09/05/2012 10:46 AM, Lionel Elie Mamane wrote:

>>> I thought we close the bug when the fix is committed in all branches
>>> where it should be, and that's what I was doing in the bugs I was
>>> fixing.

>> That's my understanding too, setting a bug to RESOLVED/FIXED only
>> once all the relevant commits have reached the intended branches.

> That is quite tricky as "intended branches" is not clearly defined,

How is it "not clearly defined"?

 - Either we want the fix in 3.6.x or we don't.

 - When in the RC phase of 3.6.2, either we want the fix in
   3.6.2.next-rc or not.

 - Either we want the fix in 3.5.x or we don't.

 - When in the RC phase of 3.5.7, either we want the fix in
   3.5.7.next-rc or not.

Once these decisions are taken, the intended branches are fixed:

 - Yes -> libreoffice-3-6

 - Yes -> libreoffice-3-6-2

 - Yes -> libreoffice-3-5

 - Yes -> libreoffice-3-5-7

We can change our opinion on these questions, and then the "intended
branches" set changes.

> and in addition it runs counter to what mozilla defines the RESOLVED state:

>  https://bugzilla.mozilla.org/page.cgi?id=fields.html

Bugzilla has absolutely no clue about multiple development branches,
and this is one of its main flaws.

Even considering this, in the link you give "RESOLVED" is: "A
resolution has been taken, (...)", which to me does not say whether it
is "a resolution has been taken in some branch" or "a resolution has
been taken in all intended branches".

> In our case, as we dont really verify yet, I would suggest the following:

> RESOLVED: assumed to be fixed for some branch, not tested, not yet released

So if you go to https://bugs.freedesktop.org/show_bug.cgi?id=37361 (LO
3.5 MAB), you have to click through on *each* resolved bug to read the
bug log and try to see if there is a "fixed in 3.5.x" comment (or
possibly look in whiteboard for a target:3.5", so that you can
evaluate whether it is still relevant, or if action is needed?
This makes it IMHO too easy for a bug to "slip under the radar" and be
forgotten.

With my / Stephan's way you'd have to click on each *open* bug to get
certainty whether action is needed for 3.5; but each of these bugs has
"action needed for some branch".

I feel less bad about making people reviewing MAB list go to bugs that
need some action, but elsewhere, rather than having to look at all
already handled bugs.

In the ESC call agenda, we have MAB statistics that say e.g.

 * 3.5 most annoying bugs ...
 + 81 open (of 269) older 73/258 73/257 76/256 75/253 77/253 73/250  72/249
30% 26%28%30% 30%30%29%   29%
 + 
https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

   With your suggestion, this would mean "81 not fixed anywhere", and
   this might be... between 81 and 269 fixed in 3.5.

   With my / Stephan's way, this means "81 not fixed everywhere it
   should", and this might be between 0 and 81 fixed in 3.5.

I prefer to err on the side of caution, that is overreporting the
number of relevant bugs rather than underreproting them.


> CLOSED: there is a version with the fix released

OK with me (and a nice service to our users). Same bikeshedding on
"all intended branches have a version with the fix" or "at least one
branch has a version with the fix".

We could consider automoving on RC release rather than final release?

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: vcl/source

2012-09-05 Thread Libreoffice Gerrit user
 vcl/source/gdi/pdfwriter_impl.cxx |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit b6ee7da3bff1eaca3425bfdf074a979a48f3305e
Author: Fridrich Å trba 
Date:   Wed Sep 5 16:21:07 2012 +0200

Revert "Relax ICC profile version for PDF/1-a to 2.4"

The lcms2 author advises 2.1 and that is the version we advertize
in the name of the embedded icc file.

This reverts commit 3bb22684c3e0e865f1635ba52ea84630ff766b8c.

diff --git a/vcl/source/gdi/pdfwriter_impl.cxx 
b/vcl/source/gdi/pdfwriter_impl.cxx
index 4760555..a5d6a77 100644
--- a/vcl/source/gdi/pdfwriter_impl.cxx
+++ b/vcl/source/gdi/pdfwriter_impl.cxx
@@ -6563,8 +6563,8 @@ sal_Int32 PDFWriterImpl::emitOutputIntent()
 beginCompression();
 checkAndEnableStreamEncryption( nICCObject );
 cmsHPROFILE hProfile = cmsCreate_sRGBProfile();
-//force ICC profile version 2.4
-cmsSetProfileVersion(hProfile, 2.4);
+//force ICC profile version 2.1
+cmsSetProfileVersion(hProfile, 2.1);
 cmsUInt32Number nBytesNeeded = 0;
 cmsSaveProfileToMem(hProfile, NULL, &nBytesNeeded);
 if (!nBytesNeeded)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[REVIEW-3-6] better import for old conditional format documents

2012-09-05 Thread Markus Mohrhard
Hey,

I have a little bit bigger patch for the cond format import from the
old ODF structures. ODF stores conditional formats as part of the
styles so if you have different cells using different styles but the
same conditional format they were imported as separated conditional
formats. This was no problem as long as we did not care about the
range of the conditional format but results now in extremely long
lists in the new structure. The patch now imports the same conditional
format in the ODF structure also in the same in the new structure and
just adjusts the range.

I have attached two test documents. The larger one is to check that
the cond format import still works and the smaller one shows the
problem with the old approach. It would be good if we get this patch
into 3.6.2 to prevent more documents with the new structure and the
large number of conditional formats instead of adjusted ranges.

Regards,
Markus

[1] 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=bedbb471c3f49e0860dd63b17c1faeee837096ae

P.S. The large test document was kindly provided by Miguel Ángel.


test_old_cond_format.ods
Description: application/vnd.oasis.opendocument.spreadsheet


LibreO_qaTest_ConditionalFormatting_Up_3-5_en.ods
Description: application/vnd.oasis.opendocument.spreadsheet
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: sc/inc sc/source

2012-09-05 Thread Libreoffice Gerrit user
 sc/inc/conditio.hxx   |4 
 sc/source/core/data/conditio.cxx  |   34 +++-
 sc/source/filter/xml/xmlimprt.cxx |2 
 sc/source/filter/xml/xmlimprt.hxx |1 
 sc/source/filter/xml/xmlstyli.cxx |  259 --
 sc/source/filter/xml/xmlstyli.hxx |   32 +---
 6 files changed, 151 insertions(+), 181 deletions(-)

New commits:
commit bedbb471c3f49e0860dd63b17c1faeee837096ae
Author: Markus Mohrhard 
Date:   Mon Sep 3 19:30:26 2012 +0200

better import of conditional format from old ODF structure

The old ODF storage is style based and so the sam cond format can be
divided up into several single stlyes which resulted in several new
style cond formats.

Now we check for old stlye cond formats if there is a equal cond format
and in this case just extend the area. This should make it easier to
transform old documents into the new range based cond formats.

Change-Id: I51a5148922e19e6860de9915abfc59d49b18d96e

diff --git a/sc/inc/conditio.hxx b/sc/inc/conditio.hxx
index 9890758..b4f686e 100644
--- a/sc/inc/conditio.hxx
+++ b/sc/inc/conditio.hxx
@@ -111,6 +111,8 @@ public:
 
 virtual void SetParent( ScConditionalFormat* pNew ) = 0;
 
+bool operator==( const ScFormatEntry& ) const;
+
 #if DUMP_FORMAT_INFO
 virtual void dumpInfo() const = 0;
 #endif
@@ -282,6 +284,8 @@ public:
 voidAddEntry( ScFormatEntry* pNew );
 voidAddRange( const ScRangeList& rRanges );
 const ScRangeList&  GetRange() const  { return maRanges; }
+// don't use the same name as for the const version
+ScRangeList& GetRangeList() { return maRanges; }
 
 bool IsEmpty() const { return maEntries.empty(); }
 size_t size() const   { return maEntries.size(); }
diff --git a/sc/source/core/data/conditio.cxx b/sc/source/core/data/conditio.cxx
index 17483c3..5a0c483 100644
--- a/sc/source/core/data/conditio.cxx
+++ b/sc/source/core/data/conditio.cxx
@@ -54,6 +54,27 @@ ScFormatEntry::ScFormatEntry(ScDocument* pDoc):
 {
 }
 
+bool ScFormatEntry::operator==( const ScFormatEntry& r ) const
+{
+if(GetType() != r.GetType())
+return false;
+
+switch(GetType())
+{
+case condformat::CONDITION:
+return static_cast(*this) == 
static_cast(r);
+break;
+default:
+// TODO: implement also this case
+// actually return false for these cases is not that bad
+// as soon as databar and color scale are tested we need
+// to think about the range
+return false;
+}
+
+return true;
+}
+
 bool lcl_HasRelRef( ScDocument* pDoc, ScTokenArray* pFormula, sal_uInt16 
nRecursion = 0 )
 {
 if (pFormula)
@@ -1286,8 +1307,6 @@ int ScCondFormatEntry::operator== ( const 
ScCondFormatEntry& r ) const
 {
 return ScConditionEntry::operator==( r ) &&
 aStyleName == r.aStyleName;
-
-//  Range wird nicht verglichen
 }
 
 ScCondFormatEntry::~ScCondFormatEntry()
@@ -1353,13 +1372,14 @@ bool ScConditionalFormat::EqualEntries( const 
ScConditionalFormat& r ) const
 
 //! auf gleiche Eintraege in anderer Reihenfolge testen ???
 
-/*
-for (sal_uInt16 i=0; iFillPropertySet(xProperties);
+// here needs to be the cond format import method
 sal_Int32 nNumberFormat(pStyle->GetNumberFormat());
 SetType(xProperties, nNumberFormat, nPrevCellType, 
sPrevCurrency);
 
 // store first cell of first range for each style, once per 
sheet
 uno::Sequence 
aAddresses(xSheetCellRanges->getRangeAddresses());
+pStyle->ApplyCondFormat(aAddresses);
 if ( aAddresses.getLength() > 0 )
 {
 const table::CellRangeAddress& rRange = aAddresses[0];
diff --git a/sc/source/filter/xml/xmlimprt.hxx 
b/sc/source/filter/xml/xmlimprt.hxx
index f3706d9..d9d86fc 100644
--- a/sc/source/filter/xml/xmlimprt.hxx
+++ b/sc/source/filter/xml/xmlimprt.hxx
@@ -852,6 +852,7 @@ class ScXMLImport: public SvXMLImport
 com::sun::star::uno::Reference  
xNumberFormats;
 com::sun::star::uno::Reference  
xNumberFormatTypes;
 
+ScRangeList maSheetRanges;
 com::sun::star::uno::Reference 
 xSheetCellRanges;
 
 rtl::OUString   sEmpty;
diff --git a/sc/source/filter/xml/xmlstyli.cxx 
b/sc/source/filter/xml/xmlstyli.cxx
index 1ef7cda..5776d72 100644
--- a/sc/source/filter/xml/xmlstyli.cxx
+++ b/sc/source/filter/xml/xmlstyli.cxx
@@ -52,6 +52,15 @@
 #include "docuno.hxx"
 #include "unonames.hxx"
 #include "document.hxx"
+#include "conditio.hxx"
+#include "svl/intitem.hxx"
+#include "rangelst.hxx"
+#include "rangeutl.hxx"
+#include "docfunc.hxx"
+#include "markdata.hxx"
+#include "docpool.hxx"
+#include "scitems.hxx"
+#include "patattr.hxx"
 
 #define XML_LINE_LEFT 0
 #define XML_LINE_RIGHT 1
@@ -279,9 +288,12 @@ void ScXMLRowImportPropertyMapper::finished(::std::vector< 
X

Re: Tinderbox failure, Linux-x86-64@8-SLED11, libreoffice-3-5, last success: 2012-08-29 21:47:46

2012-09-05 Thread lio...@mamane.lu
On Wed, Sep 05, 2012 at 09:14:10AM +, ke...@suse.cz wrote:
> Commits since the last success:

>  core 
>   8806e6e  fdo#53872: reportdesign: fix section drawpage crash:
>  binfilter 
>  dictionaries 
>  help 

> In file included from 
> /local/home/tinderbox/libreoffice-3-5/solver/unxlngx6.pro/inc/sfx2/sfx.hrc:389,
>  from 
> /local/home/tinderbox/libreoffice-3-5/sfx2/source/bastyp/fltfnc.src:29:
> /local/home/tinderbox/libreoffice-3-5/solver/unxlngx6.pro/inc/sfx2/sfxsids.hrc:27:1:
>  error: unterminated #ifndef
> In file included from 
> /local/home/tinderbox/libreoffice-3-5/solver/unxlngx6.pro/inc/sfx2/sfx.hrc:389,
>  from 
> /local/home/tinderbox/libreoffice-3-5/sfx2/source/bastyp/bastyp.hrc:28,
>  from 
> /local/home/tinderbox/libreoffice-3-5/sfx2/source/bastyp/bastyp.src:27:
> /local/home/tinderbox/libreoffice-3-5/solver/unxlngx6.pro/inc/sfx2/sfxsids.hrc:27:1:
>  error: unterminated #ifndef

Hmm... I don't my commit could have caused that. Kendy, could you just
"try again"? (AFAIK, the tinderbox won't try again until next commit
which could be days away.)

OTOH, that file is a bit weird in that there is stuff *after* the
"#endif" that corresponds to the standard double-include protection
"#ifndef _SFXSIDS_HRC". Most of it looks safe, having its own #ifndef,
but there is also unconditional stuff at the very end.


#ifndef _SFXSIDS_HRC
#define _SFXSIDS_HRC

(lots of stuff)

#endif  // #ifndef _SFXSIDS_HRC

//---
// SfxSecurityPage related stuff

#define FN_EDIT2(SID_SW_START + 1800)
#define FN_REDLINE_PROTECT  (FN_EDIT2 + 23)
#define FN_REDLINE_ON   (FN_EDIT2 + 25)

#define SID_HTML_MODE   (SID_SVX_START + 414)

// Calc-Id's used for SfxSecurityPage
#ifndef SC_FUNCTION_START
#define SC_FUNCTION_START   (SID_SC_START + 200)
#endif
#ifndef FILE_MENU_END
#define FILE_MENU_END   (SC_FUNCTION_START + 20)
#endif
#ifndef EDIT_MENU_START
#define EDIT_MENU_START (FILE_MENU_END)
#endif
#ifndef SC_VIEW_START
#define SC_VIEW_START   (SID_SC_START)
#endif
#define FID_CHG_RECORD  (EDIT_MENU_START + 18)
#define SID_CHG_PROTECT (SC_VIEW_START + 84)

// eof


-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] Change in core[libreoffice-3-6]: HelpIndexer, HelpLinker are build-time tools

2012-09-05 Thread Gerrit
>From Michael Stahl :

Michael Stahl has submitted this change and it was merged.

Change subject: HelpIndexer, HelpLinker are build-time tools
..


HelpIndexer, HelpLinker are build-time tools

Change-Id: I43186271f36f67a95a7e3766e1998ea42531e596
(cherry picked from commit beab021ffe57cf6004971d4f285984b6debe5b5f)
---
M Repository.mk
1 file changed, 2 insertions(+), 2 deletions(-)

Approvals:
  Michael Stahl: Verified; Looks good to me, approved


--
To view, visit https://gerrit.libreoffice.org/562
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I43186271f36f67a95a7e3766e1998ea42531e596
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Stephan Bergmann 
Gerrit-Reviewer: Michael Stahl 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: Branch 'libreoffice-3-6' - Repository.mk

2012-09-05 Thread Libreoffice Gerrit user
 Repository.mk |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit f7b30deea8ec205a252908107d1c1b37a38a114b
Author: Stephan Bergmann 
Date:   Thu Aug 30 08:17:53 2012 +0200

HelpIndexer, HelpLinker are build-time tools

Change-Id: I43186271f36f67a95a7e3766e1998ea42531e596
(cherry picked from commit beab021ffe57cf6004971d4f285984b6debe5b5f)
Reviewed-on: https://gerrit.libreoffice.org/562
Reviewed-by: Michael Stahl 
Tested-by: Michael Stahl 

diff --git a/Repository.mk b/Repository.mk
index 6d74bfa..67ba527 100644
--- a/Repository.mk
+++ b/Repository.mk
@@ -27,6 +27,8 @@
 #*
 
 $(eval $(call gb_Helper_register_executables,NONE, \
+HelpIndexer \
+HelpLinker \
 bestreversemap \
 bmp \
 bmpsum \
@@ -83,8 +85,6 @@ endif
 
 $(eval $(call gb_Helper_register_executables,OOO, \
 gnome-open-url.bin \
-HelpLinker \
-HelpIndexer \
 spadmin.bin \
$(if $(filter $(GUIBASE)$(ENABLE_TDE),unxTRUE), \
tdefilepicker \
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[PUSHED] Change in core[libreoffice-3-6]: fdo#53009: Compile extension help in gbuild

2012-09-05 Thread Gerrit
>From Michael Stahl :

Michael Stahl has submitted this change and it was merged.

Change subject: fdo#53009: Compile extension help in gbuild
..


fdo#53009: Compile extension help in gbuild

...as had been done in the old build system (solenv/inc/extension_helplink.mk).
Especially for bundled extensions, this removes the need to compile the help
data per user on first start.

gb_Extension_add_helpfile(s) replaces gb_Extension_localize_help, and takes care
of all the steps (localization, compilation, inclusion in .oxt), even for the
en-US data (which was handled with additional gb_Extension_add_file calls
before).

(cherry picked from commit b23bb8e0de3dbdc2c66c3dedf70dfd318868f76c with
additional fixes from follow-up commits 152ffaa15f963f92b1564946a648c53d6b5c808c
"Call HelpIndexer/Linker with gb_Helper_set_ld_path" and
a297372210396260da57f34da3790f76682603cc "Quote .ddf content (potentially
containing stuff like '%2F')")

Conflicts:
solenv/gbuild/Extension.mk
solenv/gbuild/ExtensionTarget.mk

Change-Id: Ie4bab66d3cad2b713780a23bf2606ca56cfff37f
---
M nlpsolver/Extension_nlpsolver.mk
M sdext/Extension_presenter.mk
M solenv/bin/modules/installer/windows/msiglobal.pm
M solenv/gbuild/Extension.mk
M swext/Extension_wiki-publisher.mk
5 files changed, 141 insertions(+), 52 deletions(-)

Approvals:
  Michael Stahl: Verified; Looks good to me, approved


--
To view, visit https://gerrit.libreoffice.org/563
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Ie4bab66d3cad2b713780a23bf2606ca56cfff37f
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Stephan Bergmann 
Gerrit-Reviewer: Michael Stahl 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: Branch 'libreoffice-3-6' - nlpsolver/Extension_nlpsolver.mk sdext/Extension_presenter.mk solenv/bin solenv/gbuild swext/Extension_wiki-publisher.mk

2012-09-05 Thread Libreoffice Gerrit user
 nlpsolver/Extension_nlpsolver.mk  |   15 +-
 sdext/Extension_presenter.mk  |6 
 solenv/bin/modules/installer/windows/msiglobal.pm |   18 +-
 solenv/gbuild/Extension.mk|  136 ++
 swext/Extension_wiki-publisher.mk |   18 +-
 5 files changed, 141 insertions(+), 52 deletions(-)

New commits:
commit 4ae49101fd43d052c3556b2db753e4d8ae7d86ce
Author: Stephan Bergmann 
Date:   Wed Sep 5 10:57:25 2012 +0200

fdo#53009: Compile extension help in gbuild

...as had been done in the old build system 
(solenv/inc/extension_helplink.mk).
Especially for bundled extensions, this removes the need to compile the help
data per user on first start.

gb_Extension_add_helpfile(s) replaces gb_Extension_localize_help, and takes 
care
of all the steps (localization, compilation, inclusion in .oxt), even for 
the
en-US data (which was handled with additional gb_Extension_add_file calls
before).

(cherry picked from commit b23bb8e0de3dbdc2c66c3dedf70dfd318868f76c with
additional fixes from follow-up commits 
152ffaa15f963f92b1564946a648c53d6b5c808c
"Call HelpIndexer/Linker with gb_Helper_set_ld_path" and
a297372210396260da57f34da3790f76682603cc "Quote .ddf content (potentially
containing stuff like '%2F')")

Conflicts:
solenv/gbuild/Extension.mk
solenv/gbuild/ExtensionTarget.mk

Change-Id: Ie4bab66d3cad2b713780a23bf2606ca56cfff37f
Reviewed-on: https://gerrit.libreoffice.org/563
Reviewed-by: Michael Stahl 
Tested-by: Michael Stahl 

diff --git a/nlpsolver/Extension_nlpsolver.mk b/nlpsolver/Extension_nlpsolver.mk
index b7de4b0..6f2690f 100644
--- a/nlpsolver/Extension_nlpsolver.mk
+++ b/nlpsolver/Extension_nlpsolver.mk
@@ -1,3 +1,4 @@
+# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
 #
 # Version: MPL 1.1 / GPLv3+ / LGPLv3+
 #
@@ -39,11 +40,9 @@ $(eval $(call 
gb_Extension_add_file,nlpsolver,locale/NLPSolverStatusDialog_en_US
 $(eval $(call 
gb_Extension_localize_properties,nlpsolver,locale/NLPSolverCommon_en_US.properties,$(SRCDIR)/nlpsolver/src/locale/NLPSolverCommon_en_US.properties))
 $(eval $(call 
gb_Extension_localize_properties,nlpsolver,locale/NLPSolverStatusDialog_en_US.properties,$(SRCDIR)/nlpsolver/src/locale/NLPSolverStatusDialog_en_US.properties))
 
-$(eval $(call 
gb_Extension_add_file,nlpsolver,help/en-US/com.sun.star.comp.Calc.NLPSolver/Options.xhp,
 \
-   
$(SRCDIR)/nlpsolver/help/en/com.sun.star.comp.Calc.NLPSolver/Options.xhp))
-$(eval $(call 
gb_Extension_add_file,nlpsolver,help/en-US/com.sun.star.comp.Calc.NLPSolver/Usage.xhp,
 \
-   $(SRCDIR)/nlpsolver/help/en/com.sun.star.comp.Calc.NLPSolver/Usage.xhp))
-$(eval $(call 
gb_Extension_localize_help,nlpsolver,help/lang/com.sun.star.comp.Calc.NLPSolver/Options.xhp,
 \
-   
$(SRCDIR)/nlpsolver/help/en/com.sun.star.comp.Calc.NLPSolver/Options.xhp))
-$(eval $(call 
gb_Extension_localize_help,nlpsolver,help/lang/com.sun.star.comp.Calc.NLPSolver/Usage.xhp,
 \
-   $(SRCDIR)/nlpsolver/help/en/com.sun.star.comp.Calc.NLPSolver/Usage.xhp))
+$(eval $(call 
gb_Extension_add_helpfiles,nlpsolver,$(SRCDIR)/nlpsolver/help/en, \
+com.sun.star.comp.Calc.NLPSolver/Options.xhp \
+   com.sun.star.comp.Calc.NLPSolver/Usage.xhp \
+))
+
+# vim: set noet sw=4 ts=4:
diff --git a/sdext/Extension_presenter.mk b/sdext/Extension_presenter.mk
index 2a83712..ba5a51a 100644
--- a/sdext/Extension_presenter.mk
+++ b/sdext/Extension_presenter.mk
@@ -141,10 +141,6 @@ $(eval $(call 
gb_Extension_add_files,presenter-screen,registry/data/org/openoffi
 $(call 
gb_XcuDataTarget_get_target,sdext/source/presenter/registry/data/org/openoffice/Office/ProtocolHandler.xcu)
 \
 ))
 
-$(eval $(call 
gb_Extension_add_files,presenter-screen,help/en-US/com.sun.PresenterScreen-$(sdext_PLATFORM),\
-
$(WORKDIR)/CustomTarget/sdext/source/presenter/help/en-US/com.sun.PresenterScreen/presenter.xhp
 \
-))
-
-$(eval $(call 
gb_Extension_localize_help,presenter-screen,help/lang/com.sun.PresenterScreen-$(sdext_PLATFORM)/presenter.xhp,$(WORKDIR)/CustomTarget/sdext/source/presenter/help/en-US/com.sun.PresenterScreen/presenter.xhp))
+$(eval $(call 
gb_Extension_add_helpfile,presenter-screen,$(WORKDIR)/CustomTarget/sdext/source/presenter/help/en-US,com.sun.PresenterScreen-$(sdext_PLATFORM)/presenter.xhp,com.sun.PresenterScreen/presenter.xhp))
 
 # vim:set shiftwidth=4 softtabstop=4 expandtab:
diff --git a/solenv/bin/modules/installer/windows/msiglobal.pm 
b/solenv/bin/modules/installer/windows/msiglobal.pm
index c6a70ff..82db7dd 100644
--- a/solenv/bin/modules/installer/windows/msiglobal.pm
+++ b/solenv/bin/modules/installer/windows/msiglobal.pm
@@ -210,7 +210,7 @@ sub generate_cab_file_list
 
 write_ddf_file_header(\@ddffile, $cabinetfile, $installdir);
 
-my $ddfline = "\"" . $sourcepath . "\"" . " " . $uniquename . "\n";
+my $ddfline = "\"" 

Re: not delivering cairo on mac os x build

2012-09-05 Thread Stephan Bergmann

On 09/05/2012 04:00 PM, Alexander Thurgood wrote:

Le 05/09/12 15:55, Stephan Bergmann a écrit :

--disable-librsvg


Does that mean no SVG filters get built ?


To be honest, all I know is that it made one specific Mac build scenario 
work for me.  :)


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: not delivering cairo on mac os x build

2012-09-05 Thread Riccardo Magliocchetti

Hello,

Il 05/09/2012 15:55, Stephan Bergmann ha scritto:

On 09/05/2012 03:50 PM, Michael Stahl wrote:

On 05/09/12 15:40, Alexander Thurgood wrote:

I'm getting cairo build failure on the Mac, and even when I specifically
use --disable-cairo-canvas in my configure line, it still gets built ?


that option only disables the cairo canvas but not other cairo using
components such as the SVG filter. if you use --disable-rsvg as well
you may be able to get a cairo-less build.


--disable-librsvg


Yes, i've spent the last few days on chasing down build issues related 
to --enable-headless on linux and i'm down to three separate switches 
(there is cups for sure and another package) i still need to compile 
correctly. I've aready fixed two issues in master and plan to resolve 
these issues in before end of week. Last famous words :)


thanks,
riccardo

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: not delivering cairo on mac os x build

2012-09-05 Thread Alexander Thurgood
Le 05/09/12 15:55, Stephan Bergmann a écrit :

Hi Stephan, Michael,

>
>> that option only disables the cairo canvas but not other cairo using
>> components such as the SVG filter.  if you use --disable-rsvg as well
>> you may be able to get a cairo-less build.
> 
> --disable-librsvg


Does that mean no SVG filters get built ?

Alex


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: not delivering cairo on mac os x build

2012-09-05 Thread Stephan Bergmann

On 09/05/2012 03:50 PM, Michael Stahl wrote:

On 05/09/12 15:40, Alexander Thurgood wrote:

I'm getting cairo build failure on the Mac, and even when I specifically
use --disable-cairo-canvas in my configure line, it still gets built ?


that option only disables the cairo canvas but not other cairo using
components such as the SVG filter.  if you use --disable-rsvg as well
you may be able to get a cairo-less build.


--disable-librsvg

Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: not delivering cairo on mac os x build

2012-09-05 Thread Michael Stahl
On 05/09/12 15:40, Alexander Thurgood wrote:
> Le 27/08/12 18:27, Riccardo Magliocchetti a écrit :
> 
> Hi Riccardo,
> 
>> i'm trying to sort out building with --enable-headless on mac os x, with
>> the attached patch it does not try to build cairo and pixman anymore but
>> somewhere cairo is still expected:
>>
> 
> I'm getting cairo build failure on the Mac, and even when I specifically
> use --disable-cairo-canvas in my configure line, it still gets built ?

that option only disables the cairo canvas but not other cairo using
components such as the SVG filter.  if you use --disable-rsvg as well
you may be able to get a cairo-less build.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: 2 commits - comphelper/source eventattacher/source extensions/source extensions/test pyuno/source udkapi/com udkapi/UnoApi_udkapi.mk

2012-09-05 Thread Libreoffice Gerrit user
 comphelper/source/eventattachermgr/eventattachermgr.cxx |   22 +-
 eventattacher/source/eventattacher.cxx  |4 -
 extensions/source/ole/unoobjw.cxx   |   34 +++
 extensions/test/ole/cpnt/cpnt.cxx   |   35 +++-
 pyuno/source/module/pyuno_runtime.cxx   |   12 +
 udkapi/UnoApi_udkapi.mk |3 +
 udkapi/com/sun/star/reflection/CoreReflection.idl   |   10 
 udkapi/com/sun/star/reflection/theCoreReflection.idl|   35 
 8 files changed, 90 insertions(+), 65 deletions(-)

New commits:
commit 0411360989b7a1371d4fa13dcd695ebe9157bbd1
Author: Stephan Bergmann 
Date:   Wed Sep 5 15:46:18 2012 +0200

Some clean up of previous commit

Change-Id: I05287fd79455f968c770d61bf5f320b07bba7d9e

diff --git a/pyuno/source/module/pyuno_runtime.cxx 
b/pyuno/source/module/pyuno_runtime.cxx
index a89b182..c61ae00 100644
--- a/pyuno/source/module/pyuno_runtime.cxx
+++ b/pyuno/source/module/pyuno_runtime.cxx
@@ -46,7 +46,6 @@ using com::sun::star::uno::TypeDescription;
 using com::sun::star::uno::Sequence;
 using com::sun::star::uno::Type;
 using com::sun::star::uno::UNO_QUERY;
-using com::sun::star::uno::UNO_QUERY_THROW;
 using com::sun::star::uno::Exception;
 using com::sun::star::uno::RuntimeException;
 using com::sun::star::uno::XComponentContext;
commit b679a2a02180c017bd8b596fb2e4f283bad93b75
Author: Noel Grandin 
Date:   Tue Sep 4 16:12:17 2012 +0200

fdo#46808, Adapt reflection::CoreReflection UNO service to new style

The XComponent part of the interface made no sense for a singleton,
so it was removed.
Explicitly document the 'theCoreReflection' singleton and move it
into it's own file.
Deprecated the now old CoreReflection service.

Change-Id: Ib8befa87c7da7eb53a2f587948fd54a64c082472

diff --git a/comphelper/source/eventattachermgr/eventattachermgr.cxx 
b/comphelper/source/eventattachermgr/eventattachermgr.cxx
index 644d2d9..9b24026 100644
--- a/comphelper/source/eventattachermgr/eventattachermgr.cxx
+++ b/comphelper/source/eventattachermgr/eventattachermgr.cxx
@@ -23,6 +23,7 @@
 #endif
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,14 +96,14 @@ class ImplEventAttacherManager
 OInterfaceContainerHelper   aScriptListeners;
 // Instance of EventAttacher
 Reference< XEventAttacher2 >xAttacher;
-Reference< XMultiServiceFactory >   mxSMgr;
+Reference< XComponentContext >  mxContext;
 Reference< XIdlReflection > mxCoreReflection;
 Reference< XIntrospection > mxIntrospection;
 Reference< XTypeConverter > xConverter;
 sal_Int16   nVersion;
 public:
 ImplEventAttacherManager( const Reference< XIntrospection > & 
rIntrospection,
-  const Reference< XMultiServiceFactory > rSMgr );
+  const Reference< XComponentContext > xContext );
 ~ImplEventAttacherManager();
 
 // Methods of XEventAttacherManager
@@ -361,7 +363,7 @@ Reference< XEventAttacherManager > 
createEventAttacherManager( const Reference<
 if ( xIFace.is() )
 {
 Reference< XIntrospection > xIntrospection( xIFace, UNO_QUERY);
-return new ImplEventAttacherManager( xIntrospection, rSMgr );
+return new ImplEventAttacherManager( xIntrospection, 
comphelper::ComponentContext(rSMgr).getUNOContext() );
 }
 }
 
@@ -370,19 +372,20 @@ Reference< XEventAttacherManager > 
createEventAttacherManager( const Reference<
 
 //-
 ImplEventAttacherManager::ImplEventAttacherManager( const Reference< 
XIntrospection > & rIntrospection,
-const Reference< 
XMultiServiceFactory > rSMgr )
+const Reference< 
XComponentContext > xContext )
 : aScriptListeners( aLock )
-, mxSMgr( rSMgr )
+, mxContext( xContext )
 , mxIntrospection( rIntrospection )
 {
-if ( rSMgr.is() )
+if ( xContext.is() )
 {
-Reference< XInterface > xIFace( rSMgr->createInstance( OUString( 
RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.script.EventAttacher" )) ) );
+Reference< XInterface > xIFace( 
xContext->getServiceManager()->createInstanceWithContext(
+ OUString( RTL_CONSTASCII_USTRINGPARAM( 
"com.sun.star.script.EventAttacher" )), xContext)  );
 if ( xIFace.is() )
 {
 xAttacher = Reference< XEventAttacher2 >::query( xIFace );
 }
-xConverter = 
Converter::create(comphelper::ComponentContext(rSMgr).getUNOContext());
+xConverter = Converter::create(xContext);
 }
 
 Reference< X

Re: not delivering cairo on mac os x build

2012-09-05 Thread Alexander Thurgood
Le 27/08/12 18:27, Riccardo Magliocchetti a écrit :

Hi Riccardo,

> i'm trying to sort out building with --enable-headless on mac os x, with
> the attached patch it does not try to build cairo and pixman anymore but
> somewhere cairo is still expected:
> 

I'm getting cairo build failure on the Mac, and even when I specifically
use --disable-cairo-canvas in my configure line, it still gets built ?


Alex


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: vcl/source

2012-09-05 Thread Libreoffice Gerrit user
 vcl/source/gdi/pdfwriter_impl.cxx |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 3bb22684c3e0e865f1635ba52ea84630ff766b8c
Author: Lionel Elie Mamane 
Date:   Wed Sep 5 15:21:27 2012 +0200

Relax ICC profile version for PDF/1-a to 2.4

Change-Id: I26942f1a046651e30a1625dcd3dcbf201fa65d5b

diff --git a/vcl/source/gdi/pdfwriter_impl.cxx 
b/vcl/source/gdi/pdfwriter_impl.cxx
index a5d6a77..4760555 100644
--- a/vcl/source/gdi/pdfwriter_impl.cxx
+++ b/vcl/source/gdi/pdfwriter_impl.cxx
@@ -6563,8 +6563,8 @@ sal_Int32 PDFWriterImpl::emitOutputIntent()
 beginCompression();
 checkAndEnableStreamEncryption( nICCObject );
 cmsHPROFILE hProfile = cmsCreate_sRGBProfile();
-//force ICC profile version 2.1
-cmsSetProfileVersion(hProfile, 2.1);
+//force ICC profile version 2.4
+cmsSetProfileVersion(hProfile, 2.4);
 cmsUInt32Number nBytesNeeded = 0;
 cmsSaveProfileToMem(hProfile, NULL, &nBytesNeeded);
 if (!nBytesNeeded)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[Libreoffice-commits] .: Branch 'libreoffice-3-6' - vcl/source

2012-09-05 Thread Libreoffice Gerrit user
 vcl/source/gdi/pdfwriter_impl.cxx |2 ++
 1 file changed, 2 insertions(+)

New commits:
commit 5a36a0cab0d4d32968404c0d88772e1a6303af00
Author: Fridrich Å trba 
Date:   Wed Sep 5 14:27:21 2012 +0200

fdo#54546: Force version 2.1 of the sRGB profile for PDF/A-1a

(cherry picked from commit 24f691867d02e853153a53e49276c2a8c30ea1fe)

Change-Id: I7c40c37fbe344f1e46ea4a09fb99a5ac82ffd577
Signed-off-by: Lionel Elie Mamane 

diff --git a/vcl/source/gdi/pdfwriter_impl.cxx 
b/vcl/source/gdi/pdfwriter_impl.cxx
index 2c4d10b..6676cfb 100644
--- a/vcl/source/gdi/pdfwriter_impl.cxx
+++ b/vcl/source/gdi/pdfwriter_impl.cxx
@@ -6203,6 +6203,8 @@ sal_Int32 PDFWriterImpl::emitOutputIntent()
 beginCompression();
 checkAndEnableStreamEncryption( nICCObject );
 cmsHPROFILE hProfile = cmsCreate_sRGBProfile();
+//force ICC profile version 2.1
+cmsSetProfileVersion(hProfile, 2.1);
 cmsUInt32Number nBytesNeeded = 0;
 cmsSaveProfileToMem(hProfile, NULL, &nBytesNeeded);
 if (!nBytesNeeded)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[PUSHED] Change in core[libreoffice-3-6]: idlc: clear include file set in Idlc::reset():

2012-09-05 Thread Gerrit
>From Stephan Bergmann :

Stephan Bergmann has submitted this change and it was merged.

Change subject: idlc: clear include file set in Idlc::reset():
..


idlc: clear include file set in Idlc::reset():

Resetting the set between files reduces the size of the generated
offapi.d from 41M to 4.5M.

Change-Id: I221e6dfb75cbadb5d970f18eccfc85ffdb83ce6c
(cherry picked from commit 39c3a4d6644ae78783aa8877557e4c021cba7973)
---
M idlc/source/idlc.cxx
1 file changed, 2 insertions(+), 0 deletions(-)

Approvals:
  Stephan Bergmann: Verified; Looks good to me, approved


--
To view, visit https://gerrit.libreoffice.org/566
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I221e6dfb75cbadb5d970f18eccfc85ffdb83ce6c
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Michael Stahl 
Gerrit-Reviewer: Stephan Bergmann 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: Branch 'libreoffice-3-6' - idlc/source

2012-09-05 Thread Libreoffice Gerrit user
 idlc/source/idlc.cxx |2 ++
 1 file changed, 2 insertions(+)

New commits:
commit ac5345c4d9ac03cff9e6efc7f6269a2282119ea5
Author: Michael Stahl 
Date:   Wed Sep 5 15:01:25 2012 +0200

idlc: clear include file set in Idlc::reset():

Resetting the set between files reduces the size of the generated
offapi.d from 41M to 4.5M.

Change-Id: I221e6dfb75cbadb5d970f18eccfc85ffdb83ce6c
(cherry picked from commit 39c3a4d6644ae78783aa8877557e4c021cba7973)
Reviewed-on: https://gerrit.libreoffice.org/566
Reviewed-by: Stephan Bergmann 
Tested-by: Stephan Bergmann 

diff --git a/idlc/source/idlc.cxx b/idlc/source/idlc.cxx
index 4d15b2f..0fd721f 100644
--- a/idlc/source/idlc.cxx
+++ b/idlc/source/idlc.cxx
@@ -279,6 +279,8 @@ void Idlc::reset()
 // push the root node on the stack
 m_pScopes->push(m_pRoot);
 initializePredefinedTypes(m_pRoot);
+
+m_includes.clear();
 }
 
 sal_Bool Idlc::isDocValid()
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[Libreoffice-commits] .: Branch 'feature/cmclayouttrans' - vcl/source

2012-09-05 Thread Libreoffice Gerrit user
 vcl/source/window/builder.cxx |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

New commits:
commit 9b1439436bb39042e771c491cc9eaa5d014f8d90
Author: Caolán McNamara 
Date:   Wed Sep 5 14:27:59 2012 +0100

want to be able to find tabpages by name

Change-Id: I4e08ded38a4d1d9d193d5d7731c7ac667c70048c

diff --git a/vcl/source/window/builder.cxx b/vcl/source/window/builder.cxx
index 7eb5d44..e7ad8a4 100644
--- a/vcl/source/window/builder.cxx
+++ b/vcl/source/window/builder.cxx
@@ -365,7 +365,8 @@ Window *VclBuilder::makeObject(Window *pParent, const 
rtl::OString &name, const
 //ids and positive numbers for the handleTabChild
 //derived ids
 TabControl *pTabControl = static_cast(pParent);
-sal_uInt16 nNewPageId = -(pTabControl->GetPageCount()+1);
+sal_uInt16 nNewPageCount = pTabControl->GetPageCount()+1;
+sal_uInt16 nNewPageId = -nNewPageCount;
 pTabControl->InsertPage(nNewPageId, rtl::OUString());
 pTabControl->SetCurPageId(nNewPageId);
 
@@ -373,7 +374,13 @@ Window *VclBuilder::makeObject(Window *pParent, const 
rtl::OString &name, const
 {
 TabPage* pPage = new TabPage(pTabControl);
 pPage->Show();
-m_aChildren.push_back(WinAndId(rtl::OString(), pPage));
+
+//Make up a name for it
+rtl::OString sTabPageId = get_by_window(pParent) +
+rtl::OString("-page") +
+rtl::OString::valueOf(static_cast(nNewPageCount));
+m_aChildren.push_back(WinAndId(sTabPageId, pPage));
+pPage->SetHelpId(m_sHelpRoot + sTabPageId);
 
 //And give the page one container as a child to make it a layout 
enabled
 //tab page
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[Libreoffice-commits] .: 3 commits - android/Bootstrap android/qa sal/android

2012-09-05 Thread Libreoffice Gerrit user
 android/Bootstrap/src/org/libreoffice/android/Bootstrap.java |2 
 android/qa/sc/Makefile   |   31 ---
 sal/android/lo-bootstrap.c   |1 
 3 files changed, 27 insertions(+), 7 deletions(-)

New commits:
commit dbab9cbf2078faef3c8bc76ae31adece6b6621bd
Author: Tor Lillqvist 
Date:   Wed Sep 5 16:09:32 2012 +0300

More hacking to get this to work again

At least partially unnecessary, assuming some of the problems were
caused by the erroneous usage of Arrays.copyOfRange() in
Bootstrap.java.

Change-Id: I230b0ca6c17420f765a7d20aa377efc261186adb

diff --git a/android/qa/sc/Makefile b/android/qa/sc/Makefile
index b04f6ee..e52b589 100644
--- a/android/qa/sc/Makefile
+++ b/android/qa/sc/Makefile
@@ -115,11 +115,12 @@ copy-stuff:
 #
 # Then other "assets" that can be left in the .apk. Let the directory
 # structure under assets mimic that under solver or workdir for now.
-   mkdir -p assets/bin assets/lib assets/xml/ure
+   mkdir -p assets/bin assets/bin/ure assets/lib assets/xml/ure
cp $(OUTDIR)/bin/udkapi.rdb assets/bin
cp $(OUTDIR)/bin/types.rdb assets/bin
+   cp $(OUTDIR)/bin/ure/types.rdb assets/bin/ure
 #
-   for F in xml/ure/services; do \
+   for F in xml/services xml/ure/services; do \
cp $(OUTDIR)/$$F.rdb assets/$$F.rdb; \
done
 # For some reason the vnd.sun.star.expand:$LO_LIB_DIR doesn't seem to work, it 
expands to empty!?
@@ -130,6 +131,13 @@ copy-stuff:
done
cp -R $(OUTDIR)/xml/registry assets/xml
 #
+   mkdir -p assets/share/registry/res assets/share/config/soffice.cfg
+   cp $(OUTDIR)/xml/*.xcd assets/share/registry
+   mv assets/share/registry/fcfg_langpack_en-US.xcd 
assets/share/registry/res
+   cp -R $(OUTDIR)/xml/uiconfig/* assets/share/config/soffice.cfg
+   cp -R $(OUTDIR)/xml/registry/* assets/share/registry
+   cp $(OUTDIR)/bin/images_tango.zip assets/share/config/images.zip
+#
 # .res files
for F in $(OUTDIR)/bin/*.res; do \
cp $$F assets/bin; \
@@ -139,9 +147,9 @@ copy-stuff:
 # doesn't use soffice_main() (at least I think it shouldn't), the
 # rtl::Bootstrap::setIniFilename() call there that hardcodes
 # /assets/program/lofficerc isn't executed. Instead the hardcoding of
-# /assets/rc in BootstrapMap::getBaseIni() gets used. However, probably it can
-# be effectively empty as we pass all we need (?) on the command line.
+# /assets/rc in BootstrapMap::getBaseIni() gets used.
echo '[Bootstrap]' > assets/rc
+   echo 'URE_BOOTSTRAP=file:///assets/program/fundamentalrc' >> assets/rc
 #
 # unorc is also mandatory. It seems that it *has* to contain the
 # URE_INTERNAL_LIB_DIR, UNO_TYPES and UNO_SERVICES settings(?)
@@ -151,6 +159,17 @@ copy-stuff:
echo "UNO_TYPES=file:///assets/bin/udkapi.rdb 
file:///assets/bin/types.rdb"  >> assets/program/unorc
echo "UNO_SERVICES=file:///assets/xml/ure/services.rdb 
file:///assets/ComponentTarget/basic/util/sb.component 
file:///assets/ComponentTarget/chart2/source/controller/chartcontroller.component
 file:///assets/ComponentTarget/chart2/source/tools/charttools.component 
file:///assets/ComponentTarget/chart2/source/model/chartmodel.component 
file:///assets/ComponentTarget/comphelper/util/comphelp.component 
file:///assets/ComponentTarget/dbaccess/util/dba.component 
file:///assets/ComponentTarget/eventattacher/source/evtatt.component 
file:///assets/ComponentTarget/fileaccess/source/fileacc.component 
file:///assets/ComponentTarget/filter/source/config/cache/filterconfig1.component
 file:///assets/ComponentTarget/forms/util/frm.component 
file:///assets/ComponentTarget/oox/util/oox.component 
file:///assets/ComponentTarget/package/source/xstor/xstor.component 
file:///assets/ComponentTarget/package/util/package2.component 
file:///assets/ComponentTarget/sax/source/expatwrap/expwrap.componen
 t file:///assets/ComponentTarget/sax/source/fastparser/fastsax.component 
file:///assets/ComponentTarget/sc/util/sc.component 
file:///assets/ComponentTarget/sc/util/scfilt.component 
file:///assets/ComponentTarget/scaddins/source/analysis/analysis.component 
file:///assets/ComponentTarget/scaddins/source/datefunc/date.component 
file:///assets/ComponentTarget/sot/util/sot.component 
file:///assets/ComponentTarget/svl/util/svl.component 
file:///assets/ComponentTarget/toolkit/util/tk.component 
file:///assets/ComponentTarget/ucb/source/ucp/tdoc/ucptdoc1.component 
file:///assets/ComponentTarget/unotools/util/utl.component 
file:///assets/ComponentTarget/unoxml/source/rdf/unordf.component 
file:///assets/ComponentTarget/framework/util/fwk.component 
file:///assets/ComponentTarget/i18npool/util/i18npool.component 
file:///assets/ComponentTarget/sfx2/util/sfx.component 
file:///assets/ComponentTarget/unoxml/source/service/unoxml.component 
file:///assets/ComponentTarget/configmgr/source/confi
 gmgr.component fi

Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?

2012-09-05 Thread Peter Jentsch
Splitting the Saxon stuff should be possible and has been one of the goals of 
the libxslt port. I haven't tested that, though. 

Peter

Von meinem iPhone gesendet

Am 05.09.2012 um 14:27 schrieb Caolán McNamara :

> On Wed, 2012-09-05 at 08:15 +0200, Peter Jentsch wrote:
>> JAXTHelper is not going away in the near future, as it provides support
>> for XSLT 2.0, which is not going to appear in libxslt any time soon.
> 
> Do any of our bundled xslt filter things make use of the JAXTHelper
> stuff. I mean, "out of the box" is there anything we have that requires
> the saxon-based stack ? I'm wondering about the theoretical possibility
> of splitting that saxon-based stuff out as an optional standalone
> extension that gets distributed from our extensions repository rather
> than built-in.
> 
> C.
> 
> 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PATCH] Change in core[libreoffice-3-6]: idlc: clear include file set in Idlc::reset():

2012-09-05 Thread Gerrit
>From Michael Stahl :

Michael Stahl has uploaded a new change for review.

Change subject: idlc: clear include file set in Idlc::reset():
..

idlc: clear include file set in Idlc::reset():

Resetting the set between files reduces the size of the generated
offapi.d from 41M to 4.5M.

Change-Id: I221e6dfb75cbadb5d970f18eccfc85ffdb83ce6c
(cherry picked from commit 39c3a4d6644ae78783aa8877557e4c021cba7973)
---
M idlc/source/idlc.cxx
1 file changed, 2 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/66/566/1
--
To view, visit https://gerrit.libreoffice.org/566
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I221e6dfb75cbadb5d970f18eccfc85ffdb83ce6c
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Michael Stahl 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Bug 37361] LibreOffice 3.5 most annoying bugs

2012-09-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=37361

Timur  changed:

   What|Removed |Added

 Depends on||35568

-- 
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


[Bug 37361] LibreOffice 3.5 most annoying bugs

2012-09-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=37361

--- Comment #372 from Timur  2012-09-05 13:11:20 UTC ---
Added Bug 35568 - "QuickStarter setting not remembered after upgrade" because
it's required for a resolved Bug 46510 - "Turn on Quickstarter by silent
install" to work.

-- 
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


[Bug 37361] LibreOffice 3.5 most annoying bugs

2012-09-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=37361

--- Comment #371 from Timur  2012-09-05 13:10:22 UTC ---
Added Bug 35568 - "QuickStarter setting not remembered after upgrade" because
it's required for a resolved Bug 46510 - "Turn on Quickstarter by silent
install" to work.

-- 
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


[Libreoffice-commits] .: idlc/source

2012-09-05 Thread Libreoffice Gerrit user
 idlc/source/idlc.cxx |2 ++
 1 file changed, 2 insertions(+)

New commits:
commit 39c3a4d6644ae78783aa8877557e4c021cba7973
Author: Michael Stahl 
Date:   Wed Sep 5 15:01:25 2012 +0200

idlc: clear include file set in Idlc::reset():

Resetting the set between files reduces the size of the generated
offapi.d from 41M to 4.5M.

Change-Id: I221e6dfb75cbadb5d970f18eccfc85ffdb83ce6c

diff --git a/idlc/source/idlc.cxx b/idlc/source/idlc.cxx
index cd427c5..a064e7b 100644
--- a/idlc/source/idlc.cxx
+++ b/idlc/source/idlc.cxx
@@ -270,6 +270,8 @@ void Idlc::reset()
 // push the root node on the stack
 m_pScopes->push(m_pRoot);
 initializePredefinedTypes(m_pRoot);
+
+m_includes.clear();
 }
 
 sal_Bool Idlc::isDocValid()
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[Libreoffice-commits] .: vcl/source

2012-09-05 Thread Libreoffice Gerrit user
 vcl/source/gdi/pdfwriter_impl.cxx |2 ++
 1 file changed, 2 insertions(+)

New commits:
commit 24f691867d02e853153a53e49276c2a8c30ea1fe
Author: Fridrich Å trba 
Date:   Wed Sep 5 14:27:21 2012 +0200

Force version 2.1 of the sRGB profile for PDF/A (fdo#54546)

Change-Id: I7c40c37fbe344f1e46ea4a09fb99a5ac82ffd577

diff --git a/vcl/source/gdi/pdfwriter_impl.cxx 
b/vcl/source/gdi/pdfwriter_impl.cxx
index e17c318..a5d6a77 100644
--- a/vcl/source/gdi/pdfwriter_impl.cxx
+++ b/vcl/source/gdi/pdfwriter_impl.cxx
@@ -6563,6 +6563,8 @@ sal_Int32 PDFWriterImpl::emitOutputIntent()
 beginCompression();
 checkAndEnableStreamEncryption( nICCObject );
 cmsHPROFILE hProfile = cmsCreate_sRGBProfile();
+//force ICC profile version 2.1
+cmsSetProfileVersion(hProfile, 2.1);
 cmsUInt32Number nBytesNeeded = 0;
 cmsSaveProfileToMem(hProfile, NULL, &nBytesNeeded);
 if (!nBytesNeeded)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?

2012-09-05 Thread Caolán McNamara
On Wed, 2012-09-05 at 08:15 +0200, Peter Jentsch wrote:
> JAXTHelper is not going away in the near future, as it provides support
> for XSLT 2.0, which is not going to appear in libxslt any time soon.

Do any of our bundled xslt filter things make use of the JAXTHelper
stuff. I mean, "out of the box" is there anything we have that requires
the saxon-based stack ? I'm wondering about the theoretical possibility
of splitting that saxon-based stuff out as an optional standalone
extension that gets distributed from our extensions repository rather
than built-in.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?

2012-09-05 Thread Noel Grandin


On 2012-09-05 14:23, John Smith wrote:

 Of course, if you really don't want to look into / learn that; I had
another idea that'd be great to get implemented:

 https://bugs.freedesktop.org/show_bug.cgi?id=39439

 That is a webby / scripty / build-a-database-from-the-code type
scripting task that would really help people get stuck into coding more
quickly I think - any bites ? :-)

Oof... You call that one an 'EasyHack' ? Surely there must be some
software out there already that enables you to efficiently
search/browse a codebase and/or API / etc ? For example, doesnt
'doxygen' do what you want here ?




This is kind of specific to LO - it's like OpenGrok 
(opengrok.libreoffice.org), but restricted to a particular subset of the 
files (the *.?rc files), and with some smarts built-in to link things 
together.



Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?

2012-09-05 Thread John Smith
On Wed, Sep 5, 2012 at 1:15 PM, Michael Meeks  wrote:
>
> Well - it's worth creating an easy hack so people can look at this
> stuff; also - I'm impressed by your work - I think you underestimate
> your ability to learn C++ :-)
>
Well I did just order O'Reilly's 'Head First Programming: A Learner's
Guide to Programming Using the Python Language', so perhaps Ill
finally get myself to learn how to code now. Ive been putting that off
for years now, as I really never did find a good book for complete
newbees that I was able to learn C from. Also - the neat HTML reports
are what makes it look impressive; remember I basically didnt have to
do much more than compile the sources and execute some scripts.


>
> Of course, if you really don't want to look into / learn that; I had
> another idea that'd be great to get implemented:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=39439
>
> That is a webby / scripty / build-a-database-from-the-code type
> scripting task that would really help people get stuck into coding more
> quickly I think - any bites ? :-)
>
Oof... You call that one an 'EasyHack' ? Surely there must be some
software out there already that enables you to efficiently
search/browse a codebase and/or API / etc ? For example, doesnt
'doxygen' do what you want here ?



- John Smith
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Question about fdo#45702 - UI: RTL Direction and Asian Text orientation buttons can not be hidden

2012-09-05 Thread Manal M. Alhassoun

Hello all,

I'm currently looking at bug #45702 (1).

I found out that the only way to show/hide "Text Direction From Left To Right" 
and "Text Direction From Top To Bottom" buttons is by
activating/deactivating "Enabled for Asian languages" option in the language 
settings.
And the same thing is for the "Right-To-Left" and "Left-To-Right" buttons , 
visibility/invisibility of these two buttons depends on
activating/deactivating "Enabled for complex text layout (CTL)" option.

Since LibreOffice intended to work this way, put these buttons on "Visible 
Buttons" and "Customize Toolbar" make no sense.

I'm wondering if we can solve this by just remove them from  "Visible Buttons" 
and "Customize Toolbar".

The reason that makes me ask this question is that this bug is exists since the 
OpenOffice (2).
and I'm sure that several solutions were proposed to deal with this bug since 
then and my suggested solution maybe
one of them.

So, should I go for this solution or it's not an appropriate?


(1) https://bugs.freedesktop.org/show_bug.cgi?id=45702
(2) https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/44993




Regards,
Manal M. Alhassoun
Motah Program, KACST
http://www.motah.org.sa

Warning: This message and its attachment, if any, are confidential and may 
contain information protected by law. If you are not the intended recipient, 
please contact the sender immediately and delete the message and its 
attachment, if any. You should not copy the message and its attachment, if any, 
or disclose its contents to any other person or use it for any purpose. 
Statements and opinions expressed in this e-mail and its attachment, if any, 
are those of the sender, and do not necessarily reflect those of King Abdulaziz 
city for Science and Technology (KACST) in the Kingdom of Saudi Arabia. KACST 
accepts no liability for any damage caused by this email.

?: ??? ??? ??? ? ?? ?? (?? )  ?  ?? ? ??? 
??? ? ? ???. ??? ?? ??? ? ??  ???   
? ???  ?? ?  ??? ? (?? )? ???  ?? 
??? ?? ? ??? ??? ??  (?? ) ?? ?? ??? ? ?? ? 
?? ? ?? ? ??? ???. ? ???  ??? ??? ? (?? 
)  ?? ??? ???   ??? ? ? ? ?? 
  ??? ? ??? ? ??? ?? ??? ?? ??? 
??? ?? ?? ?? ?? ??? ??.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: helpcontent2/helpers helpcontent2/source

2012-09-05 Thread Libreoffice Gerrit user
 helpcontent2/helpers/xmlhelp.dtd|   18 +++---
 helpcontent2/source/auxiliary/index.xsl |   12 
 helpcontent2/source/text/shared/01/06040400.xhp |4 ++--
 3 files changed, 25 insertions(+), 9 deletions(-)

New commits:
commit e3ed3283b7867afa0084371e2050ed6a23a59d37
Author: Caolán McNamara 
Date:   Wed Sep 5 12:26:17 2012 +0100

add superscript and subscript support and remove odd 1^st construct

so we can get rid of the confusing 1^st help text suggestion

Change-Id: If6ce1b7a347c89f6209cfc09b67d939088efa6fc

diff --git a/helpcontent2/helpers/xmlhelp.dtd b/helpcontent2/helpers/xmlhelp.dtd
index bd0c39f..96dcefa 100644
--- a/helpcontent2/helpers/xmlhelp.dtd
+++ b/helpcontent2/helpers/xmlhelp.dtd
@@ -3,7 +3,7 @@ Version 03-Feb-2006
   added optional localize attribute to images
 -->
 
-
+
 
 
-
+
 
 
-
+
 
@@ -56,7 +56,7 @@ Version 03-Feb-2006
 
 
 
-
+
 
 
 
 
+
+
+
+
 
 
 
@@ -101,7 +105,7 @@ Version 03-Feb-2006
   date CDATA #REQUIRED
 >
 
-
+
 
 
-
+
 
 
-
+
 
 
 
+
+  
+  
+  
+
+
+
+  
+  
+  
+
+
 
   
   
diff --git a/helpcontent2/source/text/shared/01/06040400.xhp 
b/helpcontent2/source/text/shared/01/06040400.xhp
index c0c246b..2a911f4 100644
--- a/helpcontent2/source/text/shared/01/06040400.xhp
+++ b/helpcontent2/source/text/shared/01/06040400.xhp
@@ -60,8 +60,8 @@
 Inserts a non breaking space before ";", "!", "?" and ":" when the 
character language is set to French (France, Belgium, Luxembourg, Monaco, or 
Switzerland) and before ":" only when the character language is set to French 
(Canada).
 
 moved two paras from 06040100.xhp, cws cbosdo01
-Format ordinal number suffixes (1st ... 1^st)
-Formats the text characters of ordinals, such as 1st, 2nd, or 3rd, 
as superscripts. For example, in English text, 1st will be converted to 
1^st.
+Format ordinal number suffixes (1st ... 
1st)
+Formats the text characters of ordinals, such as 1st, 2nd, or 3rd, 
as superscripts. For example, in English text, 1st will be converted to 
1st.
 
 
 Single quotes / Double quotes
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[Libreoffice-commits] .: xmlhelp/util

2012-09-05 Thread Libreoffice Gerrit user
 xmlhelp/util/idxcontent.xsl |   10 ++
 xmlhelp/util/main_transform.xsl |   16 
 2 files changed, 26 insertions(+)

New commits:
commit c96e2c238f8fd3a78773e29ced11ddaa9e9d783f
Author: Caolán McNamara 
Date:   Wed Sep 5 12:30:45 2012 +0100

add superscript and subscript support to enable removing odd 1^st construct

so we can get rid of the confusing 1^st help text suggestion

Change-Id: I38fea2c15f6764bd64aaebe2a41935149f62b9c5

diff --git a/xmlhelp/util/idxcontent.xsl b/xmlhelp/util/idxcontent.xsl
index aa371d7..cfc16ea 100644
--- a/xmlhelp/util/idxcontent.xsl
+++ b/xmlhelp/util/idxcontent.xsl
@@ -67,6 +67,16 @@
   

 
 
+
+  
+  

+
+
+
+  
+  

+
+
 
   
   

diff --git a/xmlhelp/util/main_transform.xsl b/xmlhelp/util/main_transform.xsl
index 4385cf4..f32cc9d 100644
--- a/xmlhelp/util/main_transform.xsl
+++ b/xmlhelp/util/main_transform.xsl
@@ -250,6 +250,22 @@

 
 
+
+
+   
+
+
+   
+
+
+
+
+   
+
+
+   
+
+
 
 
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?

2012-09-05 Thread Michael Meeks

On Wed, 2012-09-05 at 10:46 +0200, John Smith wrote:
> On Wed, Sep 5, 2012 at 10:43 AM, Noel Grandin  wrote:
> > How about producing some patches to fix issues you found?

> I wish I could. Im just a unix sys admin, and not a developer. Writing
> shell scripts is no problem, but I doubt ill be coding C++ anytime
> soon. :(

Well - it's worth creating an easy hack so people can look at this
stuff; also - I'm impressed by your work - I think you underestimate
your ability to learn C++ :-)

Of course, if you really don't want to look into / learn that; I had
another idea that'd be great to get implemented:

https://bugs.freedesktop.org/show_bug.cgi?id=39439

That is a webby / scripty / build-a-database-from-the-code type
scripting task that would really help people get stuck into coding more
quickly I think - any bites ? :-)

Thanks !

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Impress Remote / dbus

2012-09-05 Thread Michael Meeks

On Wed, 2012-09-05 at 11:30 +0200, Andrzej J. R. Hunt wrote:
> I've ported my code to dbus-glib now (wrapped in ENABLE_DBUS) -- for
> the moment I don't think it's too critical to have dbus enabled, but
> would be nice to have for 3.7.

Makes sense I think :-) Of course, if you really want to have fun; and
given that this is only for one or two methods, we could perhaps use
libdbus directly - it has a very static/stable ABI and has been around
~forever. We could also dlopen / wrap that in extremis I suppose.

> I've found that the other code using dbus
> ( vcl/unx/gtk/window/gtkframe.cxx ) spits out:

Oh - that's annoying; we should prolly just stop those arriving.

> (Presumably since I'm on kde.)

But using the gtk+ theming under KDE ?

>  I'm not building with any of the debug options (I only have debug=t
> for sd). Would it not be more appropriate to use g_debug rather than
> g_warning for these messages, as currently they'll appear on any
> system that doesn't have gnome?

Seems reasonable to me ;-)

Thanks !

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: i18npool/source

2012-09-05 Thread Libreoffice Gerrit user
 i18npool/source/ordinalsuffix/ordinalsuffix.cxx |  102 
 1 file changed, 69 insertions(+), 33 deletions(-)

New commits:
commit a05357ab69712bec53c2d8d17efbbf25907ff9b8
Author: Caolán McNamara 
Date:   Wed Sep 5 11:31:10 2012 +0100

Resolves: fdo#54486 ensure ordinal format has non-ordinal prefix

Make sure that the ordinal format and the non-ordinal format match at the
start, so that the expectation can be verified that there is some trailing
"ordinal suffix" which can be extracted.

I'm not at all sure that this will be true for all languages.

Change-Id: Ib89a51cdd743db12bfe6e723a9acb61d9fe5e6ce

diff --git a/i18npool/source/ordinalsuffix/ordinalsuffix.cxx 
b/i18npool/source/ordinalsuffix/ordinalsuffix.cxx
index 4d75b0f..e74fa03 100644
--- a/i18npool/source/ordinalsuffix/ordinalsuffix.cxx
+++ b/i18npool/source/ordinalsuffix/ordinalsuffix.cxx
@@ -17,6 +17,7 @@
  *   the License at http://www.apache.org/licenses/LICENSE-2.0 .
  */
 
+#include 
 #include 
 #include 
 #include "ordinalsuffix.hxx"
@@ -44,6 +45,23 @@ OrdinalSuffix::~OrdinalSuffix()
 {
 }
 
+namespace
+{
+OUString mungeUnicodeStringToOUString(const icu::UnicodeString &rIn, 
UErrorCode &rCode)
+{
+// Apply NFKC normalization to get normal letters
+icu::UnicodeString normalized;
+icu::Normalizer::normalize(rIn, UNORM_NFKC, 0, normalized, rCode);
+// Convert the normalized UnicodeString to OUString
+OUString sRet = (U_SUCCESS(rCode))
+? OUString(reinterpret_cast(normalized.getBuffer()), normalized.length())
+: OUString();
+// replace any minus signs with hyphen-minus so that negative numbers
+// from the simple number formatter and heavy-duty pattern formatter
+// agree as to their negative number sign
+return sRet.replace(0x2212, '-');
+}
+}
 
 /*
  * For this method to properly return the ordinal suffix for other locales
@@ -60,46 +78,64 @@ uno::Sequence< OUString > SAL_CALL 
OrdinalSuffix::getOrdinalSuffix( sal_Int32 nN
 CSTR( aLocale.Language ),
 CSTR( aLocale.Country ),
 CSTR( aLocale.Variant ) );
-icu::RuleBasedNumberFormat formatter(
-icu::URBNF_ORDINAL, rIcuLocale, nCode );
 
-if ( U_SUCCESS( nCode ) )
+icu::RuleBasedNumberFormat formatter(icu::URBNF_ORDINAL, rIcuLocale, 
nCode);
+if (!U_SUCCESS(nCode))
+return retValue;
+
+boost::scoped_ptr 
xNumberFormat(icu::NumberFormat::createInstance(rIcuLocale, nCode));
+if (!U_SUCCESS(nCode))
+return retValue;
+
+icu::UnicodeString sFormatWithNoOrdinal;
+xNumberFormat->format((int32_t)nNumber, sFormatWithNoOrdinal, NULL, nCode);
+if (!U_SUCCESS(nCode))
+return retValue;
+
+OUString sValueWithNoOrdinal = 
mungeUnicodeStringToOUString(sFormatWithNoOrdinal, nCode);
+if (!U_SUCCESS(nCode))
+return retValue;
+
+int32_t nRuleSets = formatter.getNumberOfRuleSetNames( );
+for (int32_t i = 0; i < nRuleSets; ++i)
 {
-int32_t nRuleSets = formatter.getNumberOfRuleSetNames( );
-for ( int32_t i = 0; i < nRuleSets; i++ )
-{
-icu::UnicodeString ruleSet = formatter.getRuleSetName( i );
-// format the string
-icu::UnicodeString icuRet;
-icu::FieldPosition icuPos;
-formatter.format( (int32_t)nNumber, ruleSet, icuRet, icuPos, nCode 
);
-
-if ( U_SUCCESS( nCode ) )
-{
-// Apply NFKC normalization to get normal letters
-icu::UnicodeString normalized;
-nCode = U_ZERO_ERROR;
-icu::Normalizer::normalize( icuRet, UNORM_NFKC, 0, normalized, 
nCode );
-if ( U_SUCCESS( nCode ) )
-{
-// Convert the normalized UnicodeString to OUString
-OUString sValue( reinterpret_cast( 
normalized.getBuffer( ) ), normalized.length() );
-
-// Remove the number to get the prefix
-sal_Int32 len = OUString::valueOf( nNumber ).getLength( );
-
-sal_Int32 newLength = retValue.getLength() + 1;
-retValue.realloc( newLength );
-retValue[ newLength - 1 ] = sValue.copy( len );
-}
-}
-}
+icu::UnicodeString ruleSet = formatter.getRuleSetName(i);
+
+// format the string
+icu::UnicodeString sFormatWithOrdinal;
+icu::FieldPosition icuPos;
+formatter.format( (int32_t)nNumber, ruleSet, sFormatWithOrdinal, 
icuPos, nCode );
+
+if (!U_SUCCESS(nCode))
+continue;
+
+OUString sValueWithOrdinal = 
mungeUnicodeStringToOUString(sFormatWithOrdinal, nCode);
+if (!U_SUCCESS(nCode))
+continue;
+
+// fdo#54486 lets make sure that the ordinal format and the non-ordinal
+// format match at the start, 

Re: [Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

2012-09-05 Thread Bjoern Michaelsen
On Wed, Sep 05, 2012 at 11:39:04AM +0200, Stephan Bergmann wrote:
> On 09/05/2012 10:46 AM, Lionel Elie Mamane wrote:
> >I thought we close the bug when the fix is committed in all branches
> >where it should be, and that's what I was doing in the bugs I was
> >fixing.
> 
> That's my understanding too, setting a bug to RESOLVED/FIXED only
> once all the relevant commits have reached the intended branches.

That is quite tricky as "intended branches" is not clearly defined, and in
addition it runs counter to what mozilla defines the RESOLVED state:

 https://bugzilla.mozilla.org/page.cgi?id=fields.html

Note that there are two more bug states "after" RESOLVED in standard bugzilla:
VERIFIED and CLOSED. AFAIK the default workflow is:

RESOLVED: assumed to be fixed for some branch, not tested, not yet released
VERIFIED: verified to be fixed for some branch
CLOSED: there is a version with the fix released

In our case, as we dont really verify yet, I would suggest the following:

RESOLVED: assumed to be fixed for some branch, not tested, not yet released
CLOSED: there is a version with the fix released

Endusers should then look for CLOSED bugs (not RESOLVED unless they run
dailies), and we would automove bugs from RESOLVED->CLOSED with a release.

Best,

Bjoern

P.S.: IMHO launchpad does this a lot better with the explicit states "Fix
committed" and "Fix released".
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Impress Remote / dbus

2012-09-05 Thread Andrzej J. R. Hunt

On 09/04/2012 05:47 PM, Caolán McNamara wrote:

1. Port my code to dbus-glib and always build dbus-glib? Or port my
code to dbus-glib and leave everything else as is, meaning bluetooth
on Linux needs the user to use --enable-dbus?

I feel this is the best approach. Except that I'll toggle enable-dbus on
by default rather than off when I get the chance. Which would mean that
the rhel-4 based universal-build-generating box would either have to
start using --disable-dbus or get upgraded to something less archaic.
I've ported my code to dbus-glib now (wrapped in ENABLE_DBUS) -- for the 
moment I don't think it's too critical to have dbus enabled, but would 
be nice to have for 3.7.



I've found that the other code using dbus ( 
vcl/unx/gtk/window/gtkframe.cxx ) spits out:


** (soffice:28499): WARNING **: Inhibit method failed

** (soffice:28499): WARNING **: Inhibit problem : The name 
org.gnome.SessionManager was not provided by any .service files


** (soffice:28499): WARNING **: Invalid cookie

(Presumably since I'm on kde.) I'm not building with any of the debug 
options (I only have debug=t for sd). Would it not be more appropriate 
to use g_debug rather than g_warning for these messages, as currently 
they'll appear on any system that doesn't have gnome?


Cheers,

Andrzej

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: sd/CppunitTest_sd_uimpress.mk sd/Library_sd.mk sd/source

2012-09-05 Thread Libreoffice Gerrit user
 sd/CppunitTest_sd_uimpress.mk  |1 
 sd/Library_sd.mk   |2 
 sd/source/ui/remotecontrol/BluetoothServer.cxx |  113 -
 sd/source/ui/remotecontrol/BluetoothServer.hxx |6 -
 4 files changed, 62 insertions(+), 60 deletions(-)

New commits:
commit 5dcb5399d70976311591f4041e3a816ea96fb80b
Author: Andrzej J.R. Hunt 
Date:   Wed Sep 5 11:50:54 2012 +0200

Port remote from gdbus to dbus-glib.

Change-Id: I291ee5d32110d2fffd976f3e5257daf976428a76

diff --git a/sd/CppunitTest_sd_uimpress.mk b/sd/CppunitTest_sd_uimpress.mk
index 7519186..4b324b0 100644
--- a/sd/CppunitTest_sd_uimpress.mk
+++ b/sd/CppunitTest_sd_uimpress.mk
@@ -82,6 +82,7 @@ endif
 
 $(eval $(call gb_CppunitTest_use_externals,sd_uimpress,\
 gtk \
+dbus \
 ))
 
 $(eval $(call gb_CppunitTest_add_exception_objects,sd_uimpress,\
diff --git a/sd/Library_sd.mk b/sd/Library_sd.mk
index e2c7191..4dcadc3 100644
--- a/sd/Library_sd.mk
+++ b/sd/Library_sd.mk
@@ -108,7 +108,7 @@ $(eval $(call gb_Library_use_libraries,sd,\
 
 $(eval $(call gb_Library_use_externals,sd,\
  libxml2 \
- gio \
+ dbus \
 ))
 
 ifeq ($(OS),WNT)
diff --git a/sd/source/ui/remotecontrol/BluetoothServer.cxx 
b/sd/source/ui/remotecontrol/BluetoothServer.cxx
index 2a4e95a..170c51c 100644
--- a/sd/source/ui/remotecontrol/BluetoothServer.cxx
+++ b/sd/source/ui/remotecontrol/BluetoothServer.cxx
@@ -9,20 +9,19 @@
 #include "BluetoothServer.hxx"
 #include 
 
-#if defined(LINUX) && defined(ENABLE_GIO) && defined(ENABLE_DBUS)
+#if defined(LINUX) && defined(ENABLE_DBUS)
 #include 
-#include 
+#include 
 #include 
 #include 
-#endif
-#include 
-#include 
-
-#ifdef LINUX
 #include "bluetooth/bluetooth.h"
 #include "bluetooth/rfcomm.h"
 #endif
 
+// FIXME: move this into an external file and look at sharing definitions
+// across OS's (i.e. UUID and port ).
+// Also look at determining which ports are available.
+#define BLUETOOTH_SERVICE_RECORD ""
 
 #include "Communicator.hxx"
 
@@ -38,66 +37,71 @@ BluetoothServer::~BluetoothServer()
 {
 }
 
-struct oslSocketImpl {
-int m_Socket;
-int m_nLastError;
-void*m_CloseCallback;
-void*   m_CallbackArg;
-oslInterlockedCount m_nRefCount;
-#if defined(LINUX)
-sal_Boolm_bIsAccepting;
-sal_Boolm_bIsInShutdown;
-#endif
-};
-
-
 void BluetoothServer::execute()
 {
-#if defined(LINUX) && defined(ENABLE_GIO) && defined(ENABLE_DBUS)
-#ifdef GLIB_VERSION_2_26
+#if defined(LINUX) && defined(ENABLE_DBUS)
 g_type_init();
-GError* aError = NULL;
 
-GDBusConnection* aConnection = g_bus_get_sync( G_BUS_TYPE_SYSTEM, NULL, 
&aError );
-if ( aError )
-{
-g_error_free( aError );
-return; // We can't get a dbus connection
+GError *aError = NULL;
+
+DBusGConnection *aConnection = NULL;
+aConnection = dbus_g_bus_get( DBUS_BUS_SYSTEM, &aError );
+
+if ( aError != NULL ) {
+g_error_free (aError);
+return;
 }
 
-GVariant *aAdapter = g_dbus_connection_call_sync( aConnection,
-"org.bluez", "/", "org.bluez.Manager",
-"DefaultAdapter", NULL,
-G_VARIANT_TYPE_TUPLE,
-G_DBUS_CALL_FLAGS_NONE, -1, NULL, &aError);
-if ( aError )
+
+DBusGProxy *aManager = NULL;
+aManager = dbus_g_proxy_new_for_name( aConnection, "org.bluez", "/",
+  "org.bluez.Manager" );
+
+if ( aManager == NULL )
 {
-g_error_free( aError );
-g_object_unref( aConnection );
-return; // We can't get an adapter -- no bluetooth possible
+dbus_g_connection_unref( aConnection );
+return;
 }
-GVariant *aAdapterName = g_variant_get_child_value( aAdapter, 0 );
 
-GVariant *aRecordHandle = g_dbus_connection_call_sync( aConnection,
-"org.bluez", g_variant_get_string( 
aAdapterName, NULL ), "org.bluez.Service",
-"AddRecord",
- g_variant_new("(s)",
-""),
-G_VARIANT_TYPE_TUPLE,
-G_DBUS_CALL_FLAGS_NONE, -1, NULL, &aError);
+gboolean aResult;
+DBusGObjectPath *aAdapterPath = NULL;
+aResult = dbus_g_proxy_call( aManager, "DefaultAdapter", &aError,
+ G_TYPE_INVALID,
+ DBUS_TYPE_G_OBJECT_PATH, &aAdapterPath,
+ G_TYPE_INVALID);
 
-g_variant_unref( aAdapter );
-g_object_unref( aConnection );
+g_object_unref( G_OBJECT( aManager ));
+if ( !aResult )
+{
+dbus_g_connection_unref( aConnection );
+return;
+}
 
-if ( aError )
+DBusGProxy *aAdapter = NULL;
+aAdapter = dbus_g_proxy_new_for_name( aC

Re: Closing bugs in bugzilla: fixed in master or fixed everywhere?

2012-09-05 Thread Stephan Bergmann

On 09/05/2012 10:46 AM, Lionel Elie Mamane wrote:

I thought we close the bug when the fix is committed in all branches
where it should be, and that's what I was doing in the bugs I was
fixing.


That's my understanding too, setting a bug to RESOLVED/FIXED only once 
all the relevant commits have reached the intended branches.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PATCH] Change in core[libreoffice-3-5]: fdo#38913: Prevent invalid parameter handler crashes

2012-09-05 Thread Gerrit
>From Stephan Bergmann :

Stephan Bergmann has uploaded a new change for review.

Change subject: fdo#38913: Prevent invalid parameter handler crashes
..

fdo#38913: Prevent invalid parameter handler crashes

It appears that on Windows at least some jvm.dll versions can cause calls to
_fileno(NULL), which leads to a call of the invalid parameter handler (see
 "Parameter
Validation: Visual Studio 2005").  The default handler causes the application to
crash, so install a "harmless" one instead.

Change-Id: Id6a3ffb63f70b0c65546bc933e994c8dbf35203c
(cherry picked from commit a82e532ce006c54b2740de74d1da5d11307da7c1)
---
M sal/osl/w32/salinit.cxx
1 file changed, 29 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/65/565/1
--
To view, visit https://gerrit.libreoffice.org/565
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Id6a3ffb63f70b0c65546bc933e994c8dbf35203c
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-5
Gerrit-Owner: Stephan Bergmann 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PATCH] Change in core[libreoffice-3-6]: fdo#38913: Prevent invalid parameter handler crashes

2012-09-05 Thread Gerrit
>From Stephan Bergmann :

Stephan Bergmann has uploaded a new change for review.

Change subject: fdo#38913: Prevent invalid parameter handler crashes
..

fdo#38913: Prevent invalid parameter handler crashes

It appears that on Windows at least some jvm.dll versions can cause calls to
_fileno(NULL), which leads to a call of the invalid parameter handler (see
 "Parameter
Validation: Visual Studio 2005").  The default handler causes the application to
crash, so install a "harmless" one instead.

Change-Id: Id6a3ffb63f70b0c65546bc933e994c8dbf35203c
(cherry picked from commit a82e532ce006c54b2740de74d1da5d11307da7c1)
---
M sal/osl/w32/salinit.cxx
1 file changed, 29 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/64/564/1
--
To view, visit https://gerrit.libreoffice.org/564
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Id6a3ffb63f70b0c65546bc933e994c8dbf35203c
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Stephan Bergmann 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [PATCH] Fix docx 'absolute' frame position import

2012-09-05 Thread Stephan van den Akker
Hi Pierre-Eric, All,

Could this be a fix for fdo#53356: "FILEOPEN formula in imported DOCX has
wrong vertical position" too?


2012/9/5 Gerrit 

> >From Pierre-Eric Pelloux-Prayer :
>
> Pierre-Eric Pelloux-Prayer has uploaded a new change for review.
>
> Change subject: Fix docx 'absolute' frame position import
> ..
>
> Fix docx 'absolute' frame position import
>
> Frames with absolute position style must be vertically placed relative
> to 'Margin', otherwise parent paragraph style may modify their Y coord.
>
> Change-Id: Ifae8f73ad9c6aa98b67283663cfc37dd847ff095
> ---
> M oox/source/vml/vmlshape.cxx
> 1 file changed, 4 insertions(+), 0 deletions(-)
>
>
>   git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/61/561/1
> --
> To view, visit https://gerrit.libreoffice.org/561
> To unsubscribe, visit https://gerrit.libreoffice.org/settings
>
> Gerrit-MessageType: newchange
> Gerrit-Change-Id: Ifae8f73ad9c6aa98b67283663cfc37dd847ff095
> Gerrit-PatchSet: 1
> Gerrit-Project: core
> Gerrit-Branch: master
> Gerrit-Owner: Pierre-Eric Pelloux-Prayer 
>
> ___
> 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


[Libreoffice-commits] .: 2 commits - i18npool/source vcl/generic vcl/inc

2012-09-05 Thread Libreoffice Gerrit user
 i18npool/source/ordinalsuffix/ordinalsuffix.cxx |2 
 vcl/generic/glyphs/gcach_layout.cxx |   83 ++--
 vcl/inc/generic/glyphcache.hxx  |2 
 3 files changed, 10 insertions(+), 77 deletions(-)

New commits:
commit defe079d455ccc958fd0128e8a8cf0e4aeb5cd9c
Author: Caolán McNamara 
Date:   Wed Sep 5 10:00:37 2012 +0100

Make autocorrect of 1st to 1 + superscripted st work again

It surely doesn't matter if the result of normalization is unchanged

Change-Id: I87dfd0dadee33897f5df4b0dc532166a8bd9d7e5

diff --git a/i18npool/source/ordinalsuffix/ordinalsuffix.cxx 
b/i18npool/source/ordinalsuffix/ordinalsuffix.cxx
index 596c6ff..4d75b0f 100644
--- a/i18npool/source/ordinalsuffix/ordinalsuffix.cxx
+++ b/i18npool/source/ordinalsuffix/ordinalsuffix.cxx
@@ -80,7 +80,7 @@ uno::Sequence< OUString > SAL_CALL 
OrdinalSuffix::getOrdinalSuffix( sal_Int32 nN
 icu::UnicodeString normalized;
 nCode = U_ZERO_ERROR;
 icu::Normalizer::normalize( icuRet, UNORM_NFKC, 0, normalized, 
nCode );
-if ( U_SUCCESS( nCode ) && ( normalized != icuRet ) )
+if ( U_SUCCESS( nCode ) )
 {
 // Convert the normalized UnicodeString to OUString
 OUString sValue( reinterpret_cast( 
normalized.getBuffer( ) ), normalized.length() );
commit 5c3dc6791c8737b24d5b8211bf7330caff47b62b
Author: Caolán McNamara 
Date:   Wed Sep 5 09:06:55 2012 +0100

should be able to remove SimpleLayoutEngine now

Change-Id: I74d2cb7c47ec04f4276755fa1bd74779842c7832

diff --git a/vcl/generic/glyphs/gcach_layout.cxx 
b/vcl/generic/glyphs/gcach_layout.cxx
index cd6b96c..774f0f8 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -42,8 +42,6 @@
 #include 
 #include 
 
-namespace { struct SimpleLayoutEngine : public rtl::Static< 
ServerFontLayoutEngine, SimpleLayoutEngine > {}; }
-
 // ===
 // layout implementation for ServerFont
 // ===
@@ -62,10 +60,8 @@ void ServerFontLayout::DrawText( SalGraphics& rSalGraphics ) 
const
 bool ServerFontLayout::LayoutText( ImplLayoutArgs& rArgs )
 {
 ServerFontLayoutEngine* pLE = mrServerFont.GetLayoutEngine();
-if( !pLE )
-pLE = &SimpleLayoutEngine::get();
-
-bool bRet = (*pLE)( *this, rArgs );
+assert(pLE);
+bool bRet = pLE ? pLE->layout(*this, rArgs) : false;
 return bRet;
 }
 
@@ -95,68 +91,6 @@ void ServerFontLayout::AdjustLayout( ImplLayoutArgs& rArgs )
 }
 
 // ===
-
-bool ServerFontLayoutEngine::operator()( ServerFontLayout& rLayout, 
ImplLayoutArgs& rArgs )
-{
-ServerFont& rFont = rLayout.GetServerFont();
-
-Point aNewPos( 0, 0 );
-int nOldGlyphId = -1;
-int nGlyphWidth = 0;
-GlyphItem aPrevItem;
-bool bRightToLeft;
-
-rLayout.Reserve(rArgs.mnLength);
-for( int nCharPos = -1; rArgs.GetNextPos( &nCharPos, &bRightToLeft ); )
-{
-sal_UCS4 cChar = rArgs.mpStr[ nCharPos ];
-if( (cChar >= 0xD800) && (cChar <= 0xDFFF) )
-{
-if( cChar >= 0xDC00 ) // this part of a surrogate pair was already 
processed
-continue;
-cChar = 0x1 + ((cChar - 0xD800) << 10)
-  + (rArgs.mpStr[ nCharPos+1 ] - 0xDC00);
-}
-
-if( bRightToLeft )
-cChar = GetMirroredChar( cChar );
-int nGlyphIndex = rFont.GetGlyphIndex( cChar );
-// when glyph fallback is needed update LayoutArgs
-if( !nGlyphIndex ) {
-rArgs.NeedFallback( nCharPos, bRightToLeft );
-if( cChar >= 0x1 ) // handle surrogate pairs
-rArgs.NeedFallback( nCharPos+1, bRightToLeft );
-}
-
-// apply pair kerning to prev glyph if requested
-if( SAL_LAYOUT_KERNING_PAIRS & rArgs.mnFlags )
-{
-int nKernValue = rFont.GetGlyphKernValue( nOldGlyphId, nGlyphIndex 
);
-nGlyphWidth += nKernValue;
-aPrevItem.mnNewWidth = nGlyphWidth;
-}
-
-// finish previous glyph
-if( nOldGlyphId >= 0 )
-rLayout.AppendGlyph( aPrevItem );
-aNewPos.X() += nGlyphWidth;
-
-// prepare GlyphItem for appending it in next round
-nOldGlyphId = nGlyphIndex;
-const GlyphMetric& rGM = rFont.GetGlyphMetric( nGlyphIndex );
-nGlyphWidth = rGM.GetCharWidth();
-int nGlyphFlags = bRightToLeft ? GlyphItem::IS_RTL_GLYPH : 0;
-aPrevItem = GlyphItem( nCharPos, nGlyphIndex, aNewPos, nGlyphFlags, 
nGlyphWidth );
-}
-
-// append last glyph item if any
-if( nOldGlyphId >= 0 )
-rLayout.AppendGlyph( aPrevItem );
-
-return true;
-}
-
-// 

[PATCH] Change in core[libreoffice-3-6]: fdo#53009: Compile extension help in gbuild

2012-09-05 Thread Gerrit
>From Stephan Bergmann :

Stephan Bergmann has uploaded a new change for review.

Change subject: fdo#53009: Compile extension help in gbuild
..

fdo#53009: Compile extension help in gbuild

...as had been done in the old build system (solenv/inc/extension_helplink.mk).
Especially for bundled extensions, this removes the need to compile the help
data per user on first start.

gb_Extension_add_helpfile(s) replaces gb_Extension_localize_help, and takes care
of all the steps (localization, compilation, inclusion in .oxt), even for the
en-US data (which was handled with additional gb_Extension_add_file calls
before).

(cherry picked from commit b23bb8e0de3dbdc2c66c3dedf70dfd318868f76c with
additional fixes from follow-up commits 152ffaa15f963f92b1564946a648c53d6b5c808c
"Call HelpIndexer/Linker with gb_Helper_set_ld_path" and
a297372210396260da57f34da3790f76682603cc "Quote .ddf content (potentially
containing stuff like '%2F')")

Conflicts:
solenv/gbuild/Extension.mk
solenv/gbuild/ExtensionTarget.mk

Change-Id: Ie4bab66d3cad2b713780a23bf2606ca56cfff37f
---
M nlpsolver/Extension_nlpsolver.mk
M sdext/Extension_presenter.mk
M solenv/bin/modules/installer/windows/msiglobal.pm
M solenv/gbuild/Extension.mk
M swext/Extension_wiki-publisher.mk
5 files changed, 141 insertions(+), 52 deletions(-)


  git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/63/563/1
--
To view, visit https://gerrit.libreoffice.org/563
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ie4bab66d3cad2b713780a23bf2606ca56cfff37f
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Stephan Bergmann 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PATCH] Change in core[libreoffice-3-6]: HelpIndexer, HelpLinker are build-time tools

2012-09-05 Thread Gerrit
>From Stephan Bergmann :

Stephan Bergmann has uploaded a new change for review.

Change subject: HelpIndexer, HelpLinker are build-time tools
..

HelpIndexer, HelpLinker are build-time tools

Change-Id: I43186271f36f67a95a7e3766e1998ea42531e596
(cherry picked from commit beab021ffe57cf6004971d4f285984b6debe5b5f)
---
M Repository.mk
1 file changed, 2 insertions(+), 2 deletions(-)


  git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/62/562/1
--
To view, visit https://gerrit.libreoffice.org/562
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I43186271f36f67a95a7e3766e1998ea42531e596
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Stephan Bergmann 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?

2012-09-05 Thread John Smith
On Wed, Sep 5, 2012 at 10:43 AM, Noel Grandin  wrote:
> How about producing some patches to fix issues you found?
>
I wish I could. Im just a unix sys admin, and not a developer. Writing
shell scripts is no problem, but I doubt ill be coding C++ anytime
soon.
:(


Regards,


John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Closing bugs in bugzilla: fixed in master or fixed everywhere?

2012-09-05 Thread Lionel Elie Mamane
I'd like to check if maybe I misunderstood our bugzilla handling
standards.

I thought we close the bug when the fix is committed in all branches
where it should be, and that's what I was doing in the bugs I was
fixing.

But obviously, if our community standards are the other way round,
I'll follow them.


I asked because I have now lived several times now that several
developers close a bug I'm CCed to as soon as they commit the fix to
master.

The disadvantage of the latter method is that these bugs appear
crossed out in the "most annoying" (and other) lists.

Its advantage, maybe, is that it goes away from said developer's
list: their job is "finished" so it should get the hell out of their
TODO list.

I've come to see this last point as not completely obvious, and maybe
even wrong: when I commit a fix to master, I regard it as also my job
to get it backported to the other branches, so my job on this bug is
_not_ finished, so it makes sense for it to linger in my TODO list
until the fix is everywhere it should.

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PATCH] Fix docx 'absolute' frame position import

2012-09-05 Thread Gerrit
>From Pierre-Eric Pelloux-Prayer :

Pierre-Eric Pelloux-Prayer has uploaded a new change for review.

Change subject: Fix docx 'absolute' frame position import
..

Fix docx 'absolute' frame position import

Frames with absolute position style must be vertically placed relative
to 'Margin', otherwise parent paragraph style may modify their Y coord.

Change-Id: Ifae8f73ad9c6aa98b67283663cfc37dd847ff095
---
M oox/source/vml/vmlshape.cxx
1 file changed, 4 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/61/561/1
--
To view, visit https://gerrit.libreoffice.org/561
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ifae8f73ad9c6aa98b67283663cfc37dd847ff095
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Pierre-Eric Pelloux-Prayer 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?

2012-09-05 Thread Noel Grandin

How about producing some patches to fix issues you found?

On 2012-09-05 10:40, John Smith wrote:

I was wondering, now that there are initial reports for both code
coverage and statistic analysis, what the next step could be ? For
example, are people interested in mini-HOWTO's on how to (re-)produce
the reports ? Something else entirely ?





Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: Branch 'libreoffice-3-5' - reportdesign/source svx/inc svx/source

2012-09-05 Thread Libreoffice Gerrit user
 reportdesign/source/core/api/Section.cxx |   14 --
 svx/inc/svx/svdpage.hxx  |   12 +++-
 svx/source/svdraw/svdpage.cxx|5 -
 3 files changed, 23 insertions(+), 8 deletions(-)

New commits:
commit 8806e6e1029f08cb43540f1aa9753b19f0e459f8
Author: Michael Stahl 
Date:   Tue Sep 4 20:38:17 2012 +0200

fdo#53872: reportdesign: fix section drawpage crash:

In order to wrap the SdrPage's UNO object completely, set its mxUnoPage
member to the OSection wrapper instance in OSection::init; only OSection
should have access to it.
Also initialize m_xDrawPage_Tunnel (thanks Lionel for the hint).
(regression from 05218c101df486302bf4cfe8be23ad840daa3f73)

Change-Id: I048ddafc31e946853e56e6a403ddc9487cfbcf0e
Signed-off-by: Lionel Elie Mamane 
(cherry picked from commit 0e6054f8f5e2d41e50a50645defa5861599fe375)

Signed-off-by: Lionel Elie Mamane 

diff --git a/reportdesign/source/core/api/Section.cxx 
b/reportdesign/source/core/api/Section.cxx
index 678808c..5433c5c 100644
--- a/reportdesign/source/core/api/Section.cxx
+++ b/reportdesign/source/core/api/Section.cxx
@@ -165,6 +165,12 @@ void SAL_CALL OSection::dispose() 
throw(uno::RuntimeException)
 {
 OSL_ENSURE(!rBHelper.bDisposed,"Already disposed!");
 SectionPropertySet::dispose();
+uno::Reference const xPageComponent(m_xDrawPage,
+uno::UNO_QUERY);
+if (xPageComponent.is())
+{
+xPageComponent->dispose();
+}
 cppu::WeakComponentImplHelperBase::dispose();
 
 }
@@ -208,11 +214,15 @@ void OSection::init()
 if ( pModel )
 {
 uno::Reference const xSection(this);
-m_xDrawPage.set(pModel->createNewPage(xSection)->getUnoPage(),
-uno::UNO_QUERY_THROW);
+SdrPage & rSdrPage(*pModel->createNewPage(xSection));
+m_xDrawPage.set(rSdrPage.getUnoPage(), uno::UNO_QUERY_THROW);
 m_xDrawPage_ShapeGrouper.set(m_xDrawPage, uno::UNO_QUERY_THROW);
 // apparently we may also get OReportDrawPage which doesn't support 
this
 m_xDrawPage_FormSupplier.set(m_xDrawPage, uno::UNO_QUERY);
+m_xDrawPage_Tunnel.set(m_xDrawPage, uno::UNO_QUERY_THROW);
+// fdo#53872: now also exchange the XDrawPage in the SdrPage so that
+// rSdrPage.getUnoPage returns this
+rSdrPage.SetUnoPage(this);
 // createNewPage _should_ have stored away 2 uno::References to this,
 // so our ref count cannot be 1 here, so this isn't destroyed here
 assert(m_refCount > 1);
diff --git a/svx/inc/svx/svdpage.hxx b/svx/inc/svx/svdpage.hxx
index 3833a67..782dbab 100644
--- a/svx/inc/svx/svdpage.hxx
+++ b/svx/inc/svx/svdpage.hxx
@@ -43,12 +43,14 @@
 #include 
 #include "svx/svxdllapi.h"
 #include 
+#include 
 #include 
 #include 
 
 //
 // predefines
 
+namespace reportdesign { class OSection; }
 namespace sdr { namespace contact { class ViewContact; }}
 class SdrPage;
 class SdrModel;
@@ -428,8 +430,8 @@ public:
 friend class SvxUnoDrawPagesAccess;
 
 // this class uses its own UNO wrapper
-// and thus has to set mxUnoPage
-friend class ChXChartDocument;
+// and thus has to set mxUnoPage (it also relies on mxUnoPage not being 
WeakRef)
+friend class reportdesign::OSection;
 
 sal_Int32 nWdt; // Seitengroesse
 sal_Int32 nHgt; // Seitengroesse
@@ -438,13 +440,11 @@ friend class ChXChartDocument;
 sal_Int32 nBordRgt; // Seitenrand rechts
 sal_Int32 nBordLwr; // Seitenrand unten
 
-// this is a weak reference to a possible living api wrapper for this page
-::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > 
mxUnoPage;
-
 protected:
 SdrLayerAdmin*  pLayerAdmin;
 private:
 SdrPageProperties*  mpSdrPageProperties;
+::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > 
mxUnoPage;
 
 public:
 SdrPageProperties& getSdrPageProperties() { return *mpSdrPageProperties; }
@@ -467,6 +467,8 @@ protected:
 // #i93597#
 unsignedmbPageBorderOnlyLeftRight : 1;
 
+void SetUnoPage(::com::sun::star::uno::Reference<
+::com::sun::star::drawing::XDrawPage> const&);
 virtual ::com::sun::star::uno::Reference< 
::com::sun::star::uno::XInterface > createUnoPage();
 
 public:
diff --git a/svx/source/svdraw/svdpage.cxx b/svx/source/svdraw/svdpage.cxx
index 3fcd836..d6d148e 100644
--- a/svx/source/svdraw/svdpage.cxx
+++ b/svx/source/svdraw/svdpage.cxx
@@ -1788,10 +1788,13 @@ void SdrPage::SetInserted( bool bIns )
 }
 }
 
+void SdrPage::SetUnoPage(uno::Reference const& xNewPage)
+{
+mxUnoPage = xNewPage;
+}
 
 uno::Reference< uno::XInterface > SdrPage::getUnoPage()
 {
-// try weak reference first
 if( !mxUnoPage.is() )
 {
 // create one
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.

Bugs 38840+39596: Coverage analysis and static analysis: Whats next ?

2012-09-05 Thread John Smith
Hi,


I was wondering, now that there are initial reports for both code
coverage and statistic analysis, what the next step could be ? For
example, are people interested in mini-HOWTO's on how to (re-)produce
the reports ? Something else entirely ?


Regards,


John Smith.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?

2012-09-05 Thread Peter Jentsch
Am 04.09.12 13:16, schrieb Caolán McNamara:
> On Thu, 2012-08-30 at 10:10 +0900, mete0r wrote:
>> Hi,
>>
>> I'm developing an document import filter (which will be packaged as
>> an .oxt extension) and it needs to perform XSLT transformations during
>> the process of importing (I don't believe xsltfilter could cover these
>> process). So I'm finding a way to use XSLT transformation services
>> directly.
>>
>> In libreoffice 3.5.4, which I'm working with, there seem 2 UNO service,
>> i.e., com.sun.star.comp.JAXTHelper and
>> com.sun.star.comp.documentconversion.LibXSLTTransformer.
>>
>> Currently I'm using the later one (by specifiying its service name in
>> the ServiceManager.createInstanceWithContext()), but both are just
>> working fine for me. So here are my questions:
>>
>> 1. Which one is preferred to be used in regard to forward/backward
>> compatibility? It looks like LibXSLTTransformer is introduced later,
>> then will JAXTHelper be deprecated at some point in the future?
>>
>> 2. Or should I choose one of them conditionally according to the version
>> of the Libreoffice installation? If this is the case, from what version
>> should I use LibXSLTTransformer?
>>
>> 3. Or direct instantiation and use of them like these (not through
>> xsltfilter), is unsupported and discouraged way?
>>
>> Any guidance or comments would be greatly appreciated.
> This isn't an area I know much about, maybe Peter can give the best
> suggestions. But if the question ends up being "directly use the java
> backend vs directly use the libxslt-based backend" then I imagine the
> answer is to use the libxslt-based one.
>
> C.
>
>
Hi mete0r,

that's an interesting one: xslt filter uses LibXSLTTransformer as a
default that can be overriden with JAXTHelper, but we don't have a real
default for that.

JAXTHelper is, as you said, the older implemenetation, and is the one
still being used by Apache OpenOffice. It delegates transformation to a
bundled version of Saxon 9 (Java).

The main differences between the to services are as follows:

LibXSLTTransformer:

- fast initialization
- does not require Java
- supports XSLT 1.0 + most exslt extension (support for exslt within
LibO depending on a patch pending to be submitted by me)
- fast for most simple transformations
- extensions need to be written in C an incorporated into LibO source
(currently no dynamic loading of extension functions)

JAXTHelper:
- slow initialization
- requires Java
- supports XSLT 2.0
- contains some optimizations which make if a lot faster for some
complex transformations
- extensions need to be written in Java an can be bundled with LibO
extensions (supports dynamic loading of extension functions)

JAXTHelper is not going away in the near future, as it provides support
for XSLT 2.0, which is not going to appear in libxslt any time soon.

I'd suggest you choose on the criteria above, giving LibXSLTTransformer
a slight preference.

Cheers,

Peter
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: feature/vs2012: testing needed

2012-09-05 Thread Peter Foley
On 9/4/2012 1:48 AM, Noel Grandin wrote:

> failing because:
> 
> 13fbc2e8b37ddf28181dd6d8081c2b8e-dbghelp.dll
> --2012-09-04 07:47:03--
> http://dev-www.libreoffice.org/extern/13fbc2e8b37ddf28181dd6d8081c2b8e-dbghelp.dll
> 
> Resolving proxy.ct (proxy.ct)... 192.168.1.5
> Connecting to proxy.ct (proxy.ct)|192.168.1.5|:3128... connected.
> Proxy request sent, awaiting response... 404 Not Found
> 2012-09-04 07:47:04 ERROR 404: Not Found.

See 
http://article.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/35595

Hopefully someone will either agree and upload dbghelp.dll or I'll have to come 
up with another solution.
Meanwhile, you can just copy the dll to 
src/13fbc2e8b37ddf28181dd6d8081c2b8e-dbghelp.dll manually.

Thanks,

Peter Foley
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] Change in core[libreoffice-3-6]: fdo#53872: reportdesign: fix section drawpage crash:

2012-09-05 Thread Gerrit
>From Lionel Elie Mamane :

Lionel Elie Mamane has submitted this change and it was merged.

Change subject: fdo#53872: reportdesign: fix section drawpage crash:
..


fdo#53872: reportdesign: fix section drawpage crash:

In order to wrap the SdrPage's UNO object completely, set its mxUnoPage
member to the OSection wrapper instance in OSection::init; only OSection
should have access to it.
Also initialize m_xDrawPage_Tunnel (thanks Lionel for the hint).
(regression from 05218c101df486302bf4cfe8be23ad840daa3f73)

Change-Id: I048ddafc31e946853e56e6a403ddc9487cfbcf0e
Signed-off-by: Lionel Elie Mamane 
---
M reportdesign/source/core/api/Section.cxx
M svx/inc/svx/svdpage.hxx
M svx/source/svdraw/svdpage.cxx
3 files changed, 23 insertions(+), 8 deletions(-)


--
To view, visit https://gerrit.libreoffice.org/558
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I048ddafc31e946853e56e6a403ddc9487cfbcf0e
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Michael Stahl 
Gerrit-Reviewer: Lionel Elie Mamane 
Gerrit-Reviewer: Michael Stahl 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: Branch 'libreoffice-3-6' - reportdesign/source svx/inc svx/source

2012-09-05 Thread Libreoffice Gerrit user
 reportdesign/source/core/api/Section.cxx |   14 --
 svx/inc/svx/svdpage.hxx  |   12 +++-
 svx/source/svdraw/svdpage.cxx|5 -
 3 files changed, 23 insertions(+), 8 deletions(-)

New commits:
commit 0e6054f8f5e2d41e50a50645defa5861599fe375
Author: Michael Stahl 
Date:   Tue Sep 4 20:38:17 2012 +0200

fdo#53872: reportdesign: fix section drawpage crash:

In order to wrap the SdrPage's UNO object completely, set its mxUnoPage
member to the OSection wrapper instance in OSection::init; only OSection
should have access to it.
Also initialize m_xDrawPage_Tunnel (thanks Lionel for the hint).
(regression from 05218c101df486302bf4cfe8be23ad840daa3f73)

Change-Id: I048ddafc31e946853e56e6a403ddc9487cfbcf0e
Signed-off-by: Lionel Elie Mamane 

diff --git a/reportdesign/source/core/api/Section.cxx 
b/reportdesign/source/core/api/Section.cxx
index 8142bef..d498cda 100644
--- a/reportdesign/source/core/api/Section.cxx
+++ b/reportdesign/source/core/api/Section.cxx
@@ -165,6 +165,12 @@ void SAL_CALL OSection::dispose() 
throw(uno::RuntimeException)
 {
 OSL_ENSURE(!rBHelper.bDisposed,"Already disposed!");
 SectionPropertySet::dispose();
+uno::Reference const xPageComponent(m_xDrawPage,
+uno::UNO_QUERY);
+if (xPageComponent.is())
+{
+xPageComponent->dispose();
+}
 cppu::WeakComponentImplHelperBase::dispose();
 
 }
@@ -208,11 +214,15 @@ void OSection::init()
 if ( pModel )
 {
 uno::Reference const xSection(this);
-m_xDrawPage.set(pModel->createNewPage(xSection)->getUnoPage(),
-uno::UNO_QUERY_THROW);
+SdrPage & rSdrPage(*pModel->createNewPage(xSection));
+m_xDrawPage.set(rSdrPage.getUnoPage(), uno::UNO_QUERY_THROW);
 m_xDrawPage_ShapeGrouper.set(m_xDrawPage, uno::UNO_QUERY_THROW);
 // apparently we may also get OReportDrawPage which doesn't support 
this
 m_xDrawPage_FormSupplier.set(m_xDrawPage, uno::UNO_QUERY);
+m_xDrawPage_Tunnel.set(m_xDrawPage, uno::UNO_QUERY_THROW);
+// fdo#53872: now also exchange the XDrawPage in the SdrPage so that
+// rSdrPage.getUnoPage returns this
+rSdrPage.SetUnoPage(this);
 // createNewPage _should_ have stored away 2 uno::References to this,
 // so our ref count cannot be 1 here, so this isn't destroyed here
 assert(m_refCount > 1);
diff --git a/svx/inc/svx/svdpage.hxx b/svx/inc/svx/svdpage.hxx
index 19f9d35..a1efef6 100644
--- a/svx/inc/svx/svdpage.hxx
+++ b/svx/inc/svx/svdpage.hxx
@@ -42,12 +42,14 @@
 #include 
 #include "svx/svxdllapi.h"
 #include 
+#include 
 #include 
 #include 
 
 //
 // predefines
 
+namespace reportdesign { class OSection; }
 namespace sdr { namespace contact { class ViewContact; }}
 class SdrPage;
 class SdrModel;
@@ -427,8 +429,8 @@ public:
 friend class SvxUnoDrawPagesAccess;
 
 // this class uses its own UNO wrapper
-// and thus has to set mxUnoPage
-friend class ChXChartDocument;
+// and thus has to set mxUnoPage (it also relies on mxUnoPage not being 
WeakRef)
+friend class reportdesign::OSection;
 
 sal_Int32 nWdt; // Seitengroesse
 sal_Int32 nHgt; // Seitengroesse
@@ -437,13 +439,11 @@ friend class ChXChartDocument;
 sal_Int32 nBordRgt; // Seitenrand rechts
 sal_Int32 nBordLwr; // Seitenrand unten
 
-// this is a weak reference to a possible living api wrapper for this page
-::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > 
mxUnoPage;
-
 protected:
 SdrLayerAdmin*  pLayerAdmin;
 private:
 SdrPageProperties*  mpSdrPageProperties;
+::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > 
mxUnoPage;
 
 public:
 SdrPageProperties& getSdrPageProperties() { return *mpSdrPageProperties; }
@@ -466,6 +466,8 @@ protected:
 // #i93597#
 unsignedmbPageBorderOnlyLeftRight : 1;
 
+void SetUnoPage(::com::sun::star::uno::Reference<
+::com::sun::star::drawing::XDrawPage> const&);
 virtual ::com::sun::star::uno::Reference< 
::com::sun::star::uno::XInterface > createUnoPage();
 
 public:
diff --git a/svx/source/svdraw/svdpage.cxx b/svx/source/svdraw/svdpage.cxx
index cd8ba23..de8c4f4 100644
--- a/svx/source/svdraw/svdpage.cxx
+++ b/svx/source/svdraw/svdpage.cxx
@@ -1785,10 +1785,13 @@ void SdrPage::SetInserted( bool bIns )
 }
 }
 
+void SdrPage::SetUnoPage(uno::Reference const& xNewPage)
+{
+mxUnoPage = xNewPage;
+}
 
 uno::Reference< uno::XInterface > SdrPage::getUnoPage()
 {
-// try weak reference first
 if( !mxUnoPage.is() )
 {
 // create one
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits


[Bug 44446] LibreOffice 3.6 most annoying bugs

2012-09-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=6

Timur  changed:

   What|Removed |Added

 Depends on||54259

--- Comment #109 from Timur  2012-09-05 08:19:26 UTC ---
I added Bug 54259 - FILESAVE: When saving in MSWord doc format, some table
cells unmerged so data not shown properly. It seems that this started in 3.6.
We are affected also on our memo, so it's highly visible.

-- 
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


Re: [ABANDONED]Obsolete RTL_CONSTASCII_USTRINGPARAM

2012-09-05 Thread Stephan Bergmann
For the record, this got superseded by 
 "Change Ic56451b2: OUString and 
RTL_CONSTASCII cleanup."


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[PUSHED] OUString and RTL_CONSTASCII cleanup

2012-09-05 Thread Gerrit
>From Stephan Bergmann :

Stephan Bergmann has submitted this change and it was merged.

Change subject: OUString and RTL_CONSTASCII cleanup
..


OUString and RTL_CONSTASCII cleanup

Change-Id: Ic56451b2c13d8561bb6e6ee92bf9147b35640a5c
---
M binaryurp/source/bridge.cxx
M binaryurp/source/bridgefactory.cxx
M binaryurp/source/currentcontext.cxx
M binaryurp/source/incomingrequest.cxx
M binaryurp/source/marshal.cxx
M binaryurp/source/outgoingrequests.cxx
M binaryurp/source/proxy.cxx
M binaryurp/source/reader.cxx
M binaryurp/source/unmarshal.cxx
M binaryurp/source/writer.cxx
10 files changed, 99 insertions(+), 221 deletions(-)


--
To view, visit https://gerrit.libreoffice.org/560
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Ic56451b2c13d8561bb6e6ee92bf9147b35640a5c
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Ricardo Montania 
Gerrit-Reviewer: Ricardo Montania 
Gerrit-Reviewer: Stephan Bergmann 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice-commits] .: 2 commits - binaryurp/source

2012-09-05 Thread Libreoffice Gerrit user
 binaryurp/source/bridge.cxx   |   87 --
 binaryurp/source/bridgefactory.cxx|   24 ++---
 binaryurp/source/currentcontext.cxx   |   10 +--
 binaryurp/source/incomingrequest.cxx  |   13 +
 binaryurp/source/marshal.cxx  |6 --
 binaryurp/source/outgoingrequests.cxx |3 -
 binaryurp/source/proxy.cxx|7 +-
 binaryurp/source/reader.cxx   |   85 +
 binaryurp/source/unmarshal.cxx|   84 
 binaryurp/source/writer.cxx   |   16 +-
 10 files changed, 94 insertions(+), 241 deletions(-)

New commits:
commit 7a7a2c5495e9e03181843c327a0c28fd6e5e88bd
Author: Stephan Bergmann 
Date:   Wed Sep 5 10:12:40 2012 +0200

Cosmetics

Change-Id: I7b217c4fb48bbee4a2872d15cf23a955b464ffca

diff --git a/binaryurp/source/bridge.cxx b/binaryurp/source/bridge.cxx
index 89ef720..e59311d 100644
--- a/binaryurp/source/bridge.cxx
+++ b/binaryurp/source/bridge.cxx
@@ -180,12 +180,8 @@ Bridge::Bridge(
 factory_(factory), name_(name), connection_(connection),
 provider_(provider),
 binaryUno_(UNO_LB_UNO),
-cppToBinaryMapping_(
-CPPU_CURRENT_LANGUAGE_BINDING_NAME,
-UNO_LB_UNO),
-binaryToCppMapping_(
-UNO_LB_UNO,
-CPPU_CURRENT_LANGUAGE_BINDING_NAME),
+cppToBinaryMapping_(CPPU_CURRENT_LANGUAGE_BINDING_NAME, UNO_LB_UNO),
+binaryToCppMapping_(UNO_LB_UNO, CPPU_CURRENT_LANGUAGE_BINDING_NAME),
 protPropTid_(
 reinterpret_cast< sal_Int8 const * >(".UrpProtocolPropertiesTid"),
 RTL_CONSTASCII_LENGTH(".UrpProtocolPropertiesTid")),
@@ -193,10 +189,8 @@ Bridge::Bridge(
 protPropType_(
 cppu::UnoType<
 css::uno::Reference< css::bridge::XProtocolProperties > >::get()),
-protPropRequest_(
-"com.sun.star.bridge.XProtocolProperties::requestChange"),
-protPropCommit_(
-"com.sun.star.bridge.XProtocolProperties::commitChange"),
+protPropRequest_("com.sun.star.bridge.XProtocolProperties::requestChange"),
+protPropCommit_("com.sun.star.bridge.XProtocolProperties::commitChange"),
 state_(STATE_INITIAL), threadPool_(0), currentContextMode_(false),
 proxies_(0), calls_(0), normalCall_(false), activeCalls_(0),
 mode_(MODE_REQUESTED)
@@ -696,8 +690,7 @@ void Bridge::handleRequestChangeReply(
 }
 if (n != exp) {
 throw css::uno::RuntimeException(
-"URP: requestChange reply with unexpected return value"
-" received",
+"URP: requestChange reply with unexpected return value received",
 static_cast< cppu::OWeakObject * >(this));
 }
 decrementCalls();
@@ -797,8 +790,7 @@ void Bridge::handleCommitChangeRequest(
 assert(ok);
 (void) ok; // avoid warnings
 for (sal_Int32 i = 0; i != s.getLength(); ++i) {
-if ( s[i].Name == "CurrentContext" )
-{
+if (s[i].Name == "CurrentContext") {
 ccMode = true;
 } else {
 ccMode = false;
@@ -883,8 +875,8 @@ css::uno::Reference< css::uno::XInterface > 
Bridge::getInstance(
 for (sal_Int32 i = 0; i != sInstanceName.getLength(); ++i) {
 if (sInstanceName[i] > 0x7F) {
 throw css::io::IOException(
-"XBridge::getInstance sInstanceName contains non-ASCII"
-" character",
+("XBridge::getInstance sInstanceName contains non-ASCII"
+ " character"),
 css::uno::Reference< css::uno::XInterface >());
 }
 }
@@ -997,8 +989,7 @@ void Bridge::makeReleaseCall(
 AttachThread att(getThreadPool());
 sendRequest(
 att.getTid(), oid, type,
-css::uno::TypeDescription(
-"com.sun.star.uno.XInterface::release"),
+css::uno::TypeDescription("com.sun.star.uno.XInterface::release"),
 std::vector< BinaryAny >());
 }
 
diff --git a/binaryurp/source/bridgefactory.cxx 
b/binaryurp/source/bridgefactory.cxx
index c53e56c..634ddb3 100644
--- a/binaryurp/source/bridgefactory.cxx
+++ b/binaryurp/source/bridgefactory.cxx
@@ -52,14 +52,12 @@ css::uno::Reference< css::uno::XInterface > 
BridgeFactory::static_create(
 }
 
 OUString BridgeFactory::static_getImplementationName() {
-return OUString(
-"com.sun.star.comp.bridge.BridgeFactory");
+return OUString("com.sun.star.comp.bridge.BridgeFactory");
 }
 
 css::uno::Sequence< OUString >
 BridgeFactory::static_getSupportedServiceNames() {
-OUString name(
-"com.sun.star.bridge.BridgeFactory");
+OUString name("com.sun.star.bridge.BridgeFactory");
 return css::uno::Sequence< OUString >(&name, 1);
 }
 
@@ -132,11 +130,10 @@ css::uno::Reference< css::bridge::XBridge > 
BridgeFactory::createBridge(
 throw css::bridge::BridgeExistsException(
 sName, static_cast< cppu::OWeakObject * >(this));
 }
-if ( sProtocol != "urp" || !aConnection.is() )
- 

Re: feature/vs2012: testing needed

2012-09-05 Thread Noel Grandin


On 2012-09-04 23:19, Peter Foley wrote:
See 
http://article.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/35595 


Hopefully someone will either agree and upload dbghelp.dll or I'll 
have to come up with another solution.


Norbert very kindly uploaded the file.

BTW, I'm on IRC in #libreoffice-dev if you want faster turnaround - 
username 'noelg'


Now the build is failing with:

$ make check
make -r -f /cygdrive/C/libo/Makefile.top check
make[1]: Entering directory `/cygdrive/C/libo'

*
*   Running the post download checks.
*

checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking for dbghelp.dll... found
Copying /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
9.0/VC/redist/x86/Microsoft.VC90.CRT/msvcp90.dll to ./external/msvcp90
Copying /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
9.0/VC/redist/x86/Microsoft.VC90.CRT/msvcr90.dll to ./external/msvcp90
Copying /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
9.0/VC/redist/x86/Microsoft.VC90.CRT/msvcm90.dll to ./external/msvcp90
Copying /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
9.0/VC/redist/x86/Microsoft.VC90.CRT/Microsoft.VC90.CRT.manifest to 
./external/msvcp90

MSMDir not found at ./oowintool line 330.
post_download: error: oowintool failed to copy merge modules
make[1]: *** [src.downloaded] Error 1
make[1]: Leaving directory `/cygdrive/C/libo'
make: *** [check] Error 2



Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice