date:20120228


On 02/29/2012 04:10 AM, Kohei Yoshida wrote:

The attached patch fixes a bug in our current leap year calculation
code.  It is based on the algorithm posted on wikipedia[1], and seems to
correctly identify year 2000 as a leap year.

Without this, Calc would convert 2000-2-29 into 1899-12-30 on load,
which is ugly but very hard to detect.

Please consider this for 3.5.1, in which case I'll need 3 sign-offs.  I
haven't pushed this to master yet.  I wanted to run it by Eike first
before pushing to master.


You can count me in as +1 towards pushing it to all the relevant branches.

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

Re: String literals, ASCII vs UTF-8


On 02/28/2012 02:48 PM, Lubos Lunak wrote:

  Speaking of the size at the call-site, I good part is the code trying to
throw std::bad_alloc in case the allocation fails. That actually looks rather
useless to me, for several reasons:

- not all OUString methods check for this anyway
- rtl_uString* functions do OSL_ASSERT() after allocations
- with today's systems (overcommitting, etc.) it is rather pointless to guard
against allocation failures

  Does somebody see a good reason not to just remove it?


First of all, Linux' memory overcommitting is a bug IMO (and, AFAIU, 
fully optional these days), and should not be misused to justify sloppy 
application design.


Out-of-memory (OOM) is a somewhat curious conditions, as it can occur 
for two rather different reasons (that ask for different solutions), but 
it is not generally possible to tell which is which.  If a system gets 
really low on memory, there is typically little use in trying to carry 
on with an application that experiences OOM, and the best overall 
solution is to terminate the application quickly and as gracefully as 
possible.


However, there are also situations where bad input (malicious or 
otherwise) would cause an application to request excessive amounts of 
memory to do a single task (e.g., open a document), and at least in 
theory the application should be able to cope with such 
externally-induced OOM conditions, by abandoning the bad operation, 
cleaning up after it, telling the user the operation failed, and 
carrying on.


The traditional building blocks for memory acknowledge this dichotomy by 
reporting OOM to the call site (NULL in case of malloc, bad_alloc in 
case of new), as only the call site can decide how to properly react (or 
pass on up the stack to a knowledgeable one).


With LO we are certainly far away from the ideal, where excessive 
operations would be detected and abandoned cleanly, letting the overall 
application continue as if nothing happened.  But I would nevertheless 
not be happy with shaky foundations that ignore OOM and only fail down 
the road when dereferencing a null pointer.  (Even if that "down the 
road" is still nearby, within the same inline function.  It is already 
hard enough to make use of the typical crash report's call stacks, 
always having to judge whether the situation it presents can have 
legitimately occurred, or is due to some earlier memory corruption that 
put wild data into in-use memory.  "Fail fast" is a sound software 
engineering principle, IMO.)


Hence, my preference is still to flag OOM in C++ code with bad_alloc. 
The second best alternative is IMO to abort.


That this OOM handling has to happen in those inline C++ wrapper 
functions is an unfortunate consequence of our C-based low-level API 
(something that we should probably change, if we ever come around to an 
incompatible LO 4 and still are determined to write that in C++).


But how bad is that, anyway?  A little experiment shows that the 
compiler will happily outline those inline functions detecting for 
bad_alloc, creating one instance of them per library.


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

Re: [PUSHED 3.5][REVIEW 3.5.1] Fix crash on exit using KDE interface

2012-02-28 Thread Josh Heidenreich

Hi,

> Needs two more reviews for libreoffice-3-5-1.

I don't know much about this code, nor if I have the authority to
sign-off, but the patch looks sane to me. Just my 2c.

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

[REVIEW 3-5][PATCH] Fix leap year calculation

2012-02-28 Thread Kohei Yoshida

Hi there,

The attached patch fixes a bug in our current leap year calculation
code.  It is based on the algorithm posted on wikipedia[1], and seems to
correctly identify year 2000 as a leap year.

Without this, Calc would convert 2000-2-29 into 1899-12-30 on load,
which is ugly but very hard to detect.

Please consider this for 3.5.1, in which case I'll need 3 sign-offs.  I
haven't pushed this to master yet.  I wanted to run it by Eike first
before pushing to master.

Kohei

[1] http://en.wikipedia.org/wiki/Leap_year

-- 
Kohei Yoshida, LibreOffice hacker, Calc
>From 0666b5dca1a210ce7abc61a522a59c48661fe664 Mon Sep 17 00:00:00 2001
From: Kohei Yoshida 
Date: Tue, 28 Feb 2012 22:01:52 -0500
Subject: [PATCH] Correctly calculate leap year.

With the old code, year 2000 would not be a leap year, but it actually
is.  With this, Calc correctly loads cell with date value of 2000-2-29.
---
 sax/source/tools/converter.cxx |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sax/source/tools/converter.cxx b/sax/source/tools/converter.cxx
index eb8cc74..95f6494 100644
--- a/sax/source/tools/converter.cxx
+++ b/sax/source/tools/converter.cxx
@@ -1304,7 +1304,7 @@ readDateTimeComponent(const ::rtl::OUString & rString,
 static bool lcl_isLeapYear(const sal_uInt32 nYear)
 {
 return ((nYear % 4) == 0)
-&& !(((nYear % 100) == 0) || ((nYear % 400) == 0));
+&& (((nYear % 100) != 0) || ((nYear % 400) == 0));
 }
 
 static sal_uInt16
-- 
1.7.3.4

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

[PUSHED 3.5][REVIEW 3.5.1] Fix crash on exit using KDE interface

On Tue, Feb 28, 2012 at 09:16:25PM +0100, Tomáš Chvátal wrote:
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=24f4cd9983aa2bc9d642c40a8fef19d7fe7b98a6

Looks simple and sane. Review and pushed to libreoffice-3-5 as:

 
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=e532d4932b8a265cc82bf06ef54db58c9b532e38

Needs two more reviews for libreoffice-3-5-1.

Best,

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

License statement

2012-02-28 Thread Rene Engelhard

Hi,

it seems I didn't send this explicitely yet:

I declare that all my past and future contributions to LibreOffice (and stuff
formerly from OpenOffice.org/go-oo) are licensed under under
LGPL3+/GPL3+/MPL1.1+.

Grüße/Regards,

Rene


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

SVG: debugging svg export

2012-02-28 Thread Chr. Rossmanith


Hi,

I'm currently debugging SVGFilter::implExportPages() especially around 
line 1336


// In case we are dealing with a master page we need to to 
group all its shapes

// into a group element, this group will make up the so named 
"background objects"

if( bMaster )

{

// background objects id = "bo-" + page id

OUString sBackgroundObjectsId = B2UCONST( "bo-" );

sBackgroundObjectsId += sPageId;

mpSVGExport->AddAttribute( XML_NAMESPACE_NONE, "id", 
sBackgroundObjectsId );

if( i == nVisiblePage&&  
mVisiblePagePropSet.bAreBackgroundObjectsVisible )

aAttrVisibilityValue = B2UCONST( "visible" );

else

aAttrVisibilityValue = B2UCONST( "hidden" );

mpSVGExport->AddAttribute( XML_NAMESPACE_NONE, 
"visibility", aAttrVisibilityValue );

mpSVGExport->AddAttribute( XML_NAMESPACE_NONE, "class",  
B2UCONST( "BackgroundObjects" ) );

// insert the  open tag related to the Background 
Objects

 ** SvXMLElementExport aExp2( *mpSVGExport, XML_NAMESPACE_NONE, 
"g", sal_True, sal_True );

// append all shapes that make up the Master Slide

bRet = implExportShapes( xShapes ) || bRet;

}   // append the  closing tag related to the 
Background Objects


The tag opened in the line marked with ** is never closed. (It should be 
closed by the destructor.) I've tested the export with a drawing 
containing a single letter 'a' and in that case there are no background 
objects. So maybe testing if xShapes has no shapes could avoid exporting 
an empty block? But how would I test if xShapes has any shapes?


Any hint concerning the never called destructor for aExp2 and retrieving 
information from xShapes is welcome.


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

Re: String literals, ASCII vs UTF-8

On Tue, 2012-02-28 at 14:48 +0100, Lubos Lunak wrote:
> - with today's systems (overcommitting, etc.) it is rather pointless to guard 
> against allocation failures

Another scenario of possibly more usefulness than actually "running out
of memory" is being directed to allocate a lunatic string size by some
busted document during import which is physically impossible to allocate
on a given architecture e.g. a broken .doc or whatever which claims to
have strings of SAL_MAX_SIZE * sal_Unicodes. Those would currently throw
std::bad_alloc without going anywhere near actually attempting to
allocate memory.

>  Does somebody see a good reason not to just remove it?

Mine's a somewhat contrived scenario, probably better to use custom foo
in places like the filters where the whole import can be abandoned on
epic failure.

C.

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

Re: [PATCH] fdo#46193: Let the user copy error message from error dialog

Hi Szabolcs,

2012/2/28 Dézsi Szabolcs :
> Hello!
>
> I created a new class in cui/. : CopyableWarningBox (copywarnbox.hxx and
> copywarnbox.cxx). This class gets instantiated in
> cui/source/dialogs/scriptdlg.cxx (last method).
>
> I couldn't manage to do the sizing dynamically, so it creates a fix
> (500*300)
> dialog.
>
> To test the dialog run ./soffice. Tools/Macros/Run Macro...
> Expand LibreOffice Macros/Gimmicks/GetTexts and run GetCellTexts.
>

Thanks for the patch, it is the first step into the right direction. A
few notes:
* When you create a new file, please use the boilerplate licence
header, it is TEMPLATE.SOURCECODE.HEADER in root. Fill it in with your
details, e.g. you are the initial contributor, etc.
* What did you try for dynamical resizing? I did not try, but I think
you can query the text width and height with GetCtrlTextWidth and
GetTextHeight methods, then (textwidth % dialogwidth + 1)*textheight
or something like this will give you the required height of the
control.

Would you please try and send a new patch?

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

Re: [REVIEW 3-5, 3-5-1] Make libxslt link the right libxml on mac ppc


On 02/28/2012 03:21 PM, Fridrich Strba wrote:

diff --git a/libxslt/makefile.mk b/libxslt/makefile.mk
index cc89185..d21c0e3 100644
--- a/libxslt/makefile.mk
+++ b/libxslt/makefile.mk
@@ -86,6 +86,11 @@ CONF_ILIB=
 .ELSE
 CONF_ILIB=-L$(ILIB:s/;/ -L/)
 .ENDIF
+
+.IF "$(OS)"=="MACOSX" && "$(SYSTEM_LIBXML)" != "YES"
+LIBXML2LIB=-L$(SOLARLIBDIR) -lxml2
+.ENDIF
+


But that is inside an .IF "$(OS)"=="WNT" block, isn't it?  Also, at 
least for my Mac OS X 10.6 x86 tests, the existing libxslt/makefile.mk 
seemed to already work fine with --without-system-libxml (probably due 
to the



.IF "$(SYSTEM_LIBXML)"!="YES"
# Use the xml2-config from our own libxml2 copy
CONFIGURE_FLAGS+=--with-libxml-prefix=$(SOLARVER)/$(INPATH)
.ENDIF


at line 143).

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

[PATCH] Fix crash on exit using KDE interface

2012-02-28 Thread Tomáš Chvátal

Hi guys,

Please review this commit for merge request to 3.5 and possibly to 3.5.1 as it 
is considered reproducable every time one use kde4 interface.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=24f4cd9983aa2bc9d642c40a8fef19d7fe7b98a6

Cheers

Tom

signature.asc
Description: This is a digitally signed message part.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] fdo#46343 fix opening of 8-bit encoded filenames

Hi,

The attached patch is from bugzilla, Alex Prokofiev made it. It looks
OK to me, but I'd like to ask a 2nd review before push.

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

Thanks,
Andras


0001-fdo-46434-fix-opening-of-8-bit-encoded-filenames.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Convert SV_DECL_VARARR_SORT and SV_IMPL_VARARR_SORT with std::set

2012-02-28 Thread Bartosz

Hi.

I converted the SV_DECL_VARARR_SORT and SV_IMPL_VARARR_SORT with ::std::set.
I also made some optimization (cppcheck).

Could you please check this patch and push it into libreoffice.

License statement is on file.

Thanks in advance
Bartosz
diff --git a/editeng/source/editeng/impedit.hxx 
b/editeng/source/editeng/impedit.hxx
index 1c008fb..417415e 100644
--- a/editeng/source/editeng/impedit.hxx
+++ b/editeng/source/editeng/impedit.hxx
@@ -906,7 +906,7 @@ public:
 LanguageTypeGetDefaultLanguage() const { return eDefLanguage; }
 
 
-LanguageTypeGetLanguage( const EditSelection rSelection ) const;
+LanguageTypeGetLanguage( const EditSelection &rSelection ) const;
 LanguageTypeGetLanguage( const EditPaM& rPaM, sal_uInt16* pEndPos 
= NULL ) const;
 ::com::sun::star::lang::Locale GetLocale( const EditPaM& rPaM ) const;
 
@@ -946,12 +946,12 @@ public:
 //adds one or more portions of text to the SpellPortions depending on 
language changes
 voidAddPortionIterated(
 EditView& rEditView,
-const EditSelection rSel,
+const EditSelection &rSel,
 ::com::sun::star::uno::Reference< 
::com::sun::star::linguistic2::XSpellAlternatives > xAlt,
 ::svx::SpellPortions& rToFill);
 //adds one portion to the SpellPortions
 voidAddPortion(
-const EditSelection rSel,
+const EditSelection &rSel,
 ::com::sun::star::uno::Reference< 
::com::sun::star::linguistic2::XSpellAlternatives > xAlt,
 ::svx::SpellPortions& rToFill,
 bool bIsField );
diff --git a/editeng/source/editeng/impedit3.cxx 
b/editeng/source/editeng/impedit3.cxx
index 719a8753..b32cdc3 100644
--- a/editeng/source/editeng/impedit3.cxx
+++ b/editeng/source/editeng/impedit3.cxx
@@ -68,6 +68,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -86,9 +87,6 @@ using namespace ::com::sun::star::uno;
 using namespace ::com::sun::star::beans;
 using namespace ::com::sun::star::linguistic2;
 
