[Libreoffice] [PATCH] Removes zoom button from default standard toolbar

[Samuel Cantrell]

I've created a couple patches that remove the zoom button from the
standard bar by default. (That is, they are still present, so if a
user so chooses to, he can add them, but they're not shown by
default.)

One patch applies to Calc, and the other to Writer. To apply them, you
have to cd into their respective directories.

Any contributions I've made (if you can call them that), are licensed
under the MPL/LGPLv3+.

Thanks!

Samuel Cantrell
From 5ca2a472b5aa271c25d417bf8c91701582a7f028 Mon Sep 17 00:00:00 2001
From: Samuel Cantrell 
Date: Fri, 10 Jun 2011 20:21:15 -0700
Subject: [PATCH] Removes zoom button from Writer

This patch removes the zoom button from the standard toolbar
by default in Writer. As the "Default UI Improvements" wiki page
notes, we now have a much better method for changing the zoom
level.
---
 sw/uiconfig/sglobal/toolbar/standardbar.xml  |2 +-
 sw/uiconfig/sweb/toolbar/standardbar.xml |2 +-
 sw/uiconfig/swform/toolbar/standardbar.xml   |2 +-
 sw/uiconfig/swreport/toolbar/standardbar.xml |2 +-
 sw/uiconfig/swriter/toolbar/standardbar.xml  |2 +-
 sw/uiconfig/swxform/toolbar/standardbar.xml  |2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/sw/uiconfig/sglobal/toolbar/standardbar.xml b/sw/uiconfig/sglobal/toolbar/standardbar.xml
index 33792ed..9132ae9 100644
--- a/sw/uiconfig/sglobal/toolbar/standardbar.xml
+++ b/sw/uiconfig/sglobal/toolbar/standardbar.xml
@@ -35,7 +35,7 @@
  
  
  
- 
+ 
  
  
  
diff --git a/sw/uiconfig/sweb/toolbar/standardbar.xml b/sw/uiconfig/sweb/toolbar/standardbar.xml
index 109f6e5..cb803fa 100644
--- a/sw/uiconfig/sweb/toolbar/standardbar.xml
+++ b/sw/uiconfig/sweb/toolbar/standardbar.xml
@@ -38,7 +38,7 @@
  
  
  
- 
+ 
  
  
  
diff --git a/sw/uiconfig/swform/toolbar/standardbar.xml b/sw/uiconfig/swform/toolbar/standardbar.xml
index 33792ed..9132ae9 100644
--- a/sw/uiconfig/swform/toolbar/standardbar.xml
+++ b/sw/uiconfig/swform/toolbar/standardbar.xml
@@ -35,7 +35,7 @@
  
  
  
- 
+ 
  
  
  
diff --git a/sw/uiconfig/swreport/toolbar/standardbar.xml b/sw/uiconfig/swreport/toolbar/standardbar.xml
index 33792ed..9132ae9 100644
--- a/sw/uiconfig/swreport/toolbar/standardbar.xml
+++ b/sw/uiconfig/swreport/toolbar/standardbar.xml
@@ -35,7 +35,7 @@
  
  
  
- 
+ 
  
  
  
diff --git a/sw/uiconfig/swriter/toolbar/standardbar.xml b/sw/uiconfig/swriter/toolbar/standardbar.xml
index 33792ed..9132ae9 100644
--- a/sw/uiconfig/swriter/toolbar/standardbar.xml
+++ b/sw/uiconfig/swriter/toolbar/standardbar.xml
@@ -35,7 +35,7 @@
  
  
  
- 
+ 
  
  
  
diff --git a/sw/uiconfig/swxform/toolbar/standardbar.xml b/sw/uiconfig/swxform/toolbar/standardbar.xml
index 935aff9..0e24e93 100644
--- a/sw/uiconfig/swxform/toolbar/standardbar.xml
+++ b/sw/uiconfig/swxform/toolbar/standardbar.xml
@@ -35,7 +35,7 @@
  
  
  
- 
+ 
  
  
  
-- 
1.7.5.2

From fad3f2a1973d1de7428cab2d64717bd09b66bdc1 Mon Sep 17 00:00:00 2001
From: Samuel Cantrell 
Date: Fri, 10 Jun 2011 20:19:58 -0700
Subject: [PATCH] Removes zoom button from Calc

This patch removes the zoom button from the standard toolbar by
default in Calc. As the "Default UI Improvements" wiki page notes,
we now have a much better method of zooming than this stupid
button.
---
 sc/uiconfig/scalc/toolbar/standardbar.xml |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sc/uiconfig/scalc/toolbar/standardbar.xml b/sc/uiconfig/scalc/toolbar/standardbar.xml
index a52ed00..7367971 100644
--- a/sc/uiconfig/scalc/toolbar/standardbar.xml
+++ b/sc/uiconfig/scalc/toolbar/standardbar.xml
@@ -37,7 +37,7 @@
  
  
  
- 
+ 
  
  
  
-- 
1.7.5.2

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

Re: [Libreoffice] Patch for Bug 35938 - EasyHack: UI - Picture Caption dialog not remembering Separator textbox value

[Jeff Aigner]

The patch I provided for Bug 35938 is licensed under LGPLv3+/MPL.

Jeff Aigner

On 06/10/2011 01:42 AM, Thorsten Behrens wrote:
> Jeff Aigner wrote:
>> I'm new to contributing here, so greetings to all! Attached is a patch
>> for bug 35938. It changes the Picture Caption dialog to remember the
>> last-used value of the caption separator text.
>>
> Hi Jeff,
> 
> can you please confirm your patch is under LGPLv3+/MPL license?
> 
> Thanks,
> 
> -- Thorsten
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] QA-hints ? -> question for devs !

[Cor Nouws]

Hi all,

Quite regular I have the feeling that at least me would be helped a bit 
by doing QA if there is some hint-list..


I mean, it is not often that I make time to install a nightly build and 
really start using it.
And then it feels a bit pointless just to do some often easy work - 
after all, work has to be done here.


Therefore the idea for some sort of collected hints. When one knows 
there has been done some work in this or that area. it feels much more 
sense full to do some tests ;-)


Yes, I know that for good testing it is necessary to check also the 
un-expected (so basically anything ;-), but you'll get what I mean.


And also I know that just by lurking on the list, I pick up some ideas, 
possible areas to have a look at, but with some extra hints...


What do people think if this?

Regards,


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

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

[Libreoffice] [PATCH] Removes mail function from make_installer.pl

[Samuel Cantrell]

I created a patch that I believe deletes the mail function from
mail_installer.pl and related modules, per the item listed on the Easy
Hacks wiki page.

I ran "make" and "make dev-install" and it works...however, if there's
something else I should run to ensure that the code is functioning
properly, please let me know.

Also, I created the patch from the "solenv/bin" directory, where the
code lies. Should I have created it from the bootstrap directory?

Thanks!

Samuel Cantrell
From b8571e6be489f528b7b3a6c5037f2d4b46a6dc7f Mon Sep 17 00:00:00 2001
From: Samuel Cantrell 
Date: Fri, 10 Jun 2011 17:29:32 -0700
Subject: [PATCH] Removes mail function from make_installer.pl

