[Libreoffice] unit test concept for draw/impress

[Markus Mohrhard]

Hey,

I finally found some time working on a unit test concept for
draw/impress as promised to Thorsten in Paris. (see [1])

The attached patch enables the new test concept in sd. The test is
based on calc's filters-test concept but needs to do some additional
steps.

We take a import file (e.g. an ppt file) and import it into impress,
and in the next step export it to svg. The advantage of the svg file
is that it represents the visual representation extremely good and we
ca easily compare it againts an reference svg file. I hope that this
approach allows us to easily find changes that break features and
change the visual representation of files.

I listed some advantages and disadvantages of this concept in my
commit message. Please feel free to comment my idea.

I have not yet implemented the last step, comparing the exported file
to a reference file but that should be a minor problem. Use the
attached patch to enable the and check my idea. The current test
should take sd/qa/unit/data/a.pptx and export it to
solver/platform/unittest/sd/test2.svg

Regards,
Markus

[1] 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=2b2fbf7350cbc53b878a7faf9ab353146fb598bf
From 7950b170ebedb2e0e64c3f4065577aa0184bcb85 Mon Sep 17 00:00:00 2001
From: Markus Mohrhard 
Date: Fri, 13 Jan 2012 05:02:31 +0100
Subject: [PATCH] enable sd's regression test

---
 sd/Module_sd.mk |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/sd/Module_sd.mk b/sd/Module_sd.mk
index 4fd3a95..ba86665 100644
--- a/sd/Module_sd.mk
+++ b/sd/Module_sd.mk
@@ -42,6 +42,7 @@ $(eval $(call gb_Module_add_targets,sd,\
 
 ifneq ($(OS),DRAGONFLY)
 $(eval $(call gb_Module_add_check_targets,sd,\
+CppunitTest_sd_regression_test \
 CppunitTest_sd_uimpress \
 ))
 # disabled for now, seems to have incomplete deps and hangs on a build from scratch
-- 
1.7.7

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

[Libreoffice] prevent the creation of lockfiles during unit tests

[Markus Mohrhard]

Hey,

I finally found a solution to the lockfile problem. The attached patch
prevents lockfiles during unit tests.

I did not push that patch directly because I'm not sure if we really
want to introduce another registry entry for this.

If this is the correct patch i would like to push that to master and
3-5 to prevent test failures because of old lockfiles. This brings us
now one step closer to a read-only source tree.

Regards,
Markus
From 2fe17e493046b9ecb58e3886d1f8cd27250f32b5 Mon Sep 17 00:00:00 2001
From: Markus Mohrhard 
Date: Fri, 13 Jan 2012 03:34:28 +0100
Subject: [PATCH] don't create lock files for unit tests

special thanks to Stephan for the configuration part
---
 .../schema/org/openoffice/Office/Common.xcs|7 
 sfx2/source/doc/docfile.cxx|   30 
 test/user-template/registry/modifications.xcd  |   10 ++
 3 files changed, 47 insertions(+), 0 deletions(-)

diff --git a/officecfg/registry/schema/org/openoffice/Office/Common.xcs b/officecfg/registry/schema/org/openoffice/Office/Common.xcs
index 2cee667..c74e508 100644
--- a/officecfg/registry/schema/org/openoffice/Office/Common.xcs
+++ b/officecfg/registry/schema/org/openoffice/Office/Common.xcs
@@ -6269,6 +6269,13 @@
 
 true
   
+  
+
+  Allows to specify whether locking should be used at all.
+  Use this setting only for debugging purpose.
+
+true
+  
   
 
   THB
diff --git a/sfx2/source/doc/docfile.cxx b/sfx2/source/doc/docfile.cxx
index 0332493..6d06057 100644
--- a/sfx2/source/doc/docfile.cxx
+++ b/sfx2/source/doc/docfile.cxx
@@ -204,6 +204,31 @@ sal_Bool IsOOoLockFileUsed()
 return bOOoLockFileUsed;
 }
 
+bool IsLockingUsed()
+{
+bool bLocking = true;
+try
+{
+
+uno::Reference< uno::XInterface > xCommonConfig = ::comphelper::ConfigurationHelper::openConfig(
+::comphelper::getProcessServiceFactory(),
+::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "/org.openoffice.Office.Common" ) ),
+::comphelper::ConfigurationHelper::E_STANDARD );
+if ( !xCommonConfig.is() )
+throw uno::RuntimeException();
+
+::comphelper::ConfigurationHelper::readRelativeKey(
+xCommonConfig,
+::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "Misc/" ) ),
+::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "UseLocking" ) ) ) >>= bLocking;
+}
+catch( const uno::Exception& )
+{
+}
+
+return bLocking;
+}
+
 } // anonymous namespace
 //==
 
@@ -998,6 +1023,11 @@ sal_Bool SfxMedium::LockOrigFileOnDemand( sal_Bool bLoading, sal_Bool bNoUI )
 // if user cancel the loading the ERROR_ABORT is set
 sal_Bool bResult = sal_False;
 
+if (!IsLockingUsed())
+{
+return sal_True;
+}
+
 if ( !GetURLObject().HasError() ) try
 {
 if ( pImp->m_bLocked && bLoading && ::utl::LocalFileHelper::IsLocalFile( GetURLObject().GetMainURL( INetURLObject::NO_DECODE ) ) )
diff --git a/test/user-template/registry/modifications.xcd b/test/user-template/registry/modifications.xcd
index d323645..87cacf7 100644
--- a/test/user-template/registry/modifications.xcd
+++ b/test/user-template/registry/modifications.xcd
@@ -27,6 +27,16 @@
  * instead of those above.
 -->
 http://openoffice.org/2001/registry";>
+ 
+  
+
+  false
+
+
+  false
+
+  
+ 
  
   

-- 
1.7.7

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

Re: [Libreoffice] [REVIEW][3-4] date change regression fdo#44385

[Michael Stahl]

On 12/01/12 16:55, Noel Power wrote:
> Be good to get this in, afaict this shouldn't cause any problems
> see attached patch
> 
> Noel

looking at the change, i notice that now it is independent of the
operation being performed, while the code that was originally removed in
adcba12537d047f5ad65334b65512615311cf872 checked for addition only (as
the comment says):

> -// #45465 Date needs with "+" a special handling
> -if( eOp == SbxPLUS && (GetType() == SbxDATE || 
> rOp.GetType() == SbxDATE ) )
> -aL.eType = SbxDATE;

is that intentional?

i'm +1 for putting the original change back, and perhaps also for your
changed variant if you have a good explanation :)

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

[Libreoffice] FATToVFat_Impl: desktop/source/app/appsys.*: windows

[Caolán McNamara]

These can be removed right ?, I mean, I don't see any use of them
anywhere or anything using appsys.hxx, so appsys.hxx and appsys.cxx
could be completely removed as far as I can see.

C.

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

Re: [Libreoffice] [Libreoffice-qa] 3.5.0 QA ... from BHS 1 to BHS 2

[Cor Nouws]

Hi all,

Cor Nouws wrote (09-01-12 23:10)


Find mentors "officially" and don't rely on people to show up for the
second one. It did work out on the first session, but esp. for the
follow-up event it should be sure that mentors are around.


I agree with that.


Are there people that can help with this?

--
 - Cor
 - http://nl.libreoffice.org

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

Re: [Libreoffice] Dumping to valgrind.log from soffice shell script needed?

[August Sodora]

Does it make sense to do --log-file=valgrind.out.%p ?

August Sodora
aug...@gmail.com
(201) 280-8138