-SV_DECL_VARARR_SORT( SortedPositions, sal_uInt32, 16 )
-SV_IMPL_VARARR_SORT( SortedPositions, sal_uInt32 );
-
 #define CH_HYPH '-'
 
 #define RESDIFF 10
@@ -2252,14 +2250,14 @@ sal_uInt16 ImpEditEngine::SplitTextPortion( 
ParaPortion* pPortion, sal_uInt16 nP
 return nSplitPortion;
 }
 
-void ImpEditEngine::CreateTextPortions( ParaPortion* pParaPortion, sal_uInt16& 
rStart /* , sal_Bool bCreateBlockPortions */ )
+void ImpEditEngine::CreateTextPortions( ParaPortion* pParaPortion, sal_uInt16& 
rStart )
 {
 sal_uInt16 nStartPos = rStart;
 ContentNode* pNode = pParaPortion->GetNode();
 DBG_ASSERT( pNode->Len(), "CreateTextPortions should not be used for empty 
paragraphs!" );
 
-SortedPositions aPositions;
-aPositions.Insert( (sal_uInt32) 0 );
+::std::set< sal_uInt32 > aPositions;
+aPositions.insert( 0 );
 
 sal_uInt16 nAttr = 0;
 EditCharAttrib* pAttrib = GetAttrib( pNode->GetCharAttribs().GetAttribs(), 
nAttr );
@@ -2267,23 +2265,23 @@ void ImpEditEngine::CreateTextPortions( ParaPortion* 
pParaPortion, sal_uInt16& r
 {
 // Insert Start and End into the Array...
 // The Insert method does not allow for duplicate values
-aPositions.Insert( pAttrib->GetStart() );
-aPositions.Insert( pAttrib->GetEnd() );
+aPositions.insert( pAttrib->GetStart() );
+aPositions.insert( pAttrib->GetEnd() );
 nAttr++;
 pAttrib = GetAttrib( pNode->GetCharAttribs().GetAttribs(), nAttr );
 }
-aPositions.Insert( pNode->Len() );
+aPositions.insert( pNode->Len() );
 
 if ( pParaPortion->aScriptInfos.empty() )
 ((ImpEditEngine*)this)->InitScriptTypes( GetParaPortions().GetPos( 
pParaPortion ) );
 
 const ScriptTypePosInfos& rTypes = pParaPortion->aScriptInfos;
 for ( size_t nT = 0; nT < rTypes.size(); nT++ )
-aPositions.Insert( rTypes[nT].nStartPos );
+aPositions.insert( rTypes[nT].nStartPos );
 
 const WritingDirectionInfos& rWritingDirections = 
pParaPortion->aWritingDirectionInfos;
 for ( size_t nD = 0; nD < rWritingDirections.size(); nD++ )
-aPositions.Insert( rWritingDirections[nD].nStartPos );
+aPositions.insert( rWritingDirections[nD].nStartPos );
 
 if ( mpIMEInfos && mpIMEInfos->nLen && mpIMEInfos->pAttribs && ( 
mpIMEInfos->aPos.GetNode() == pNode ) )
 {
@@ -2292,11 +2290,11 @@ void ImpEditEngine::CreateTextPortions( ParaPortion* 
pParaPortion, sal_uInt16& r
 {
 if ( mpIMEInfos->pAttribs[n] != nLastAttr )
 {
-aPositions.Insert( mpIMEInfos->aPos.GetIndex() + n );
+aPositions.insert( mpIMEInfos->aPos.GetIndex() + n );
 nLastAttr = mpIMEInfos->pAttribs[n];
 }
 }
-aPositions.I

License Statement

2012-02-28 Thread Yifan Jiang

Dear libreoffice,

All of my past, present and future contributions to LibreOffice may be
licensed under the MPL/LGPLv3+ dual license, including the go-oo (and where
applicable, OpenOffice.org) code contributions.

Best wishes,
Yifan Jiang

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

Re: [libreoffice-projects] [ANN] LibreOffice 3.5.1 RC1 available


2012.02.27. 14:31 keltezéssel, Volker Merschmann írta:

There are some duplicate entries in the options menu for Writer here,
installed in german on Windows XP32. One localized, one in english,
for Mailmerge, Compatibility and AutoCaption.


Thanks for the bug report, it is really annoying. I know how to fix it, 
and I will fix it for RC2.


Thanks,
Andras

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

Re: [libreoffice-l10n] [ANN] LibreOffice 3.5.1 RC1 available

2012-02-28 Thread Jon Lachmann

Hi!

I am translating LibreOffice into Swedish using Pootle.

I just wonder at what time the latest translated strings were pulled?
I do not see a lot of my newer translations in the new build, it would
be great if they were added to let me evaluate how well they fit in.

Best regards Jon

> Hi *,
> 
> for the upcoming new version 3.5.1, the RC1 builds now start to be
> available on pre-releases. This build is slated to be one of two
> release candidate builds on the way towards 3.5.1, please refer to our
> release plan timings here:
> 
>  http://wiki.documentfoundation.org/ReleasePlan#3.5_release
> 
> Builds are now being uploaded to a public (but non-mirrored - so don't
> spread news too widely!) place, as soon as they're available. Grab
> them here:
> 
>  http://dev-builds.libreoffice.org/pre-releases/
> 
> If you've a bit of time, please give them a try & report *critical*
> bugs not yet in bugzilla here, so we can incorporate them into the
> release notes. Please note that it takes approximately 24 hours to
> populate the mirrors, so that's about the time we have to collect
> feedback.
> 
> The list of fixed bugs relative to 3.5.0 is here:
> 
>  
> http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-5-1-release-3.5.1.1.log
> 
> So playing with the areas touched there also greatly appreciated - and
> validation that those bugs are really fixed.
> 
> Thanks a lot for your help,
> 
> -- Thorsten
> 
> -- 
> Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/l10n/
> All messages sent to this list will be publicly archived and cannot be
> deleted
> 
> 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [libreoffice-l10n] [ANN] LibreOffice 3.5.1 RC1 available

2012-02-28 Thread Carlo Strata


Il 26/02/2012 23:56, Thorsten Behrens ha scritto:

Hi *,

for the upcoming new version 3.5.1, the RC1 builds now start to be
available on pre-releases. This build is slated to be one of two
release candidate builds on the way towards 3.5.1, please refer to our
release plan timings here:

  http://wiki.documentfoundation.org/ReleasePlan#3.5_release

Builds are now being uploaded to a public (but non-mirrored - so don't
spread news too widely!) place, as soon as they're available. Grab
them here:

  http://dev-builds.libreoffice.org/pre-releases/

If you've a bit of time, please give them a try&  report *critical*
bugs not yet in bugzilla here, so we can incorporate them into the
release notes. Please note that it takes approximately 24 hours to
populate the mirrors, so that's about the time we have to collect
feedback.

The list of fixed bugs relative to 3.5.0 is here:

  
http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-5-1-release-3.5.1.1.log

So playing with the areas touched there also greatly appreciated - and
validation that those bugs are really fixed.

Thanks a lot for your help,

-- Thorsten




Hi *, ;-)

just installed on my notebbok upgrading a LibreOffice 3.5.0 RC3, Linux, 
x86-64. I got this message (I translate it from Italian):


carlobook:/home/carlo/Download/office/LibreOffice/LibO_3.5.1rc1_Linux_x86-64_install-rpm_en-US/RPMS 
# rpm -Uvh *.rpm

Preparing...### [100%]
the file /opt/libreoffice3.5/ure/lib/libstdc++.so.6 conflicts 
during the installation of the following packages: 
libreoffice3.5-stdlibs-3.5.1-101.x86_64 and 
libreoffice3.5-ure-3.5.1-101.x86_64



I can go on and got LibreOffice 3.5.1.1 (RC1, Linux, x86-64) installed 
and running correctly using

/rpm -Uvh *.rpm --force/

My notebook is running
- OpenSuSE 12.1;
- x86-64 architecture;
- about a daily update;
- Linux kernel 3.1.10-4-desktop;
- kernel inside nuveau video driver (nVidia GeForce 9500M GS, 512 Mbyte 
dedicated video RAM).


Have a nice day,

Carlo

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

[Bug 37361] LibreOffice 3.5 most annoying bugs

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

Bug 37361 depends on bug 46038, which changed state.

Bug 46038 Summary: EDITING: CRASH when pasting text from writer into draw when 
there's a header/footer with a table in it present
https://bugs.freedesktop.org/show_bug.cgi?id=46038

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

-- 
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: Disabling Temporary Files?


On Tue, 2012-02-28 at 13:46 -0500, Marc-André Laverdière wrote:
> I need to ensure that data confidentiality.

Ok; so as Michael says, tons of apps dump lots of state into /tmp files
- an encrypted /tmp would help with that. Failing that mounting a
ramdisk over /tmp would do it (on Linux). I guess you could imagine
using the built-in document encryption to do it ...

You -might- hope that the autosave / tmp files etc. might be encrypted
if you use encryption on the document and a good password, but I suspect
that that is unlikely to work ;-) though it might be a good place to
start if you want to hack on that.

HTH,

Michael.

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

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

Re: String literals, ASCII vs UTF-8


On Tue, 2012-02-28 at 15:07 -0300, Olivier Hallot wrote:
> Em 28-02-2012 14:40, Eike Rathke escreveu:
> > People also complained about Writer paragraphs being limited to 64k
> > characters ... that's ~15 pages of eye-tiring continuous lines, but ...
> 
> https://issues.apache.org/ooo/show_bug.cgi?id=17171
> 
> That one hurted me in portuguese/spanish judiciary/legal documents,
> where secular tradition prevents writing with banks/white "spaces" in
> the document (my guess: to not allow adding text in these "holes").

Ho hum :-)

> This is a bug I really care about.
> A layman question: will OString/OUString replacements address this issue?

Well - if by address you mean -potentially- (in writer - when it it is
finally converted) allow for -huge- (4Gb) paragraphs, then possibly
yes ;-)

On the other hand ... I imagine that writer has scalability issues by
the time you get to a handful of pages of the same string anyway ;-)

And that is before you start doing red-lining etc.

> Of course, this issue does not exist "elsewhere".

Sure - those guys use a piece-table to store stuff, and do layout
rather differently ;-)

All the best,

Michael.

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

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

Re: [PATCH] fdo#33697 Unable to reset "System" as Internet Proxy mode. XPropertyState unsupported


On 02/28/2012 02:36 PM, Caolán McNamara wrote:

There's something odd here, RestoreConfigDefaults_Impl is supposed to
basically do the right thing, reset the values to their defaults, but
the cast of m_xConfigurationUpdateAccess to an XPropertyState throws in
SvxProxyTabPage::ReadConfigDefaults_Impl and
SvxProxyTabPage::RestoreConfigDefaults_Impl so all of that reset is
skipped/non-functional.

Looking into configmgr I don't see any mention of XPropertyState in the
list of things an Access supports. Though I do see a mention in (the
unbuilt) configmgr/qa/unit/test.cxx of
//TODO: support setPropertyToDefault

caolanm->sb: What's the story with XPropertyState and
configmgr::Access ? Should Access support XPropertyState so the
XPropertyState stuff in optinet2.cxx works ?, or is it not supposed to
support XPropertyState and the stuff in optinet2.cxx should be changed ?


Sorry for the long delay.  I marked the initial mail for later 
consumption but then lost sight of it.  Looking into this now, it 
appears that was a deliberate act of my subconscious...


See .

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

Re: Disabling Temporary Files?

2012-02-28 Thread Michael Stahl

On 28/02/12 19:46, Marc-André Laverdière wrote:
> Hello,
> 
> I need to ensure that data confidentiality.

i don't believe that the completely undisciplined use of temp files in
the historic OpenOffice.org code base is conductive to this goal; it
would probably be a good idea to investigate encrypted file systems, at
least for /home and /tmp or whatever the equivalent is on Windows (also,
you want to ensure that swap/pagefile is on encrypted storage).

regards,
 michael

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

Re: Disabling Temporary Files?

2012-02-28 Thread Marc-André Laverdière

Hello,

I need to ensure that data confidentiality.

Marc-André LAVERDIÈRE
"Perseverance must finish its work so that you may be mature and complete,
not lacking anything." -James 1:4
http://asimplediscipleslife.blogspot.com/
mlaverd.theunixplace.com




2012/2/27 Michael Meeks :
> Hi Marc,
>
> On Mon, 2012-02-27 at 04:15 -0500, Marc-André Laverdière wrote:
>> I am working on something for which we want the document to stay in
>> memory, with no temp file on disk.
>
>        Ho hum ;-)
>
>> And the result is that we have a temporary file in
>> C:\Users\meh\AppData|local\Temp\
>
>        Sounds normal, -hopefully- the properties on that file are such that
> only the user can read/write them - otherwise we have a bigger problem.
>
>> Is there any PropertyValue that we can set that will disable all
>> temporary files?
>
>        It seems unlikely - we rely on tmp files quite heavily in a number of
> situations I think. Of course - we could try collecting those all
> together behind one API in sal/ and then using an in-memory storage
> instead I guess but ...
>
>        Why do you want to keep them off the oxide ?
>
>        Sorry,
>
>                Michael.
>
> --
> michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Checking string allocations (was Re: String literals, ASCII vs UTF-8)

2012-02-28 Thread Lubos Lunak

On Tuesday 28 of February 2012, Eike Rathke wrote:
> On Tuesday, 2012-02-28 16:37:38 +, Michael Meeks wrote:
> > Of course, on the very rare
> > occasions that we do a huge allocation for a string - perhaps we store
> > an entire VBA module in a single string or something silly ;-)
>
> As soon as Calc will use OUString instead of String for cell content and
> formula results exactly that will happen..
>
> I've seen Calc abused as a front end for some sort of web CMS, holding
> entire HTML "template" fragments in one cell ... complaint was that not
> more than 64k characters would fit into a formula result when
> concatenating those ...