Removed mail module from installer subdirectory. I also removed code
that referenced the functions within this module (such as one
that sent a message if the process failed, one that sent a message
if the process succeeded, etc.)
---
 solenv/bin/make_installer.pl|1 -
 solenv/bin/modules/installer/copyproject.pm |1 -
 solenv/bin/modules/installer/mail.pm|  136 ---
 solenv/bin/modules/installer/worker.pm  |6 +-
 4 files changed, 2 insertions(+), 142 deletions(-)
 delete mode 100644 solenv/bin/modules/installer/mail.pm

diff --git a/solenv/bin/make_installer.pl b/solenv/bin/make_installer.pl
index e5734ce..d895cc9 100644
--- a/solenv/bin/make_installer.pl
+++ b/solenv/bin/make_installer.pl
@@ -48,7 +48,6 @@ use installer::helppack;
 use installer::languagepack;
 use installer::languages;
 use installer::logger;
-use installer::mail;
 use installer::packagelist;
 use installer::packagepool;
 use installer::parameter;
diff --git a/solenv/bin/modules/installer/copyproject.pm b/solenv/bin/modules/installer/copyproject.pm
index 93f4d29..0a31009 100644
--- a/solenv/bin/modules/installer/copyproject.pm
+++ b/solenv/bin/modules/installer/copyproject.pm
@@ -32,7 +32,6 @@ use installer::converter;
 use installer::files;
 use installer::globals;
 use installer::logger;
-use installer::mail;
 use installer::systemactions;
 use installer::worker;
 