On Thu, Jan 12, 2012 at 11:46 AM, Petr Mladek  wrote:
> Stephan Bergmann píše v Čt 12. 01. 2012 v 11:37 +0100:
>> On 11/11/2011 09:36 AM, Stephan Bergmann wrote:
>> > On 10/26/2011 09:00 PM, Stephan Bergmann wrote:
>> > But today I had to find out that even a single invocation of the
>> > sw/qa_complex test internally starts multiple soffice instances in a
>> > row, and coming back to a multi-hour valgrind run of that test all I got
>> > was a most unhelpful valgrind.log for a single soffice invocation.
>> >
>> > This feature turns out to be a real productivity problem for me after
>> > all. Petr, can you please re-consider whether it is really too much to
>> > ask your clients to type
>
> Ah, I am sorry for the troubles. I have somehow missed this mail. You
> probably did not keep me in CC and I overlooked it on the mailing
> list :-(
>
>
>> > VALGRIND=memcheck soffice 2>valgrind.log
>> >
>> > instead of
>> >
>> > VALGRIND=memcheck soffice
>>
>> Removed that feature now, after yet another round of frustrations.
>> 
>
> I think that the main problem is that valgrind is invoked two ways,
> either by exporting the variable VALGRIND or using the --valgrind option
>
> The variable was introduced to make debugging easier when running unit-
> and subsequent-test. The option was introduced for normal users.
>
> What about the following solution:
>
> + print log on the standart output when invoking via the variable
> + print to valgrind.log when using the --valgrind option
>
>
> Would it fit your needs?
>
>
> Best Regards,
> Petr
>
> PS: I wonder why I did not get this idea earlier.
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Kohei Yoshida  changed:

   What|Removed |Added

 Depends on|37860   |

-- 
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: [Libreoffice] How can we use extensions' plugins ?

[Petr Mladek]

Matúš Kukan píše v Čt 12. 01. 2012 v 16:32 +0100:
> Hi there,
> 
> I was wondering, mainly because there are still problems to compile 
> extensions:
> 
> there are two *plugin* directories:
> extensions/source/plugin/
> extensions/source/nsplugin/
>  - Here we also build Executable and Library but how can we use them ?
>Because the library npsoplugin has no .component file associated to it.

You might enable it from inside LO by the checkbox
Tools/Options/Internet/Browser Plug-in/Display documents in browser

AFAIK, you might also enable it for all users when you symlink
libnpsoplugin.so into the mozilla plugin directory. I guess that the
standard path is /usr/lib/browser-plugins.

The result is that it will display LO documents inside the browser
window. It even shows a simple menu that allows basic operations with
the document.

I do not have good experiences with it. Sometimes it showed blank
documents instead of the real one. It slowed down the browser. I had
troubles to save the original document on disk.


Best Regards,
Petr

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

Re: [Libreoffice] minutes of ESC call ...

[Petr Mladek]

Michael Meeks píše v Čt 12. 01. 2012 v 16:23 +:
>  Hard English string & UI freeze - in effect now 
> 
>   + After Monday/Tuesday's RC1 tag need a 2nd review

It means to ask for one review/approval on the
libreoffice@lists.freedesktop.org mailing list before cherry-pikcing
from master.

This is the usual rule for the libreoffice-A-X branches as described at
http://wiki.documentfoundation.org/Development/Branches


>  From Monday 16th - one extra pair of eyes needed per commit 
> 
>   + the future:
>   + 2x extra patch reviewers starts at RC2

We will create the libreoffice-3-5-0 from the tag for 3.5.0-rc2 (about
Jan 24). So, these is the usual rule for libreoffice-A-X-Y branches as
described at http://wiki.documentfoundation.org/Development/Branches


>   + 3x extra patch reviewers starts at RC3

rc3 should be final, so there won't be this extra level of review.


I am sorry if I explained it a confusing way on the TSC call. I hope
that the above comments make it more clear :-)


Best Regards,
Petr

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

Re: [Libreoffice] [REVIEW][3-4] fdo#44078 boxes shown for glyph fallback with DejaVu Sans ExtraLight (he/ar)

[Kohei Yoshida]

On Thu, 2012-01-12 at 11:08 +, Caolán McNamara wrote:
> We probably need a wiki dashboard

Perhaps we could add such info to this wiki page:

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

Best,

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc

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

Re: [Libreoffice] [PATCH] Replace getLength() with isEmpty() in vcl/generic/fontmanager

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Christina

Em 12-01-2012 14:30, Chr. Rossmanith escreveu:
> Am 12.01.2012 17:17, schrieb Olivier Hallot:
> 
> 1) update bug fdo43460 with your (pushed) patch?
>> You mean just add an comment which mentions the directory I've been
>> working in? Of course can I do that. When I'm finished with vcl or
>> already now with that little bit?

It is up to you, really. It is only for the records.

> 2) complete module vcl/ with these replacements? I will mark it as yours
> in my control file. Attached an exerpt of the files and lines to look at.

>> As time permits. Probably interleaved with the ByteString replacement.

Please do it at your earliest and comfortable convenience. I leave vcl
to you.

Thank you for helping me.

Kind regards
- -- 
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/

iQEcBAEBAgAGBQJPDxZKAAoJEJp3R7nH3vLxKYIH/08sEao2BRkRzunDXQWU/alO
nI3AiKOtWXOUjbIEn9fZuJb6EQCOC/C0jsRhBDvBuAXyjZ2aq+t2XVglrxzrYlZ3
iMWT/VatngZn1m+qPUzN735jPivgQiWenyS/3vOY3U0AvW41NSWu5yh9/fq2mePY
fvfNd043kr7O7qhRbvA+Kbo5L0x9n/h9p69RbRh+ahavbtcNHL87WWSDbjP8FUTK
RuuOvum8/DXLbABxq2jgqVeq2x/zl603DrG+xdW22FkbQowakKssd2BGjM2r9ty/
GvdWIjbnkVMI6abC47fU4b5fo00Vgwqhlhz18MgM1dZ6dWIQWgG9WkHtZLY+yNU=
=3ph4
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Dumping to valgrind.log from soffice shell script needed?

[Petr Mladek]

Stephan Bergmann píše v Čt 12. 01. 2012 v 11:37 +0100:
> On 11/11/2011 09:36 AM, Stephan Bergmann wrote:
> > On 10/26/2011 09:00 PM, Stephan Bergmann wrote:
> > But today I had to find out that even a single invocation of the
> > sw/qa_complex test internally starts multiple soffice instances in a
> > row, and coming back to a multi-hour valgrind run of that test all I got
> > was a most unhelpful valgrind.log for a single soffice invocation.
> >
> > This feature turns out to be a real productivity problem for me after
> > all. Petr, can you please re-consider whether it is really too much to
> > ask your clients to type

Ah, I am sorry for the troubles. I have somehow missed this mail. You
probably did not keep me in CC and I overlooked it on the mailing
list :-(


> > VALGRIND=memcheck soffice 2>valgrind.log
> >
> > instead of
> >
> > VALGRIND=memcheck soffice
> 
> Removed that feature now, after yet another round of frustrations. 
> 

I think that the main problem is that valgrind is invoked two ways,
either by exporting the variable VALGRIND or using the --valgrind option

The variable was introduced to make debugging easier when running unit-
and subsequent-test. The option was introduced for normal users.

What about the following solution:

+ print log on the standart output when invoking via the variable
+ print to valgrind.log when using the --valgrind option


Would it fit your needs?


Best Regards,
Petr

PS: I wonder why I did not get this idea earlier.

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

Re: [Libreoffice] [PATCH] Replace getLength() with isEmpty() in vcl/generic/fontmanager

[Chr. Rossmanith]

Am 12.01.2012 17:17, schrieb Olivier Hallot:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thank you Christina for the patch.

It look like your patch is ok, with respect to the logic inversion. A
build should indicate if the method isEmpty() is valid for the right
object (e.g. it is not valid for OUStringBuffer or Sequence).
I've built it successfully and found out that O(U)StringBuffer has no 
isEmpty() this morning  :-)

Do you mind to
1) update bug fdo43460 with your (pushed) patch?
You mean just add an comment which mentions the directory I've been 
working in? Of course can I do that. When I'm finished with vcl or 
already now with that little bit?

2) complete module vcl/ with these replacements? I will mark it as yours
in my control file. Attached an exerpt of the files and lines to look at.

As time permits. Probably interleaved with the ByteString replacement.

Christina


Regards

Olivier


Em 12-01-2012 12:29, Chr. Rossmanith escreveu:

Hi,

while replacing ByteString with OString I came across some getLength()
calls which might be replaced with isEmpty(). Hope Olivier won't be
annoyed  :-)

Some reviewing would be nice to be sure the logic didn't get inverted
accidently.I have git push access - so reviewing would be sufficient.

Christina


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
- -- 
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/

iQEcBAEBAgAGBQJPDwehAAoJEJp3R7nH3vLxl3cH/0qtyGFDI44WaSWr5XVKgU7n
oGzqcz/DBAuaDRr7NZnHp2rerAXNur1r6M1gVL+yyO/DsLxwnDdUAQsUdwcZspzR
zckK5D8l9q6oD/+o16Ismr5/r+E9Fn5Jz/MH+ER+nqslZe5k138eJZH2L5KrwR7i
J1Uq5ZIZHa+Q9+aWCBeRVpb8RU+VnBx2nVBUQ98ovQ/ShDCE3SNGOwNSQAQtz8si
LzXd4MfTmFZJSk4DwlTXXOAoXcYn6rwRdxr2DsyOa/faOeBwWrBVLrKfGN4Bl1rn
MYEDLvQqZQ7T3FHik4aOHVUmvfYvJKaP1X+oAcHgM5WJpHhYmURf1wAMY8QgrI4=
=tufN
-END PGP SIGNATURE-


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


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

[Libreoffice] minutes of ESC call ...

[Michael Meeks]

* Present:
+ Lionel, Tor, Michael, Eike, Norbert, Stephan,
  David, Fridrich, Rainer, Christian, Petr, Andras,
  Kohei, Thorsten, Mitch