> > which
> > might reasonably fail, then no doubt we could use the native C method,
> > and act accordingly if it failed.
>
> I doubt anyone would actually do that, so we could only hope for memory
> allocation exiting the application gracefully in that case.

 I think that is the real question. I've just found out that e.g. openSUSE 
12.1 in fact has memory overcommitting disabled by default, so such checks 
actually can work and would detect running out of memory. But I doubt anybody 
would be realistically bothered to check that these days.

 Even if the OUString ctor throws std::bad_alloc, there's unlikely any code 
catching it, except for some generic catch(), which perhaps may recover from 
it, or may not. And even if yes, the next time the larger string can cause 
running out of memory when appending to OUStringBuffer, when invokend with 
OUString's operator+, or any other of those functions that OSL_ENSURE the 
allocation result and are done with it.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: String literals, ASCII vs UTF-8

On Tue, 2012-02-28 at 18:40 +0100, Eike Rathke wrote:
> As soon as Calc will use OUString instead of String for cell content and
> formula results exactly that will happen..

:-)

> I've seen Calc abused as a front end for some sort of web CMS, holding
> entire HTML "template" fragments in one cell ... complaint was that not
> more than 64k characters would fit into a formula result when
> concatenating those ...

Sure - so, then I guess we need to be slightly careful about those code
paths.

> People also complained about Writer paragraphs being limited to 64k
> characters ... that's ~15 pages of eye-tiring continuous lines, but ...

Right - but - what failure mode are we going to have here ? so we
manage somehow to catch a std::bad_alloc exception - what do we do
then ? beyond hitting something like the crash handler it's hard to know
what: refusing to load the document, discarding existing document
state ? [ do we want a "per document crash" functionality ? ;-]

> I doubt anyone would actually do that, so we could only hope for memory
> allocation exiting the application gracefully in that case.

Sure - no doubt we'll get a NULL pointer back at some stage and
beautifully de-reference it ;-) so - I don't know that even the dumb
things that people use writer / calc for justify the exception - unless
we have some sensible and user-comprehensible strategy for cleaning up
after it.

All the best,

Michael.

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

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

Re: String literals, ASCII vs UTF-8

2012-02-28 Thread Olivier Hallot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi gentlemen

Em 28-02-2012 14:40, Eike Rathke escreveu:
> People also complained about Writer paragraphs being limited to 64k
> characters ... that's ~15 pages of eye-tiring continuous lines, but ...

https://issues.apache.org/ooo/show_bug.cgi?id=17171

That one hurted me in portuguese/spanish judiciary/legal documents,
where secular tradition prevents writing with banks/white "spaces" in
the document (my guess: to not allow adding text in these "holes").

This is a bug I really care about.

A layman question: will OString/OUString replacements address this issue?

Of course, this issue does not exist "elsewhere".

Thanks
- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPTRf8AAoJEJp3R7nH3vLxcbAIAJ7DbLakcgJBtDcQcvp1+BVi
wUGCj8fNZDlopyM2o740/Q9Fs3rHyZfUIVxObNvZ40h+406+RtsZ9i7TvvYMZjnj
RPRooOF0Ao4Xm5DhQHoO7F03RnHP7DWn0lz0YjZKzyGfwF2ZAueKwp1b8KCM3R63
fRkn5VzXKXLKmSJ8xgjNwNFf305VtZR+wEsk/ph59MZKo1EjzMpMWjqGC/jcxeh8
3wJPQrF/ytSY1ji7U5yX5F1aIBJ1YeIANnRVXuiJOenw1+UAhGo+KoD/NIOWuQYd
nCf5NY+PjY5YW0AP71Q/l5Xa3Dm3Je/IjpSVofGPuytqcRZFhYAGNV4Yu2ssfUY=
=skZu
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] fdo#46193: Let the user copy error message from error dialog

2012-02-28 Thread Dézsi Szabolcs


Hello!

I created a new class in cui/. : CopyableWarningBox (copywarnbox.hxx and
copywarnbox.cxx). This class gets instantiated in
cui/source/dialogs/scriptdlg.cxx (last method).

I couldn't manage to do the sizing dynamically, so it creates a fix (500*300)
dialog.

To test the dialog run ./soffice. Tools/Macros/Run Macro...
Expand LibreOffice Macros/Gimmicks/GetTexts and run GetCellTexts.

Szabolcs
  From 1c0c3a082e65b1cab77dc6a86c3849b98b3b9f7a Mon Sep 17 00:00:00 2001
From: Szabolcs Dezsi 
Date: Tue, 28 Feb 2012 19:40:14 +0100
Subject: [PATCH] Selectable text in error dialogs (when macros fail etc.)

---
 cui/Library_cui.mk |1 +
 cui/source/dialogs/copywarnbox.cxx |   53 
 cui/source/dialogs/scriptdlg.cxx   |   10 +++---
 cui/source/inc/copywarnbox.hxx |   51 ++
 4 files changed, 110 insertions(+), 5 deletions(-)
 create mode 100644 cui/source/dialogs/copywarnbox.cxx
 create mode 100644 cui/source/inc/copywarnbox.hxx