diff --git a/solenv/bin/modules/installer/mail.pm b/solenv/bin/modules/installer/mail.pm
deleted file mode 100644
index f0e3251..000
--- a/solenv/bin/modules/installer/mail.pm
+++ /dev/null
@@ -1,136 +0,0 @@
-#*
-#
-# 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.
-#
-#*
-
-package installer::mail;
-
-use Net::SMTP;
-use installer::converter;
-use installer::exiter;
-use installer::ziplist;
-
-#
-# Sending a mail
-#
-
-sub send_mail
-{
-my ($message, $listenerstring, $mailinfostring, $languagesref, $destdir) = @_;
-
-my $listener = installer::converter::convert_stringlist_into_array($listenerstring, ",");
-my $mailinfo = installer::converter::convert_stringlist_into_array($mailinfostring, ",");
-
-my @listener = ();
-
-for ( my $i = 0; $i <= $#{$listener}; $i++ ) { push(@listener, ${$listener}[$i]); }
-for ( my $i = 0; $i <= $#{$mailinfo}; $i++ ) { ${$mailinfo}[$i] =~ s/\s*$//g; }
-
-my $smtphost = ${$mailinfo}[0];
-my $account = ${$mailinfo}[1];
-my $sender = ${$mailinfo}[2];
-
-if ( ! $smtphost ) { installer::exiter::exit_program("ERROR: Could not read SMTP Host in list file!", "send_mail"); }
-if ( ! $account ) { installer::exiter::exit_program("ERROR: Could not read Account in list file!", "send_mail"); }
-if ( ! $sender ) { installer::exiter::exit_program("ERROR: Could not read Sender in list file!", "send_mail"); }
-
-my $subject = "";
-my $basestring = $installer::globals::product . " " . $installer::globals::compiler . $installer::globals::productextension . " " . $installer::globals::build. " " . $installer::globals::buildid . " " . $$languagesref . "\n";
-if ( $message eq "ERROR" ) { $subject = "ERROR: $basestring" }
-if ( $messa

[Libreoffice] Easy Hack Completed - Remove non-compiled / dead code

[Júlio Hoffimann]

Hi devs,

One more Easy Hack completed:

http://wiki.documentfoundation.org/Development/Easy_Hacks#remove_non-compiled_.2F_dead_code

Someone finished it, there is no results in mine regex here.

Regards,
Júlio.

P.S.: Are you having problems with TDF Wiki? My account is not logging
anymore, i'm trying to change the password and the system tells me: you have
made too many recent login attempts, please wait before trying again. Ok,
i'll wait. ¬¬
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] Bug 33293 - [EasyHack] Make starting count of worksheets configurable

[Miklos Vajna]

On Fri, Jun 10, 2011 at 10:34:39PM +0200, Albert Thuswaldner 
 wrote:
> --- /dev/null
> +++ b/sc/source/ui/optdlg/tpdefaults.cxx
> @@ -0,0 +1,87 @@
> +/* -*- 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 2010 Novell, Inc.
> + *
> + * LibreOffice - a multi-platform office productivity suite
> + *
> + * This file is part of LibreOffice.
> + *
> + * LibreOffice 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.
> + *
> + * LibreOffice 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 LibreOffice.  If not, see
> + * 
> + * for a copy of the LGPLv3 License.

Nitpicking: Why don't you use the TEMPLATE.SOURCECODE.HEADER file from
the bootstrap root, which includes MPL and retains copyright?


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

Re: [Libreoffice] [PATCH] Bug 33293 - [EasyHack] Make starting count of worksheets configurable

[Albert Thuswaldner]

Hi,
It took some time to fix this. I moved stuff to a new computer, had
some build problems, implemented some changes (see below), and had a
fair share of bugs to straighten out. But now I think I'm finished
with this feature patch. Please have a look

- Changed the option tab page to defaults.
- Changed the name of the handler class to ScTpDefaultsOptions
- Changed the type of the tab enumerator to SCTAB
- Changed to c++ type static casts
- Renamed variables to more sensable names
- Added new option nodes in
officecfg/registry/schema/org/openoffice/Office/Calc.xcs
- Set the maximum allowed sheet tabs tat you can enter into the input
field to 32000

I also looked at checking that no negative numbers/character are
inserted. To my understanding, you don't have to to anything special,
it is taken care of in the input field. If you try to give a negative
value as an input it changes to the minimum value (in this case  have
been setting this to 1) and the same happens when you try to enter a
character. This is also consistent with how other input fields behave.

Regards,

/Albert

On Wed, Jun 1, 2011 at 16:15, Kohei Yoshida  wrote:
> Sorry I forgot to snip a large part of it.  Don't copy this behavior of
> mine... It's something to be used as a counter-example of good
> behavior. ;-)
>
> Kohei
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
diff --git a/sc/Library_scui.mk b/sc/Library_scui.mk
index 1e0ef6b..c85de9f 100644
--- a/sc/Library_scui.mk
+++ b/sc/Library_scui.mk
@@ -103,6 +103,7 @@ $(eval $(call gb_Library_add_exception_objects,scui,\
 sc/source/ui/optdlg/tpcalc \
 sc/source/ui/optdlg/tpcompatibility \
 sc/source/ui/optdlg/tpformula \
+sc/source/ui/optdlg/tpdefaults \
 sc/source/ui/optdlg/tpprint \
 sc/source/ui/optdlg/tpusrlst \
 sc/source/ui/optdlg/tpview \
diff --git a/sc/inc/docoptio.hxx b/sc/inc/docoptio.hxx
index 9ca84eb..de6b970 100644
--- a/sc/inc/docoptio.hxx
+++ b/sc/inc/docoptio.hxx
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include "scdllapi.h"
+#include "scmod.hxx"
 #include "optutil.hxx"
 
 #include "formula/grammar.hxx"
@@ -41,6 +42,7 @@ class SC_DLLPUBLIC ScDocOptions
 {
 double fIterEps;// epsilon value dazu
 sal_uInt16 nIterCount;// number
+SCTAB nInitTabCount;			// number of Tabs for new Spreadssheet doc
 sal_uInt16 nPrecStandardFormat; // precision for standard format
 ScOptionsUtil::KeyBindingType eKeyBindingType;
 sal_uInt16 nDay;	// Null date:
@@ -79,6 +81,8 @@ public:
 void   SetIter( sal_Bool bVal )			{ bIsIter = bVal; }
 sal_uInt16 GetIterCount() const			{ return nIterCount; }
 void   SetIterCount( sal_uInt16 nCount) { nIterCount = nCount; }
+SCTAB GetInitTabCount() const			{ return nInitTabCount; }
+void   SetInitTabCount( SCTAB nTabs) { nInitTabCount = nTabs; }
 double GetIterEps() const			{ return fIterEps; }
 void   SetIterEps( double fEps )	{ fIterEps = fEps; }
 
@@ -134,6 +138,7 @@ inline const ScDocOptions& ScDocOptions::operator=( const ScDocOptions& rCpy )
 bIsIgnoreCase		= rCpy.bIsIgnoreCase;
 bIsIter= rCpy.bIsIter;
 nIterCount			= rCpy.nIterCount;
+nInitTabCount   = rCpy.nInitTabCount;
 fIterEps			= rCpy.fIterEps;
 nPrecStandardFormat = rCpy.nPrecStandardFormat;
 eKeyBindingType = rCpy.eKeyBindingType;
@@ -162,6 +167,7 @@ inline int ScDocOptions::operator==( const ScDocOptions& rOpt ) const
 rOpt.bIsIgnoreCase			== bIsIgnoreCase
 &&	rOpt.bIsIter == bIsIter
 &&	rOpt.nIterCount 			== nIterCount
+&&  rOpt.nInitTabCount  == nInitTabCount
 &&	rOpt.fIterEps == fIterEps
 &&	rOpt.nPrecStandardFormat 	== nPrecStandardFormat
 &&  rOpt.eKeyBindingType== eKeyBindingType
@@ -221,16 +227,19 @@ class ScDocCfg : public ScDocOptions
 ScLinkConfigItemaFormulaItem;
 ScLinkConfigItem	aLayoutItem;
 ScLinkConfigItemaCompatItem;
+ScLinkConfigItemaDefaultsItem;
 
 DECL_LINK( CalcCommitHdl, void* );
 DECL_LINK( FormulaCommitHdl, void* );
 DECL_LINK( LayoutCommitHdl, void* );
 DECL_LINK( CompatCommitHdl, void* );
+DECL_LINK( DefaultsCommitHdl, void* );
 
 com::sun::star::uno::Sequence GetCalcPropertyNames();
 com::sun::star::uno::Sequence GetFormulaPropertyNames();
 com::sun::star::uno::Sequence GetLayoutPropertyNames();
 com::sun::star::uno::Sequence GetCompatPropertyNames();
+com::sun::star::uno::Sequence GetDefaultsPropertyNames();
 
 public:
 ScDocCfg();
diff --git a/sc/inc/helpids.h b/sc/inc/helpids.h
index de666a3..6273186 100644
--- a/sc/inc/helpids.h
+++ b/sc/inc/helpids.h
@@ -99,7 +99,7 @@
 #define HID_SCPAGE_COMPATIBILITY"SC_HID_SCPAGE_COMPATIBILITY"
 #define HID_SCPAGE_TABLE

Re: [Libreoffice] [REVIEWED] [PUSHED] Fix for a crash during Multiple Operations

[Kohei Yoshida]

On Fri, 2011-06-10 at 16:25 -0400, Kohei Yoshida wrote:
> P.S. BTW, Tor already gave me his sign-off on IRC and cherry-picked
> this
> to the -3-4 branch while writing this mail, so no review is
> needed. ;-)

Setting the right tags...

-- 
Kohei Yoshida, LibreOffice hacker, Calc


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

[Libreoffice] [REVIEW] Fix for a crash during Multiple Operations

[Kohei Yoshida]

I'd like to cherry-pick

http://cgit.freedesktop.org/libreoffice/calc/commit/?id=933a945c6c065d7a1897451bde57035d8597f580

to the -3-4 branch.  There is no bug report associated with this, but
Tor found this while running demo code for UNO C# binding.

This is also one of the unfortunate crashers resulted from the
DECLARE_LIST removal.  The original line as of 3.3 was

pDok->aTableOpList.Remove( pTableOp );

which removes the element from the container (if exists), but the object
itself is not destroyed.  After the List was replaced with
boost::ptr_vector, the line changed to

pTableOp = pDok->aTableOpList.release( pDok->aTableOpList.end()
).release();

which almost nailed it, except that the end position iterator

  pDok->aTableOpList.end()

doesn't point to any element so what that line does is undefined and
apparently causes a crash on Windows at least.  I'm pretty sure that
back() was intended to be used instead of end() there.  But even then,
the original code doesn't make the assumption that pTableOp was always
the last element of the list.  So, the right thing to do here to
faithfully emulate the original code is to try to find pTableOp position
using std::find_if, followed by the release of that element from the
ptr_vector container using the iterator returned from the find_if call.

Kohei

P.S. BTW, Tor already gave me his sign-off on IRC and cherry-picked this
to the -3-4 branch while writing this mail, so no review is needed. ;-)

-- 
Kohei Yoshida, LibreOffice hacker, Calc


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

Re: [Libreoffice] [REVIEW] Fix for #fdo36719

[Norbert Thiebaud]

On Fri, Jun 10, 2011 at 12:23 PM, Kohei Yoshida  wrote:
> Here is another bug fix I'd like to push to the -3-4 branch.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=36719
>
> Opening a document with a pivot table that is linked to a invalid
> database source crashes Calc in various places.  The attached patch
> fixes this.
>
> The changes are mostly simple things such as checking for NULL pointers
> before dereferencing.
>
> I'm attaching a patch instead of cherry-picking because the commit I
> pushed to master has a wrong bug ID in the message.
>
> Anyway, review & sign-off appreciated.

Pushed to 3-4

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

Re: [Libreoffice] Master build Seg faults in starmath test

[John LeMoyne Castle]

Caolan, 
I saw your related posts here and on bug 37668.   You have an amazing eye to
spot that very not obvious sign extension error as the difference between 64
bit OK and 32 not OK.  Thanks for making the connection explicit here.  

My first attempt failed (later?) in tail_build within cppucheck for filters. 
After going back to num-cpus=1 the build completes just fine.  Now smoketest
fails in dev-install which is clearly a separate issue with a simple
workaround.  I understand that I can actually build and test forward looking
work in master now.  \o/ yay \o/

I have multiple projects going ATM but I look forward to looking at the
smoketest failure in particular and the cppu unit tests in general as well.
- tysm -- jlc

--
View this message in context: 
http://nabble.documentfoundation.org/Master-build-Seg-faults-in-starmath-test-tp3020219p3050224.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

[Libreoffice] [REVIEW] Fix for #fdo36719

[Kohei Yoshida]

Here is another bug fix I'd like to push to the -3-4 branch.

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

Opening a document with a pivot table that is linked to a invalid
database source crashes Calc in various places.  The attached patch
fixes this.

The changes are mostly simple things such as checking for NULL pointers
before dereferencing.

I'm attaching a patch instead of cherry-picking because the commit I
pushed to master has a wrong bug ID in the message.

Anyway, review & sign-off appreciated.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc

>From 9b4370d6946f9dee5d363e362d86247df7d2958c Mon Sep 17 00:00:00 2001
From: Kohei Yoshida 
Date: Fri, 10 Jun 2011 13:06:49 -0400
Subject: [PATCH] fdo#36719: Prevent crash on pivot table with invalid database connection.

Check for NULL cache state to handle invalid database connection more
gracefully (i.e. without crashing).
---
 sc/source/core/data/dpcachetable.cxx |   11 ---
 sc/source/core/data/dpsdbtab.cxx |   10 +-
 sc/source/ui/view/cellsh1.cxx|   24 +++-
 3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/sc/source/core/data/dpcachetable.cxx b/sc/source/core/data/dpcachetable.cxx
index 40d34ac..b7b8a64 100644
--- a/sc/source/core/data/dpcachetable.cxx
+++ b/sc/source/core/data/dpcachetable.cxx
@@ -180,12 +180,12 @@ ScDPCacheTable::~ScDPCacheTable()
 
 sal_Int32 ScDPCacheTable::getRowSize() const
 {
-return getCache()->GetRowCount();
+return mpCache ? getCache()->GetRowCount() : 0;
 }
 
 sal_Int32 ScDPCacheTable::getColSize() const
 {
-return getCache()->GetColumnCount();
+return mpCache ? getCache()->GetColumnCount() : 0;
 }
 
 void ScDPCacheTable::fillTable(
@@ -313,6 +313,9 @@ void ScDPCacheTable::filterByPageDimension(const vector& rCriteria, c
 
 const ScDPItemData* ScDPCacheTable::getCell(SCCOL nCol, SCROW nRow, bool bRepeatIfEmpty) const
 { 
+if (!mpCache)
+return NULL;
+
SCROW nId= getCache()->GetItemDataId(nCol, nRow, bRepeatIfEmpty);
return getCache()->GetItemDataById( nCol, nId );
 }
@@ -331,6 +334,8 @@ void  ScDPCacheTable::getValue( ScDPValueData& rVal, SCCOL nCol, SCROW nRow, boo
 }
 String ScDPCacheTable::getFieldName(SCCOL  nIndex) const
 {
+if (!mpCache)
+return String();
 return getCache()->GetDimensionName( nIndex );
 }
 
@@ -410,7 +415,7 @@ void ScDPCacheTable::filterTable(const vector& rCriteria, Sequence< S
 
 SCROW ScDPCacheTable::getOrder(long nDim, SCROW nIndex) const
 {
-return getCache()->GetOrder(nDim, nIndex);
+return mpCache ? getCache()->GetOrder(nDim, nIndex) : 0;
 }
 
 void ScDPCacheTable::clear()
diff --git a/sc/source/core/data/dpsdbtab.cxx b/sc/source/core/data/dpsdbtab.cxx
index 417c142..d16d03e 100644
--- a/sc/source/core/data/dpsdbtab.cxx
+++ b/sc/source/core/data/dpsdbtab.cxx
@@ -136,10 +136,18 @@ void ScDatabaseDPData::SetEmptyFlags( sal_Bool /* bIgnoreEmptyRows */, sal_Bool
 void ScDatabaseDPData::CreateCacheTable()
 {
 if (!aCacheTable.empty())
+// cache table already created.
 return;
 
 if (!aCacheTable.hasCache())
-aCacheTable.setCache(mrImport.CreateCache());
+{
+const ScDPCache* pCache = mrImport.CreateCache();
+if (!pCache)
+// Cache creation failed.  Perhaps invalid database connection.
+return;
+
+aCacheTable.setCache(pCache);
+}
 
 aCacheTable.fillTable();
 }
diff --git a/sc/source/ui/view/cellsh1.cxx b/sc/source/ui/view/cellsh1.cxx
index 30d3933..90fb0ba 100644
--- a/sc/source/ui/view/cellsh1.cxx
+++ b/sc/source/ui/view/cellsh1.cxx
@@ -2127,6 +2127,27 @@ void ScCellShell::ExecuteExternalSource(
 _rRequest.Ignore();
 }
 
+namespace {
+
+bool isDPSourceValid(const ScDPObject& rDPObj)
+{
+if (rDPObj.IsImportData())
+{
+// If the data type is database, check if the database is still valid.
+const ScImportSourceDesc* pDesc = rDPObj.GetImportSourceDesc();
+if (!pDesc)
+return false;
+
+const ScDPCache* pCache = pDesc->CreateCache();
+if (!pCache)
+// cashe creation failed, probably due to invalid connection.
+return false;
+}
+return true;
+}
+
+}
+
 void ScCellShell::ExecuteDataPilotDialog()
 {
 ScModule* pScMod = SC_MOD();
@@ -2142,7 +2163,8 @@ void ScCellShell::ExecuteDataPilotDialog()
 pData->GetTabNo() );
 if ( pDPObj )   // on an existing table?
 {
-pNewDPObject.reset(new ScDPObject(*pDPObj));
+if (isDPSourceValid(*pDPObj))
+pNewDPObject.reset(new ScDPObject(*pDPObj));
 }
 else// create new table
 {
-- 
1.7.3.4

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

Re: [Libreoffice] [PATCH][PUISHED] List structure cleaning in impress

[Petr Mladek]

Rafael Dominguez píše v St 08. 06. 2011 v 22:07 -0430:

I have pushed it with the following changes:

=

1. 0001-Replace-List-for-std-vector-sd-FrameView.patch

replaced

+rViews.push_back( new ::sd::FrameView( mpDoc ) ); 

with

+pFrameView = new ::sd::FrameView( mpDoc ); 
+rViews.push_back( pFrameView );

in sd/source/filter/ppt/pptin.cxx, see 
http://cgit.freedesktop.org/libreoffice/impress/commit/?id=4ad79ee8fe80be4b7795c797b820b798da4a1891

The pFrameView pointer is later used in the method. It was not set after your 
change.


===


2. 0002-Replace-List-for-std-vector-String.impress.patch

Moved

String aToken( aString.GetToken( nToken, (sal_Unicode)',' ) );

to the original location in sd/source/filter/ppt/pptin.cxx
in the 3rd hunk.

Your original patch moved it in front of 
for ( nToken = 0; nToken < nTokenCount; nToken++ )

You see that the result depends on nToken, so it must be inside the cycle.


=


3. 0003-Replace-List-for-std-vector-rtl-OUString.impress.patch

used

  nStartSlide = pIter - maSlideNameList.begin() + 1;

in sd/source/filter/eppt/eppt.cxx in the 3rd hunk

-

used 

   sal_uInt32 nPageNumber = pIter - maSlideNameList.begin();

in sd/source/filter/eppt/eppt.cxx in the 4th hunk


-

used

   nPageIndex = pIter - maSlideNameList.begin();

in sd/source/filter/eppt/epptso.cxx in the 1st hunk


-

It was the same mistake in all three locations. The value was
incremented in the original "for" cycle. You replaced the for cycle with 
std::find but forgot to update the counter according to the result.



==

You do great job. It is normal to do mistakes. Well, I suggest to do
more breaks. It is not easy to keep concentration during this task. I
had to stop checking it yesterday evening because I stopped seeing the
problems ;-)

I am looking forward to see more nice patches from you.

Thanks a lot for contribution.


Best Regards,
Petr

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

Re: [Libreoffice] Duplicate code: libs-core/framework/test/typecfg/cfgview.cxx

[Michael Meeks]

On Thu, 2011-06-02 at 22:07 +0200, Chr. Rossmanith wrote:
> CFGView::impl_generateFilter{Modul}?ListHTML(). Shall I continue or is 
> it "only" a test?

I guess I'd look at the makefiles to see if it is linked into the main
binary at all (apparently a git grep for cfgview show it is not).

So I'd abandon it; much of that test code is not run, used, and much of
it doesn't compile either :-)

Thanks,

Michael.

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


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

Re: [Libreoffice] [REVIEWED] [PUSHED] fix for fdo#37872

[Kohei Yoshida]

On Fri, 2011-06-10 at 16:27 +0200, Markus Mohrhard wrote:

> this patch is for https://bugs.freedesktop.org/show_bug.cgi?id=37872 .
> I discussed the underlying problem with Kohei and we agreed that we
> should not allow points in range names any more. There are even more
> problems with points in range names than discussed in this bug report
> because points are used to seperate table names from cell address. 

Hi Markus,

The patch looks good, and I've sign-off on this & pushed to the -3-4
branch.  Thanks a lot for looking into this.

Just for an idea, we probably should disallow '!' also since we support
Excel A1 and Excel R1C1 formula syntax where '!' is used as the
separator.  But we can do that separately.

> This patch only avoids that new range names with points are created
> but will not deal with range names during import. This is much more
> difficult and nothing I want to introduce into 3.4.1. 

Yes.  Solving this is a bit tricky.  I don't have a good suggestion at
the moment so let's flag this as a known issue (in case someone asks),
and tries to figure out a way to solve it.

Best,

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc


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

[Libreoffice] [REVIEW]fix for fdo#37872

[Markus Mohrhard]

Hello,

this patch is for https://bugs.freedesktop.org/show_bug.cgi?id=37872 . I
discussed the underlying problem with Kohei and we agreed that we should not
allow points in range names any more. There are even more problems with
points in range names than discussed in this bug report because points are
used to seperate table names from cell address.

This patch only avoids that new range names with points are created but will
not deal with range names during import. This is much more difficult and
nothing I want to introduce into 3.4.1.

I think we should include this patch into the 3.4 branch so we will not have
to deal with new documents that cause problems.

Regards,
Markus


0001-fix-for-fdo-37872-we-don-t-allow-points-in-range-nam.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] replace OpenOffice.org and StarOffice references with LibreOffice

[Thorsten Behrens]

Michael Münch wrote:
> Just an idea, would a wiki page where you can list that your
> contributions until removal from that page  will be under license x/y
> sufficient? Or is it not reliable enough that the edit is from the same
> person sending a patch.
> 
Hi Michael,

because of the problems you mention, I'd not be so very happy with
that solution. Easiest is to just state the license with your patch
submission. Other people with frequent submission use something like
this - "until further notice, all my contributions here are
LGPLv3+/MPL licensed".

Cheers,

-- Thorsten


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

Re: [Libreoffice] How to add new commands for Math

[Michael Meeks]

Hi there,

On Fri, 2011-06-10 at 08:56 -0300, Rodolfo wrote:
> Hi. I'm new here at LibO development.

Welcome ! :-) fantastic to have you.

> I have interest on improve the Math component of LibreOffice by adding
> some new commands into it: things like a wide inverted breve for
> description of an arc between points A and B.

Sounds exciting.

> In order to do so, I've been looking & changing files with WideVec in
> starmath module (files like starmath.h, commands.src, parse.cxx, etc).
> Not successfully, though. My "wideibreve" attribute command isn't even
> recognized as a command: its texts appears normally.

Oh - that sucks; any chance you can send a patch so we can have a read
through / play here ? [ always good to talk code ].

> I know it's kinda vague, but any guides what I should do for add any
> new command? And how to put it into the toolbox?

I just had a poke; UI stuff is in .src files - in this case
starmath/source/toolbox.src - you would need to add a new magic number
in a .hrc file for that button (I guess), and then the src files are
associated with source files via those #define magic names. so eg. git
grep for RID_XCDOTY.

Having said that - in this case, there seems to be some magic, whereby
the toolboxitem identifier, is also the identifier of another string
that is a command ;-)