* Completed Action Items
+ add postgresql to 3.5 feature page (Lionel)
+ make it clear the SAL_INFO etc. macros are internal only for 3.5 
(Stephan)
+ checking pg baseline on windows (Fridrich)
+ FOSDEM: add  talk (Stephan)
+ FOSDEM: add Internal structure of calc talk (Eike)
+ FOSDEM: add easy hacks talk (Michael)
+ poke fdo bugzilla hero Tollef wrt. performance (Michael)
+ major hardware upgrade planned soon.
+ cleanup old test build server directories (Thorsten)
+ WONTFIX fdo#... in pleasant way (Thorsten)
+ qa list incomplete, or updating slowly on gmane, poke Florian 
(Thorsten)
+ unknown transient issue apparently gone.
+ qa heros issues (Michael)
+ needs a new bugzilla extension, wait a bit.

* Pending Action Items
+ add tinderbox name to build-id (Norbert)
+ [slow progress] extract 64bit build hardware from firewall (Kendy / 
Admins)
+ get a permanant re-direction link for bug assistent (Thorsten)
+ hack up the Help->File bug menu item (Thorsten)
+ rename VCL API to make it GetBeamerFoo & fix (Michael)
+ include slowchecks into tail_build's Makefile (Markus?)

* Action Items review

* Release Engineering update (Petr)
+ 3.4.5 status
+ bit delayed by Christmas catchup
+ blocker proposed, investigated but not a regression
+ scheduled to be announced shortly, pending marketing input
+ 3.5.0 status
+ pre-release Beta 3 builds up-loaded
+ blocked by getting 3.4.5 out first
+ hope to have it out by Saturday

 Hard English string & UI freeze - in effect now 

+ After Monday/Tuesday's RC1 tag need a 2nd review

 From Monday 16th - one extra pair of eyes needed per commit 

+ the future:
+ 2x extra patch reviewers starts at RC2
+ 3x extra patch reviewers starts at RC3
+ lots of bugs being fixed - please continue !

* Mechanism for asking Translators permission for string freeze breakage ?
+ how many translators to ask (Andras?)
+ previous rule was bug fixes that required them were ok
+ rule: if the bug is more serious than a broken translation ? (Petr)
+ potentially in point-zero releases less serious (Petr?)
+ Decided - ask: l...@global.libreoffice.org for approval in future

* QA update (Rainer)
+ Windows 8 problem
+ running under Virtualbox, can be reproduced
+ Bugzilla updates sorted out with Thorsten
+ status of permanent re-direction link for assistant ?
+ admins need to be told what link they want
+ create link in a couple of minutes,
  ver+os+ as parameters to allow re-direction of
  old versions.
AA: + create http://hub.libreoffice.org/file-a-bug/ (Christian)
+ unreviewed bugs
+ stopped the trend of unchecked bugs increasing
+ lots of bug-fixes coming in
+ very good situation

* ICU size shrink - save 4Mb ... (Eike)
+ great, but prolly not ready for 3.5.0

* Mitch / MSI building update
+ vacation since the last meeting
+ pushed-back by another high-prio project
+ two week delay expected

* FOSDEM dev-room schedule
+ tons of talks, not much time - maximum time slot 30mins
+ program still under discussion, for publication decision soon.

* all bugs created by LibO considered invalid by MS Office
+ we do the right thing: putting 1.2 in the manifest version (Thorsten)
+ recent bug-fix in a 3.4 CWS
+ ODF 1.2 makes the version mandatory, and must have value=1.2
+ if it is seen, MS Office will claim it is invalid.
+ it's not possible for us to write valid ODF 1.2 docs about
  which MS Office doesn't complain
+ MS Office offers to 'repair' & import it
+ that looks scary.
+ it's not our bug
+ Need to release-note this:
+ avoid recommending the legacy 1.1 format due to
  data loss concerns

* 3.5 most annoying bugs ...
+ 23 open (of 71 total)
+ 
https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

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

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

Re: [Libreoffice] [PATCH] Replace getLength() with isEmpty() in vcl/generic/fontmanager

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thank you Christina for the patch.

It look like your patch is ok, with respect to the logic inversion. A
build should indicate if the method isEmpty() is valid for the right
object (e.g. it is not valid for OUStringBuffer or Sequence).

Do you mind to
1) update bug fdo43460 with your (pushed) patch?

2) complete module vcl/ with these replacements? I will mark it as yours
in my control file. Attached an exerpt of the files and lines to look at.

Regards

Olivier


Em 12-01-2012 12:29, Chr. Rossmanith escreveu:
> Hi,
> 
> while replacing ByteString with OString I came across some getLength()
> calls which might be replaced with isEmpty(). Hope Olivier won't be
> annoyed  :-)
> 
> Some reviewing would be nice to be sure the logic didn't get inverted
> accidently.I have git push access - so reviewing would be sufficient.
> 
> Christina
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

iQEcBAEBAgAGBQJPDwehAAoJEJp3R7nH3vLxl3cH/0qtyGFDI44WaSWr5XVKgU7n
oGzqcz/DBAuaDRr7NZnHp2rerAXNur1r6M1gVL+yyO/DsLxwnDdUAQsUdwcZspzR
zckK5D8l9q6oD/+o16Ismr5/r+E9Fn5Jz/MH+ER+nqslZe5k138eJZH2L5KrwR7i
J1Uq5ZIZHa+Q9+aWCBeRVpb8RU+VnBx2nVBUQ98ovQ/ShDCE3SNGOwNSQAQtz8si
LzXd4MfTmFZJSk4DwlTXXOAoXcYn6rwRdxr2DsyOa/faOeBwWrBVLrKfGN4Bl1rn
MYEDLvQqZQ7T3FHik4aOHVUmvfYvJKaP1X+oAcHgM5WJpHhYmURf1wAMY8QgrI4=
=tufN
-END PGP SIGNATURE-
/data/lo/core/vcl/generic/app/gensys.cxx:159:9: note: [EmptyLength plugin] 
replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontcache.cxx:179:21: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontcache.cxx:236:17: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontconfig.cxx:1003:5: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontconfig.cxx:767:5: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontconfig.cxx:778:5: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontconfig.cxx:856:13: note: [EmptyLength 
plugin] replace "getLength() > 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontconfig.cxx:921:5: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontconfig.cxx:988:5: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontconfig.cxx:992:9: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontconfig.cxx:999:5: note: [EmptyLength 
plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:1697:9: note: 
[EmptyLength plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:1702:9: note: 
[EmptyLength plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:1898:5: note: 
[EmptyLength plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:1949:13: note: 
[EmptyLength plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:2165:5: note: 
[EmptyLength plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:2174:13: note: 
[EmptyLength plugin] replace "getLength() == 0" with "isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:3281:17: note: 
[EmptyLength plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:3447:5: note: 
[EmptyLength plugin] replace "getLength() == 0" with "isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:3497:13: note: 
[EmptyLength plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:3573:17: note: 
[EmptyLength plugin] replace "getLength() != 0" with "!isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:792:9: note: [EmptyLength 
plugin] replace "getLength() == 0" with "isEmpty()"
/data/lo/core/vcl/generic/fontmanager/fontmanager.cxx:806:5: note: [EmptyLength 
plugin] replace "getLength() == 0" with "isEmpty()"
/data/lo/core/vcl/generic/fontmanager/helper.cxx:160:9: note: [EmptyLength 
plugin] replace "getLength() == 0" with "isEmpty()"
/data/lo/core/vcl/

[Libreoffice] [REVIEW][3-4] date change regression fdo#44385

[Noel Power]

Be good to get this in, afaict this shouldn't cause any problems
see attached patch

Noel
>From 778c2ad1225ee3d1e9ac40ab584d8f5f428845fe Mon Sep 17 00:00:00 2001
From: Noel Power 
Date: Thu, 12 Jan 2012 15:46:52 +
Subject: [PATCH] restore special DATE handling code for SbxValue::Compute 
fdo#44385

restore code that seemed to be erroneously moved as part of the currency 
enhancement feature
---
 basic/source/sbx/sbxvalue.cxx |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/basic/source/sbx/sbxvalue.cxx b/basic/source/sbx/sbxvalue.cxx
index e21234c..39dfadb 100644
--- a/basic/source/sbx/sbxvalue.cxx
+++ b/basic/source/sbx/sbxvalue.cxx
@@ -1311,9 +1311,6 @@ Lbl_OpIsDouble:
 else aL.nDouble /= aR.nDouble; break;
 case SbxPLUS:
 aL.nDouble += aR.nDouble; break;
-// #45465 Date needs with "+" a special handling: 
forces date type
-if( GetType() == SbxDATE || rOp.GetType() == 
SbxDATE )
-aL.eType = SbxDATE;
 case SbxMINUS:
 aL.nDouble -= aR.nDouble; break;
 case SbxNEG:
@@ -1321,6 +1318,9 @@ Lbl_OpIsDouble:
 default:
 SetError( SbxERR_NOTIMP );
 }
+// #45465 Date needs with "+" a special handling: forces 
date type
+if( GetType() == SbxDATE || rOp.GetType() == SbxDATE )
+aL.eType = SbxDATE;
 
 }
 }
-- 
1.7.3.4

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

Re: [Libreoffice] How can we use extensions' plugins ?

[Michael Stahl]

On 12/01/12 16:32, Matúš Kukan wrote:
> extensions/source/nsplugin/
>  - Here we also build Executable and Library but how can we use them ?
>Because the library npsoplugin has no .component file associated to it.
>Maybe here the executable loads the library ? But who is running
> the executable ?

i guess you can load it into Firefox somehow, but i never tried that :)

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

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

--- Comment #92 from Petr Mladek  2012-01-12 07:37:43 PST ---
I understand it the way that all bugs are kind of nominated because they could
be added and removed from the dependencies at any time if there are good
reasons.

I think that the main confusion is whether to update bug dependencies together
with the explanation comment or wait for someone to accept it.

My suggestion is to update dependencies immediately if you are pretty sure that
it is annoying for many users. You could just leave a comment if you are not
sure.
It is how it works now and I think that it works well.

I agree with Rainer that we do not want long discussions about every bug. Most
people nominate reasonable bugs. This is why the initial comment suggest to add
the dependency immediately.

By other words, both approaches are good. You can't do a mistake :-)

-- 
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] How can we use extensions' plugins ?

[Matúš Kukan]

Hi there,

I was wondering, mainly because there are still problems to compile extensions:

there are two *plugin* directories:
extensions/source/plugin/
 - We build there Library which has pl.component file, so I understand
we can use it.
   There is also Executable for Linux which I guess is called from the
library. This is ok.

extensions/source/nsplugin/
 - Here we also build Executable and Library but how can we use them ?
   Because the library npsoplugin has no .component file associated to it.
   Maybe here the executable loads the library ? But who is running
the executable ?

Thanks,

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

Re: [Libreoffice] [PUSHED] progressbar for rtf import

[Miklos Vajna]

On Thu, Jan 12, 2012 at 01:59:39PM +, Michael Meeks 
 wrote:
> 
> On Thu, 2012-01-12 at 14:11 +0100, Andras Timar wrote:
> > We don't have process for that. The best solution would be, if I
> > leveraged translation from sw for each language. So translators won't
> > even notice. What a pity that writerfilter cannot use sw's resources
> > directly. :)
> 
>   Which sounds to me as if you should push it Miklos