diff --git a/cui/Library_cui.mk b/cui/Library_cui.mk
index 516c68c..e17e009 100644
--- a/cui/Library_cui.mk
+++ b/cui/Library_cui.mk
@@ -93,6 +93,7 @@ $(eval $(call gb_Library_add_exception_objects,cui,\
 cui/source/dialogs/about \
 cui/source/dialogs/colorpicker \
 cui/source/dialogs/commonlingui \
+cui/source/dialogs/copywarnbox \
 cui/source/dialogs/cuicharmap \
 cui/source/dialogs/cuifmsearch \
 cui/source/dialogs/cuigaldlg \
diff --git a/cui/source/dialogs/copywarnbox.cxx b/cui/source/dialogs/copywarnbox.cxx
new file mode 100644
index 000..46e3525
--- /dev/null
+++ b/cui/source/dialogs/copywarnbox.cxx
@@ -0,0 +1,53 @@
+/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+/*
+ *
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * Copyright 2000, 2010 Oracle and/or its affiliates.
+ *
+ * OpenOffice.org - a multi-platform office productivity suite
+ *
+ * This file is part of OpenOffice.org.
+ *
+ * OpenOffice.org is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License version 3
+ * only, as published by the Free Software Foundation.
+ *
+ * OpenOffice.org is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License version 3 for more details
+ * (a copy is included in the LICENSE file that accompanied this code).
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * version 3 along with OpenOffice.org.  If not, see
+ * 
+ * for a copy of the LGPLv3 License.
+ *
+ /
+
+// include ---
+
+#include "copywarnbox.hxx"
+
+CopyableWarningBox::CopyableWarningBox( Window* pParent, const XubString& title, const XubString& rMessage ) :
+SfxModalDialog  ( pParent,  0 ),
+aMessage( this, WB_NOBORDER | WB_AUTOVSCROLL | WB_WORDBREAK ),
+aOKButton   ( this, BUTTON_OK )
+{
+SetText( title );
+
+aMessage.SetPaintTransparent( sal_True );
+aMessage.SetReadOnly();
+aMessage.SetText( rMessage );
+aMessage.SetPosPixel( Point( 10, 10 ) );
+aMessage.SetSizePixel( Size( 500, 300 ) );
+
+SetSizePixel( Size( aMessage.GetSizePixel().Width() + 20, aMessage.GetSizePixel().Height() + 60 ) );
+aOKButton.SetPosSizePixel( Point( (GetSizePixel().Width() / 2) - 25, aMessage.GetSizePixel().Height() + 10 ), Size( 50, 30 ) );
+
+aMessage.Show();
+aOKButton.Show();
+}
+
+/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/cui/source/dialogs/scriptdlg.cxx b/cui/source/dialogs/scriptdlg.cxx
index 0970951..2f37ddd 100644
--- a/cui/source/dialogs/scriptdlg.cxx
+++ b/cui/source/dialogs/scriptdlg.cxx
@@ -67,6 +67,8 @@
 #include 
 #include 
 
+#include "copywarnbox.hxx"
+
 using namespace ::com::sun::star;
 using namespace ::com::sun::star::uno;
 using namespace ::com::sun::star::script;
@@ -1574,11 +1576,9 @@ IMPL_LINK( SvxScriptErrorDialog, ShowDialog, ::rtl::OUString*, pMessage )
 message = String( CUI_RES( RID_SVXSTR_ERROR_TITLE ) );
 }
 
-MessBox* pBox = new WarningBox( NULL, WB_OK, message );
-pBox->SetText( CUI_RES( RID_SVXSTR_ERROR_TITLE ) );
-pBox->Execute();
-
-delete pBox;
+Dialog* pDlg = new CopyableWarningBox( NULL, CUI_RES( RID_SVXSTR_ERROR_TITLE ), message );
+pDlg->Execute();
+delete pDlg;
 delete pMessage;
 
 return 0;
diff --git a/cui/source/inc/copywarnbox.hxx b/cui/source/inc/copywarnbox.hxx
new file mode 100644
index 000..9ffc635
--- /dev/null
+++ b/cui/source/inc/copywarnbox.hxx
@@ -0

Re: String literals, ASCII vs UTF-8

Hi Michael,

On Tuesday, 2012-02-28 16:37:38 +, Michael Meeks wrote:

> Of course, on the very rare
> occasions that we do a huge allocation for a string - perhaps we store
> an entire VBA module in a single string or something silly ;-)

As soon as Calc will use OUString instead of String for cell content and
formula results exactly that will happen..

I've seen Calc abused as a front end for some sort of web CMS, holding
entire HTML "template" fragments in one cell ... complaint was that not
more than 64k characters would fit into a formula result when
concatenating those ...

People also complained about Writer paragraphs being limited to 64k
characters ... that's ~15 pages of eye-tiring continuous lines, but ...

> which
> might reasonably fail, then no doubt we could use the native C method,
> and act accordingly if it failed.

I doubt anyone would actually do that, so we could only hope for memory
allocation exiting the application gracefully in that case.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

pgpoSMXiuBN0A.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED 3-5][PUSHED 3-5-1]UI fix on PDF export dialog fdo#45023

2012/2/28 Eike Rathke :
> Hi,
>
> On Tuesday, 2012-02-28 13:58:07 +, Caolán McNamara wrote:
>
>> On Tue, 2012-02-28 at 13:41 +, Michael Meeks wrote:
>> >     screenshots are super-helpful for review; two more for -3-5-1 ?
>>
>> Sure, +1
>
> Pushed to 3-5-1
> http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-1&id=f009ee83af38d33299133878f760cbb0e97a9566
>
> I'm not sure about this, but it might be that the resulting line
> height/spacing is too narrow for CJK fonts, someone with a CJK UI build
> should check.

I checked zh-TW and ja, and they look OK. Dimensions are proprotional
to font size (in theory).

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

Re: [PUSHED 3-5][REVIEW 3-5-1]UI fix on PDF export dialog fdo#45023

Hi,

On Tuesday, 2012-02-28 13:58:07 +, Caolán McNamara wrote:

> On Tue, 2012-02-28 at 13:41 +, Michael Meeks wrote:
> > screenshots are super-helpful for review; two more for -3-5-1 ?
> 
> Sure, +1

Pushed to 3-5-1
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-1&id=f009ee83af38d33299133878f760cbb0e97a9566

I'm not sure about this, but it might be that the resulting line
height/spacing is too narrow for CJK fonts, someone with a CJK UI build
should check.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpp7iqeht5Gi.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: String literals, ASCII vs UTF-8


On Tue, 2012-02-28 at 14:48 +0100, Lubos Lunak wrote:
>  Speaking of the size at the call-site, I good part is the code trying to 
> throw std::bad_alloc in case the allocation fails. That actually looks rather 
> useless to me, for several reasons:
> 
> - not all OUString methods check for this anyway
> - rtl_uString* functions do OSL_ASSERT() after allocations
> - with today's systems (overcommitting, etc.) it is rather pointless to guard 
> against allocation failures
> 
>  Does somebody see a good reason not to just remove it?

Not me :-) I'd love to kill that cruft. Of course, on the very rare
occasions that we do a huge allocation for a string - perhaps we store
an entire VBA module in a single string or something silly ;-) which
might reasonably fail, then no doubt we could use the native C method,
and act accordingly if it failed.

So - I'd love to remove this compound source of bloat and if we're
indeed deeply worried about out of memory crashes, then doing a better
job of logging and journaling user input as it's entered so we can
replay it later if necessary ;-)

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: JUnit sc_complex fails in Localized enviroment

2012-02-28 Thread Markus Mohrhard

2012/2/28 Stephan Bergmann :
> On 02/28/2012 11:38 AM, Markus Mohrhard wrote:
>>
>> Let me take this over. I think that we might miss a step in our java
>> tests that forces the some parts of formulas. We had problems with
>> this already in our c++ based tests but were able to force them to
>> en-US too.
>>
>> I think this might be another case that we need to force it like in
>> test/source/bootstrapfixture.cxx:95 and 96
>
>
> Not sure if something like that can also be done from remote (which would be
> necessary for that sc_complex test).  Setting LC_ALL within the relevant
> makefile is possible, but can get nasty wrt multi-platform. (Another option
> would be to migrate that test from a qadevOOo based one to a single-process
> one.)

This is not the only qaDevOOo test that assumes en_US in calc. Nearly
all tests aussme it in some way, either in sheet names, separators,
date formatting, ... I hope that there is a way to force this through
UNO.

>
>
>> IMHO it is not a good idea to change the tests so that they no longer
>> use the sheet names because we have them all over the place and it
>> will make the test code more complex tha necessary.
>
>
> That would of course keep the test failing for the OP with --with-lang
> lacking en-US.  Not sure if we want to support that, though.

It is not the only calc test failing if you build without en_US. I
think we once defined building with en_US as a requirement otherwise
we need to rethink the whole calc test concepts. They all assume that
en_US is present and set. It is otherwise not possible to test correct
import of anything (different formula names, different separator,
different default number formats, ...)

IMHO we should execute all tests in en_US and assume that everyone
builds with en_US.

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

Re: JUnit sc_complex fails in Localized enviroment


On 02/28/2012 11:38 AM, Markus Mohrhard wrote:

Let me take this over. I think that we might miss a step in our java
tests that forces the some parts of formulas. We had problems with
this already in our c++ based tests but were able to force them to
en-US too.

I think this might be another case that we need to force it like in
test/source/bootstrapfixture.cxx:95 and 96


Not sure if something like that can also be done from remote (which 
would be necessary for that sc_complex test).  Setting LC_ALL within the 
relevant makefile is possible, but can get nasty wrt multi-platform. 
(Another option would be to migrate that test from a qadevOOo based one 
to a single-process one.)



IMHO it is not a good idea to change the tests so that they no longer
use the sheet names because we have them all over the place and it
will make the test code more complex tha necessary.


That would of course keep the test failing for the OP with --with-lang 
lacking en-US.  Not sure if we want to support that, though.


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

Re: [PATCH] fdo#33697 Unable to reset "System" as Internet Proxy mode. XPropertyState unsupported

2012-02-28 Thread jumbo444

Hello,


Caolán McNamara wrote
> 
> There's something odd here,

I don't know if my weak skills could help, but I noticed that the bug
appeared between OOo 3.2.1 and 3.3.0, and the code in Optinet2.cxx did not
change for SvxProxyTabPage except some SVX_ replaced by CUI_. So the
bug is not at the place I mentioned, but removing the return solve the
issue.

Laurent BP


-
LibreOffice 3.5.0
--
View this message in context: 
http://nabble.documentfoundation.org/PATCH-fdo-33697-Unable-to-reset-System-as-Internet-Proxy-mode-tp3767969p3784419.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

license permissions

2012-02-28 Thread Roman Shtylman

All of my past & future contributions to LibreOffice may be licensed under the 
MPL/LGPLv3+ dual license, including the go-oo code.

cheers,
~Roman Shtyman
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

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

--- Comment #205 from sasha.libreoff...@gmail.com 2012-02-28 07:14:35 PST ---
Printing problem on Windows 7. My be somebody can help to reproduce this or
understand source of problem or knows workaround:
Bug 44275 - Letter-size landscape 2-column Laser PRINTING bug

-- 
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 / go-oo license

2012-02-28 Thread Kálmán „KAMI” Szalai

Hi!

"All of my past & future contributions to LibreOffice may be licensed under the 
MPL/LGPLv3+ dual license, including the go-oo code."

Best regards,

KAMI




signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED 3-5-1] Fix for fdo#46074 "FILEOPEN: No Recent Documents..."

On Tue, Feb 28, 2012 at 12:44:33PM +, Michael Meeks wrote:
> > +1 for 3-5-1, some more required to get it pushed there.
> 
>   +1 from me too, one more required for 3.5.1

There you are:

 
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-1&id=8eb49978a2454c154e94588c9e0e53bcb110253d

Best,

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

Re: Question: How do I rasterize an SVG to a BitmapEx

2012-02-28 Thread Thorsten Behrens

Andrew Higginson wrote:
> Sorry still don't understand, what class is the aSvgData? :/
> 
Hi Andrew,

ah, that was a somewhat made-up example - uno::Sequence
for the methods I used there. But it really depends on how/where you
get your data read.

HTH,

-- Thorsten

pgpS75qAdVkhj.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

License Statement

2012-02-28 Thread Fridrich Strba

As I see many people doing this statement, I would also love to have my
15 seconds of fame with them:

I hereby declare that all my contributions to LibreOffice,
OpenOffice.org and GoOo were always under the tripple LGPL3+, GPL3+,
MPL1.1+.

Cheers

Fridrich

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

[PUSHED] n#695479 fix rtf/docx import of transparent frames


On Tue, 2012-02-28 at 09:42 +0100, Miklos Vajna wrote:
> Attached a backport of these commits to -3-5.

Thanks ! ack'd and pushed to -3-5

Michael.

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

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

[PUSHED] Reduced duplicate code (simian) / vcl/generic/print/glyphset.cxx

Hi Christina,

On Tue, 2012-02-28 at 11:07 +0100, Chr. Rossmanith wrote:
> here is the patch to reduce code which seems to be copy&pasted (cf. 
> Duplicate code: GlyphSet::DrawGlyphs() and GlyphSet::ImplDrawText() / 
> 27.2.2012)

Thanks for that - a beautiful clean, pushed :-)

[ how do you find such things ? ;-]

Incidentally, it'd be much appreciated if you could send a generic
MPL/LGPLv3+ license statement for all your contributions to the list, so
we can link you into:

http://wiki.documentfoundation.org/Development/Developers

Many thanks,

Michael.

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

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

Relicensing permission

2012-02-28 Thread Bernhard Rosenkränzer

As requested by Michael, with some extensions:

All of my past & future contributions to LibreOffice or any other
project sharing the same code base (including, but not limited to
OpenOffice.org) may be licensed under the MPL/LGPLv3+ dual license,
including the go-oo code.
Furthermore, they may be licensed under any other Open Source
compliant license TDF may adopt in the future (such as MPL/LGPLv4).

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

[REVIEW 3-5, 3-5-1] Make libxslt link the right libxml on mac ppc

2012-02-28 Thread Fridrich Strba

Here is the patch doing that for me.

Cheers

F.
>From d21fb3716721c9c52c242a3eff038314d82d66f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fridrich=20=C5=A0trba?= 
Date: Tue, 28 Feb 2012 14:54:20 +0100
Subject: [PATCH] make libxslt link with the right libxml

---
 libxslt/makefile.mk |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/libxslt/makefile.mk b/libxslt/makefile.mk
index cc89185..d21c0e3 100644
--- a/libxslt/makefile.mk
+++ b/libxslt/makefile.mk
@@ -86,6 +86,11 @@ CONF_ILIB=
 .ELSE
 CONF_ILIB=-L$(ILIB:s/;/ -L/)
 .ENDIF
+
+.IF "$(OS)"=="MACOSX" && "$(SYSTEM_LIBXML)" != "YES"
+LIBXML2LIB=-L$(SOLARLIBDIR) -lxml2
+.ENDIF
+
 CONFIGURE_FLAGS=--without-crypto --without-python --enable-static=no $(BUILD_AND_HOST) CC="$(xslt_CC)" CFLAGS="$(xslt_CFLAGS)" LDFLAGS="-Wl,--no-undefined -Wl,--enable-runtime-pseudo-reloc-v2 $(CONF_ILIB)" LIBS="$(xslt_LIBS)"  LIBXML2LIB=$(LIBXML2LIB) OBJDUMP=objdump
 BUILD_ACTION=chmod 777 xslt-config && $(GNUMAKE)
 BUILD_FLAGS+= -j$(EXTMAXPROCESS)
-- 
1.7.3.1

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

Re: [REVIEW][3.5]fdo#46531, spell checking display fun


On Tue, 2012-02-28 at 12:26 +, Caolán McNamara wrote:
> FWIW, the nastiness in that SpellDialog is that there are a bunch of
> things which would be natural to put directly into the ctor, but they
> would require calling virtual methods during construction, which doesn't
> work in c++, so there's some lame post-an-event hack and complete the
> construction steps that want to call virtuals in the event-callback
> which gets called on the next iteration of the main loop after the
> construction has completed.

Oh - that sounds pretty horrible lifecycle wise.

> Dialog is fragile and tricky :-(

So - given that the dialog was moved to cui, is not public, and has
only one constructor in the factory method - would something like the
appended clean that up rather pleasantly ?

Thoughts on the appended appreciated ...

All the best,

Michael.

diff --git a/cui/source/dialogs/SpellDialog.cxx 
b/cui/source/dialogs/SpellDialog.cxx
index cd9b273..8fe8036 100644
--- a/cui/source/dialogs/SpellDialog.cxx
+++ b/cui/source/dialogs/SpellDialog.cxx
@@ -284,9 +284,6 @@ SpellDialog::SpellDialog(
 // disable controls if service is missing
 if (!xSpell.is())
 Enable( sal_False );
-
-Application::PostUserEvent( STATIC_LINK(
-this, SpellDialog, InitHdl ) );
 }
 
 // ---
@@ -530,34 +527,33 @@ void SpellDialog::SpellContinue_Impl(bool 
bUseSavedSentence, bool bIgnoreCurrent
 /* Initialize, asynchronous to prevent virtial calls
from a constructor
  */
-IMPL_STATIC_LINK( SpellDialog, InitHdl, SpellDialog *, EMPTYARG )
+void SpellDialog::LateInit()
 {
-pThis->SetUpdateMode( sal_False );
+SetUpdateMode( sal_False );
 //show or hide AutoCorrect depending on the modules abilities
-pThis->aAutoCorrPB.Show(pThis->rParent.HasAutoCorrection());
-pThis->SpellContinue_Impl();
-pThis->aSentenceED.ResetUndo();
-pThis->aUndoPB.Enable(sal_False);
+aAutoCorrPB.Show(rParent.HasAutoCorrection());
+SpellContinue_Impl();
+aSentenceED.ResetUndo();
+aUndoPB.Enable(sal_False);
 
 // get current language
-pThis->UpdateBoxes_Impl();
+UpdateBoxes_Impl();
 
 // fill dictionary PopupMenu
-pThis->InitUserDicts();
-
-pThis->LockFocusChanges(true);
-if( pThis->aChangePB.IsEnabled() )
-pThis->aChangePB.GrabFocus();
-else if( pThis->aIgnorePB.IsEnabled() )
-pThis->aIgnorePB.GrabFocus();
-else if( pThis->aClosePB.IsEnabled() )
-pThis->aClosePB.GrabFocus();
-pThis->LockFocusChanges(false);
+InitUserDicts();
+
+LockFocusChanges(true);
+if( aChangePB.IsEnabled() )
+aChangePB.GrabFocus();
+else if( aIgnorePB.IsEnabled() )
+aIgnorePB.GrabFocus();
+else if( aClosePB.IsEnabled() )
+aClosePB.GrabFocus();
+LockFocusChanges(false);
 //show grammar CheckBox depending on the modules abilities
-pThis->aCheckGrammarCB.Check( pThis->rParent.IsGrammarChecking() );
-pThis->SetUpdateMode( sal_True );
-pThis->Show();
-return 0;
+aCheckGrammarCB.Check( rParent.IsGrammarChecking() );
+SetUpdateMode( sal_True );
+Show();
 };
 
 // ---
diff --git a/cui/source/factory/dlgfact.cxx b/cui/source/factory/dlgfact.cxx
index 5825421..c3f53e8 100644
--- a/cui/source/factory/dlgfact.cxx
+++ b/cui/source/factory/dlgfact.cxx
@@ -1184,6 +1184,7 @@ AbstractSpellDialog *  
AbstractDialogFactory_Impl::CreateSvxSpellDialog(
 svx::SpellDialogChildWindow* pSpellChildWindow )
 {
 svx::SpellDialog* pDlg = new svx::SpellDialog(pSpellChildWindow, pParent, 
pBindings);
+pDlg->LateInit();
 return new AbstractSpellDialog_Impl(pDlg);
 }
 
diff --git a/cui/source/inc/SpellDialog.hxx b/cui/source/inc/SpellDialog.hxx
index 71d502c..bf496c3 100644
--- a/cui/source/inc/SpellDialog.hxx
+++ b/cui/source/inc/SpellDialog.hxx
@@ -217,8 +217,6 @@ private:
 DECL_LINK( DialogUndoHdl, SpellUndoAction_Impl* );
 DECL_LINK( HandleHyperlink, svt::FixedHyperlink * );
 
-DECL_STATIC_LINK( SpellDialog, InitHdl, SpellDialog * );
-
 voidStartSpellOptDlg_Impl();
 voidInitUserDicts();
 voidUpdateBoxes_Impl();
@@ -251,10 +249,10 @@ public:
 SfxBindings* pBindings);
 ~SpellDialog();
 
-voidSetLanguage( sal_uInt16 nLang );
-virtual sal_BoolClose();
-
-voidInvalidateDialog();
+void LateInit();
+void SetLanguage( sal_uInt16 nLang );
+virtual sal_Bool Close();
+void InvalidateDialog();
 };
 } //namespace svx
 


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

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

Re: [REVIEW 3-5][REVIEW 3-5-1] Fix for fdo#34669, lp#562027, deb#632920: Quickstarter breaks log out

Eh, wrong fdo bug reference in subject (fixed now, thanks Rene):

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

On Tue, Feb 28, 2012 at 02:38:29PM +0100, Bjoern Michaelsen wrote:
>  
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=5279616d50b0394e8ec6d8e2109471ca649412b7

Best,

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

Re: [PUSHED][PATCH] Remove unused code in BiffInputStream

On Mon, 2012-02-27 at 21:10 +0100, Santiago Martinez wrote:
> Hi, i'm not sure if this patch is correct so please review. I deleted
> BiffInputStream::sizeBase(), skipByteString(bool) and skipUniString()
> methods listed in unusedcode.easy. But also deleted another two
> methods (skipUniStringBody and skipUniStringChars ) because these two
> methods are used only by previously deleted methods. 

Looks fine, pushed now. Thanks for these. The next respin of
unusedcode.easy would have picked them up, but looks fine.

C.


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

Re: [PUSHED][PATCH] Remove unused code in BiffObjLineModel

On Mon, 2012-02-27 at 20:10 +0100, Santiago Martinez wrote:
> This patch removes unused code as listed in unusedcode.easy

Looks good, pushed now, thanks for this.

C.

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

Re: [PUSHED 3-5][REVIEW 3-5-1]UI fix on PDF export dialog fdo#45023

On Tue, 2012-02-28 at 13:41 +, Michael Meeks wrote:
>   screenshots are super-helpful for review; two more for -3-5-1 ?

Sure, +1

C.

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

Re: [PATCH] Translated german comments in sw/source/core/layout/

2012-02-28 Thread David Vogt


On 28/02/12 14:46, Philipp Weissenbacher wrote:
> So what's the status of these patches?
> 
> Have all been reviewed and pushed by now?

Yes :) Look here:

http://lists.freedesktop.org/archives/libreoffice/2012-February/027098.html