Looks like you'd just want to add a new entry for each of those &
bingo :-)

Are you on IRC ? poke me mmeeks on #libreoffice-dev on freenode for
something more interactive.

Hope that helps !

Michael.

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


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

Re: [Libreoffice] [PATCH] replace OpenOffice.org and StarOffice references with LibreOffice

[Michael Münch]

Am Freitag, den 10.06.2011, 08:36 +0200 schrieb Thorsten Behrens:
> Michael Meeks wrote:
> > None with me, as long as you commit Michael's nice patch with his
> > attribution too ;-) [ I assume Michael that this is under the MPL/LGPLv3
> > + (?) ]
> > 
> Hi Michael - please, can you confirm your patch is under said
> license?

Sorry, nearly missed that, my mail filter was miconfigured :(
Yes, LGPLv3+/MPL

Just an idea, would a wiki page where you can list that your
contributions until removal from that page  will be under license x/y
sufficient? Or is it not reliable enough that the edit is from the same
person sending a patch.

Regards,
Michael


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


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

Re: [Libreoffice] [GSoC 2011][svgexport] I need some help on exporting "all selected slides" task

[Thorsten Behrens]

Marco wrote:
> (2) I see that the Export Dialog has a "Selection" check box.
> I guess that its role is to let the user choose if he/she wants
> to export the whole presentation or only the selected slides.
> However I don't know yet, if/how the state of such check box is
> passed to the svg export filter, and in case it isn't, how to get
> that state.
> 
That should be the "SelectionOnly" property - e.g. look into
svtools/source/filter/SvFilterOptionsDialog.cxx - then again, that
so far has the rather different semantics of exporting the selection
_on a slide_.

> (3) The present svg export filter class is designed to export one
> or all slides. So adapting it to export a generic subset of slides
> will require a not so small effort as I thought (but surely doable :)).
> 
Cool! :)