Pushed, thanks for the review.


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

[Libreoffice] [ANN] LibreOffice 3.5.0 beta3 available

[Thorsten Behrens]

Hi *,

for the upcoming new version 3.5.0, we continue with a beta3 build
that is now feature-complete. For further milestones on the way
towards 3.5.0, 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 beta2 is here:

 
http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-5-release-3.4.99.3.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


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

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

--- Comment #91 from Rainer Bielefeld  
2012-01-12 07:01:01 PST ---
@Tor:
Because of that confusion I changed my wording to "Adding bug ...". I do not
believe we should do long discussions here concerning each bug, IMHO the
proceeding should be: 
- Always add the Bug Number to "Depends on"
- Always cite the Bug Subject in a comment with a one sentence reason why
  it is a "Most Annoying" one, so that we keep overview here.

Without objection the Bug remains listed here, or someone objects and deletes
it from "Depends on", further discussion in the Bug report itself.
A "nominate first, discuss, add" would be too bureaucratic

-- 
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] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

--- Comment #90 from Tor Lillqvist  2012-01-12 06:48:52 
PST ---
I am still confused about the usage of "nominate" here.
http://en.wiktionary.org/wiki/nominate says it has two meanings: 1) To name
someone as a candidate for a particular role or position, including that of an
office. and 2) (obsolete) To entitle, confer a name upon. 

So, when people "nominate" a bug for the coveted Most Annoying membership, does
that mean they 1) suggest it as a candidate for being Most Annoying, i.e.
invite discussion whether it is or not? Or that they 2) directly entitle it,
say that it *is* a Most Annoying 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] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

--- Comment #89 from Lionel Elie Mamane  2012-01-12 06:30:52 
PST ---
Nominate bug 44721: Cannot resize a control with the mouse in Report Builder.

-- 
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] [PATCH] Replace getLength() with isEmpty() in vcl/generic/fontmanager

[Chr. Rossmanith]

Hi,

while replacing ByteString with OString I came across some getLength() 
calls which might be replaced with isEmpty(). Hope Olivier won't be 
annoyed  :-)


Some reviewing would be nice to be sure the logic didn't get inverted 
accidently.I have git push access - so reviewing would be sufficient.


Christina
>From ed04863f8e7daeb00058b00a664b810b0bc204f6 Mon Sep 17 00:00:00 2001
From: Christina Rossmanith 
Date: Thu, 12 Jan 2012 15:23:07 +0100
Subject: [PATCH 2/2] Replace getLength() with isEmpty() in vcl/generic/fontmanager

---
 vcl/generic/fontmanager/fontcache.cxx   |4 ++--
 vcl/generic/fontmanager/fontconfig.cxx  |   16 
 vcl/generic/fontmanager/fontmanager.cxx |   24 
 vcl/generic/fontmanager/helper.cxx  |   12 ++--
 4 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/vcl/generic/fontmanager/fontcache.cxx b/vcl/generic/fontmanager/fontcache.cxx