-- Dave

-- 
Adfinis SyGroup AG
David Vogt, Software Engineer / Project Manager
Keltenstrasse 98 | CH-3018 Bern
Tel. 031 381 70 47 | Direct 031 550 31 12



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED][REVIEW:3-5-1] do not pack stdlibs twice (fdo#46658)

On Mon, 2012-02-27 at 15:39 +, Michael Meeks wrote:
> One more review required.
> 
> On Mon, 2012-02-27 at 14:44 +0100, Stephan Bergmann wrote:
> > Pushed to libreoffice-3-5 as 216e30277b06124822cccdc2a6d46de57a2f8e6e, 
> > more reviews needed for libreoffice-3-5-1.
> 
>   Trivial patch, ack from me.

pushed to 3-5-1

C.

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

Re: String literals, ASCII vs UTF-8

2012-02-28 Thread Lubos Lunak

On Tuesday 28 of February 2012, Michael Meeks wrote:
>   I would really prefer to use a new:
>
> rtl_uString_newFromAsciiL( &pNew, literal, N - 1 );

 Attached.

>   method - which should shrink the call-site, and allow for a rather
> better implementation vs.


 Speaking of the size at the call-site, I good part is the code trying to 
throw std::bad_alloc in case the allocation fails. That actually looks rather 
useless to me, for several reasons:

- not all OUString methods check for this anyway
- rtl_uString* functions do OSL_ASSERT() after allocations
- with today's systems (overcommitting, etc.) it is rather pointless to guard 
against allocation failures

 Does somebody see a good reason not to just remove it?

-- 
 Lubos Lunak
 l.lu...@suse.cz
From e1e3406cb73559c7760f0e28965a8bb0c4c19b4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= 
Date: Tue, 28 Feb 2012 13:09:46 +0100
Subject: [PATCH 1/2] rtl_uString_newFromAscii_WithLength() and use it in OUString

---
 sal/inc/rtl/ustring.h  |   10 ++
 sal/inc/rtl/ustring.hxx|4 ++--
 sal/rtl/source/ustring.cxx |   10 +-
 sal/util/sal.map   |1 +
 4 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/sal/inc/rtl/ustring.h b/sal/inc/rtl/ustring.h
index 03f145b..80703f8 100644
--- a/sal/inc/rtl/ustring.h
+++ b/sal/inc/rtl/ustring.h
@@ -1243,6 +1243,16 @@ SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromStr_WithLength(
 SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromAscii(
 rtl_uString ** newStr, const sal_Char * value ) SAL_THROW_EXTERN_C();
 
+/** Allocate a new string that contains a copy of a character array.
+
+This is equivalent to rtl_uString_newFromAscii(), except that
+length of the character array is explicitly passed to the function.
+
+@since 3.6
+ */
+SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromAscii_WithLength(
+rtl_uString ** newStr, const sal_Char * value, sal_Int32 len ) SAL_THROW_EXTERN_C();
+
 /** Allocate a new string from an array of Unicode code points.
 
 @param newString
diff --git a/sal/inc/rtl/ustring.hxx b/sal/inc/rtl/ustring.hxx
index b74cd37..151e0a2 100644
--- a/sal/inc/rtl/ustring.hxx
+++ b/sal/inc/rtl/ustring.hxx
@@ -184,7 +184,7 @@ public:
 OUString( const char (&literal)[ N ] )
 {
 pData = 0;
-rtl_string2UString( &pData, literal, N - 1, RTL_TEXTENCODING_ASCII_US, 0 );
+rtl_uString_newFromAscii_WithLength( &pData, literal, N - 1 );
 if (pData == 0) {
 #if defined EXCEPTIONS_OFF
 SAL_WARN("sal", "std::bad_alloc but EXCEPTIONS_OFF");
@@ -338,7 +338,7 @@ public:
 template< int N >
 OUString& operator=( const char (&literal)[ N ] )
 {
-rtl_string2UString( &pData, literal, N - 1, RTL_TEXTENCODING_ASCII_US, 0 );
+rtl_uString_newFromAscii_WithLength( &pData, literal, N - 1 );
 if (pData == 0) {
 #if defined EXCEPTIONS_OFF
 SAL_WARN("sal", "std::bad_alloc but EXCEPTIONS_OFF");
diff --git a/sal/rtl/source/ustring.cxx b/sal/rtl/source/ustring.cxx
index 7c99758..763d9c5 100644
--- a/sal/rtl/source/ustring.cxx
+++ b/sal/rtl/source/ustring.cxx
@@ -471,6 +471,14 @@ void SAL_CALL rtl_uString_newFromAscii( rtl_uString** ppThis,
 else
 nLen = 0;
 
+rtl_uString_newFromAscii_WithLength( ppThis, pCharStr, nLen );
+}
+
+void SAL_CALL rtl_uString_newFromAscii_WithLength( rtl_uString** ppThis,
+const sal_Char* pCharStr,
+sal_Int32 nLen )
+SAL_THROW_EXTERN_C()
+{
 if ( !nLen )
 {
 IMPL_RTL_STRINGNAME( new )( ppThis );
@@ -489,7 +497,7 @@ void SAL_CALL rtl_uString_newFromAscii( rtl_uString** ppThis,
 {
 /* Check ASCII range */
 SAL_WARN_IF( ((unsigned char)*pCharStr) > 127, "rtl.string",
-"rtl_uString_newFromAscii - Found char > 127" );
+"rtl_uString_newFromAscii_WithLength - Found char > 127" );
 
 *pBuffer = *pCharStr;
 pBuffer++;
diff --git a/sal/util/sal.map b/sal/util/sal.map
index d6c3ab1..5ee60b9 100644
--- a/sal/util/sal.map
+++ b/sal/util/sal.map
@@ -305,6 +305,7 @@ UDK_3_0_0 {
 rtl_uString_newFromStr;
 rtl_uString_newFromStr_WithLength;
 rtl_uString_newFromAscii;
+rtl_uString_newFromAscii_WithLength;
 rtl_uString_newFromString;
 rtl_uString_newReplace;
 rtl_uString_newReplaceStrAt;
-- 
1.7.3.4

From 81117980acf002a35ebee69c5964e5595cecb4c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= 
Date: Tue, 28 Feb 2012 14:39:41 +0100
Subject: [PATCH 2/2] remove std::bad_alloc() throwing in some OUString functions

Not all OUString functions check this, rtl_uString* functions
usually assert on allocations, and checking for allocation failures
with memory overcommitting is pointless anyway. This way it just
creates useless code that is expande

Re: [PATCH] Translated german comments in sw/source/core/layout/

2012-02-28 Thread Philipp Weissenbacher

So what's the status of these patches?

Have all been reviewed and pushed by now?

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

[PUSHED 3-5][REVIEW 3-5-1]UI fix on PDF export dialog fdo#45023

On Tue, 2012-02-28 at 14:10 +0100, Andras Timar wrote:
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=e54773aa64af28795155aa55b3179141ca904f12
> Half of the help text was cut in German UI.

Thanks ! pushed to 3-5, the:

before: https://bugs.freedesktop.org/attachment.cgi?id=55896
after:  https://bugs.freedesktop.org/attachment.cgi?id=57764

screenshots are super-helpful for review; two more for -3-5-1 ?

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: String literals, ASCII vs UTF-8


On 02/28/2012 12:30 PM, Lubos Lunak wrote:

  The reason for this is that I have patches adding more functions taking
string literals and there it makes much more sense to require only ASCII. For
example OUString::operator== can be simply a call to OUString::equalsAsciiL()
for ASCII, but for UTF-8 it requires a conversion and unicode comparison.


Yes.


PS: Any idea why ' OUString foo() { return "foo";} ' does not work, even
though the ctor is not explicit? I can't recall a reason why a return value
would need to be different from the other cases.


Looks like a GCC error to me.

  struct S { S(char const (&)[2]); };
  S f() { return "a"; }

compiles just fine with recent Clang and 
, but fails with


  could not convert ‘(const char*)"a"’ from ‘const char*’ to ‘S’

on GCC.

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

[REVIEW 3-5][REVIEW 3-5-1] Fix for fdo#562027, lp#562027, deb#632920: Quickstarter breaks log out

Hi all,

please review:

 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5279616d50b0394e8ec6d8e2109471ca649412b7

fixing the longstanding issue with the quickstarter breaking logout.

Best,

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

Re: [PATCH] fdo#33697 Unable to reset "System" as Internet Proxy mode. XPropertyState unsupported

On Wed, 2012-02-22 at 13:45 -0800, jumbo444 wrote:
> Hello,
> 
> This patch remove a line preventing the saving of Internet Proxy "System"
> mode. It solves the problem described in fdo#33697.

There's something odd here, RestoreConfigDefaults_Impl is supposed to
basically do the right thing, reset the values to their defaults, but
the cast of m_xConfigurationUpdateAccess to an XPropertyState throws in
SvxProxyTabPage::ReadConfigDefaults_Impl and
SvxProxyTabPage::RestoreConfigDefaults_Impl so all of that reset is
skipped/non-functional.

Looking into configmgr I don't see any mention of XPropertyState in the
list of things an Access supports. Though I do see a mention in (the
unbuilt) configmgr/qa/unit/test.cxx of
//TODO: support setPropertyToDefault

caolanm->sb: What's the story with XPropertyState and
configmgr::Access ? Should Access support XPropertyState so the
XPropertyState stuff in optinet2.cxx works ?, or is it not supposed to
support XPropertyState and the stuff in optinet2.cxx should be changed ?

C.

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

Re: [Pushed] [PATCH] Clean-up and translation of German comments in ScTabPageSortFields

2012-02-28 Thread Muthu Subramanian K

Pushed. Thank you :)

On 02/21/2012 04:54 AM, Albert Thuswaldner wrote:
> Hi,
> This is just a small clean-up patch of files that I'm currently working on.
> 
> Regarding the translation effort I hope Christina is not working on
> these particular files:
> 
> http://wiki.documentfoundation.org/Development/Easy_Hacks/Translation_Of_Comments
> 
> I've put her in copy of this email.
> 
> Haven't sent a patch for a while (to much code reading/head scratching) ;)
> 
> /Albert
> 
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

Re: [PATCH] Removed unused code

2012-02-28 Thread Muthu Subramanian K

@all: Was wondering: Should we be removing the todo code, please?

On 02/26/2012 12:29 AM, Bartolomé Sánchez Salado wrote:
> Hello.
> 
> I've removed some unused virtual methods inside backends as Michael
> Meeks requested me:
> 
> http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg23796.html
> 
> after my first commit:
> 
> http://lists.freedesktop.org/archives/libreoffice-commits/2012-February/027928.html
> 
> Bartolomé Sánchez.
> 
> 
> 
> ___
> 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

[REVIEW 3-5][REVIEW 3-5-1]UI fix on PDF export dialog fdo#45023

Hi,

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e54773aa64af28795155aa55b3179141ca904f12
Half of the help text was cut in German UI.

Best regards,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW 3-5-1] Fix for fdo#46074 "FILEOPEN: No Recent Documents..."


On Tue, 2012-02-28 at 12:08 +, Caolán McNamara wrote:
> > "FILEOPEN: No Recent Documents..." and cherry-pick it to libreoffice-3-5 
> > and libreoffice-3-5-1.
> 
> Its an v. annoying bug, you know configmgr well, nothing jumps out at
> nuts, though its a little obscure to me. Pushed to 3-5.

Agreed - gave it a good read; having some centralised path management
would be really useful.

> +1 for 3-5-1, some more required to get it pushed there.

+1 from me too, one more required for 3.5.1

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: [REVIEW][3.5]fdo#46531, spell checking display fun

On Mon, 2012-02-27 at 17:07 +0100, Cedric Bosdonnat wrote:
> Hello people,
> 
> Could someone review and cherry-pick -s this commit into -3-5 branch?
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=adf45eced404c33be6db884a3e809725e7975872

FWIW, the nastiness in that SpellDialog is that there are a bunch of
things which would be natural to put directly into the ctor, but they
would require calling virtual methods during construction, which doesn't
work in c++, so there's some lame post-an-event hack and complete the
construction steps that want to call virtuals in the event-callback
which gets called on the next iteration of the main loop after the
construction has completed.

Dialog is fragile and tricky :-(

C.

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

Re: [Libreoffice] [REVIEW] problems with encryption if thunderbird is installed

On Thu, 2012-02-02 at 01:01 +0100, Markus Mohrhard wrote:
> 2012/1/27 Stephan Bergmann :
> > On 01/27/2012 12:11 AM, Markus Mohrhard wrote:
> >>
> >> - the problem is in
> >> connectivity/source/drivers/mozab/bootstrap/MNSInit.cxx:228-235
> >> -- the loop is sleeping for 1 ms and therefore running a thousand
> >> times per second without doing any real work because there are no
> >> events
> >>
> >> Since this also affects Loading of encrypted documents do we really
> >> need to initialize mozilla there? It should work now also without
> >> mozilla or am I missing something( see nssinitializer.cxx:197 ).
> >
> >
> > No idea.

So, we use nss for encrypting our docs under Linux and we also use nss
via xmlsec to xml-sign our docs under Linux. For signing we need to set
the certificate directory in order to show what certs we could sign
with. And nss gets to be initialized once, so on first-time signing or
encryption we set the cert dir. The cert dir is set as the appropiate
firefox profile dir, so we need to know the thunderbird/firefox profile
dir. We use the mozbootstrap stuff to find that and that launches xpcom
and this thread

That suggests that
a) this probably doesn't happen under Windows seeing as we don't backend
onto nss for xml signing there ?
b) this definitely shouldn't happen under MacOSX or under Linux with
system-mozilla because in those cases we use a minimal profile finder
thing which isn't sufficient to support the mozilla-address-book feature
but is sufficient to find the profile dir, and doesn't touch any xpcom
stuff

If we drop the mozilla-address-book support, life gets a lot easier and
we can just use the minimal-profile-finder throughout and all is simple.
If we retain the mozilla-address-book support perhaps we could use the
minimal-profile-finder to *find* the profiles and switch to the
heavy-weight xpcom code when we need to boot/use them in order to get
the mozilla-address-book (and ldap?) features up and running.