> (4) In the present implementation I see that in the "single slide
> to export" case, once the slide/page to export has been retrieved,
> instead of taking a reference to that page as a data member, what is
> performed is to get the page number property, then to append it to
> the descriptor object as a "PagePos" property. This information is
> retrieved later by the implExport method and then forwarded to
> the other export methods as needed. What is the rationale for such
> a solution ? I am asking/pointing out that, because the selection
> object I get is of type Sequence< Reference < XInterface > >, but
> the actual type is Sequence< Reference < presentation::XDrawPage > >,
> so imo the simple solution would be to have a data member with such
> a type. Is this sensible ? Or, on the contrary, should I add an
> array data member containing the page numbers of all selected slides
> and then access a given slide through the rxDrawPages->getByIndex
> method ?
> 
I like your proposal better (i.e. holding a sequence of page refs).

> A side issue, while I was making some test I noticed that the
> following code produced some unexpected result:
> 
> OUString s1 = xObj1->getName();
> OUString s2 = xObj2->getName();
> 
> const char* ps1
>   = OUStringToOString( s1, RTL_TEXTENCODING_UTF8 ).getStr();
> const char* ps2
>   = OUStringToOString( s2, RTL_TEXTENCODING_UTF8 ).getStr();
> 
> OSL_TRACE( "s1= '%s'", ps1);
> OSL_TRACE( "s2= '%s'", ps2);
> 
> 
> From some code similar to the fragment above, and put inside
> a for loop, come out that the char const* pointer doesn't point
> to what it should. Is it normal that creating some new instance of
> a OUString invalidate the exported pointers to the internal
> data ? I am used to std container where an iterator is invalidated
> in some circumstances but only if you modify the container.
> 
Yes, this is to be expected - note that you create two temporaries,
via "OUStringToOString( sN, RTL_TEXTENCODING_UTF8 )", retrieve some
internal parts from it - and then those temporaries go out of scope
again.