index 5df9b03..ec93599 100644
--- a/vcl/generic/fontmanager/fontcache.cxx
+++ b/vcl/generic/fontmanager/fontcache.cxx
@@ -176,7 +176,7 @@ void FontCache::flush()
 for( ::std::list< int >::const_iterator name_it = (*it)->m_aAliases.begin(); name_it != (*it)->m_aAliases.end(); ++name_it )
 {
 const OUString& rAdd( pAtoms->getString( ATOM_FAMILYNAME, *name_it ) );
-if( rAdd.getLength() )
+if( !rAdd.isEmpty() )
 {
 aLine.append(';');
 aLine.append(OUStringToOString(rAdd, RTL_TEXTENCODING_UTF8));
@@ -233,7 +233,7 @@ void FontCache::flush()
 break;
 default: break;
 }
-if( (*it)->m_aStyleName.getLength() )
+if( !(*it)->m_aStyleName.isEmpty() )
 {
 aLine.append(';');
 aLine.append(OUStringToOString((*it)->m_aStyleName, RTL_TEXTENCODING_UTF8));
diff --git a/vcl/generic/fontmanager/fontconfig.cxx b/vcl/generic/fontmanager/fontconfig.cxx
index 4d02a76..49944fe 100644
--- a/vcl/generic/fontmanager/fontconfig.cxx
+++ b/vcl/generic/fontmanager/fontconfig.cxx
@@ -764,7 +764,7 @@ bool PrintFontManager::Substitute( FontSelectPattern &rPattern, rtl::OUString& r
 FcPatternAddString(pPattern, FC_FAMILY, pTargetNameUtf8);
 
 const rtl::OString aLangAttrib = MsLangId::convertLanguageToIsoByteString(rPattern.meLanguage);
-if( aLangAttrib.getLength() )
+if( !aLangAttrib.isEmpty() )
 {
 const FcChar8* pLangAttribUtf8;
 if (aLangAttrib.equalsIgnoreAsciiCase(OString(RTL_CONSTASCII_STRINGPARAM("pa-in"
@@ -775,7 +775,7 @@ bool PrintFontManager::Substitute( FontSelectPattern &rPattern, rtl::OUString& r
 }
 
 // Add required Unicode characters, if any
-if ( rMissingCodes.getLength() )
+if ( !rMissingCodes.isEmpty() )
 {
FcCharSet *unicodes = FcCharSetCreate();
for( sal_Int32 nStrIndex = 0; nStrIndex < rMissingCodes.getLength(); )
@@ -853,7 +853,7 @@ bool PrintFontManager::Substitute( FontSelectPattern &rPattern, rtl::OUString& r
 }
 
 // update rMissingCodes by removing resolved unicodes
-if( rMissingCodes.getLength() > 0 )
+if( !rMissingCodes.isEmpty() )
 {
 sal_uInt32* pRemainingCodes = (sal_uInt32*)alloca( rMissingCodes.getLength() * sizeof(sal_uInt32) );
 int nRemainingLen = 0;
@@ -918,7 +918,7 @@ ImplFontOptions* PrintFontManager::getFontOptions(
 boost::unordered_map< rtl::OString, rtl::OString, rtl::OStringHash >::const_iterator aI = rWrapper.m_aLocalizedToCanonical.find(sFamily);
 if (aI != rWrapper.m_aLocalizedToCanonical.end())
 sFamily = aI->second;
-if( sFamily.getLength() )
+if( !sFamily.isEmpty() )
 FcPatternAddString(pPattern, FC_FAMILY, (FcChar8*)sFamily.getStr());
 
 addtopattern(pPattern, rInfo.m_eItalic, rInfo.m_eWeight, rInfo.m_eWidth, rInfo.m_ePitch);
@@ -985,22 +985,22 @@ bool PrintFontManager::matchFont( FastPrintFontInfo& rInfo, const com::sun::star
 
 OString aLangAttrib;
 // populate pattern with font characteristics
-if( rLocale.Language.getLength() )
+if( !rLocale.Language.isEmpty() )
 {
 OUStringBuffer aLang(6);
 aLang.append( rLocale.Language );
-if( rLocale.Country.getLength() )
+if( !rLocale.Country.isEmpty() )
 {
 aLang.append( sal_Unicode('-') );
 aLang.append( rLocale.Country );
 }
 aLangAttrib = OUStringToOString( aLang.makeStringAndClear(), RTL_TEXTENCODING_UTF8 );
 }
-if( aLangAttrib.getLength() )
+if( !aLangAttrib.isEmpty() )
 FcPatternAddString(pPattern, FC_LANG, (FcChar8*)aLangAttrib.getStr());
 
 OString aFamily = OUStringToOString( rInfo.m_aFamilyName, RTL_TEXTENCODING_UTF8 );
-if( aFamily.getLength() )
+if( !aFamily.isEmpty() )
 FcPat

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Lionel Elie Mamane  changed:

   What|Removed |Added

 Depends on||44721

-- 
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] [PATCH] Replace (Byte)String with rtl::O(U)String

[Chr. Rossmanith]

Hi,

another bit of replacements for reviewing.

Christina
>From aadab6fdb17ef5fd56964164b711c3034d42168f Mon Sep 17 00:00:00 2001
From: Christina Rossmanith 
Date: Thu, 12 Jan 2012 10:52:31 +0100
Subject: [PATCH 1/2] Replace (Byte)String with rtl::O(U)String

---
 vcl/generic/fontmanager/fontcache.cxx |   30 +++---
 1 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/vcl/generic/fontmanager/fontcache.cxx b/vcl/generic/fontmanager/fontcache.cxx
index cbad197..5df9b03 100644
--- a/vcl/generic/fontmanager/fontcache.cxx
+++ b/vcl/generic/fontmanager/fontcache.cxx
@@ -265,9 +265,9 @@ void FontCache::read()
 }
 
 
-ByteString aLine;
+OString aLine;
 aStream.ReadLine( aLine );
-if( !aLine.Equals( CACHE_MAGIC ) )
+if( !aLine.equals( rtl::OString(RTL_CONSTASCII_STRINGPARAM( CACHE_MAGIC )) ) )
 {
 #if OSL_DEBUG_LEVEL >1
 fprintf( stderr, "FontCache::read: cache file %s fails magic test\n", rtl::OUStringToOString(m_aCacheFile, osl_getThreadTextEncoding()).getStr() );
@@ -282,20 +282,20 @@ void FontCache::read()
 do
 {
 aStream.ReadLine( aLine );
-if( aLine.CompareTo( "FontCacheDirectory:", 19 ) == COMPARE_EQUAL ||
-aLine.CompareTo( "EmptyFontCacheDirectory:", 24 ) == COMPARE_EQUAL )
+if( aLine.compareTo( RTL_CONSTASCII_STRINGPARAM( "FontCacheDirectory:" ) ) == 0 ||
+aLine.compareTo( RTL_CONSTASCII_STRINGPARAM( "EmptyFontCacheDirectory:" ) ) == 0 )
 {
-bool bEmpty = (aLine.CompareTo( "Empty", 5 ) == COMPARE_EQUAL);
+bool bEmpty = (aLine.compareTo( RTL_CONSTASCII_STRINGPARAM ("Empty" ) ) == 0);
 xub_StrLen nSearchIndex = bEmpty ? 24 : 19;
 
 OString aDir;
 sal_Int64 nTimestamp = 0;
-xub_StrLen nTEnd = aLine.Search( ':', nSearchIndex );
+xub_StrLen nTEnd = aLine.indexOf( ':', nSearchIndex );
 if( nTEnd != STRING_NOTFOUND )
 {
-rtl::OString aTimeStamp = aLine.Copy( nSearchIndex, nTEnd - nSearchIndex );
+rtl::OString aTimeStamp = aLine.copy( nSearchIndex, nTEnd - nSearchIndex );
 nTimestamp = aTimeStamp.toInt64();
-aDir = aLine.Copy( nTEnd+1 );
+aDir = aLine.copy( nTEnd+1 );
 }
 else
 {
@@ -327,12 +327,12 @@ void FontCache::read()
 m_aCache[ nDir ].m_bUserOverrideOnly = bKeepOnlyUserOverridden;
 }
 }
-else if( pDir && aLine.CompareTo( "File:", 5 ) == COMPARE_EQUAL )
+else if( pDir && aLine.compareTo( RTL_CONSTASCII_STRINGPARAM( "File:" ) ) == 0 )
 {
-OString aFile( aLine.Copy( 5 ) );
+OString aFile( aLine.copy( 5 ) );
 aStream.ReadLine( aLine );
 
-const char* pLine = aLine.GetBuffer();
+const char* pLine = aLine.getStr();
 
 fonttype::type eType = (fonttype::type)atoi( pLine );
 if( eType != fonttype::TrueType &&
@@ -350,8 +350,8 @@ void FontCache::read()
 for( int n = 0; n < nFonts; n++ )
 {
 aStream.ReadLine( aLine );
-pLine = aLine.GetBuffer();
-int nLen = aLine.Len();
+pLine = aLine.getStr();
+int nLen = aLine.getLength();
 
 PrintFontManager::PrintFont* pFont = NULL;
 switch( eType )
@@ -386,8 +386,8 @@ void FontCache::read()
 }
 }
 aStream.ReadLine( aLine );
-pLine = aLine.GetBuffer();
-nLen = aLine.Len();
+pLine = aLine.getStr();
+nLen = aLine.getLength();
 
 // get up to 20 token positions
 const int nMaxTokens = 20;
-- 
1.7.4.1

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

Re: [Libreoffice] error in writerperfect?

[Fridrich Strba]

Yes, indeed,

Fixed now, thanks a lot.

Cheers

F.

On 12/01/12 14:30, Ivan Timofeev wrote:

Hi,

glancing over the git-log I have noticed the following code

writerperfect/source/filter/OdgGenerator.cxx:951

if (!propList["libwpg:mime-type"] &&
propList["libwpg:mime-type"]->getStr().len() <= 0)
return;

Is there should be || instead of && ?

Regards,
Ivan


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

Re: [Libreoffice] [REVIEW-3-5] progressbar for rtf import

[Michael Stahl]

On 11/01/12 21:26, Miklos Vajna wrote:
> Hi,
> 
> I've implemented a progressbar for rtf import yesterday:
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=92c7b6733e55a6ab62bc231ecf0ffd5c0da7c8d2
> 
> There are two bugreports requesting this: fdo#38057 and fdo#44157. The
> second calls this a 3.4 -> 3.5 regression, which is true.
> 
> What is better - should I cherry-pick this to -3-5, introducing a new
> string to be localized or respect string freeze and ignore this being a
> regression? (It's unfortune that till now I was not aware so far that
> this is a regression, sure.)

looks good to me (except that i have no idea how this l10n stuff works)

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

Re: [Libreoffice] [REVIEWED] progressbar for rtf import

[Michael Meeks]

On Thu, 2012-01-12 at 14:11 +0100, Andras Timar wrote:
> We don't have process for that. The best solution would be, if I
> leveraged translation from sw for each language. So translators won't
> even notice. What a pity that writerfilter cannot use sw's resources
> directly. :)

Which sounds to me as if you should push it Miklos, and Andras will
clean up after you ;-)

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: [Libreoffice] New Tinderbox Linux-RHEL6-x86_64-check

[Michael Stahl]

On 12/01/12 14:44, Stephan Bergmann wrote:
> I added a new tinderbox "Linux-RHEL6-x86_64-check" to 
>  (and it will spam 
> suspects with messages about failing builds in the usual way).
> 
> The box does a rather complete build (--enable-binfilter, no 
> --with-system switches) and especially enables the debug features 
> --enable-dbgutil and --enable-werror.  Additionally, it calls tinbuild2 
> with -t switch, i.e., it runs all the subsequent tests via a toplevel 
> "make check".  The turnaround time is approximately four hours.

great news!

> The other is a sporadic failure of forms_unoapi, an soffice.bin crash 
> somewhere underneath
> 
>> [...]
>> #12 in SdrPageView::DrawLayer at svx/source/svdraw/svdpagv.cxx:398
>> #13 in SwViewImp::PaintLayer at sw/source/core/view/vdraw.cxx:148
>> #14 in SwRootFrm::Paint at sw/source/core/layout/paintfrm.cxx:2976
>> #15 in ViewShell::Paint at sw/source/core/view/viewsh.cxx:1678
>> #16 in SwCrsrShell::Paint at sw/source/core/crsr/crsrsh.cxx:1165
>> #17 in SwEditWin::Paint at sw/source/ui/docvw/edtwin2.cxx:535
>> #18 in Window::ImplCallPaint at vcl/source/window/window.cxx:2417
>> #19 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
>> #20 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
>> #21 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
>> #22 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
>> #23 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
>> #24 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
>> #25 in Window::ImplCallOverlapPaint at vcl/source/window/window.cxx:2477
>> #26 in Window::ImplHandlePaintHdl at vcl/source/window/window.cxx:2497
>> #27 in Window::LinkStubImplHandlePaintHdl at 
>> vcl/source/window/window.cxx:2491
>> #28 in Link::Call at solver/unxlngx6/inc/tools/link.hxx:140
>> #29 in Timer::Timeout at vcl/source/app/timer.cxx:256
>> [...]
> 
> on the main thread while an URP thread is simultaneously executing 
> SwXTextDocument::close.  Looks like SwXTextDocument::close destroys data 
> that is still accessed within SwEditWin::Paint, but I haven't yet come 
> around to find the cause here.  (Problem can only be observed 
> sporadically, and valgrind didn't help yet.)  I plan to follow up on 
> this, however.  Please ignore tinderbox failure mails that are due to 
> this crash in the meantime.

sounds bad; that looks like a SolarMutex guard is missing somewhere...

but if that's the only problem we have, then you must have fixed quite a
few bugs :)

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

[Libreoffice] New Tinderbox Linux-RHEL6-x86_64-check

[Stephan Bergmann]

I added a new tinderbox "Linux-RHEL6-x86_64-check" to 
 (and it will spam 
suspects with messages about failing builds in the usual way).


The box does a rather complete build (--enable-binfilter, no 
--with-system switches) and especially enables the debug features 
--enable-dbgutil and --enable-werror.  Additionally, it calls tinbuild2 
with -t switch, i.e., it runs all the subsequent tests via a toplevel 
"make check".  The turnaround time is approximately four hours.


"make check" does still suffer from sporadic soffice.bin failures, but 
the given box appears to run rather stable now.  In the last couple of 
weeks, the vast majority of builds succeeded, and the few that failed 
consistently did so for one of two reasons.


One was the issue (hopefully) fixed now by 
 
"ScGlobal::GetAutoFormat not always required to create fresh instance."


The other is a sporadic failure of forms_unoapi, an soffice.bin crash 
somewhere underneath



[...]
#12 in SdrPageView::DrawLayer at svx/source/svdraw/svdpagv.cxx:398
#13 in SwViewImp::PaintLayer at sw/source/core/view/vdraw.cxx:148
#14 in SwRootFrm::Paint at sw/source/core/layout/paintfrm.cxx:2976
#15 in ViewShell::Paint at sw/source/core/view/viewsh.cxx:1678
#16 in SwCrsrShell::Paint at sw/source/core/crsr/crsrsh.cxx:1165
#17 in SwEditWin::Paint at sw/source/ui/docvw/edtwin2.cxx:535
#18 in Window::ImplCallPaint at vcl/source/window/window.cxx:2417
#19 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
#20 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
#21 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
#22 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
#23 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
#24 in Window::ImplCallPaint at vcl/source/window/window.cxx:2441
#25 in Window::ImplCallOverlapPaint at vcl/source/window/window.cxx:2477
#26 in Window::ImplHandlePaintHdl at vcl/source/window/window.cxx:2497
#27 in Window::LinkStubImplHandlePaintHdl at vcl/source/window/window.cxx:2491
#28 in Link::Call at solver/unxlngx6/inc/tools/link.hxx:140
#29 in Timer::Timeout at vcl/source/app/timer.cxx:256
[...]


on the main thread while an URP thread is simultaneously executing 
SwXTextDocument::close.  Looks like SwXTextDocument::close destroys data 
that is still accessed within SwEditWin::Paint, but I haven't yet come 
around to find the cause here.  (Problem can only be observed 
sporadically, and valgrind didn't help yet.)  I plan to follow up on 
this, however.  Please ignore tinderbox failure mails that are due to 
this crash in the meantime.


The one local change I did to tinbuild2 is


diff --git a/bin/tinbuild_internals.sh b/bin/tinbuild_internals.sh
index e9f4f3d..680aecb 100644
--- a/bin/tinbuild_internals.sh
+++ b/bin/tinbuild_internals.sh
@@ -354,7 +354,8 @@ do_build()
 if [ -n "${last_checkout_date}" ] ; then
report_error committer "$last_checkout_date" `printf 
"${report_msgs?}:\n\n"` "$(cat build_error.
 ==
-$(tail -n50 ${report_log?} | grep -A25 'internal build errors' | grep 'ERROR:' 
)"
+Last 400 lines of ${report_log?}:
+$(tail -n400 ${report_log?} )"
report_to_tinderbox "${last_checkout_date?}" "build_failed" 
"yes"
 else
 log_msgs "Failed to primed branch '$TINDER_BRANCH'. see 
build_error.log"


so that a failing test produces meaningful log output in the failure 
mails (i.e., the last 400 lines of the log, which should be enough to 
include the backtraces from the crashed soffice.bin process, if any).


The state of "make check" at least for this given box looks rather 
promising, so I would encourage other tinderbox owners to try whether 
adding the -t tinbuild2 switch would work well for their boxes as well.


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

[Libreoffice] error in writerperfect?

[Ivan Timofeev]

Hi,

glancing over the git-log I have noticed the following code

writerperfect/source/filter/OdgGenerator.cxx:951

if (!propList["libwpg:mime-type"] && 
propList["libwpg:mime-type"]->getStr().len() <= 0)

return;

Is there should be || instead of && ?

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

Re: [Libreoffice] Trying to diagnose base running extremely slowly

[Michael Meeks]

On Thu, 2012-01-12 at 10:44 +0100, Stephan Bergmann wrote:
> > I think the best solution here would be to change the LibO hsqldb code,
> > to call Attach/DetachCurrentThread rarely rather than frequently, but
> > according to Ocke Janssen (who used to maintain that code) that was no
> > easy option.
> 
> One rather easy fix would be to confine the 
> com.sun.star.comp.sdbc.JDBCDriver UNO code to a thread-affine apartment, 
> see the attached patch.  That way, all code related to this UNO service 
> (which is the code that calls Attach/DetachCurrentThread so frequently 
> and thus causes the performance degradation) is run in a single, 
> dedicated thread.

That sounds like a rather elegant fix to me :-) as long as that thread
is not the "main thread" - we use rather deep stacks in the calc code
there & this is how the original bug was found etc. it'd be a good fix.

> One drawback of using the thread-affine apartment is that all code 
> related to the JDBC driver is effectively serialized, removing any 
> potential performance advantage from accessing the driver from multiple 
> treads.  I do not know whether that is acceptable or not.

Given the generally tangled locking everywhere I would expect that
virtually everything is serialised anyway ;-) so ...

It'd be great to have a fix for the base guys I guess.

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: [Libreoffice] [REVIEW-3-5] progressbar for rtf import

[Andras Timar]

Hi Michael,

2012/1/12 Michael Meeks :
> Hi Miklos,
>
> On Wed, 2012-01-11 at 21:26 +0100, Miklos Vajna wrote:
>> I've implemented a progressbar for rtf import yesterday:
>
>        Nice work ! :-)
>
>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=92c7b6733e55a6ab62bc231ecf0ffd5c0da7c8d2
>>
>> There are two bugreports requesting this: fdo#38057 and fdo#44157. The
>> second calls this a 3.4 -> 3.5 regression, which is true.
>
>        I think we're fairly happy about regressions here given the
> improvements in the code, but it'd be nice to fix for sure.
>
>> What is better - should I cherry-pick this to -3-5, introducing a new
>> string to be localized or respect string freeze and ignore this being a
>> regression? (It's unfortune that till now I was not aware so far that
>> this is a regression, sure.)
>
>        IIRC the translators would need to approve any such break; Andras -
> what review / approval mechanism do we use there ? Given that the exact
> same string "Loading Document ..." occurs in starmath and writer
> already, I'd hope that they'd be sympathetic :-)
>
We don't have process for that. The best solution would be, if I
leveraged translation from sw for each language. So translators won't
even notice. What a pity that writerfilter cannot use sw's resources
directly. :)

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

Re: [Libreoffice] [LibreOffice] fdo#39428 Remove/audit SvStream operator long

[Stephan Bergmann]

On 01/11/2012 06:51 PM, Keith McRae wrote:

Trying a full build resulted in "undefined reference to
SvStream::operator>>(long&)" in svl/ vcl/ and svtools/ (so far). As
most of these errors are the result of trying to (de)serialize Pair
derived classes, I'm now wondering whether it may be a good idea to
change the troublesome members of these classes to sal_ types?

A quick hack and attempt at build tells me that would be a complete
nightmare! I'll leave that until I'm more familiar with the code :-)


"these classes" being the ones deriving from Pair?  Yes, probably 
easiest to keep the changes from long etc. to sal_ as localized as 
possible, even if that means the clean up of the surrounding code still 
needs to be done.


One way to highlight those "intermediate" conversions is to use 
sal::static_int_cast (sal/types.hxx).  That potentially helps to flag 
those conversions in the code that can be removed again when all code 
consistently uses the sal_ types.


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

Re: [Libreoffice] [REVIEW-3-5] progressbar for rtf import

[Michael Meeks]

Hi Miklos,

On Wed, 2012-01-11 at 21:26 +0100, Miklos Vajna wrote:
> I've implemented a progressbar for rtf import yesterday:

Nice work ! :-)

> http://cgit.freedesktop.org/libreoffice/core/commit/?id=92c7b6733e55a6ab62bc231ecf0ffd5c0da7c8d2
> 
> There are two bugreports requesting this: fdo#38057 and fdo#44157. The
> second calls this a 3.4 -> 3.5 regression, which is true.

I think we're fairly happy about regressions here given the
improvements in the code, but it'd be nice to fix for sure.

> What is better - should I cherry-pick this to -3-5, introducing a new
> string to be localized or respect string freeze and ignore this being a
> regression? (It's unfortune that till now I was not aware so far that
> this is a regression, sure.)

IIRC the translators would need to approve any such break; Andras -
what review / approval mechanism do we use there ? Given that the exact
same string "Loading Document ..." occurs in starmath and writer
already, I'd hope that they'd be sympathetic :-)

On the code front everything looks good, though it too me a double read
to grok what the nPercentSize is doing, and I -hate- the seek to
begin/end stuff to work out the stream size getting pushed into the code
- but that is a standard limitation of that stream API ie. not your
fault [ we see this coming out as pointless syscalls underneath quite a
bite FWIW ;-].

So - overall, it'd be great to get it in if we can persuade the
translators :-)

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: [Libreoffice] [REVIEW][PUSHED][3-4] fdo#44078 boxes shown for glyph fallback with DejaVu Sans ExtraLight (he/ar)

[Stephan Bergmann]

On 01/12/2012 12:08 PM, Michael Meeks wrote:

On Thu, 2012-01-12 at 11:54 +0100, Stephan Bergmann wrote:

How many reviews are currently needed for 3-4?


One (ie. author + 1) - so it can be picked ;-)


Pushed now.

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

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Philipp Gassmann  changed:

   What|Removed |Added

 Depends on||37860

--- Comment #88 from Philipp Gassmann  2012-01-12 04:32:07 PST 
---
Add Bug 37860 - Formula returns #VALUE in 3.4RC2 but works as expected in 3.3

Although the change is intended, it breaks compatibility to earlier versions
and to Excel import.
There's a common pattern =IF(A1+B1=0;"";A1+B1) which is used to hide zeros,
that leads to an error if another formula references this cell when 0/"".
Additionally it is already tagged as EasyHack.

-- 
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] [Bug 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Philipp Gassmann  changed:

   What|Removed |Added

 Depends on||37860

--- Comment #246 from Philipp Gassmann  2012-01-12 04:31:01 
PST ---
Add Bug 37860 - Formula returns #VALUE in 3.4RC2 but works as expected in 3.3

Although the change is intended, it breaks compatibility to earlier versions
and to Excel import.
There's a common pattern =IF(A1+B1=0;"";A1+B1) which is used to hide zeros,
that leads to an error if another formula references this cell when 0/"".
Additionally it is already tagged as EasyHack.

-- 
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: [Libreoffice] [REVIEWED: 3-4] [PUSHED: 3-4] possible missing translations

[David Tardon]

On Thu, Jan 12, 2012 at 11:06:26AM +0100, Andras Timar wrote:
> Hi David,
> 
> 2012/1/12 David Tardon :
> > Hi,
> >
> > commit 196885980bbb51562264cb5aad9a3e01133d1d7d fixes a situation where
> > some translated strings may be missing from installation because of a
> > bug in one of our tools. I would like to see it in 3.4 .
> >
> 
> +1 from me. I tested your version on 3.4.5 and 3.5 and it worked well.
> Please push it.

Thanks for the review. Pushed now.

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

Re: [Libreoffice] [REVIEW][3-4] fdo#44078 boxes shown for glyph fallback with DejaVu Sans ExtraLight (he/ar)

[Michael Meeks]

On Thu, 2012-01-12 at 11:54 +0100, Stephan Bergmann wrote:
> How many reviews are currently needed for 3-4?

One (ie. author + 1) - so it can be picked ;-)

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: [Libreoffice] [REVIEW][3-4] fdo#44078 boxes shown for glyph fallback with DejaVu Sans ExtraLight (he/ar)

[Caolán McNamara]

On Thu, 2012-01-12 at 11:54 +0100, Stephan Bergmann wrote:
> On 01/11/2012 10:09 PM, Caolán McNamara wrote:
> > http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=25b90909a7a22f6900abbe9df12570a24e528c9a
> 
> Patch looks good to me (at least, it can't really make things worse, 
> anyway; the cacheLocalizedFontNames signature change is not related, 
> strictly speaking, right?).

Nope.

> How many reviews are currently needed for 3-4?

Dunno actually. We probably need a wiki dashboard, I get confused easily
as to how many are needed at any given time. I think one is sufficient
for 3-4.

C.

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

Re: [Libreoffice] [REVIEW][3-4] fdo#44078 boxes shown for glyph fallback with DejaVu Sans ExtraLight (he/ar)

[Stephan Bergmann]

On 01/11/2012 10:09 PM, Caolán McNamara wrote:

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


Patch looks good to me (at least, it can't really make things worse, 
anyway; the cacheLocalizedFontNames signature change is not related, 
strictly speaking, right?).


How many reviews are currently needed for 3-4?

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

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Petr Mladek  changed:

   What|Removed |Added

 Depends on||38515

--- Comment #87 from Petr Mladek  2012-01-12 02:51:48 PST ---
(In reply to comment #82)
> Bug 38515 - LibreOffice crashes in Bibliography dialog when pressing Enter
> – Because it's a crash and has been in LibO at least since 3.4

I crashes even when adding TOC, so let's add it


> Bug 44602 - Modeless Word Count window hides when user clicks into a note
> – Because it's a new feature that doesn't always work as advertised

I think that this one is rather funny than annoying. I think that we do not
need to prioritize it that much.

-- 
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: [Libreoffice] Dumping to valgrind.log from soffice shell script needed?

[Stephan Bergmann]

On 11/11/2011 09:36 AM, Stephan Bergmann wrote:

On 10/26/2011 09:00 PM, Stephan Bergmann wrote:

On 10/26/2011 01:55 PM, Petr Mladek wrote:

What is your preferred way of use?
What exactly do you hate and/or miss?


One problem is output of multiple (batched, like "make subsequentcheck")
valgrind'ed invocations of soffice.bin is lost.

Another problem is attaching a debugger (VALGRIND_OPTS=--db-attach=yes)
does not work.


So, meanwhile I had thought that I can somehow live with the
inconvenience the automatic-valgrind.log feature brings, trying to
remember to remove the relevant line from the soffice script in
scenarios where it matters.

But today I had to find out that even a single invocation of the
sw/qa_complex test internally starts multiple soffice instances in a
row, and coming back to a multi-hour valgrind run of that test all I got
was a most unhelpful valgrind.log for a single soffice invocation.

This feature turns out to be a real productivity problem for me after
all. Petr, can you please re-consider whether it is really too much to
ask your clients to type

VALGRIND=memcheck soffice 2>valgrind.log

instead of

VALGRIND=memcheck soffice


Removed that feature now, after yet another round of frustrations. 



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

Re: [Libreoffice] [REVIEWED: 3-4] possible missing translations

[Andras Timar]

Hi David,

2012/1/12 David Tardon :
> Hi,
>
> commit 196885980bbb51562264cb5aad9a3e01133d1d7d fixes a situation where
> some translated strings may be missing from installation because of a
> bug in one of our tools. I would like to see it in 3.4 .
>

+1 from me. I tested your version on 3.4.5 and 3.5 and it worked well.
Please push it.

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

Re: [Libreoffice] crasher in writer (footer)

[Cedric Bosdonnat]

Hi Michael,

On Tue, 2012-01-10 at 22:28 +0100, Michael Stahl wrote:
> should be fixed now on master and libreoffice-3-5:
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=0e898354fc76339a9a007b30f1ebe123981d0426
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=debb4be8886a4c5fd0a714dfd1b53306b836b800

Thank you for fixing that one: I wasn't aware of the root cause of this
one.

--
Cedric

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

Re: [Libreoffice] Trying to diagnose base running extremely slowly

[Stephan Bergmann]

On 10/20/2011 09:08 AM, Stephan Bergmann wrote:

On 10/19/2011 07:17 PM, Andrew Haley wrote:

On 10/19/2011 05:57 PM, Michael Meeks wrote:


On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:

What the LibO hsqldb code does a lot is call JNI's
Attach/DetachCurrentThread. Googling around,
 "Stack
guard pages should be removed when thread is detached" suggests that
reading /proc/self/maps might have been added into
Attach/DetachCurrentThread as part of a bug fix. That would explain
things.


Good catch ! The irony ... :-) this Java bug was kindly fixed for us
indirectly via Andrew Haley to address the bad stack page left around
when
we had run some java. That page was causing crashes in calc formula
computation
in large sheets.

It seems we can't win at some stage here. Andrew - I wonder are other
people getting frustrated by performance here too ? it seems there is
some huge /proc/self/maps thrash as we enter/exit Java now on Linux.


Hmmm, I thought this had been fixed.

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6978641


This might still hit us, if the LibO hsqldb code runs in the main thread
(which I'm pretty sure it does). That code calls
Attach/DetachCurrentThread frequently.

I think the best solution here would be to change the LibO hsqldb code,
to call Attach/DetachCurrentThread rarely rather than frequently, but
according to Ocke Janssen (who used to maintain that code) that was no
easy option.


One rather easy fix would be to confine the 
com.sun.star.comp.sdbc.JDBCDriver UNO code to a thread-affine apartment, 
see the attached patch.  That way, all code related to this UNO service 
(which is the code that calls Attach/DetachCurrentThread so frequently 
and thus causes the performance degradation) is run in a single, 
dedicated thread.


That thread is guaranteed not to be the main thread (as the 
thread-affine apartment explicitly creates it), so JVM versions that 
include the fix for 
 "Fix for 
6929067 introduces additional overhead in thread creation/termination 
paths" (which significantly reduces the overhead of 
Attach/DetachCurrentThread for all but the main thread again) should 
return to an acceptable performance.  Trying it out on Fedora 16, which 
includes version 1.6.0_22 of OpenJDK, the patch noticeably improves 
performance of the test scenario described at 
.


One drawback of using the thread-affine apartment is that all code 
related to the JDBC driver is effectively serialized, removing any 
potential performance advantage from accessing the driver from multiple 
treads.  I do not know whether that is acceptable or not.


I did not find problems with using the thread-affine apartment, but then 
again my Base skills are virtually non-existent, so this would probably 
need some QA.  However, there is also already another SDBC driver that 
uses the thread-affine apartment, namely the Windows-specific ADO driver 
(com.sun.star.comp.sdbc.ado.ODriver).


Stephan
diff --git a/connectivity/source/drivers/jdbc/exports.dxp b/connectivity/source/drivers/jdbc/exports.dxp
index 7003307..f0e1c69 100755
--- a/connectivity/source/drivers/jdbc/exports.dxp
+++ b/connectivity/source/drivers/jdbc/exports.dxp
@@ -1 +1,2 @@
+component_getImplementationEnvironment
 component_getFactory
diff --git a/connectivity/source/drivers/jdbc/jservices.cxx b/connectivity/source/drivers/jdbc/jservices.cxx
index 59c73ff..85df771 100644
--- a/connectivity/source/drivers/jdbc/jservices.cxx
+++ b/connectivity/source/drivers/jdbc/jservices.cxx
@@ -83,7 +83,21 @@ struct ProviderRequest
 void* getProvider() const { return xRet.get(); }
 };
 