C.

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

Re: Most elegant way to disable all BASIC functionality?

Hi Eike,

2012/2/28 Eike Rathke :
> Hi Andras,
>
> On Monday, 2012-02-27 17:02:05 +0100, Andras Timar wrote:
>
>> 2012/2/27 Eike Rathke :
>> > If Security Level is set to Very High and no paths are added to Trusted
>> > Sources, then no BASIC is executed at all (which btw I strongly
>> > recommend as a developer loading bug documents from external sources).
>> > So maybe hard-wiring that setting for the App-Store and not offer the
>> > dialog would be enough?
>>
>> When I set Macro Security Very High, I can still run the Euro
>> Converter Wizard (written in Basic).
>
> I should had restricted "not at all" to "all basic calls emitted by
> a document" ;-)  where basic is called through
> SfxObjectShell::CallBasic()
>
> For functionality that we ship or extensions installed it should not
> matter which language they are written in?!?

I don't know... If I can modify that file (plain text, xml) on the
phone, I can do evil things that Apple didn't approve. Their point is
that all applications must come from the appstore. Extensions,
programmability, etc. are all evil in their eyes. But I know nothing
about iOS, maybe applications are protected and what I wrote is not
applicable.

Andras

>

I think extensions from external sources are also
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED][3-5-1] paste into draw from writer if writer doc has tables in header/footer -> kaboom

On Tue, 2012-02-28 at 10:46 +0200, Tor Lillqvist wrote:
> > Pushed to -3-5, two more reviews are needed for -3-5-1.
> +1 from me:
> Signed-off-by: Tor Lillqvist 

Doesn't look like it can cause any extra harm, so pushed to 3-5-1.

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: [REVIEWED][REVIEW 3-5][REVIEW 3-5-1] Fix for fdo#46074 "FILEOPEN: No Recent Documents..."

On Fri, 2012-02-24 at 18:05 +0100, Stephan Bergmann wrote:
> Please review master commit 
> 
>  
> "Resolves fdo#46074: Fix Partial::contains for paths that go past a leaf 
> node" that fixes  
> "FILEOPEN: No Recent Documents..." and cherry-pick it to libreoffice-3-5 
> and libreoffice-3-5-1.

Its an v. annoying bug, you know configmgr well, nothing jumps out at
nuts, though its a little obscure to me. Pushed to 3-5.

+1 for 3-5-1, some more required to get it pushed there.

C.

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

Re: Most elegant way to disable all BASIC functionality?

Hi Andras,

On Monday, 2012-02-27 17:02:05 +0100, Andras Timar wrote:

> 2012/2/27 Eike Rathke :
> > If Security Level is set to Very High and no paths are added to Trusted
> > Sources, then no BASIC is executed at all (which btw I strongly
> > recommend as a developer loading bug documents from external sources).
> > So maybe hard-wiring that setting for the App-Store and not offer the
> > dialog would be enough?
> 
> When I set Macro Security Very High, I can still run the Euro
> Converter Wizard (written in Basic).

I should had restricted "not at all" to "all basic calls emitted by
a document" ;-)  where basic is called through
SfxObjectShell::CallBasic()

For functionality that we ship or extensions installed it should not
matter which language they are written in?!?

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpijzEUSDxrn.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LIcensing of libwp* and its effect on that of libcdr and libvisio

2012-02-28 Thread Tor Lillqvist

> requires the result to be LGPL, the latter only has smaller requirements,
> which can be satisfied by providing a notice and our source code.

Providing source code (or pre-built object files even), is not enough,
necessarily.

I am thinking from the perspective of somebody wanting to distribute
an app using LibreOffice code, and potentially then also libwp* code,
on the iOS App Store. (LibreOffice itself I hope by then is LGPL/MPL,
MPL being the license that would be used in this case.)

As long as there is a risk that even one of the unknown number of
people holding copyright to libwp* doesn't approve of that, I wouldn't
suggest risking it... (The same holds for other LGPL libraries LO
potentially can use.)

It's not hard to interpret LGPLv2 so that it prevents that kind of
DRM-"encumbered" distribution of binaries. (After all, it was written
in frigging 1991.) No matter how good intent the app developer has,
how nicely he/she would provide source to everything , etc.

(Back in 1991 most compilers used on what was then normal desktop Unix
systems were definitely not free (in any sense), so the fact that iOS
development program membership (needed to distribute apps through the
App Store) costs €79/a is fairly irrelevant, I think, from LGPLv2's
point of view. It's the DRM and review process that somebody might say
is unacceptable. I think. But, IANAL.)

(And as for LGPLv3, it probably is even easier to interpret it in this
way, or perhaps one of its intents is specifically to prevent such
distribution? I say this based only on my prejudice and vague
knowledge of FSF's and their Dear Leader's opinions of Apple and their
ecosystem...)

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

Re: Trying to understand why LO seems freezed for some seconds when a module is started

2012-02-28 Thread Tommy

On Tue, 28 Feb 2012 11:56:53 +0100, Michael Meeks   
wrote:




On Mon, 2012-02-27 at 14:37 -0800, julien2412 wrote:
On 3.5 updated some days ago, here's the difference between the moment  
I open
Calc (so before freeze) and after the moment the freeze stops (once I  
typed

something) :


Great - so, loading / bootstrapping the python stuff is also something
of a problem it seems: urgh ! or perhaps ( as Tommy suggests )
autocorrect is implicated too.

snip




maybe there are 2 causes for that freeze.

if it may help you, I can tell that the freeze I experience has always  
been part

of old OOo/LibO releases and it's not a new thing for me in OOo 3.5.0

again, using a "virgin" portable LibreOffice 3.5 (  
http://www.winpenpack.com/main/download.php?view.1338 )

has no start-typing-freeze in my user experience.

the performace issue happens only when using a profile with my huge  
autocorrect database


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

Re: String literals, ASCII vs UTF-8


On Tue, 2012-02-28 at 12:30 +0100, Lubos Lunak wrote:
> RTL_CONSTASCII_USTRINGPARAM. While I was ambivalent about it, I now think we 
> should go with ASCII only, unless explicitly marked otherwise.

:-) your arguments make sense to me at least.

 OUString( const char (&literal)[ N ] )
 {
 pData = 0;
-rtl_string2UString( &pData, literal, N - 1, RTL_TEXTENCODING_UTF8, 
OSTRING_TO_OUSTRING_CVTFLAGS );
+rtl_string2UString( &pData, literal, N - 1, RTL_TEXTENCODING_ASCII_US, 
0 );

I would really prefer to use a new:

rtl_uString_newFromAsciiL( &pNew, literal, N - 1 );

method - which should shrink the call-site, and allow for a rather
better implementation vs.

rtl_impl_convertUStringToString

which has no fast-case for ASCII, and it requires these two extra
parameters we don't need to setup in each case :-)

Otherwise, this looks like some really nice work :-)

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: LIcensing of libwp* and its effect on that of libcdr and libvisio

2012-02-28 Thread Lubos Lunak

On Monday 27 of February 2012, Michael Meeks wrote:
> On Mon, 2012-02-27 at 20:00 +0200, Tor Lillqvist wrote:
> > The older libwpd, libwpg and libwps libraries are LGPLv2+ The newer
> > libcdr and libvisio libraries written in the same style are
> > MPL/LGPL.v+2/GPLv2+
> > However, as they depend on libwp* stuff, and link to them (statically)
> > or maybe include inline C++ code from libwp* headers, that is
> > irrelevant, isn't it, they effectively become LGPLv2+-only, too?
>
>   Linking statically might have an unintended licensing impact (IANAL),
> but my hope would be that we could re-work the (fairly small?) parts of
> libwp* that are required for libcdr / libvisio and/or persuade the
> authors to MPL dual license them, such that we can ship them on iOS :-)
> [ I assume that is the question behind the question ].

 IANAL either, but I think the linking mechanism on its own doesn't matter. 
AFAIK the LGPL distinguishes between a derived work of the library and work 
using the library, and our case should be the latter. While the sooner 
requires the result to be LGPL, the latter only has smaller requirements, 
which can be satisfied by providing a notice and our source code. 
Specifically, I think section 5 of LGPLv3 applies here.

 But the proper solution to this problem is finding somebody who can't say 
IANAL and thus should be able to provide a founded answer. I would be 
surprised if e.g. SUSE lawyers haven't run into this yet.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

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

Michael Meeks  changed:

   What|Removed |Added

 Depends on||34209

-- 
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: [PATCH] [3.5.1 and MASTER] Fix dialog controls size and position in the file preperties dialog

2012-02-28 Thread willubuntu


Michael Stahl-2 wrote
> 
> On 27/02/12 23:51, Riccardo Magliocchetti wrote:
> 
> indeed, and that is _especially_ true if you want your fix backported to
> a release branch; William, please post a no-whitespace fix for review.
> 

Don't pay attention to the indent /whitespace correction I did, it wasn't
the main purpose of my patch,
which I publish you now divided in two files:
-
http://nabble.documentfoundation.org/file/n3783713/0001-Fix-controls-size-and-position-on-the-document-infor.patch
PATCH for the size and position
(0001-Fix-controls-size-and-position-on-the-document-infor.patch) 

- http://nabble.documentfoundation.org/file/n3783713/0001-Fix-indent.patch
PATCH indent (0001-Fix-indent.patch) 

I won't waste my time anymore on the whitespace cleanup, I will just keep
focused on tab/indent problems I see when coding.
I just took the opportunity to correct them when reading the code, in order
to keep a coherence throughout the whole file which is mostly using 'foo(
bar )' style.

Regards,

William Gathoye

--
View this message in context: 
http://nabble.documentfoundation.org/PATCH-3-5-1-and-MASTER-Fix-dialog-controls-size-and-position-in-the-file-preperties-dialog-tp3782340p3783713.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

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

Bug 37361 depends on bug 46568, which changed state.

Bug 46568 Summary: VALGRIND corruption ( and sometimes coredump )
https://bugs.freedesktop.org/show_bug.cgi?id=46568

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

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

[PUSHED][REVIEWED 3-5-1] fdo#46568 - VALGRIND corruption


On Tue, 2012-02-28 at 10:00 +, Noel Power wrote:
> though it was too late for 3-5-1 but apparently not so changing subject 
> to reflect review status, thanks to Kohei just one review needed

Found reviewed by Eike & pushed :-)

Michael.

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

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

Re: [PUSHED][REVIEW 3-5-1] fdo#46568 - VALGRIND corruption

Hi Noel,

On Tuesday, 2012-02-28 10:00:11 +, Noel Power wrote:

> though it was too late for 3-5-1 but apparently not so changing
> subject to reflect review status, thanks to Kohei just one review
> needed

Pushed to 3-5-1
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-1&id=da7235196c138eed21065c94e2a855d6c3f217e0

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpNxHkBmweT5.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] [3.5.1 and MASTER] Fix dialog controls size and position in the file preperties dialog

2012-02-28 Thread Michael Stahl

On 27/02/12 23:51, Riccardo Magliocchetti wrote:
> Hello,
> 
> Il 27/02/2012 23:22, willubuntu ha scritto:
>> Hello guys,
> 
>>
>> I took also the opportunity to fix some indentation to get a consistent look
>> in code.
> 
> Usually is better to separate the behaviour changes from the whitespace 
> cleanup othwerwise it is difficult to see what you have actually changed 
> :) So if you could respin your patch fixing the bugs first it'll help 
> people reviewing your code.

indeed, and that is _especially_ true if you want your fix backported to
a release branch; William, please post a no-whitespace fix for review.

regards,
 michael

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

Re: Trying to understand why LO seems freezed for some seconds when a module is started

On Mon, 2012-02-27 at 14:37 -0800, julien2412 wrote:
> On 3.5 updated some days ago, here's the difference between the moment I open
> Calc (so before freeze) and after the moment the freeze stops (once I typed
> something) :

Great - so, loading / bootstrapping the python stuff is also something
of a problem it seems: urgh ! or perhaps ( as Tommy suggests )
autocorrect is implicated too.

The best way to 'profile' this (if it takes several seconds), is
usually to run and attach gdb from a separate remote machine; do the
thing that takes lots of time, and do a ctrl-c - then look at the
backtrace. I'd personally do that twice - once with some continues, so
press ctrl-c five time once per second for the 5 seconds [ basically
dumb sampling profiling ], and log the stack traces (with symbols).

Then I'd do it again, and type 'finish' in each method until it takes
several seconds to finish ;-) then you found the method that takes the
time.

It'd be great to get a bug opened to collect the detailed information
on this. Clearly we don't want such delays when you start typing.

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: Questions about LO BASIC's ObjectCatalog class.

2012-02-28 Thread Noel Power


Hi Tomcsik
On 28/02/12 08:46, Tomcsik Bence Tibor wrote:

Hello,


I want to modify the ObjectCatalog class to be able to dock left side 
of the window. 
http://opengrok.libreoffice.org/xref/core/basctl/source/basicide/objdlg.hxx#67
I like that idea ( and wanted to do that forever ) Have to say, in all 
my time I never even noticed this dialog :-)


The objdlg.src file contains lots of informations about positions and 
other things so if you change ObjectCatalog from FloatingWindow to 
BasicDockingWindow, then you have to deal with the rewrite of the 
objdlg.src file. 
http://opengrok.libreoffice.org/xref/core/basctl/source/basicide/objdlg.src

Is it possible to keep ObjectCatalog as FloatingWindow?
hrm, I have little clue about vcl but the name would suggest not, those 
other windows you mention ( Watch etc. ) are DockingWindows which seems 
necessary to do what you want, e.g. 'dock' :-) I doubt though that 
objdlg.src would need to change much, would it ? I mean other than 
changing the FloatingWindow to DockingWindow what do you need to change ?


So far I tried to change to BasicDockingWindow (and changed the 
constructor and source file too), but if I click on the Object Catalog 
button, the program stops.

looking at the stack or the core for that might through some light on it

I'd try changing the src file and see if that helps

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