Cheers,

-- Thorsten


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

Re: [Libreoffice] [GSoC 2011][svgexport] I need some help on exporting "all selected slides" task

[Thorsten Behrens]

Marco wrote:
> but I don know how to get such a component context object.
> So if you could give me some hint would be great!
> 
::comphelper::getProcessComponentContext() (from
comphelper/processfactory.hxx).

Didn't check whether you'll actually get the XSelectionSupplier
there - and I personally wouldn't spend too much time on that, now.
Generally, the strategy for this is, look into the implementation.
Which resides below sd/, so grepping for the interface in question
should lead you to the implementation.

For the slidesorter, most of that is here:
sd/source/ui/slidesorter/* 

HTH,

-- Thorsten


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

Re: [Libreoffice] [PUSHED] [PATCH] fdo#32263 - Config file location

[Petr Mladek]

Noel Power píše v Čt 09. 06. 2011 v 20:14 +0100:
> >>> Hmm, do we really want to use $HOME/.config/libreoffice by default?
> well, don't blame the messenger or in this case the patch pusher ;-) 
> But, it seems since we are a freedesktop application ( and we do already 
> have support for XDG_CONFIG_HOME ) that it is reasonable we should also 
> support the default config dir  (see  
> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) 
> which says when XDG_CONFIG_HOME is not  set then $HOME/.config should be 
> used

I see. I was not aware of the standard and the directory was alsmost
empty on my system, so I got confused. I agree that we should use it :-)

> Additionally using $HOME/.config/libreoffice instead of 
> $HOME/.config/.libreoffice also seems very sensible

sure, it is better to omit the dot in the subdirectory

> >>> Do we want to do it between 3.4 and 3.5?
> well now that is why I asked for 'thoughts' on this. I don't see it any 
> really more less disruptive introducing it in say '4.0' I'd hold the 
> view if we make such a change it's better sooner rather than later ( but 
> this is no pet peeve of mine so I have no real strong feelings )

You are right. The question is if we would have 4.0 at all. The
development is continuous, so...

OK, you convinced me. I think that you should commit the two patches and
be done with it for now :-)

I am sorry for the rumour.


Best Regards,
Petr

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

[Libreoffice] How to add new commands for Math

[Rodolfo]

Hi. I'm new here at LibO development.

I have interest on improve the Math component of LibreOffice by adding
some new commands into it: things like a wide inverted breve for
description of an arc between points A and B.

In order to do so, I've been looking & changing files with WideVec in
starmath module (files like starmath.h, commands.src, parse.cxx, etc).
Not successfully, though. My "wideibreve" attribute command isn't even
recognized as a command: its texts appears normally.

I know it's kinda vague, but any guides what I should do for add any
new command? And how to put it into the toolbox?

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

Re: [Libreoffice] with gbuild how to set a dependency of a cppunit test on a res file ?

[Norbert Thiebaud]

On Fri, Jun 10, 2011 at 6:25 AM, Norbert Thiebaud  wrote:
> On Fri, Jun 10, 2011 at 6:12 AM, Caolán McNamara  wrote:
>> i.e. from one of the tinderboxes it looks like I want a dependency from
>> the sw (at least, probably the sc as well) cppunit test on the .res file
>> of that module.
>>
>
> Ah, I remember now. I got that issue in starmath and I added that:
>
> $(call gb_CxxObject_get_target,starmath/qa/cppunit/test_starmath):
> $(WORKDIR)/AllLangRes/sm
>

The above is on one line, darn gmail auto-wrapper !

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

Re: [Libreoffice] with gbuild how to set a dependency of a cppunit test on a res file ?

[Bjoern Michaelsen]

Hi Caolán,

On Fri, 10 Jun 2011 12:12:05 +0100
Caolán McNamara  wrote:

> i.e. from one of the tinderboxes it looks like I want a dependency
> from the sw (at least, probably the sc as well) cppunit test on
> the .res file of that module.

I assume you need the .res file(s) at runtime, not at compile time.
Then it is:

$(call gb_CppunitTest_get_target,sw_filters_test) : \
$(call gb_AllLangResTarget_get_target,sw)

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen


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

Re: [Libreoffice] with gbuild how to set a dependency of a cppunit test on a res file ?

[Norbert Thiebaud]

On Fri, Jun 10, 2011 at 6:12 AM, Caolán McNamara  wrote:
> i.e. from one of the tinderboxes it looks like I want a dependency from
> the sw (at least, probably the sc as well) cppunit test on the .res file
> of that module.
>

Ah, I remember now. I got that issue in starmath and I added that:

$(call gb_CxxObject_get_target,starmath/qa/cppunit/test_starmath):
$(WORKDIR)/AllLangRes/sm

Norbert

> C.
>
> ___
> 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] with gbuild how to set a dependency of a cppunit test on a res file ?

[Caolán McNamara]

i.e. from one of the tinderboxes it looks like I want a dependency from
the sw (at least, probably the sc as well) cppunit test on the .res file
of that module.

C.

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

Re: [Libreoffice] [GSoC 2011][svgexport] I need some help on exporting "all selected slides" task

[Marco]

On Fri, 10 Jun 2011 08:28:04 +0200, Thorsten Behrens  
 wrote:



Ariel Constenla-Haile wrote:
I guess the export filter will get a reference to the document model,  
so he

will need to get the "SubController" [1]
Model -> Controller -> SubController


Hi Ariel,

neat! I'm always amazed about the depth of your API knowledge! :)

Marco - were you able to make anything of that?



Hi Thorsten,
this is my report on the state of the task:

(1) I succeed in getting the selected slides but only if they are
selected in the center Slide Sorter Pane (that is through the
"Slide Sorter" tab), not if they are selected in the Left Side Pane.

(2) I see that the Export Dialog has a "Selection" check box.
I guess that its role is to let the user choose if he/she wants
to export the whole presentation or only the selected slides.
However I don't know yet, if/how the state of such check box is
passed to the svg export filter, and in case it isn't, how to get
that state.

(3) The present svg export filter class is designed to export one
or all slides. So adapting it to export a generic subset of slides
will require a not so small effort as I thought (but surely doable :)).

(4) In the present implementation I see that in the "single slide
to export" case, once the slide/page to export has been retrieved,
instead of taking a reference to that page as a data member, what is
performed is to get the page number property, then to append it to
the descriptor object as a "PagePos" property. This information is
retrieved later by the implExport method and then forwarded to
the other export methods as needed. What is the rationale for such
a solution ? I am asking/pointing out that, because the selection
object I get is of type Sequence< Reference < XInterface > >, but
the actual type is Sequence< Reference < presentation::XDrawPage > >,
so imo the simple solution would be to have a data member with such
a type. Is this sensible ? Or, on the contrary, should I add an
array data member containing the page numbers of all selected slides
and then access a given slide through the rxDrawPages->getByIndex
method ?



A side issue, while I was making some test I noticed that the
following code produced some unexpected result:

OUString s1 = xObj1->getName();
OUString s2 = xObj2->getName();

const char* ps1
= OUStringToOString( s1, RTL_TEXTENCODING_UTF8 ).getStr();
const char* ps2
= OUStringToOString( s2, RTL_TEXTENCODING_UTF8 ).getStr();

OSL_TRACE( "s1= '%s'", ps1);
OSL_TRACE( "s2= '%s'", ps2);


From some code similar to the fragment above, and put inside
a for loop, come out that the char const* pointer doesn't point
to what it should. Is it normal that creating some new instance of
a OUString invalidate the exported pointers to the internal
data ? I am used to std container where an iterator is invalidated
in some circumstances but only if you modify the container.

Cheers,
   Marco


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSoC 2011][svgexport] I need some help on exporting "all selected slides" task

[Marco]

On Wed, 08 Jun 2011 12:23:25 +0200, Christian Lippka  wrote:


Am 08.06.2011 12:16, schrieb Marco:

but as I said aSelection internal type seems to be "void"
So from which controller should I get the XSelectionSupplier interface ?
You talk about an xModel object where should I get it from ?
I thought that I should get the frame/component representing the Slide  
sorter panel,

but I don't know how to do that, too.
Correctly you ask me where I am (that is which component/frame has the  
focus) when
I need this selection, well the answer is: inside the document export  
dialog, and

I guess that this makes all things more complex.
I currently do not have much time to look into this in detail. But I  
think


http://wiki.services.openoffice.org/wiki/Drawing_framework

can help you.  Basicly you will need to get the

"private:resource/floater/LeftImpressPane,  
private:resource/view/SlideSorter"


resource and find its XSelectionSupplier interface.  How this is  
actually done I don't

know (yet).



Hi Christian, Thorsten
I read the Drawing framework in details.
Now if I get the "private:resource/floater/LeftImpressPane,
private:resource/view/SlideSorter" resource what I have is a XView
interface, that in general does not provide a XSelectionSupplier
interface but probably the underlying object does.
Anyhow, in order to test it I need a Component Context instance
to get the resource:

Reference xController;  // This is regarded as  
given.
Reference xComponentContext;  // This also is regarded  
as given.


Reference xCM (xController, UNO_QUERY_THROW);
Reference xCC  
(xCM->getConfigurationController());


Reference xPane (xCC->getResource(
ResourceId::create(
xComponentContext,
FrameworkHelper::msLeftImpressPaneURL),
UNO_QUERY);

but I don know how to get such a component context object.
So if you could give me some hint would be great!

Cheers,
   Marco


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSoC 2011][svgexport] I need some help on exporting "all selected slides" task

[Marco]

On Thu, 09 Jun 2011 10:14:52 +0200, Alexander Thurgood  
 wrote:



Le 08/06/11 12:31, Marco a écrit :

Hi Marco,





Hi Christian,
thanks to point out this documentation! :)
I 'll read it as soon as possible.


There is an unpublished interface called :

com.sun.star.drawing.XSlideSorterBase

which might help you out (I haven't looked in detail), see here :

odkcommon/docs/common/ref/com/sun/star/drawing/SlideSorter.html




Hi Alex,
interesting interface, anyhow it does not provide any method to get
selected slide thumbnails. The only possibility would be if we
could query it for a XSelectioSupplier interface, but to test that
I should be able to get the XSlideSorterBase interface, and at present
I don't know how to do that.

Cheers,
   Marco


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSoC 2011][svgexport] I need some help on exporting "all selected slides" task

[Marco]

On Wed, 08 Jun 2011 13:18:27 +0200, Ariel Constenla-Haile  
 wrote:



Hello Thorsten,

On Wednesday 08 June 2011, 05:29, Thorsten Behrens wrote:

Marco wrote:
> I hoped to get some type of object or container that let me to find
> the selected thumbnail slides out.
> On the contrary the result is that the selection type is "void",
> that means "no selection" IMO.
>
> So I don't know how to carry on this task.

Hi Marco,

Cc-ing the list, this may be of public interest - for the moment, I
suggest you simply export *all* slides. Christian, off the top of
your head, is there a way to retrieve the current selection from the
Slidesorter via UNO?


I guess the export filter will get a reference to the document model, so  
he

will need to get the "SubController" [1]
Model -> Controller -> SubController


skip



aSelection = oSubController.getSelection()
'should be a "com.sun.star.drawing.ShapeCollection"

aPage = oSubController.getCurrentPage()
End Sub


[1] mmm documented but commented
http://svn.services.openoffice.org/opengrok/xref/DEV300_m106/offapi/com/sun/star/drawing/DrawingDocumentDrawView.idl#194



Hi Ariel,
thanks a lot for your example. It has been really useful!
The only drawback is that this method works only if I select
the slide thumbnails in the Slide Sorter Center Pane
(that is through the "Slide Sorter" tab), but if I select them
in the Left Side Impress Pane the selection is empty.
In fact the "com.sun.star.presentation.SlidesView"  service is
supported by the "drawing::XDrawSubController" interface only
when the Slide Sorter Center Pane is visible.

Cheers,
   Marco


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
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

Bug 35673 depends on bug 37622, which changed state.

Bug 37622 Summary: xls file loses formatting
https://bugs.freedesktop.org/show_bug.cgi?id=37622

   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: [Libreoffice] [REVIEW] [PUSHED] Fix for fdo#37622

[Katarina Machalkova]

> Ok.  This is the last one for today.
> 
> Here is the bug
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=37622
> 
> and here is the commit I'd like to cherry-pick to the -3-4 branch
> 
> http://cgit.freedesktop.org/libreoffice/calc/commit/?id=099fd0fd91485797362
> 259e45b1a971dda0511a3
> 
> The old code incorrectly returned NULL when the last font ID was passed,
> because of the wrong boundary check.
> 
> In XLS, font IDs are zero-based when it's less than 4, but it becomes
> one based when greater than 4 according to the spec.  This lookup
> behavior was accidentally altered during ScfDefList removal.

Reviewed, cherry-picked & pushed.
Thanks for fixing this, I was pretty close to finding the root cause of the 
last font in the list not being applied, but not quite there yet.

B.
-- 
  \  Katarina Machalkova
  \\\__o  LibO developer
__\\\'/_  & hedgehog painter


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

Re: [Libreoffice] [REVIEW] fix for default windows Traditional Chinese font

[Caolán McNamara]

On Fri, 2011-06-10 at 17:26 +0800, Tseng, Cheng-Chia wrote:
> I have checked the commit. There are some comments below:
> 
> "方正明體" do not used commonly on Windows, only Sun StarSuite provides this font.
> 
> "AR PL Mingti2L Big5", "文鼎PL細上海宋Uni; AR PL ShanHeiSun Uni" has been
> abandoned. Now they have been integrated into "AR PL UMing TW". AR PL
> UMIng series has three gylph viriants, TW, HK and CN.
> 
> "AR PL ZenKai Uni" has been abandoned too. Now it is called "AR PL
> UKai TW", AR PL UKai series has three gylph viriants, TW, HK and CN.

These were there already before my modification to swap 微软雅黑 with 微
軟正黑體 for the traditional locales so there's no change in relation to
the other entries in there.

For the above desired changes, and the other potential changes, it would
be ideal if a native speaker like you that is familiar with the fonts in
question could create a patch for that above VCL.xcu with all the
changes you want. Just list the fonts in order of preference for each
category. You could either place the slightly out-of-date fonts to the
end of the list if they are still commonly installed, or remove them
entirely if they are very out-of-date.

As an aside, there is no harm in having a font that doesn't exist in the
list, under windows LibreOffice will just look for the next one in the
list. And under Linux fontconfig will suggest something based off the
first entry and the rest of the contents don't get looked at anyway.

C.

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

Re: [Libreoffice] [REVIEW] fix for default windows Traditional Chinese font

[Tseng, Cheng-Chia]

Plus, there are one Chinese font which is polular on Linux platform
now, please consider to include it in CJK_HEADING, CJK_PRESENTATION.
That is "文泉驛微米黑 (WenQuanYi Micro Hei )" for TW and HK (文泉驿微米黑 for CN).
It looks like 微軟正黑體, so I think it is better to place it after 微軟正黑體.


-- 
Sincerely,
by Cheng-Chia Tseng
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] fix for default windows Traditional Chinese font

[Tseng, Cheng-Chia]

I have checked the commit. There are some comments below:

"方正明體" do not used commonly on Windows, only Sun StarSuite provides this font.

"AR PL Mingti2L Big5", "文鼎PL細上海宋Uni; AR PL ShanHeiSun Uni" has been
abandoned. Now they have been integrated into "AR PL UMing TW". AR PL
UMIng series has three gylph viriants, TW, HK and CN.

"AR PL ZenKai Uni" has been abandoned too. Now it is called "AR PL
UKai TW", AR PL UKai series has three gylph viriants, TW, HK and CN.



-- 
Sincerely,
by Cheng-Chia Tseng
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [Libreoffice-ux-advise] Performance improvements for calcs' sheet actions

[Michael Meeks]

Hi Christophe,

On Wed, 2011-06-08 at 00:18 +0200, Christoph Noack wrote:
> Let's add some more issues ... and thoughts :-)

Nice input indeed :-) thanks.

> True. Of course, there is some magic on some platforms to let the
> progress indicators appear "continuously updated", but the most sane
> solution is to really provide smooth data to them. As Cor pointed out,
> this is for the "experience" part in UX ... everything else behaves
> 80's :-)

Heh - sure; so - if we have a -very- long running task, the progress
bar will update in small, smooth increments - still at 2 fps - but
you'll see it inching along like a snail. So that is no problem.

If it takes four seconds we get perhaps the worst case: for the first
1/2 second we'll not see anything - then we get 12%, then 25% then 37.5%
then 50% and so on over the remaining 3.5 seconds. Personally I think
that is 'smooth enough' amusingly the reason it has to be a little
chunky like that is that the 'Experience' already got to work on
progress bars themselves: adding expensive to render gradients etc. to
the theme ;-)

> Moreover, in some rare cases the real performance (efficiency) of the
> system is less important than the "perceived progress" - a task may take
> longer, but showing a good progress indicator makes it feel quicker.
> (There is some research data out there, but I skip it for the moment.)

Agreed; in this case though being three-times slower and taking 12
seconds not four is rather sad for breaking the work-flow :-)

> Thus, if we know (and its possible), we should simply avoid the progress
> indicator for such fast operations.

Sure - so this should be quite easy; after our first half-second, we
can judge the percentage completeness, if it is >50% we can not show it
[ though we would need to un-conditionally if it is not complete another
second later I guess ].

> @Michael: and of course we need lots of configuration options ;-)))

:-)

> it seems they start any kind of operation and then check if there
> is a need to show a progress bar. If yes, they do so and start from
> 0% ... (Later on, they use progress dialogs, but this is another story.)

Interesting.

> By the way, another question. One of the things that might (visually)
> drive people nuts is the fact, that we (almost) use the whole width of
> the status bar to show the progress bar ... on large screens, this leads
> to 50cm progressbar flashing.

Wow - so; it would be great to shrink that progress bar - that would
simultaneously make it much faster to render; mine is perhaps 1600
pixels wide so with a gradient so: perhaps this is the key fix.

>  Would it be possible to adapt the progress
> bar to be (let's say) 200px (if space permits), or smaller (if the LibO
> window size isn't adequate). Visually, this would be an improvement ...

Yes ! :-) it is a win-win I think.

> For those who want to dig a bit deeper into the "beauty and utility of
> progress indicators",

Thanks for the helpful input; good stuff. Markus - do you have enough
to go on ? and/or are you excited :-)

ATB,

Michael.

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

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

Re: [Libreoffice] [REVIEW] [PUSHED] fix for default windows Traditional Chinese font

[Tor Lillqvist]

> think we should consider this as a low-hanging for to cherry-pick to 3-4

Cherry-picked, thanks!

--tml


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

[Libreoffice] [REVIEW] fix for default windows Traditional Chinese font

[Caolán McNamara]

So, reading
http://blogs.linux.ie/caolan/2011/02/09/small-libreoffice-font-dropdown-list-improvements/comment-page-1/#comment-157304
I see a complaint that "LibreOffice now even choose 'Microsoft YaHei'
for Traditional Chinese locale in Windows". And indeed YaHei (微软雅黑)
is a Simplified Chinese font, the Traditional equivalent is JhengHei (微
軟正黑體), and YaHei is listed as the default font for all zh-CN, zh-sg,
zh-TW and zh-HK

http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=231cdd06807a40ed3b9a3b9c896a22b46ea0a219
is the commit to set the default font to JhengHei for zh-TW and zh-HK, I
think we should consider this as a low-hanging for to cherry-pick to 3-4

This affects windows mostly, under linux only the first font in the list
is requested from fontconfig, along with the language desired, and the
fontconfig suggested returned font is used.

C.

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

Re: [Libreoffice] warning: the use of `tmpnam' is dangerous, better use `mkstemp'

[Caolán McNamara]

On Thu, 2011-06-09 at 23:43 +0200, Jesús Corrius wrote:
> On Thu, Jun 9, 2011 at 11:24 PM, Julien Nabet  wrote:
> > In the Unix man of tmpnam, we can read this :
> > "
> > BUGS
> >   Never use this function.  Use mkstemp(3) or tmpfile(3) instead.
> > "
>
> The best option probably (don't throw tomatoes at me!) would be to use
> something similar to this for windows (maybe in sal?):

See sal/inc/osl/file.hxx osl::File::createTempFile and lxr for
createTempFile

C.

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