-//---
+extern "C" SAL_DLLPUBLIC_EXPORT void SAL_CALL
+component_getImplementationEnvironment(
+char const ** ppEnvTypeName, uno_Environment **)
+{
+// Recent Java 6 VMs make calls to JNI Attach/DetachCurrentThread (which
+// this code does extensively) very expensive.  A follow-up JVM fix reduced
+// the overhead significantly again for all threads but the main thread.  So
+// a quick hack to improve performance of this component again is to confine
+// it in the affine apartment (where all code will run on a single,
+// dedicated thread that is guaranteed no to be the main thread).  However,
+// a better fix would still be to redesign the code so that it does not call
+// Attach/DetachCurrentThread so frequently:
+*ppEnvTypeName = CPPU_CURRENT_LANGUAGE_BINDING_NAME ":affine";
+}
+
 extern "C" SAL_DLLPUBLIC_EXPORT void* SAL_CALL component_getFactory(
 const sal_Char* pImplementationName,
 void* pServiceManager,
diff --git a/connectivity/source/drivers/jdbc/makefile.mk b/connectivity/source/drivers/jdbc/makefile.mk
index bef

Re: [Libreoffice] [PATCH] [PUSHED] Translate German comments

[David Tardon]

On Wed, Jan 11, 2012 at 04:10:36PM +0100, Philipp Weissenbacher wrote:
> Hi lo-devs,
> 
> More translations. Business as usual.

Thanks :)

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