Re: JUnit sc_complex fails in Localized enviroment

2012-02-28 Thread Markus Mohrhard

Hello Stephan,

2012/2/28 Stephan Bergmann :
> On 02/28/2012 08:47 AM, Stephan Bergmann wrote:
>>
>> On 02/27/2012 08:19 PM, Maciej Rumianowski wrote:
>>>
>>> I have build with pl and de languages and when I set all locale
>>> enviroment variables (LANG LC_*) to en_US.UTF-8 the test uses German
>>> language with output like:
>>
>>
>> So you configured --with-lang='pl de' (i.e., without any mention of
>> en-US), and your solver/*/installation/opt/program/resource/ directory
>> does not contain any *en-US.res files? That would explain it.
>
>
> For the record,
>
> cd sc && LC_ALL=de_DE.utf8 make
> /data/lo/core/workdir/unxlngx6/JunitTest/sc_complex/done
>
> suffices to make this fail for me in a --with-lang='en-US de' build.
>

Let me take this over. I think that we might miss a step in our java
tests that forces the some parts of formulas. We had problems with
this already in our c++ based tests but were able to force them to
en-US too.

I think this might be another case that we need to force it like in
test/source/bootstrapfixture.cxx:95 and 96

IMHO it is not a good idea to change the tests so that they no longer
use the sheet names because we have them all over the place and it
will make the test code more complex tha necessary.

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

Re: Trying to understand why LO seems freezed for some seconds when a module is started


On 02/28/2012 10:43 AM, Tommy wrote:

On Tue, 28 Feb 2012 09:14:06 +0100, Stephan Bergmann
 wrote:

But that's exactly the thing discussed in the recent "[PATCH] Reduced
loadtime of autocorrect tables" mail thread then, right?

Stephan


no, that thread was about loading time of the replacement table of
autocorrect (Ctrl+H)
shich has been fixed

this is about a freeze that happens at the start of each module
I suspect it can be a side effect of large autocorrect databases.


In which case Julien's lsof_diff.txt indicates that Python is loaded 
into the LO process at this point in time.


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

[PATCH] Reduced duplicate code (simian) / vcl/generic/print/glyphset.cxx

2012-02-28 Thread Chr. Rossmanith


Hi,

here is the patch to reduce code which seems to be copy&pasted (cf. 
Duplicate code: GlyphSet::DrawGlyphs() and GlyphSet::ImplDrawText() / 
27.2.2012)


Christina
>From 0c393ff76ec608817c51e228fa7e6c019d844c97 Mon Sep 17 00:00:00 2001
From: Christina Rossmanith 
Date: Tue, 28 Feb 2012 11:04:12 +0100
Subject: [PATCH] Reduced duplicate code (simian) / vcl/generic/print/glyphset.cxx

---
 vcl/generic/print/glyphset.cxx |   76 +++-
 vcl/generic/print/glyphset.hxx |3 +-
 2 files changed, 15 insertions(+), 64 deletions(-)

diff --git a/vcl/generic/print/glyphset.cxx b/vcl/generic/print/glyphset.cxx
index 5b03666..6d4cfde 100644
--- a/vcl/generic/print/glyphset.cxx
+++ b/vcl/generic/print/glyphset.cxx
@@ -479,7 +479,8 @@ void GlyphSet::DrawGlyphs(
   const sal_uInt32* pGlyphIds,
   const sal_Unicode* pUnicodes,
   sal_Int16 nLen,
-  const sal_Int32* pDeltaArray )
+  const sal_Int32* pDeltaArray,
+  const sal_Bool bUseGlyphs)
 {
 sal_uChar *pGlyphID= (sal_uChar*)alloca (nLen * sizeof(sal_uChar));
 sal_Int32 *pGlyphSetID = (sal_Int32*)alloca (nLen * sizeof(sal_Int32));
@@ -488,7 +489,10 @@ void GlyphSet::DrawGlyphs(
 // convert unicode to font glyph id and font subset
 for (int nChar = 0; nChar < nLen; nChar++)
 {
-GetGlyphID (pGlyphIds[nChar], pUnicodes[nChar], pGlyphID + nChar, pGlyphSetID + nChar);
+if (bUseGlyphs)
+GetGlyphID (pGlyphIds[nChar], pUnicodes[nChar], pGlyphID + nChar, pGlyphSetID + nChar);
+else
+GetCharID (pUnicodes[nChar], pGlyphID + nChar, pGlyphSetID + nChar);
 aGlyphSet.insert (pGlyphSetID[nChar]);
 }
 
@@ -536,7 +540,12 @@ void GlyphSet::DrawGlyphs(
 // show the text using the PrinterGfx text api
 aPoint.Move (nOffset, 0);
 
-OString aGlyphSetName(GetGlyphSetName(*aSet));
+OString aGlyphSetName;
+if (bUseGlyphs)
+aGlyphSetName = GetGlyphSetName(*aSet);
+else
+aGlyphSetName = GetCharSetName(*aSet);
+
 rGfx.PSSetFont  (aGlyphSetName, GetGlyphSetEncoding(*aSet));
 rGfx.PSMoveTo   (aPoint);
 rGfx.PSShowText (pGlyphSubset, nGlyphs, nGlyphs, nGlyphs > 1 ? pDeltaSubset : NULL);
@@ -614,66 +623,7 @@ GlyphSet::ImplDrawText (PrinterGfx &rGfx, const Point& rPoint,
 return;
 }
 
-sal_uChar *pGlyphID= (sal_uChar*)alloca (nLen * sizeof(sal_uChar));
-sal_Int32 *pGlyphSetID = (sal_Int32*)alloca (nLen * sizeof(sal_Int32));
-std::set< sal_Int32 > aGlyphSet;
-
-// convert unicode to font glyph id and font subset
-for (int nChar = 0; nChar < nLen; nChar++)
-{
-GetCharID (pStr[nChar], pGlyphID + nChar, pGlyphSetID + nChar);
-aGlyphSet.insert (pGlyphSetID[nChar]);
-}
-
-// loop over all glyph sets to detect substrings that can be xshown together
-// without changing the postscript font
-sal_Int32 *pDeltaSubset = (sal_Int32*)alloca (nLen * sizeof(sal_Int32));
-sal_uChar *pGlyphSubset = (sal_uChar*)alloca (nLen * sizeof(sal_uChar));
-
-std::set< sal_Int32 >::iterator aSet;
-for (aSet = aGlyphSet.begin(); aSet != aGlyphSet.end(); ++aSet)
-{
-Point aPoint  = rPoint;
-sal_Int32 nOffset = 0;
-sal_Int32 nGlyphs = 0;
-sal_Int32 nChar;
-
-// get offset to first glyph
-for (nChar = 0; (nChar < nLen) && (pGlyphSetID[nChar] != *aSet); nChar++)
-{
-nOffset = pDeltaArray [nChar];
-}
-
-// loop over all chars to extract those that share the current glyph set
-for (nChar = 0; nChar < nLen; nChar++)
-{
-if (pGlyphSetID[nChar] == *aSet)
-{
-pGlyphSubset [nGlyphs] = pGlyphID [nChar];
-// the offset to the next glyph is determined by the glyph in
-// front of the next glyph with the same glyphset id
-// most often, this will be the current glyph
-while ((nChar + 1) < nLen)
-{
-if (pGlyphSetID[nChar + 1] == *aSet)
-break;
-else
-nChar += 1;
-}
-pDeltaSubset [nGlyphs] = pDeltaArray[nChar] - nOffset;
-
-nGlyphs += 1;
-}
-}
-
-// show the text using the PrinterGfx text api
-aPoint.Move (nOffset, 0);
-
-OString aGlyphSetName(GetCharSetName(*aSet));
-rGfx.PSSetFont  (aGlyphSetName, GetGlyphSetEncoding(*aSet));
-rGfx.PSMoveTo   (aPoint);
-rGfx.PSShowText (pGlyphSubset, nGlyphs, nGlyphs, nGlyphs > 1 ? pDeltaSubset : NULL);
-}
+DrawGlyphs( rGfx, rPoint, NULL, pStr, nLen, pDeltaArray, sal_False);
 }
 
 sal_Bool
diff --git a/vcl/generic/print/glyphset.hxx b/vcl/generic

Re: Regarding development of a feature for Libreoffice Writer

2012-02-28 Thread Cedric Bosdonnat

On Tue, 2012-02-28 at 15:19 +0530, Atri Sharma wrote:
> The thrilling part of this project is more about in designing and
> implementing an innovative UI for navigating in the cliparts. The
> connection to openClipart has been implemented a few years ago. Even
> if
> it may need a small cleanup it shouldn't be the biggest part of the
> work.
>  
> 
> Need the UI system be completely graphic based?I mean,if we can
> implement a command line system which allows the user to type in a
> complete expression for e.g. 'Yellow and Round',we can search and rank
> the images accordingly and return the results.

Yes, the first thing to be done is the graphical UI part... as the
existing one is bloated and not fit for searching / tagging, etc.

Just to emphasize what I wrote before, the search will be delegated to a
backend we aren't maintaining. We may want to have some local backend...
but that'll come after the UI improvements.

--
Cedric

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

Re: [REVIEW 3-5-1] fdo#46568 - VALGRIND corruption

2012-02-28 Thread Noel Power

though it was too late for 3-5-1 but apparently not so changing subject 
to reflect review status, thanks to Kohei just one review needed


Noel
On 28/02/12 01:22, Kohei Yoshida wrote:

On Sat, 2012-02-25 at 18:36 +0100, Markus Mohrhard wrote:

Hello Noel,

2012/2/24 Noel Power:

please review the patch from master here, the detail ( valgrind and gdb
traces etc. ) already in the bug so I won't duplicate here
http://cgit.freedesktop.org/libreoffice/core/commit/?id=22871f1af3be444e747f7adaad5221b9c8b0bebf


This looks correct. It is a mistake by me that I did not think about
the UpdateCheck which will erase pData in parallel if one of the
checkboxes is modified.

Maybe the correct fix for master is to create an own handler for the
check boxes that will not erase the the range name but will think a
bit about it.

I'll give my sign-off for 3.5.1.  This is a trivial change that prevents
a crash.

One more needed to push this to the 3-5-1 branch.

Kohei



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

Re: JUnit sc_complex fails in Localized enviroment


On 02/28/2012 08:47 AM, Stephan Bergmann wrote:

On 02/27/2012 08:19 PM, Maciej Rumianowski wrote:

I have build with pl and de languages and when I set all locale
enviroment variables (LANG LC_*) to en_US.UTF-8 the test uses German
language with output like:


So you configured --with-lang='pl de' (i.e., without any mention of
en-US), and your solver/*/installation/opt/program/resource/ directory
does not contain any *en-US.res files? That would explain it.


For the record,

cd sc && LC_ALL=de_DE.utf8 make 
/data/lo/core/workdir/unxlngx6/JunitTest/sc_complex/done


suffices to make this fail for me in a --with-lang='en-US de' build.

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

Re: Trying to understand why LO seems freezed for some seconds when a module is started

2012-02-28 Thread Tommy

On Tue, 28 Feb 2012 09:14:06 +0100, Stephan Bergmann   
wrote:



On 02/28/2012 07:25 AM, Tommy wrote:

however I still confirm that the freeze has something to do with
autocorrection...

if you download this portable versione of LibO 3.5.0
http://www.winpenpack.com/main/download.php?view.1338

which comes out with a "virgin" user preset, you won't notice
any delay or freeze when starting modules... please, have your try!!!

on the other hand if I use the same package with my user preset which
is stuffed with a lot of autocorrect entries (I have 65000 in the
acor_.dat and other
62000 in the acor_it-IT.dat files) the freeze happens at each start
after digiting the first word.


But that's exactly the thing discussed in the recent "[PATCH] Reduced  
loadtime of autocorrect tables" mail thread then, right?


Stephan


no, that thread was about loading time of the replacement table of  
autocorrect (Ctrl+H)

shich has been fixed

this is about a freeze that happens at the start of each module
I suspect it can be a side effect of large autocorrect databases.

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

Re: Regarding development of a feature for Libreoffice Writer

2012-02-28 Thread Cedric Bosdonnat

Hi Atri,

On Tue, 2012-02-28 at 14:50 +0530, Atri Sharma wrote:
> So,basically,you mean that as many open source grammar checkers are
> available,I should not persue my concept?

You should leave that idea at least for GSoC. But I don't want to
discourage you to hack on it outside of GSoC. IMHO, it would be best to
contact people working on the existing FOSS grammar checkers to present
your idea.

> Actually,I talked to Kohei on IRC today and he seemed to like the
> idea.In fact,he said he'll talk to you about it.

Yes, he mailed me the whole IRC log.

> I was just going through the link you sent me.I think revamping the
> gallery tool would be a great thing as I can see that I can use many
> algorithms,techniques to build a fast and accurate system.We can
> design a system that allows more user flexiblity and we can allow the
> user to define more parameters for more accurate searching.The data
> can be stored in form of trees(that would lead to a fast search) and
> we can use other techniques for fast retrieval from various open
> sites.Later on,we can build an interface to the system that allows
> easy connectivity to any new open library.This will ensure continous
> addistion to our database.

I don't want to disappoint you, but the hard thing here isn't about
algorithms and searching. The point in that project to delegate the
storage / search to an online repository like openClipart.

The thrilling part of this project is more about in designing and
implementing an innovative UI for navigating in the cliparts. The
connection to openClipart has been implemented a few years ago. Even if
it may need a small cleanup it shouldn't be the biggest part of the
work.

I hope to have explained that topic a bit more.

--
Cedric

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

Re: [PUSHED:3-5-1] Reduced loadtime of autocorrect tables

2012-02-28 Thread Petr Mladek

Michael Meeks píše v Po 27. 02. 2012 v 12:40 +:
> On Mon, 2012-02-27 at 11:47 +, Caolán McNamara wrote:
> > Looks safe to me, +1
> 
>   And of course I love it ;-) so ... I cherry-picked it - thanks 
> Szabolcs :-)

Closing the thread clearly as pushed.

Best Regards,
Petr

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