[Libreoffice] [REVIEW: 3-4] possible missing translations

[David Tardon]

Hi,

commit 196885980bbb51562264cb5aad9a3e01133d1d7d fixes a situation where
some translated strings may be missing from installation because of a
bug in one of our tools. I would like to see it in 3.4 .

Details:

The fast_merge.pl script creates hierarchy of localize.sdf files (one
per source directory) from sdf files containing all translations for a
language. It reads from the source files by chunks, always all lines
that contain translations for one source file. If the first two source
files in the input sdfs are from different directories, the translations
for the first are lost, because the localize.sdf is created in the
directory of the second file.

It seems that the order of the source files in the input sdfs is random
(but they are grouped per directory), which suggests they are created
by crawling the directory structure in translations/source. This makes
the bug system specific.

See https://bugzilla.redhat.com/show_bug.cgi?id=771108 as an example.
Here the top translations evidently came from
framework/source/classes/resource.src and
framework/source/services/fwk_services.src and translations from the
former were lost.

Note: Miklos tried to fix it before, but unfortunately his fix was not
complete and I reverted it.

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

Re: [Libreoffice] libvisio: how can I help?

[Fridrich Strba]

Hello,

Thanks for filing the bugs. I really did not see that mistake with 
justified text, since I don't have many documents with justified text 
and since the problem with line-breaks and tabs are still preventing us 
from having the text completely correct and thus, I did not pay 
attention so much to visual differences in the text. Now


On 11/01/12 23:52, Bruno Girin wrote:

I saw you had a look at all of the bugs I filed. Thanks for the
feedback! I will have a go at progressing the arrowhead ones (#44551 and
#44576) and the pattern one (#44552).


Yeah, I flagged them as entry-level tasks because they are reasonably 
contained in one function and can be used for deeper understanding of 
libvisio and its API. Especially the arrowheads should be +/- easy to 
start with since Eilidh did already an initial implementation.



Having said this, it raises a newby question: I have a git clone of the
LO code in one folder and a git clone of the libvisio code in another.
What is the simplest way to build and run LO so that it uses the
libvisio library I'm working on rather than the one that came with it so
that I can test my fixes?


OK, here is what I do:

1) I install the git versions of libwpd/libwpg/libwps/libvisio (and 
libcdr for master builds) in the usual system prefix. For my 64-bit 
system it is --prefix=/usr --libdir=/usr/lib64


2) After that, I configure libreoffice master --with-system-libwpd, 
--with-system-libwpg, --with-system-libwps --with-system-libvisio 
--with-system-libcdr. Like that, once your build is finished and made 
dev-install, it will be using the system libraries that one can rebuild 
and reinstall.


3) For changes in writerperfect module then it is enough to have a 
terminal with sourced environment and after modifying something, just do 
"build" in the module. The dev-install should be using links to what the 
"build" produces.


Alternatively, you can build also the writerperfect module from the 
libwpd's git and install it. This will give you a vsd2odg binary that 
will output on your standard output the resulting odg from the 
conversion when called on a visio file:


vsd2odg .vsd | xmllint --format -

Because vsd2odt does not produce any line-breaks, so that command 
produces a nice readable xml that LO 3.5 loads nicely.


Don't hesitate to ask more, it allows me to document some things on this 
list. If you feel like that, you can move some of this information 
somewhere on a wiki :) I am a bit too lazy for that :)



Cheers

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