Re: [PUSHED:3-4] fdo#31966: do not create an empty slide when printing handouts

2012-02-28 Thread Petr Mladek

Michael Meeks píše v Po 27. 02. 2012 v 13:19 +:
> On Mon, 2012-02-27 at 16:41 +0400, Ivan Timofeev wrote:
> > This bug was fixed in 3-5, but I didn't propose it for 3-4, and that was 
> > confusing to the bug reporter. So, taking into account the simplicity of 
> > the patch, I'd like to see it in 3-4. The patch for the "impress" 
> > repository is attached.
> 
>   Fair enough :-)
> 
> > Sorry if it is insignificant for that branch.
> 
>   It's not that significant, but it's a trivial fix so why not, as long
> as we don't set the expectation that every bug will be fixed in 3.4, so
> I pushed it :-)

Closing the thread as pushed.

Best Regards,
Petr

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

Re: [PUSHED][3.5]fdo#46531, spell checking display fun

2012-02-28 Thread Petr Mladek

Michael Meeks píše v Po 27. 02. 2012 v 16:44 +:
> On Mon, 2012-02-27 at 17:07 +0100, Cedric Bosdonnat wrote:
> > Could someone review and cherry-pick -s this commit into -3-5 branch?
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=adf45eced404c33be6db884a3e809725e7975872
> 
>   Pushed; thanks :-)

Marking the thread as pushed ;-)

Best Regards,
Petr

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

Re: Regarding development of a feature for Libreoffice Writer

2012-02-28 Thread Atri Sharma

Thanks Cedric.

So,basically,you mean that as many open source grammar checkers are
available,I should not persue my concept?
Actually,I talked to Kohei on IRC today and he seemed to like the idea.In
fact,he said he'll talk to you about it.

I was just going through the link you sent me.I think revamping the gallery
tool would be a great thing as I can see that I can use many
algorithms,techniques to build a fast and accurate system.We can design a
system that allows more user flexiblity and we can allow the user to define
more parameters for more accurate searching.The data can be stored in form
of trees(that would lead to a fast search) and we can use other techniques
for fast retrieval from various open sites.Later on,we can build an
interface to the system that allows easy connectivity to any new open
library.This will ensure continous addistion to our database.

Please let me know your thoughts about it.

Atri

On Tue, Feb 28, 2012 at 2:27 PM, Cedric Bosdonnat wrote:

> Hi Atri,
>
> On Tue, 2012-02-28 at 14:03 +0530, Atri Sharma wrote:
>
> > I went through LightProof,and I believe LightProof,in the motive for
> > being light,has a limited set of features.They are very useful,but not
> > complete(in my opinion).
>
> The idea of LightProof is to get results without false positives as we
> have with the usual grammar checkers.
>
> > I want to build a complete,'real' system that can actually understand
> > Grammer(sentence structures,grammatical categories etc).I understand
> > that will take a long time,but I assure you that,given enough time,I
> > should be able to design and implement the system.
>
> I don't think that is possible in the time frame of a Google Summer of
> Code. If you want to apply for GSoc, you should apply for something more
> reasonable.
>
> Your project should be an external (in the sense of not being part of
> LibreOffice core) tool / library. It's basically the same idea than
> other grammatical checkers... and I certainly don't want to mess up in
> that area as we already have several opensource ones.
>
> > Another thing,I was just wondering if I could put up a part of the
> > system as a project for GSoc?Or,if I could interface lightproof(with
> > some changes) as a project for GSoc?
>
> Once you have your project implemented as a separate tool / library,
> it's pretty easy to integrate it in LibreOffice. I don't think that
> would fit in a LibreOffice GSoc: integration is far too small and the
> whole thing is far too big.
>
> That being said, if you really want to hack on LibreOffice during the
> summer you can have a look at our GSoc ideas page here:
>
> https://wiki.documentfoundation.org/Development/Gsoc/Ideas
>
> I hope that helps,
>
> --
> Cedric
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED 3-5] duplicate fonts, one broken, one not, results in neither being detected


On 02/27/2012 12:50 PM, Caolán McNamara wrote:

i.e. https://bugs.freedesktop.org/show_bug.cgi?id=42901
and this commit to fix:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=65a3ec97b5032d1748c8f84eeb0b8656e1c25918

broken duplicate seen before working duplicate, first rejected for being
broken, second rejected for being a duplicate. So remove broken fonts as
we go along allowing non-broken duplicate fonts to be processed.


Looks good to me, pushed.

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

Re: Regarding development of a feature for Libreoffice Writer

2012-02-28 Thread Cedric Bosdonnat

Hi Atri,

On Tue, 2012-02-28 at 14:03 +0530, Atri Sharma wrote:

> I went through LightProof,and I believe LightProof,in the motive for
> being light,has a limited set of features.They are very useful,but not
> complete(in my opinion).

The idea of LightProof is to get results without false positives as we
have with the usual grammar checkers.

> I want to build a complete,'real' system that can actually understand
> Grammer(sentence structures,grammatical categories etc).I understand
> that will take a long time,but I assure you that,given enough time,I
> should be able to design and implement the system.

I don't think that is possible in the time frame of a Google Summer of
Code. If you want to apply for GSoc, you should apply for something more
reasonable.

Your project should be an external (in the sense of not being part of
LibreOffice core) tool / library. It's basically the same idea than
other grammatical checkers... and I certainly don't want to mess up in
that area as we already have several opensource ones.

> Another thing,I was just wondering if I could put up a part of the
> system as a project for GSoc?Or,if I could interface lightproof(with
> some changes) as a project for GSoc?

Once you have your project implemented as a separate tool / library,
it's pretty easy to integrate it in LibreOffice. I don't think that
would fit in a LibreOffice GSoc: integration is far too small and the
whole thing is far too big.

That being said, if you really want to hack on LibreOffice during the
summer you can have a look at our GSoc ideas page here:

https://wiki.documentfoundation.org/Development/Gsoc/Ideas

I hope that helps,

--
Cedric

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

Re: Regarding development of a feature for Libreoffice Writer

2012-02-28 Thread Olivier R.

Hi,

Atri Sharma wrote
>
> Do you think customizing lightproof(adding the user correctable feature)
> and customizing abiword's link parser for libreoffice is a good idea?

Lightproof provides basic tools for grammar checking. And it’s easy to
modify this tool.
On this basis, you can connect easily to the grammar API of LibreOffice and
you can retrieve informations on words through the spellchecker. There is
also other basic features.

As it is written in Python, it’s really easy to change that in a more
complex tool and create something really elaborate.
Grammalecte, the French grammar checker, is based on Lightproof, and at the
moment I’m adding a text preprocessor to clean sentences before grammar
checking. That’s not difficult.

The main problem you will have is to get a tagged Hunspell dictionary. May
be you could convert some other lexicon into a Hunspell dictionary, or you
could create a tool in Lighproof to read another lexicon. LanguageTool,
another grammar checker written in Java for LO, contains lexicons for many
languages.

I had never heard about the Abiword’s tool before today.

I was just musing if I can put it up for GsoC?

I don’t know.
Past year, there were a GsoC project for LanguageTool.

Regards,
Olivier

--
View this message in context:
http://nabble.documentfoundation.org/Regarding-development-of-a-feature-for-Libreoffice-Writer-tp3783143p3783381.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Questions about LO BASIC's ObjectCatalog class.

2012-02-28 Thread Tomcsik Bence Tibor

Hello,


I want to modify the ObjectCatalog class to be able to dock left side of
the window.
http://opengrok.libreoffice.org/xref/core/basctl/source/basicide/objdlg.hxx#67

The objdlg.src file contains lots of informations about positions and other
things so if you change ObjectCatalog from FloatingWindow to
BasicDockingWindow, then you have to deal with the rewrite of the
objdlg.src file.
http://opengrok.libreoffice.org/xref/core/basctl/source/basicide/objdlg.src
Is it possible to keep ObjectCatalog as FloatingWindow?

So far I tried to change to BasicDockingWindow (and changed the constructor
and source file too), but if I click on the Object Catalog button, the
program stops.

It would be great to achieve similar like here:
http://opengrok.libreoffice.org/xref/core/basctl/source/basicide/baside2.hxx#237



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

Re: [PUSHED][3-5] paste into draw from writer if writer doc has tables in header/footer -> kaboom

2012-02-28 Thread Tor Lillqvist

> Pushed to -3-5, two more reviews are needed for -3-5-1.

+1 from me:
Signed-off-by: Tor Lillqvist 

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

[REVIEW 3-5] n#695479 fix rtf/docx import of transparent frames

2012-02-28 Thread Miklos Vajna

Hi,

See
http://cgit.freedesktop.org/libreoffice/core/commit/?id=4ac48167662c592c21025b89fe8f6925c680c6e0
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c306532e0bed1df36abf5d7ad6f0363056e69739

Attached a backport of these commits to -3-5.

Thanks,

Miklos
>From e0c37573ebaedeb785b9f0df1ab8d4459abbab78 Mon Sep 17 00:00:00 2001
From: Miklos Vajna 
Date: Mon, 20 Feb 2012 15:46:08 +0100
Subject: [PATCH] n#695479 fix rtf/docx import of transparent frames

Previously all frames were opaque by default, which is the Writer but
not the docx/rtf default. Change the default, while keeping the
possibility to set an opaque color background for the frame.

(cherry picked from commits 4ac48167662c592c21025b89fe8f6925c680c6e0 and
c306532e0bed1df36abf5d7ad6f0363056e69739)
---
 writerfilter/source/dmapper/DomainMapper_Impl.cxx |7 ++-
 writerfilter/source/dmapper/PropertyIds.cxx   |1 +
 writerfilter/source/dmapper/PropertyIds.hxx   |1 +
 3 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/writerfilter/source/dmapper/DomainMapper_Impl.cxx b/writerfilter/source/dmapper/DomainMapper_Impl.cxx
index d36fda0..bc38966 100644
--- a/writerfilter/source/dmapper/DomainMapper_Impl.cxx
+++ b/writerfilter/source/dmapper/DomainMapper_Impl.cxx
@@ -702,7 +702,7 @@ void DomainMapper_Impl::CheckUnregisteredFrameConversion( )
 StyleSheetEntryPtr pParaStyle =
 GetStyleSheetTable()->FindStyleSheetByConvertedStyleName(rAppendContext.pLastParagraphProperties->GetParaStyleName());
 
-uno::Sequence< beans::PropertyValue > aFrameProperties(pParaStyle ? 15: 9);
+uno::Sequence< beans::PropertyValue > aFrameProperties(pParaStyle ? 16: 9);
 
 if ( pParaStyle.get( ) )
 {
@@ -722,6 +722,7 @@ void DomainMapper_Impl::CheckUnregisteredFrameConversion( )
 pFrameProperties[12].Name = rPropNameSupplier.GetName(PROP_RIGHT_MARGIN);
 pFrameProperties[13].Name = rPropNameSupplier.GetName(PROP_TOP_MARGIN);
 pFrameProperties[14].Name = rPropNameSupplier.GetName(PROP_BOTTOM_MARGIN);
+pFrameProperties[15].Name = rPropNameSupplier.GetName(PROP_BACK_COLOR_TRANSPARENCY);
 
 const ParagraphProperties* pStyleProperties = dynamic_cast( pParaStyle->pProperties.get() );
 sal_Int32 nWidth =
@@ -794,6 +795,10 @@ void DomainMapper_Impl::CheckUnregisteredFrameConversion( )
 pStyleProperties->GetvSpace() >= 0 ? pStyleProperties->GetvSpace() : 0;
 pFrameProperties[13].Value <<= nHoriOrient == text::HoriOrientation::LEFT ? 0 : nLeftDist;
 pFrameProperties[14].Value <<= nHoriOrient == text::HoriOrientation::RIGHT ? 0 : nRightDist;
+// If there is no fill, the Word default is 100% transparency.
+// Otherwise CellColorHandler has priority, and this setting
+// will be ignored.
+pFrameProperties[15].Value <<= sal_Int32(100);
 
 lcl_MoveBorderPropertiesToFrame(aFrameProperties,
 rAppendContext.pLastParagraphProperties->GetStartingRange(),
diff --git a/writerfilter/source/dmapper/PropertyIds.cxx b/writerfilter/source/dmapper/PropertyIds.cxx
index 173be40..c8f8a55 100644
--- a/writerfilter/source/dmapper/PropertyIds.cxx
+++ b/writerfilter/source/dmapper/PropertyIds.cxx
@@ -196,6 +196,7 @@ const rtl::OUString& PropertyNameSupplier::GetName( PropertyIds eId ) const
 case PROP_CONTOUR_POLY_POLYGON :sName = ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("ContourPolyPolygon")); break;
 case PROP_PAGE_TOGGLE  :sName = ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("PageToggle")); break;
 case PROP_BACK_COLOR   :sName = ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("BackColor")); break;
+case PROP_BACK_COLOR_TRANSPARENCY:  sName = ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("BackColorTransparency")); break;
 case PROP_ALTERNATIVE_TEXT :sName = ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("AlternativeText")); break;
 case PROP_HEADER_TEXT_LEFT :sName = ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("HeaderTextLeft")); break;
 case PROP_HEADER_TEXT  :sName = ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("HeaderText")); break;
diff --git a/writerfilter/source/dmapper/PropertyIds.hxx b/writerfilter/source/dmapper/PropertyIds.hxx
index dd20f06..b109cd6 100644
--- a/writerfilter/source/dmapper/PropertyIds.hxx
+++ b/writerfilter/source/dmapper/PropertyIds.hxx
@@ -51,6 +51,7 @@ enum PropertyIds
 ,PROP_ANCHOR_TYPE
 ,PROP_AUTOMATIC_DISTANCE
 ,PROP_BACK_COLOR
+,PROP_BACK_COLOR_TRANSPARENCY
 ,PROP_BITMAP
 ,PROP_BOTTOM_BORDER
 ,PROP_BOTTOM_BORDER_DISTANCE
-- 
1.7.7

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
htt

Re: [PUSHED-3-5][PUSHED-3-5-1] libxml2 on MacOSX