[Libreoffice] [PATCH] vcl: Printing UI "page range" autofocus

[Maxim Iorsh]

When the user selects "Pages" radio button in the Range section, it is very
reasonable to expect that she would now want to specify the range. Thus moving
the focus automatically to the page range edit box would save the user a mouse
click.

Code is contributed under the LGPLv3+ / MPL.

Signed-off-by: Maxim Iorsh 
---
 vcl/source/window/printdlg.cxx |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/vcl/source/window/printdlg.cxx b/vcl/source/window/printdlg.cxx
index 969030c..5a59281 100644
--- a/vcl/source/window/printdlg.cxx
+++ b/vcl/source/window/printdlg.cxx
@@ -2300,6 +2300,27 @@ IMPL_LINK( PrintDialog, UIOption_RadioHdl, RadioButton*, i_pBtn )
 sal_Int32 nVal = it->second;
 pVal->Value <<= nVal;
 
+// when page range option is selected, focus on range input.
+if (pVal->Name.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "PrintContent" ) ) &&
+nVal == 1)
+{
+std::map< rtl::OUString, std::vector< Window* > >::const_iterator pit = maPropertyToWindowMap.find( rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "PageRange" ) ) );
+if( pit != maPropertyToWindowMap.end() )
+{
+const std::vector< Window* >& rWindows( pit->second );
+if( ! rWindows.empty() )
+{
+// we should have an Edit for this one
+Edit* pRange = dynamic_cast< Edit* >( rWindows.front() );
+if( pRange )
+{
+pRange->SetSelection( Selection( 0, 0x ) ); // select all
+pRange->GrabFocus();
+}
+}
+}
+}
+
 checkOptionalControlDependencies();
 
 // update preview and page settings
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] IDL "hyper" / Java "long"

[MarcinGutman]

> Calc add-ins do not support functions that take or
> return UNO type hyper.
> .. however, it should work if the .idl file instead
> uses unsigned hyper ...
>
 
This is why I started this topic.
Moreover, NetBeans Wizard for Calc add-ins shows Java "int" and this is
mapped correctly as "long" in IDL. But there is no Java "long". You have
to choose "double" or "Object". On the other hand "unsigned hyper" works
fine. So, why there is "int" in Wizard... use double instead.

If you write a code and you want "long" you use "long" not "double" with
Math.round().

Am I the first one who wants "clean long" in Calc add-in?  

- Marcin


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

Re: [Libreoffice] Fwd: Re: patch for scan-diialog

[Rob Snelders]

Hi,

I have added the feature with screenshot to the ReleaseNotes.

Stephan: I'm compiling the code and will test the patch when it is done.


M.V.G.
Rob Snelders

On vr 21 okt 2011 17:53:31 CEST, Michael Meeks wrote:

Hi Rob,

On Thu, 2011-10-20 at 20:37 +0200, Rob Snelders wrote:

Here are 3 patches that together make the code for adding the
scan-button to the sanedlg.


Great to see that :-) Any chance you could drop a nice screenshot /
feature note and your name at:

http://wiki.documentfoundation.org/ReleaseNotes/3.5

which saves lots of time later when it comes to building the 3.5
release notes.

Thanks again,

Michael.


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

Re: [Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

[Michael Meeks]

On Fri, 2011-10-21 at 18:16 +0200, Stephan Bergmann wrote:
> Unfortunately, this breaks the build, as basic now has a (missing) 
> dependency on sfx2, which already depends on basic.

Fair enough, my mistake. I dropped sfx from the link line, it's not
actually required, leaving the link dependencies the same as
Library_sb.mk - the beautiful unit test still passes nicely.

Thanks for the heads up :-)

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] [PUSHED] Fix for Bug fdo#41997 clean VCL enumeration

[Olivier Hallot]

Hi Michael

Em 21-10-2011 17:51, Michael Meeks escreveu:

Hi Olivier,

On Fri, 2011-10-21 at 17:15 -0200, Olivier Hallot wrote:

The following patch fixes bug fdo41997.
https://bugs.freedesktop.org/show_bug.cgi?id=41997

Wow - no sooner than I filed it, it got closed :-) great work. I pushed
the patch, it looks like you caught all the cases in mac / win32; any
chance you can close the bug ?


Will do... I found bugzilla quite strange these days with big red banner 
each time I submit something...





If you had more time, cleaning up the whole enumeration to be VCL_
prefixed would be nice too,


you mean prefix VCL_ to the remaining enumeration?
like
INPUT_PAINT
INPUT_MOUSEANDKEYBOARD
etc...?

I thought to do it, but did'nt dare to go beyond strict instructions (me 
quite shy).




  and of course it'd be great to have a
statement of MPL/LGPLv3+ for your patches linked at:
http://wiki.documentfoundation.org/Development/Developers if you have a
minute ?


Done. Let me know if this is enough.




Much appreciated though - it should make the Windows compile that bit
nicer :-) [ have you tried setting up the MingW build ? it's
particularly good for showing off these windows specific warnings - of
which there are a large number :-]


This is for me "to go boldly where no man never went before"... but I 
don't have green blood or sharp ears, so i'll try.




Oh - and ! really great to see you in Paris, and hope you got back
uneventfully ;-)


like any 11 hours flight in economy class... quite chewed.

Kind regards

--
Olivier Hallot
Founder, Steering Commitee Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812

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

Re: [Libreoffice] gbuild: use gb_CHECKOBJECTOWNER to check for double linked objects

[Michael Meeks]

On Fri, 2011-10-21 at 21:02 +0200, Michael Stahl wrote:
> have replaced this implementation with a new, faster one:

Nice work :-)

> but perhaps that just means my new machine is too fast; perhaps somebody 
> wants to benchmark it on their netbook/Alpha box/ARM wristwatch

You know I always knew I wanted that ARM wristwatch for something.

All the best,

Michael.

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

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

[Libreoffice] [PUSHED] Fix for Bug fdo#41997 clean VCL enumeration

[Michael Meeks]

Hi Olivier,

On Fri, 2011-10-21 at 17:15 -0200, Olivier Hallot wrote:
> The following patch fixes bug fdo41997.
> https://bugs.freedesktop.org/show_bug.cgi?id=41997

Wow - no sooner than I filed it, it got closed :-) great work. I pushed
the patch, it looks like you caught all the cases in mac / win32; any
chance you can close the bug ?

If you had more time, cleaning up the whole enumeration to be VCL_
prefixed would be nice too, and of course it'd be great to have a
statement of MPL/LGPLv3+ for your patches linked at:
http://wiki.documentfoundation.org/Development/Developers if you have a
minute ?

Much appreciated though - it should make the Windows compile that bit
nicer :-) [ have you tried setting up the MingW build ? it's
particularly good for showing off these windows specific warnings - of
which there are a large number :-]

Oh - and ! really great to see you in Paris, and hope you got back
uneventfully ;-)

All the best,

Michael.

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

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

[Libreoffice] [PATCH] Fix for Bug fdo#41997 clean VCL enumeration

[Olivier Hallot]

Hi

The following patch fixes bug fdo41997, clean VCL enumeration.

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

Note: tested only in Linux, not tested in Windows (no windows available 
for me)


Regards

--
Olivier Hallot
Founder, Steering Commitee Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812

>From 423326b440f05f5cb137d841600f9aede01aa5a0 Mon Sep 17 00:00:00 2001
From: Olivier Hallot 
Date: Fri, 21 Oct 2011 16:54:35 -0200
Subject: [PATCH] Fix for bug fdo#41997, cleanup vcl enumeration

---
 editeng/source/editeng/editeng.cxx   |2 +-
 editeng/source/editeng/impedit3.cxx  |2 +-
 formula/source/ui/dlg/formula.cxx|4 ++--
 sc/source/core/tool/chartlis.cxx |2 +-
 sc/source/ui/app/scmod.cxx   |2 +-
 sd/source/ui/tools/IdleDetection.cxx |2 +-
 svtools/source/control/inettbc.cxx   |2 +-
 svtools/source/edit/textview.cxx |2 +-
 sw/source/core/layout/paintfrm.cxx   |2 +-
 sw/source/core/view/viewsh.cxx   |2 +-
 sw/source/ui/docvw/edtwin.cxx|2 +-
 vcl/aqua/source/app/salinst.cxx  |4 ++--
 vcl/inc/vcl/apptypes.hxx |6 +++---
 vcl/unx/generic/app/salinst.cxx  |4 ++--
 vcl/win/source/app/salinst.cxx   |2 +-
 15 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/editeng/source/editeng/editeng.cxx b/editeng/source/editeng/editeng.cxx
index 5d745c0..573b30b 100644
--- a/editeng/source/editeng/editeng.cxx
+++ b/editeng/source/editeng/editeng.cxx
@@ -1195,7 +1195,7 @@ sal_Bool EditEngine::PostKeyEvent( const KeyEvent& rKeyEvent, EditView* pEditVie
 DBG_ASSERT( !bReadOnly, "ReadOnly but modified???" );
 // Idle-Formatter only when AnyInput.
 if ( bAllowIdle && pImpEditEngine->GetStatus().UseIdleFormatter()
-&& Application::AnyInput( INPUT_KEYBOARD) )
+&& Application::AnyInput( VCL_INPUT_KEYBOARD) )
 pImpEditEngine->IdleFormatAndUpdate( pEditView );
 else
 pImpEditEngine->FormatAndUpdate( pEditView );
diff --git a/editeng/source/editeng/impedit3.cxx b/editeng/source/editeng/impedit3.cxx
index b4efe14..8f059a3 100644
--- a/editeng/source/editeng/impedit3.cxx
+++ b/editeng/source/editeng/impedit3.cxx
@@ -327,7 +327,7 @@ void ImpEditEngine::UpdateViews( EditView* pCurView )
 
 IMPL_LINK( ImpEditEngine, OnlineSpellHdl, Timer *, EMPTYARG )
 {
-if ( !Application::AnyInput( INPUT_KEYBOARD ) && GetUpdateMode() && IsFormatted() )
+if ( !Application::AnyInput( VCL_INPUT_KEYBOARD ) && GetUpdateMode() && IsFormatted() )
 DoOnlineSpelling();
 else
 aOnlineSpellTimer.Start();
diff --git a/formula/source/ui/dlg/formula.cxx b/formula/source/ui/dlg/formula.cxx
index 97ef663..3b7c2ec 100644
--- a/formula/source/ui/dlg/formula.cxx
+++ b/formula/source/ui/dlg/formula.cxx
@@ -592,7 +592,7 @@ sal_Bool FormulaDlg_Impl::CalcValue( const String& rStrExp, String& rStrResult )
 {
 // Only calculate the value when there isn't any more keyboard input:
 
-if ( !Application::AnyInput( INPUT_KEYBOARD ) )
+if ( !Application::AnyInput( VCL_INPUT_KEYBOARD ) )
 {
 bResult = m_pHelper->calculateValue(rStrExp,rStrResult);
 }
@@ -630,7 +630,7 @@ sal_Bool FormulaDlg_Impl::CalcStruct( const String& rStrExp)
 {
 // Only calculate the value when there isn't any more keyboard input:
 
-if ( !Application::AnyInput( INPUT_KEYBOARD ) )
+if ( !Application::AnyInput( VCL_INPUT_KEYBOARD ) )
 {
 pStructPage->ClearStruct();
 
diff --git a/sc/source/core/tool/chartlis.cxx b/sc/source/core/tool/chartlis.cxx
index 8c52fe4..6f9129d 100644
--- a/sc/source/core/tool/chartlis.cxx
+++ b/sc/source/core/tool/chartlis.cxx
@@ -567,7 +567,7 @@ void ScChartListenerCollection::StartTimer()
 
 IMPL_LINK( ScChartListenerCollection, TimerHdl, Timer*, EMPTYARG )
 {
-if ( Application::AnyInput( INPUT_KEYBOARD ) )
+if ( Application::AnyInput( VCL_INPUT_KEYBOARD ) )
 {
 aTimer.Start();
 return 0;
diff --git a/sc/source/ui/app/scmod.cxx b/sc/source/ui/app/scmod.cxx
index 7932fca..b4284e7 100644
--- a/sc/source/ui/app/scmod.cxx
+++ b/sc/source/ui/app/scmod.cxx
@@ -1877,7 +1877,7 @@ IMPL_LINK( ScModule, IdleHandler, Timer*, EMPTYARG )
 
 IMPL_LINK( ScModule, SpellTimerHdl, Timer*, EMPTYARG )
 {
-if ( Application::AnyInput( INPUT_KEYBOARD ) )
+if ( Application::AnyInput( VCL_INPUT_KEYBOARD ) )
 {
 aSpellTimer.Start();
 return 0;   // dann spaeter wieder...
diff --git a/sd/source/ui/tools/IdleDetection.cxx b/sd/source/ui/tools/IdleDetection.cxx
index 4ba6163..e0fba1a 100644
--- a/sd/source/ui/tools/IdleDetection.cxx
+++ b/sd/source/ui/tools/IdleDetection.cxx
@@ -59,7 +59,7 @@ sal_Int32 IdleDetection::GetIdleState (const ::Window* pWindow)
 
 sal_Int32 IdleDetection::CheckInputPending (void)
 {
-if (GetpApp()->AnyInput(IN

Re: [Libreoffice] minutes of tech. steering call ...

[Stephan Bergmann]

On 10/21/2011 03:57 PM, Michael Meeks wrote:

On Fri, 2011-10-21 at 14:51 +0200, Stephan Bergmann wrote:

That would of course mean shipping some
duplicate legacy MSVC++ compiled libraries, but ... surely do-able.


It would not suffice to ship them, one would also need to build them.
Kind of back to square one.


For windows - shipping a pre-canned set of compiled compatibility
libraries doesn't look too disgusting to me; at least - it seems a lot
less disgusting than using MSVC++ and cygwin :-)

tar xf ure-bincompat-win32-tgz

is not in itself such a horrific outcome from a cross-compiled solution
(assuming the build of that is well documented, should you happen to
have lots of time and a proprietary system + compiler to do it). Clearly
someone needs to build them once.


There will invariably be situations were things in there will need to 
get fixed.  And if that code is only built once in a year, it will 
bitrot and no longer build in a year from now.


Been there with moz_prebuilt.  No thanks.  :)

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

[Libreoffice] Fix for Bug fdo#41997 clean VCL enumeration

[Olivier Hallot]

The following patch fixes bug fdo41997.

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

Note: tested only in Linux, not tested in Windows. No

Regards

--
Olivier Hallot
Founder, Steering Commitee Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812

>From 423326b440f05f5cb137d841600f9aede01aa5a0 Mon Sep 17 00:00:00 2001
From: Olivier Hallot 
Date: Fri, 21 Oct 2011 16:54:35 -0200
Subject: [PATCH] Fix for bug fdo#41997, cleanup vcl enumeration

---
 editeng/source/editeng/editeng.cxx   |2 +-
 editeng/source/editeng/impedit3.cxx  |2 +-
 formula/source/ui/dlg/formula.cxx|4 ++--
 sc/source/core/tool/chartlis.cxx |2 +-
 sc/source/ui/app/scmod.cxx   |2 +-
 sd/source/ui/tools/IdleDetection.cxx |2 +-
 svtools/source/control/inettbc.cxx   |2 +-
 svtools/source/edit/textview.cxx |2 +-
 sw/source/core/layout/paintfrm.cxx   |2 +-
 sw/source/core/view/viewsh.cxx   |2 +-
 sw/source/ui/docvw/edtwin.cxx|2 +-
 vcl/aqua/source/app/salinst.cxx  |4 ++--
 vcl/inc/vcl/apptypes.hxx |6 +++---
 vcl/unx/generic/app/salinst.cxx  |4 ++--
 vcl/win/source/app/salinst.cxx   |2 +-
 15 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/editeng/source/editeng/editeng.cxx b/editeng/source/editeng/editeng.cxx
index 5d745c0..573b30b 100644
--- a/editeng/source/editeng/editeng.cxx
+++ b/editeng/source/editeng/editeng.cxx
@@ -1195,7 +1195,7 @@ sal_Bool EditEngine::PostKeyEvent( const KeyEvent& rKeyEvent, EditView* pEditVie
 DBG_ASSERT( !bReadOnly, "ReadOnly but modified???" );
 // Idle-Formatter only when AnyInput.
 if ( bAllowIdle && pImpEditEngine->GetStatus().UseIdleFormatter()
-&& Application::AnyInput( INPUT_KEYBOARD) )
+&& Application::AnyInput( VCL_INPUT_KEYBOARD) )
 pImpEditEngine->IdleFormatAndUpdate( pEditView );
 else
 pImpEditEngine->FormatAndUpdate( pEditView );
diff --git a/editeng/source/editeng/impedit3.cxx b/editeng/source/editeng/impedit3.cxx
index b4efe14..8f059a3 100644
--- a/editeng/source/editeng/impedit3.cxx
+++ b/editeng/source/editeng/impedit3.cxx
@@ -327,7 +327,7 @@ void ImpEditEngine::UpdateViews( EditView* pCurView )
 
 IMPL_LINK( ImpEditEngine, OnlineSpellHdl, Timer *, EMPTYARG )
 {
-if ( !Application::AnyInput( INPUT_KEYBOARD ) && GetUpdateMode() && IsFormatted() )
+if ( !Application::AnyInput( VCL_INPUT_KEYBOARD ) && GetUpdateMode() && IsFormatted() )
 DoOnlineSpelling();
 else
 aOnlineSpellTimer.Start();
diff --git a/formula/source/ui/dlg/formula.cxx b/formula/source/ui/dlg/formula.cxx
index 97ef663..3b7c2ec 100644
--- a/formula/source/ui/dlg/formula.cxx
+++ b/formula/source/ui/dlg/formula.cxx
@@ -592,7 +592,7 @@ sal_Bool FormulaDlg_Impl::CalcValue( const String& rStrExp, String& rStrResult )
 {
 // Only calculate the value when there isn't any more keyboard input:
 
-if ( !Application::AnyInput( INPUT_KEYBOARD ) )
+if ( !Application::AnyInput( VCL_INPUT_KEYBOARD ) )
 {
 bResult = m_pHelper->calculateValue(rStrExp,rStrResult);
 }
@@ -630,7 +630,7 @@ sal_Bool FormulaDlg_Impl::CalcStruct( const String& rStrExp)
 {
 // Only calculate the value when there isn't any more keyboard input:
 
-if ( !Application::AnyInput( INPUT_KEYBOARD ) )
+if ( !Application::AnyInput( VCL_INPUT_KEYBOARD ) )
 {
 pStructPage->ClearStruct();
 
diff --git a/sc/source/core/tool/chartlis.cxx b/sc/source/core/tool/chartlis.cxx
index 8c52fe4..6f9129d 100644
--- a/sc/source/core/tool/chartlis.cxx
+++ b/sc/source/core/tool/chartlis.cxx
@@ -567,7 +567,7 @@ void ScChartListenerCollection::StartTimer()
 
 IMPL_LINK( ScChartListenerCollection, TimerHdl, Timer*, EMPTYARG )
 {
-if ( Application::AnyInput( INPUT_KEYBOARD ) )
+if ( Application::AnyInput( VCL_INPUT_KEYBOARD ) )
 {
 aTimer.Start();
 return 0;
diff --git a/sc/source/ui/app/scmod.cxx b/sc/source/ui/app/scmod.cxx
index 7932fca..b4284e7 100644
--- a/sc/source/ui/app/scmod.cxx
+++ b/sc/source/ui/app/scmod.cxx
@@ -1877,7 +1877,7 @@ IMPL_LINK( ScModule, IdleHandler, Timer*, EMPTYARG )
 
 IMPL_LINK( ScModule, SpellTimerHdl, Timer*, EMPTYARG )
 {
-if ( Application::AnyInput( INPUT_KEYBOARD ) )
+if ( Application::AnyInput( VCL_INPUT_KEYBOARD ) )
 {
 aSpellTimer.Start();
 return 0;   // dann spaeter wieder...
diff --git a/sd/source/ui/tools/IdleDetection.cxx b/sd/source/ui/tools/IdleDetection.cxx
index 4ba6163..e0fba1a 100644
--- a/sd/source/ui/tools/IdleDetection.cxx
+++ b/sd/source/ui/tools/IdleDetection.cxx
@@ -59,7 +59,7 @@ sal_Int32 IdleDetection::GetIdleState (const ::Window* pWindow)
 
 sal_Int32 IdleDetection::CheckInputPending (void)
 {
-if (GetpApp()->AnyInput(INPUT_MOUSE | INPUT_KEYBOARD | INPUT_PAINT))
+if (Get

Re: [Libreoffice] gbuild: use gb_CHECKOBJECTOWNER to check for double linked objects

[Michael Stahl]

On 21/04/11 18:33, Bjoern Michaelsen wrote:

On Tue, 19 Apr 2011 18:24:57 +0100
Michael Meeks
wrote:


If not, it sounds like we should have it always enabled (?),
particularly if we can cleanup the issues it finds :-)


Enabled by default on master with:

http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=9c028fe3ff8b5db3f367d19d4fc9f99470a0d13d

use "make -sr gb_CHECKOBJECTOWNER=" to explicitly disable.


hi all,

have replaced this implementation with a new, faster one:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e5eece31d93ed378613991c8a8bbe451aa5c081

this is also always enabled, and there is now no way of disabling it 
(i.e. gb_CHECKOBJECTOWNER is removed and does nothing) because i could 
not measure a difference in performance with it enabled/disabled.


but perhaps that just means my new machine is too fast; perhaps somebody 
wants to benchmark it on their netbook/Alpha box/ARM wristwatch; you can 
disable it temporarily by reverting the commit, or checking out the 
parent and using gb_CHECKOBJECTOWNER=, which disables the old 
implementation; then do 'time make -nsrj8" in tail_build.


regards,
 michael

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

Re: [Libreoffice] IDL "hyper" / Java "long"

[Stephan Bergmann]

Marcin, hope you don't mind I bring this back to the public mailing 
list.  I'm no expert with Calc add-ins, so we should make sure I'm not 
telling nonsense:


On 10/21/2011 05:42 PM, MarcinGutman wrote:

Sorry, not sure what you want to tell me with the above.



If you create Java Calc Add-In you have a Java function.
There is also an IDL file that reflects definition of Java function.
Parameters types are mapped from Java to IDL
If Java parameter is "int" in IDL you put "long".
If Java parameter is "long" in IDL you put "hyper" or "unsigned hyper".
If you put "hyper" there is a mentioned problem.
If you put "unsigned hyper" there is no problem.

So there are three cases:
1) A comedy: it's only my box.
2) A drama: bug in SDK i.e. "only" new Calc Add-Ins are affected.
3) A horror: bug in LOo i.e. all existing Calc Add-Ins are affected.

Due to 3) somebody should check it.


As I wrote at , 
Calc add-ins do not support functions that take or return UNO type hyper.


So I think that explains why an add-in using hyper in the .idl file does 
not work.


Why, however, it should work if the .idl file instead uses unsigned 
hyper I do not know.


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

[Libreoffice] Module moz no longer builds on Ubuntu 11.10

[Alex Thurgood]

Hi all,

I recently upgraded from Ubuntu 11.04 to 11.10 and after pulling from 
master this morning, and making clean, the build no longer completes, 
failing in the moz module with lots of internal errors of the type :


/home/alex/LODEV/core/solver/unxlngi6.pro/lib/libcrmf.a(asn1cmn.o):(.data.rel.ro+0x88): 
undefined reference to `SEC_IntegerTemplate_Util'
/home/alex/LODEV/core/solver/unxlngi6.pro/lib/libcrmf.a(asn1cmn.o):(.data.rel.ro+0xf8): 
undefined reference to `SEC_AnyTemplate_Util'
/home/alex/LODEV/core/solver/unxlngi6.pro/lib/libcrmf.a(asn1cmn.o):(.data.rel.ro+0x138): 
undefined reference to `SECOID_AlgorithmIDTemplate_Util'

collect2: ld returned 1 exit status
make[4]: *** [libpipnss.so] Error 1
make[4]: Leaving directory 
`/home/alex/LODEV/core/moz/unxlngi6.pro/misc/build/mozilla/I_objdir/security/manager/ssl/src'

make[3]: *** [libs] Error 2
make[3]: Leaving directory 
`/home/alex/LODEV/core/moz/unxlngi6.pro/misc/build/mozilla/I_objdir/security/manager/ssl'

make[2]: *** [libs] Error 2
make[2]: Leaving directory 
`/home/alex/LODEV/core/moz/unxlngi6.pro/misc/build/mozilla/I_objdir/security/manager'

make[1]: *** [tier_50] Error 2
make[1]: Leaving directory 
`/home/alex/LODEV/core/moz/unxlngi6.pro/misc/build/mozilla/I_objdir'

make: *** [default] Error 2
dmake:  Error code 2, while making 
'./unxlngi6.pro/misc/build/so_built_ooo_mozab'



Could this be the result of the recent changes to get rid of the 
requirement to have moz/nss ?


Hints, help, gratefully received.

Alex

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

Re: [Libreoffice] need mentoring on framework module (enabling toolpanels)

[Laurent Godard]

Hi Michael

Thanks for your response

I have 3 degrees of responses

> 
>   So - you can get a tool panel presented and working for you ? [ do you
> get to the green screenshot state ? ].
>

1-

well i went a bit more deeper than the green panel ;)
using the java code at
core/testautomation/extensions/optional/input/extension_sources/TaskPaneComponent

i've been able to load a dialog.xdl file and bind macros (then any scipt
code) to the events of the controls (on click for exampke). It is
perfect for my use !
one trick though, retrieving the dialog object itself, i manage only
using the on-focus event (and store it in a global variable). not
beautifull but hey, it works.

That what was i was looking for dealing with the LayoutManager,
retreiving the panel object to manipulate its components. no more urgent
need now (but the lack in core_code remains)

2-

The next step i almost finished (but currently not fully working) is
rewriting the TaskPaneComponent java code to Python
The problem i face here is that all the code is executed, but nothings
shows up. probably a stupid mistake somewhere

Once all is ok, i'll probbaly take some time to write things on the wiki
and provide a sample source code for step 1 and 2

I haven't done pyUNo for years, so it was a bit "difficult" (but really
funny !!)

I reactivated a pyUNo tool i wrote in 2004 and with a small polish it
worked like a charm. It is a very usefull tool (at least for me) for
doing introspection at runtime on pyUNo objects.
http://markmail.org/message/kt2va3mc3ggwk4e2

the download link is dead but i'll publish pyXray and offer it to
Libreoffice if it can help. At least could be a learning tool ofr pyUno
beginers

3- LibreOffice source code

once a toolpanel is created, we can not at the moment control it as we
control statusbar, toolbars, menubars (especially regarding visibility)

this is done using the XLayoutManager interface and as stated in the
announce, it is not implemented yet.

so i thought that if it was an easy hack, i could perharps do it (but my
priority remains calc very large files performances for Libo 3.5 - I'll
start working on this in november)

regarding my patch, it will be waste of time. it was more or less
"random" modifications, only copying few lines and changing names.

i'll try to first finish the point 2. and then see if this
XLayoutManager problem is really needed for scripter point of view.

i'll come back to you. (but not last week, as i'll be in hollidays with
the whole family, so hacking on computers not welcommed ;) )

 also
> what do you want to put in your panel ? [ I for one would love to have
> some share-pointy stuff in there, workflows and so on for relevant
> documents ].

my goal is to put any XControl that one can use un Basic dialogs
(buttons, labels, treeviews, pictures, combox box aso ...)
i'm pretty confident it will work (at least it works with a java factory
of the toolpanel)

This toolpanel stuff is quite exciting as it offers a lot of
possibilities for cool extensions GUI (and what is really cool, is that
you can write your events code in the language you want ;) )

I promise officially here to publish a working sample extension and
write some guidelines

Thanks a lot Michael for your response !!

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

Re: [Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

[Jan Holesovsky]

Hi August, Michael,

Michael Meeks píše v Pá 21. 10. 2011 v 10:13 +0100:

>   Ooh ! :-) this is really nice. I was previously fooled by the subject
> into not noticing that this was some sexy code cleanup + unit testing
> patch.

Michael - thank you a lot for pushing this, and sorry, August, that I
did not get to that earlier :-(  I did a small follow-up patch:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=548fc5db7c39f62d99b1c0a9e4348972ff72545e

August, can you please check that I actually did not break it? ;-)  The
first hunk should do the same thing as it was doing before your String
-> OUString conversion (force copy), just with fewer operations.

The second hunk should fix a hidden O(n^2) complexity (OUStringBuffer
creation + removal of 1 character for every cSep found).

Your unit tests pass fine, but better when more eyes actually look at
the code too :-)

Thank you,
Kendy

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

Re: [Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

[Stephan Bergmann]

On 10/21/2011 11:13 AM, Michael Meeks wrote:

Hi August,

On Thu, 2011-10-20 at 15:01 -0400, August Sodora wrote:

On Tue, Oct 18, 2011 at 3:01 PM, August Sodora  wrote:

I've attached a new patch that includes some tests for the BASIC
scanner. Most of the test cases are just to get an idea of how the
scanner handles certain situations but I tried to make sure I included
ones that specifically trigger where the GetBufferAccess was.


Ooh ! :-) this is really nice. I was previously fooled by the subject
into not noticing that this was some sexy code cleanup + unit testing
patch.

Lovely work ! I added a doc. header for the new sal/ method, and since
I have: (setq-default show-trailing-whitespace t) in my ~/.emacs I see
red warnings of trailing whitespace - so removed a bit of that. One
thing I tweaked in one place is using sal_Int32 indexes into
rtl::OUStrings where previously sal_uInt16 indexes were adequate, one
benefit of your cleanup is that we can handler bigger scripts of course.

Anyhow - a lovely job :-) I'm really looking forward to see what you
touch next :-)

Many thanks !


Unfortunately, this breaks the build, as basic now has a (missing) 
dependency on sfx2, which already depends on basic.


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

Re: [Libreoffice] [PUSHED] Frac function in BASIC

[August Sodora]

Sure all of my work can be licensed MPL/LGPLv3+.

Just noticed I forgot to refer to the bug that gave me the idea to try
this (https://bugs.freedesktop.org/show_bug.cgi?id=39900)

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



On Fri, Oct 21, 2011 at 10:11 AM, Michael Meeks  wrote:
>
> On Fri, 2011-10-21 at 08:45 -0400, August Sodora wrote:
>> Interesting, I'll take a look at those documents. I had actually
>> initially thought that adding something to the BASIC language would be
>> more controversial than adding a calc cell function :)
>
>        Heh :-) well, the direction we're trying to take StarBasic is towards
> more VBA compatibility; so - if this function is used in VBA and has the
> same semantics, there is no problem it should get it straight in.
>
>        Wrt. calc there is a lot more UI & documentation work to do there of
> course; and the 'FRAC' function appears not to exist for me in Excel -
> so there are a number of interop problems that rear their head when this
> comes up. ie. if someone uses it in calc, do we try and map this to a
> combination of other functions when we export to xls/xlsx ? or ... ;-)
> it gets a bit nastier there.
>
>        Looking at it, though I don't believe that VBA does have this function
> ( does it ? ), as such there is no huge problem adding it - but it could
> impact interoperability in the future.
>
>        Anyhow - Noel liked it, so I pushed it :-)
>
>        Could you send a mail confirming your work is under the MPL/LGPLv3+ and
> add yourself to:
> http://wiki.documentfoundation.org/Development/Developers
>
>        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] need mentoring on framework module (enabling toolpanels)

[Michael Meeks]

Hi Laurent,

On Thu, 2011-10-20 at 17:19 +0200, Laurent Godard wrote:
> before diving in calc large file in november, i have to deal at the
> moment with XToolPanel

Sounds exciting :-)

> the purpose is to be able to have things in task pane and manipulate
> them using scripting (macro or python at the moment)

Yep - looks lovely.

> i add some succes with
> core/testautomation/extensions/optional/input/extension_sources/TaskPaneComponent

So - you can get a tool panel presented and working for you ? [ do you
get to the green screenshot state ? ].

http://wiki.services.openoffice.org/wiki/Framework/Article/Tool_Panels

> So, I do not have the skills to do the whole refactoring of the
> framework module but i would like to try to add the support of toolpanels

Of course. I wonder what is not working for you (?)

> I already looked at some source code and did some rough modification
> taking example on other UIElements, but no success for the moment.

Would love to read the patch.

> essentially in
> framework/source/uiconfiguration/moduleuiconfigurationmanager.cxx as
> using it in scprit, a lot of UIElements are shown but no toolpanels

Right; unfortunately there is already quite a bit of bulk & duplication
in that beast.

> before going further and wasting a lot of time (well, i could see it at
> learning), I definitvely need someone that could mentor me and put me in
> the right directions (what is really misisng, what should i write, which
> UiElement could I take as example)

So - I'm happy to help - do you have a patch I can play with ? also
what do you want to put in your panel ? [ I for one would love to have
some share-pointy stuff in there, workflows and so on for relevant
documents ].

All the best,

Michael.

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

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

Re: [Libreoffice] Fwd: Re: patch for scan-diialog

[Michael Meeks]

Hi Rob,

On Thu, 2011-10-20 at 20:37 +0200, Rob Snelders wrote:
> Here are 3 patches that together make the code for adding the 
> scan-button to the sanedlg.

Great to see that :-) Any chance you could drop a nice screenshot /
feature note and your name at:

http://wiki.documentfoundation.org/ReleaseNotes/3.5

which saves lots of time later when it comes to building the 3.5
release notes.

Thanks again,

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] Calc Add-In IDL "hyper" type bug???

[Michael Meeks]

On Fri, 2011-10-21 at 02:25 +0200, MarcinGutman wrote:
> Could somebody confirm this bug?
> https://bugs.freedesktop.org/show_bug.cgi?id=42005

Apparently the resolution is 'Notabug' but thanks for caring about our
quality. There is a QA list: libreoffice...@lists.freedesktop.org - that
is probably the best place to ask such questions.

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] [PUSHED] String::CompareIngoreCaseToAscii

[Markus Mohrhard]

Hello Michael, August,

2011/10/21 Michael Meeks :
> Hi August,
>
> On Fri, 2011-10-21 at 08:50 -0400, August Sodora wrote:
>> Thanks to all for being so patient with me! Would it be worthwhile to
>> continue working on the mess that is scanner/tokenizer/parser (why do
>> they inherit from eachother?!) in basic? I'm also curious about VBA
>> support and whether there exists a grammar or similar documentation
>> for the StarBASIC language.
>
>        Well - of course, it'd be nice to have some more complex tests of
> StarBasic (and VBA) macros, potentially loaded from .bas files inside a
> unit test.
>
>        Noel - do you have any really nasty syntax / built-in basic
> functionality corner cases embedded into xls files that could be
> extracted and turned into compile-time unit tests in basic/ ?
>
>        Otherwise digging out some more easy hacks to play with :-) If you love
> basic then - trying to compile and execute macros that are > 64k long
> (do we have a regression test for that?) might be a good idea - I
> imagine many limits are still in-place there. Converting more code from
> the String -> OUString types is probably worthwhile.

I think we need to seperate basic tests a bit. Unit test like the
newly integrated one should and can be in basic but all tests that
should execute a macro need to move a bit later in the build, like sc
or sw. There we have all needed modules and we have already a concept
that should work fine. The advantage of these tests is that all
dependency problems we have for executing "useful" macros are solved.

StarBasic tests should already work and I'm working on VBA tests to
make them more usefull. If you want you can have a look and maybe add
some useful tests there.

But keep up your good work. Every added test is a win.

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

Re: [Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

[Michael Meeks]

Hi August,

On Fri, 2011-10-21 at 08:50 -0400, August Sodora wrote:
> Thanks to all for being so patient with me! Would it be worthwhile to
> continue working on the mess that is scanner/tokenizer/parser (why do
> they inherit from eachother?!) in basic? I'm also curious about VBA
> support and whether there exists a grammar or similar documentation
> for the StarBASIC language.

Well - of course, it'd be nice to have some more complex tests of
StarBasic (and VBA) macros, potentially loaded from .bas files inside a
unit test.

Noel - do you have any really nasty syntax / built-in basic
functionality corner cases embedded into xls files that could be
extracted and turned into compile-time unit tests in basic/ ?

Otherwise digging out some more easy hacks to play with :-) If you love
basic then - trying to compile and execute macros that are > 64k long
(do we have a regression test for that?) might be a good idea - I
imagine many limits are still in-place there. Converting more code from
the String -> OUString types is probably worthwhile.

Is that interesting ?

Thanks again,

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] SolarMutex usage...

[Michael Meeks]

Hi Michael,

Good catch with this :-)

On Fri, 2011-10-21 at 12:28 +0200, Michael Stahl wrote:
> is there any authoritative documentation on when exactly the SolarMutex 
> should be locked when coming from the UI?

So - with the gtk+ backend, it should mirror the GDK_THREADS lock that
protects the toolkit.

> i know that it must be locked on UNO API method entry in the parts of 
> the code that are not otherwise threadsafe, but i have no idea how the 
> UI stuff / VCL works.

Luckily I have a pretty good idea of what is going on there :-) I spent
a lot of time on this locking integration in the past.

> for example, somebody has put a DBG_TESTSOLARMUTEX() assertion in 
> ImplWindowFrameProc, which can easily be triggered by just creating a 
> new Writer document, entering a letter or whatever and hitting the 
> 'Save' icon.

Sure - that seems reasonable to me - it should be locked there.

> > #0  0x77d6fdb1 in osl_assertFailedLine () from 
> > /data/lo/core/solver/unxlngx6/installation/opt/program/../basis-link/ure-link/lib/libuno_sal.so.3
> > #1  0x732cfacd in ImplDbgTestSolarMutex () at 
> > /data/lo/core/vcl/source/app/dbggui.cxx:1978
> > #2  0x74457265 in DbgFunc (nAction=15, pParam=0x0) at 
> > /data/lo/core/tools/source/debug/debug.cxx:1301
> > #3  0x734be129 in DbgTestSolarMutex () at 
> > /data/lo/core/solver/unxlngx6/inc/tools/debug.hxx:322
> > #4  0x73782fe0 in ImplWindowFrameProc (pWindow=0x134b490, nEvent=2, 
> > pEvent=0x7fff6fd0) at /data/lo/core/vcl/source/window/winproc.cxx:2370
> > #5  0x7fffe56641d7 in SalFrame::CallCallback (this=0x134b910, nEvent=2, 
> > pEvent=0x7fff6fd0) at /data/lo/core/vcl/inc/salframe.hxx:294
> > #6  0x7fffe568e55e in GtkSalFrame::signalCrossing (pEvent=0x1e3c8e0, 
> > frame=0x134b910) at /data/lo/core/vcl/unx/gtk/window/gtkframe.cxx:2866
> > #7  0x00337114ef33 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
..
> > #21 0x003363c2a2e2 in g_signal_emit () from /lib64/libgobject-2.0.so.0
> > #22 0x00337128cc86 in gtk_widget_show () from 
> > /usr/lib64/libgtk-x11-2.0.so.0
> > #23 0x0033710c4f13 in gtk_dialog_run () from 
> > /usr/lib64/libgtk-x11-2.0.so.0
> > #24 0x7fffdda123c2 in RunDialog::run() () from 
> > /data/lo/core/solver/unxlngx6/installation/opt/program/../program/fps_gnome.uno.so
> > #25 0x7fffdda192b8 in SalGtkFilePicker::execute() () from 
> > /data/lo/core/solver/unxlngx6/installation/opt/program/../program/fps_gnome.uno.so

it should be locked down this entire call-frame. This looks like an
'easy' case - there is no main-loop running or anything complicated.

> > #46 0x7fffe5083249 in SalDisplay::DispatchInternalEvent (this=0x779ce0) 
> > at /data/lo/core/vcl/unx/generic/app/saldisp.cxx:2160
> > #47 0x7fffe566387a in GtkXLib::userEventFn (data=0x6fcc80) at 
> > /data/lo/core/vcl/unx/gtk/app/gtkdata.cxx:900
> > #48 0x7fffe5663737 in call_userEventFn (data=0x6fcc80) at 
> > /data/lo/core/vcl/unx/gtk/app/gtkdata.cxx:865
> > #49 0x003360c44add in g_main_context_dispatch () from 
> > /lib64/libglib-2.0.so.0
> > #50 0x003360c452d8 in ?? () from /lib64/libglib-2.0.so.0

It is missing here - the call_userEventFn should have it.

Good catch; I fixed another three missing instances and committed the
patch to feature/gtk3 - it should get merged soon (in the next few
days).

In the meantime - patience much appreciated, and thanks for the report
- well worth leaving that assertion there for the future I think.

Thanks,

Michael.

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

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

[Libreoffice] [PUSHED] Frac function in BASIC

[Michael Meeks]

On Fri, 2011-10-21 at 08:45 -0400, August Sodora wrote:
> Interesting, I'll take a look at those documents. I had actually
> initially thought that adding something to the BASIC language would be
> more controversial than adding a calc cell function :) 

Heh :-) well, the direction we're trying to take StarBasic is towards
more VBA compatibility; so - if this function is used in VBA and has the
same semantics, there is no problem it should get it straight in.

Wrt. calc there is a lot more UI & documentation work to do there of
course; and the 'FRAC' function appears not to exist for me in Excel -
so there are a number of interop problems that rear their head when this
comes up. ie. if someone uses it in calc, do we try and map this to a
combination of other functions when we export to xls/xlsx ? or ... ;-)
it gets a bit nastier there.

Looking at it, though I don't believe that VBA does have this function
( does it ? ), as such there is no huge problem adding it - but it could
impact interoperability in the future.

Anyhow - Noel liked it, so I pushed it :-)

Could you send a mail confirming your work is under the MPL/LGPLv3+ and
add yourself to:
http://wiki.documentfoundation.org/Development/Developers

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] minutes of tech. steering call ...

[Michael Meeks]

On Fri, 2011-10-21 at 14:51 +0200, Stephan Bergmann wrote:
> > That would of course mean shipping some
> > duplicate legacy MSVC++ compiled libraries, but ... surely do-able.
> 
> It would not suffice to ship them, one would also need to build them. 
> Kind of back to square one.

For windows - shipping a pre-canned set of compiled compatibility
libraries doesn't look too disgusting to me; at least - it seems a lot
less disgusting than using MSVC++ and cygwin :-)

tar xf ure-bincompat-win32-tgz

is not in itself such a horrific outcome from a cross-compiled solution
(assuming the build of that is well documented, should you happen to
have lots of time and a proprietary system + compiler to do it). Clearly
someone needs to build them once.

HTH,

Michael.

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

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

[Libreoffice] IDL "hyper" / Java "long"

[MarcinGutman]

Hello,

Please, could somebody check this...
https://bugs.freedesktop.org/show_bug.cgi?id=42005

Best Regards,
Marcin Gutman


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

Re: [Libreoffice] config & register toolbar controller in adddon

[othman]

>From my humble experience with OOo , i conclude that the designers decided to
have a limited functionality for toolbars. I would be happy to know of some
people willing to improve OOo toolbars API allowing more power and
flexibility to build complex toolbars with rich controls and dynamic events.
If i was familiar with OOo API source code i could add this improvement
myself..maybe in future if i understand more OOo source code i can work on
that.
But anyway maybe i'll have a look at the Tool Panel option.
thanks for your help

othman

--
View this message in context: 
http://nabble.documentfoundation.org/config-register-toolbar-controller-in-adddon-tp3438288p3440839.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] [REVIEWED] libreoffice-3-4 fix l10n of NLPSolver

[Caolán McNamara]

On Thu, 2011-10-20 at 11:19 +0200, Andras Timar wrote:
> My latest patch fixes it, I would like to have it in LibreOffice
> 3.4.4,

Now pushed to 3-4

C.

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

[Libreoffice] maybe clean rebuild needed

[Markus Mohrhard]

Hey,

I just enabled the macro's test in calc again and it seems that in
some situations we get a deadlock in the first incremental build after
the patch. If you observe that in your build, do a make clean and the
next make should execute the test without a problem.

If you still get problem after a make clean please write me a mail.

Sorry for the trouble I might cause.

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

Re: [Libreoffice] config & register toolbar controller in adddon

[othman]

Thanks this seems very interesting.
So we could include Tool Panels in a toolbar too and not only in a Task Pane
is that correct?
I'll be very interested to see some snippet code (java or python) on how to
make a Tool Panel and add it to a addon toolbar.
I can work on this if you give me some guidelines and tips.
thanks
othman

--
View this message in context: 
http://nabble.documentfoundation.org/config-register-toolbar-controller-in-adddon-tp3438288p3440782.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

Re: [Libreoffice] comprehensive binfilter tests?

[Stephan Bergmann]

On 10/21/2011 02:38 PM, Caolán McNamara wrote:

On Wed, 2011-09-28 at 21:58 +0200, Andras Timar wrote:

In rsc/doku/feinkonz.43 there are 3 sdw files, LibreOffice 3.4.x
crashes on all of them under Linux/Windows. I did not try master. 3.3
is OK.


master crashes for me alright,
http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=86db50edeee1d556f993589da73140582789ef42
 fixes it again for those docs anyway.

caolanm->sberg: can you have a look at my fix, looks like merge bustage
on merging in the fix for #i117310#, though that would indicate that
whatever problem exists in 3.4.3 is different.


 
(referenced from ) 
removes the


  if( !rPropSetInfo.is() )
rPropSetInfo = rPropSet->getPropertySetInfo();

part only from 
binfilter/bf_xmloff/source/style/xmloff_SinglePropertySetInfoCache.cxx 
but not from the corresponding 
xmloff/source/style/SinglePropertySetInfoCache.cxx.  I guess it was a 
mistake I introduced when manually copying over the changes I made to 
the latter to the former, and it simply went unnoticed until now.


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

[Libreoffice] [REVIEW] cherry-pick to fix .sdw import in 3-4

[Caolán McNamara]

I want to cherry-pick the attached commit back to 3-4, the .sdw import
of the binfilter is broken otherwise as timar noted.

May need git am --ignore-whitespace or whatever to apply.

C.
>From ac7475b06466404ac23d5352d9226de857d83987 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= 
Date: Wed, 13 Apr 2011 13:48:19 +0100
Subject: [PATCH] add these back in to silence the MAXFILTER assert

---
 binfilter/bf_sw/source/filter/basflt/sw_fltini.cxx |   13 ++
 .../bf_sw/source/filter/basflt/sw_shellio.cxx  |   24 +---
 binfilter/inc/bf_sw/iodetect.hxx   |5 +--
 3 files changed, 16 insertions(+), 26 deletions(-)

diff --git a/binfilter/bf_sw/source/filter/basflt/sw_fltini.cxx b/binfilter/bf_sw/source/filter/basflt/sw_fltini.cxx
index 27bfad6..6d90fac 100644
--- a/binfilter/bf_sw/source/filter/basflt/sw_fltini.cxx
+++ b/binfilter/bf_sw/source/filter/basflt/sw_fltini.cxx
@@ -89,10 +89,23 @@ inline void _SetFltPtr( USHORT& rPos, SwRead pReader, const sal_Char* pNm )
 
 void _InitFilter()
 {
+SwRead pRd;
+
 USHORT nCnt = 0;
 _SetFltPtr( nCnt, (ReadSw3 = new Sw3Reader), FILTER_SW5 );
 _SetFltPtr( nCnt, ReadSw3, FILTER_SW4 );
 _SetFltPtr( nCnt, ReadSw3, FILTER_SW3 );
+_SetFltPtr( nCnt, (ReadSwg = new SwgReader), FILTER_SWG );
+_SetFltPtr( nCnt, ReadSwg, FILTER_SWGV );
+_SetFltPtr( nCnt, new Sw6Reader, sSwDos );
+_SetFltPtr( nCnt, (ReadAscii = new AsciiReader), FILTER_BAS );
+_SetFltPtr( nCnt, new W4WReader, FILTER_W4W );
+_SetFltPtr( nCnt, ( pRd = new ExcelReader ), sCExcel );
+_SetFltPtr( nCnt, pRd, sExcel );
+_SetFltPtr( nCnt, new LotusReader, sLotusD );
+_SetFltPtr( nCnt, ReadSwg, sSwg1 );
+
+_SetFltPtr( nCnt, ReadAscii, FILTER_TEXT );
 
 OSL_ENSURE( MAXFILTER == nCnt, "Anzahl Filter ungleich der Definierten" );
 }
diff --git a/binfilter/bf_sw/source/filter/basflt/sw_shellio.cxx b/binfilter/bf_sw/source/filter/basflt/sw_shellio.cxx
index 2c5557f..3399f21 100644
--- a/binfilter/bf_sw/source/filter/basflt/sw_shellio.cxx
+++ b/binfilter/bf_sw/source/filter/basflt/sw_shellio.cxx
@@ -351,29 +351,7 @@ using namespace ::com::sun::star;
 /*?*/   // we cannot create a SwDocShell. We could create a
 /*?*/   // SwWebDocShell however, because this exists always
 /*?*/   // for the help.
-OSL_ASSERT("ReadXML removed");
-
-//   SvtModuleOptions aModuleOptions;
-//  if( aModuleOptions.IsWriter() )
-//  {
-//  SwDocShell *pDocSh =
-//  new SwDocShell ( SFX_CREATE_MODE_INTERNAL );
-//  SvEmbeddedObjectRef xDocSh = pDocSh;
-//  if( pDocSh->DoInitNew( 0 ) )
-//  {
-//  pTemplate = pDocSh->GetDoc();
-//  pTemplate->SetOle2Link( Link() );
-//  pTemplate->SetBrowseMode( bTmplBrowseMode );
-//  pTemplate->RemoveAllFmtLanguageDependencies();
-//
-//  ReadXML->SetOrganizerMode( TRUE );
-//  SwReader aRdr( *xStor, aEmptyStr, pTemplate );
-//  aRdr.Read( *ReadXML );
-//  ReadXML->SetOrganizerMode( FALSE );
-//
-//  pTemplate->AddLink();
-//  }
-//}
+OSL_ASSERT("ReadXML removed");
 /*?*/   }
 /*?*/   else
 /*?*/   {
diff --git a/binfilter/inc/bf_sw/iodetect.hxx b/binfilter/inc/bf_sw/iodetect.hxx
index e91b371..94199a9 100644
--- a/binfilter/inc/bf_sw/iodetect.hxx
+++ b/binfilter/inc/bf_sw/iodetect.hxx
@@ -105,7 +105,7 @@ struct SwIoDetect
 #endif
 
 
-const USHORT MAXFILTER = 14;
+const USHORT MAXFILTER = 13;
 
 #define FORAMTNAME_SW4  "StarWriter 4.0"
 #define FORAMTNAME_SW3  "StarWriter 3.0"
@@ -161,8 +161,7 @@ SwIoDetect aReaderWriter[ MAXFILTER ] = {  \
 {/* 9*/ SwIoEntry(sExcel, 4,FALSE)},   \
 {/*10*/ SwIoEntry(sLotusD,5,TRUE)},\
 {/*11*/ SwIoEntry(sSwg1,  4,FALSE)},   \
-{/*12*/ SwIoEntry(FILTER_XML, 4,TRUE)},\
-{/*13*/ SwIoEntry(FILTER_TEXT,4,TRUE)} \
+{/*12*/ SwIoEntry(FILTER_TEXT,4,TRUE)} \
 };
 
 // Filter erkennung
-- 
1.7.6.4

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

Re: [Libreoffice] minutes of tech. steering call ...

[Stephan Bergmann]

On 10/21/2011 10:39 AM, Michael Meeks wrote:

Hi Kevin,

On Thu, 2011-10-20 at 20:06 -0400, Kevin Hunter wrote:

   From the wiki page, one of the concerns is "binary incompatibility".  I
assume this is in reference to extensions?


Sure; of course we only export a reasonably small ABI, the 'ure' (big
chunks of which are in-lined C++ methods that call SAL_CALL C functions
that we havn't changed and should cross-compile nicely). The
C++ helper classes (it is hoped) due to windows direct linking, and a
different ABI anyway shouldn't conflict.

My hope was(is) that UNO can shine here (with some tweaks) as a
bridging technology between the ABIs - at some fairly minimal
performance cost. At least, given Stephan's expertise&  a little
testing, it "might just work". That would of course mean shipping some
duplicate legacy MSVC++ compiled libraries, but ... surely do-able.


It would not suffice to ship them, one would also need to build them. 
Kind of back to square one.



Question: is there merit to moving toward an enforced sub-process model
for extensions ?


It is an interesting idea; of course in theory UNO makes this easy, in
reality - I would scream and run away from cross-process component
usage. Debugging reference leaks / cycles / etc. is bad enough
in-process, never-mind cross-process; or worse between many (external)
components.


Note that freshly installed extensions *are* routinely loaded off to an 
external uno process.


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

Re: [Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

[August Sodora]

Thanks to all for being so patient with me! Would it be worthwhile to
continue working on the mess that is scanner/tokenizer/parser (why do
they inherit from eachother?!) in basic? I'm also curious about VBA
support and whether there exists a grammar or similar documentation
for the StarBASIC language.

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



On Fri, Oct 21, 2011 at 5:13 AM, Michael Meeks  wrote:
> Hi August,
>
> On Thu, 2011-10-20 at 15:01 -0400, August Sodora wrote:
>> On Tue, Oct 18, 2011 at 3:01 PM, August Sodora  wrote:
>> > I've attached a new patch that includes some tests for the BASIC
>> > scanner. Most of the test cases are just to get an idea of how the
>> > scanner handles certain situations but I tried to make sure I included
>> > ones that specifically trigger where the GetBufferAccess was.
>
>        Ooh ! :-) this is really nice. I was previously fooled by the subject
> into not noticing that this was some sexy code cleanup + unit testing
> patch.
>
>        Lovely work ! I added a doc. header for the new sal/ method, and since
> I have: (setq-default show-trailing-whitespace t) in my ~/.emacs I see
> red warnings of trailing whitespace - so removed a bit of that. One
> thing I tweaked in one place is using sal_Int32 indexes into
> rtl::OUStrings where previously sal_uInt16 indexes were adequate, one
> benefit of your cleanup is that we can handler bigger scripts of course.
>
>        Anyhow - a lovely job :-) I'm really looking forward to see what you
> touch next :-)
>
>        Many thanks !
>
>                Michael.
>
> --
> michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech. steering call ...

[Stephan Bergmann]

On 10/21/2011 11:08 AM, Kevin Hunter wrote:

At 4:11am -0400 Fri, 21 Oct 2011, Stephan Bergmann wrote:

On 10/21/2011 02:06 AM, Kevin Hunter wrote:

5. That API definition will be a *lot* of work, but hopefully somewhat
thought out already through only a mild reengineering of the current
binary API.


The UNO API is already there. Or what do you mean?


I was talking about an API that is not dependent on an ABI. But I freely
admit I know very little about ABIs, so I may have just conflated that
term. See below.


The upside is that if we're talking a major version change, /now/ would
be the time to do this.


A downside is that you would still need to maintain (and build!) the UNO
runtime for the MSVC ABI.


This may be the crux of what I'm not getting, but why? Why can't a
protocol be, say, text-based via (local, or other) socket? In my mind, I
see two independent programs, from two different compilers, using the OS
and something akin to pipes to communicate. I admit it might a smidgen
slower to do it that way, but do people actually use LO in HPC
scenarios? (And I fully accept that they might, I just haven't seen it
yet in my various interactions.)


That's all already there with UNO.  Only, for any code to make use of 
that, it needs to talk with "bridge" code that handles the (intra- or 
inter-process) communication.  That bridge code (which is necessarily 
ABI-specific) is also already there.


The only thing is that, if you wanted to give up building LibO with MSVC 
and switch to MinGW, but wanted to retain the MSVC-specific bridge code 
(so that old extensions can continue to run, in- or out-of-processes), 
you could not give up building LibO with MSVC completely, because you 
would still need to build that bridge code with MSVC.


Designing a new communication protocol would not buy you anything.

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

Re: [Libreoffice] [PATCH] Frac function in calc/BASIC

[August Sodora]

Interesting, I'll take a look at those documents. I had actually
initially thought that adding something to the BASIC language would be
more controversial than adding a calc cell function :) Has there been
any discussion on where these types of additions should go in the
past?

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



On Fri, Oct 21, 2011 at 7:20 AM, Regina Henschel
 wrote:
> Hi August,
>
> August Sodora schrieb:
>>
>> I came across this feature request today and decided to try my hand at
>> it. Is the attached patch an appropriate solution?
>>
>
> I understand now, that you will do BASIC and CALC at the same time.
>
> For CALC there are some problems. A function FRAC is not defined in ODF1.2
> [1]. So it has to be written different. For OOo that has been
> org.openoffice.style (for example). But I'm not sure, whether the same
> should be done for LO, or whether it should be org.libreoffice, or more
> general org.documentfoundation.
>
> The new function need to be known to the function wizard, see [2] chapter 3.
>
> [1] http://docs.oasis-open.org/office/v1.2/
> [2]
> http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions
>
> Kind regards
> Regina
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] comprehensive binfilter tests?

[Caolán McNamara]

On Wed, 2011-09-28 at 21:58 +0200, Andras Timar wrote:
> In rsc/doku/feinkonz.43 there are 3 sdw files, LibreOffice 3.4.x
> crashes on all of them under Linux/Windows. I did not try master. 3.3
> is OK.

master crashes for me alright,
http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=86db50edeee1d556f993589da73140582789ef42
 fixes it again for those docs anyway.

caolanm->sberg: can you have a look at my fix, looks like merge bustage
on merging in the fix for #i117310#, though that would indicate that
whatever problem exists in 3.4.3 is different.

C.


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

Re: [Libreoffice] Python on Windows

[Dag Wieers]

On Thu, 20 Oct 2011, Stephan Bergmann wrote:

(c) pyuno as run from an external python process might no longer work. An 
easy way to test that is to start the interactive python executable from the 
LibO program directory and execute "include uno" (and/or "include pyuno"; not 
sure right now which one is the more interesting, but if both work I'd guess 
that's good).


The solution we implemented for this for unoconv (a python tool) is to try 
to load the pyuno.so with the system's python, on failure it looks for an 
existing LibO python and swaps itself in memory with the LibO python and 
tries again. That works quite well in practice.


--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] config & register toolbar controller in adddon

[Laurent Godard]

HI
,
> I looked to this one but these are not flexible enough. i need more complex
> controls (like XFixedText and progressbar). i also want to dynamically
> show/hide toolbar controls at runtime.  do you know how we can do this?

i'm currently exploring this
http://wiki.services.openoffice.org/wiki/Framework/Article/Tool_Panels

quite promosing mixing technlogies (java/python + Basic dialogs)
it globally works with some tricks
i'm actually on writing the factory as python instead of java
(the part dealing with layoutmanager is missing, though)

i'll probably will write things about it when ok

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

Re: [Libreoffice] config & register toolbar controller in adddon

[othman]

Hi,
I looked to this one but these are not flexible enough. i need more complex
controls (like XFixedText and progressbar). i also want to dynamically
show/hide toolbar controls at runtime.  do you know how we can do this?

thanks

--
View this message in context: 
http://nabble.documentfoundation.org/config-register-toolbar-controller-in-adddon-tp3438288p3440636.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

Re: [Libreoffice] Gmane address mangling

[Thorsten Behrens]

Michael Stahl wrote:
> would anybody object to turning it off?
> 
Nope, go for it. It has bitten a few others before already...

Cheers,

-- Thorsten


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

[Libreoffice] Gmane address mangling

[Michael Stahl]

hi all,

noticed that i just committed thb's patch with a Gmane mangled mail 
address :(


is there a particular reason why this list is using the address mangling?

looks like the addresses aren't that well protected in the fd.o web 
interface anyway e.g. 'mstahl at redhat.com'.


and also the other gmane.comp.documentfoundation lists don't seem to 
have mangling enabled.


would anybody object to turning it off?

it sure is annoying... and everybody already has spam filters anyway...

regards,
 michael

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

Re: [Libreoffice] [PATCH] Frac function in calc/BASIC

[Regina Henschel]

Hi August,

August Sodora schrieb:

I came across this feature request today and decided to try my hand at
it. Is the attached patch an appropriate solution?



I understand now, that you will do BASIC and CALC at the same time.

For CALC there are some problems. A function FRAC is not defined in 
ODF1.2 [1]. So it has to be written different. For OOo that has been 
org.openoffice.style (for example). But I'm not sure, whether the same 
should be done for LO, or whether it should be org.libreoffice, or more 
general org.documentfoundation.


The new function need to be known to the function wizard, see [2] chapter 3.

[1] http://docs.oasis-open.org/office/v1.2/
[2] 
http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions


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

[Libreoffice] [PUSHED] Re: [REVIEW-3-4] Fix fdo#41995 fallout - recognize .svg in odf container

[Michael Stahl]

On 21/10/11 11:59, Thorsten Behrens wrote:

Hi there,

it seems, though the filter is there, we don't read .svg files from
the Pictures stream inside the odf zip container. Easy fix attached,
could someone please review&  commit to -3-4?

Cheers,

-- Thorsten


have reviewed and pushed to -3-4.

regards
 michael

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

Re: [Libreoffice] SolarMutex usage...

[Caolán McNamara]

On Fri, 2011-10-21 at 12:28 +0200, Michael Stahl wrote:
> now which frame in that stack should lock the SolarMutex ?

Possibly a special case because the file dialog here is the gtk file
dialog and its more a miracle it works than something to prod too
hard :-) ?

C.

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

Re: [Libreoffice] [PATCH] Frac function in calc/BASIC

[Noel Power]

On 21/10/11 04:19, August Sodora wrote:

I came across this feature request today and decided to try my hand at
it. Is the attached patch an appropriate solution?

seems like a nice patch :-). From the basic side of things , all seems 
fine, if Kohei is happy with the calc parts then I see no problem to 
push this. Have you already stated license for the patch (MPL/LGPLv3+)


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

[Libreoffice] SolarMutex usage...

[Michael Stahl]

is there any authoritative documentation on when exactly the SolarMutex 
should be locked when coming from the UI?


i know that it must be locked on UNO API method entry in the parts of 
the code that are not otherwise threadsafe, but i have no idea how the 
UI stuff / VCL works.


for example, somebody has put a DBG_TESTSOLARMUTEX() assertion in 
ImplWindowFrameProc, which can easily be triggered by just creating a 
new Writer document, entering a letter or whatever and hitting the 
'Save' icon.


now which frame in that stack should lock the SolarMutex ?


#0  0x77d6fdb1 in osl_assertFailedLine () from 
/data/lo/core/solver/unxlngx6/installation/opt/program/../basis-link/ure-link/lib/libuno_sal.so.3
#1  0x732cfacd in ImplDbgTestSolarMutex () at 
/data/lo/core/vcl/source/app/dbggui.cxx:1978
#2  0x74457265 in DbgFunc (nAction=15, pParam=0x0) at 
/data/lo/core/tools/source/debug/debug.cxx:1301
#3  0x734be129 in DbgTestSolarMutex () at 
/data/lo/core/solver/unxlngx6/inc/tools/debug.hxx:322
#4  0x73782fe0 in ImplWindowFrameProc (pWindow=0x134b490, nEvent=2, 
pEvent=0x7fff6fd0) at /data/lo/core/vcl/source/window/winproc.cxx:2370
#5  0x7fffe56641d7 in SalFrame::CallCallback (this=0x134b910, nEvent=2, 
pEvent=0x7fff6fd0) at /data/lo/core/vcl/inc/salframe.hxx:294
#6  0x7fffe568e55e in GtkSalFrame::signalCrossing (pEvent=0x1e3c8e0, 
frame=0x134b910) at /data/lo/core/vcl/unx/gtk/window/gtkframe.cxx:2866
#7  0x00337114ef33 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#8  0x003363c0ea24 in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#9  0x003363c20d17 in ?? () from /lib64/libgobject-2.0.so.0
#10 0x003363c29f13 in g_signal_emit_valist () from 
/lib64/libgobject-2.0.so.0
#11 0x003363c2a2e2 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#12 0x003371284141 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#13 0x0033712842fc in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#14 0x00337128858a in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#15 0x00337114b1c5 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#16 0x00337114b2db in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#17 0x0033712974a0 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#18 0x003363c0ea24 in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#19 0x003363c20527 in ?? () from /lib64/libgobject-2.0.so.0
#20 0x003363c2a141 in g_signal_emit_valist () from 
/lib64/libgobject-2.0.so.0
#21 0x003363c2a2e2 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#22 0x00337128cc86 in gtk_widget_show () from /usr/lib64/libgtk-x11-2.0.so.0
#23 0x0033710c4f13 in gtk_dialog_run () from /usr/lib64/libgtk-x11-2.0.so.0
#24 0x7fffdda123c2 in RunDialog::run() () from 
/data/lo/core/solver/unxlngx6/installation/opt/program/../program/fps_gnome.uno.so
#25 0x7fffdda192b8 in SalGtkFilePicker::execute() () from 
/data/lo/core/solver/unxlngx6/installation/opt/program/../program/fps_gnome.uno.so
#26 0x760f71fa in sfx2::FileDialogHelper_Impl::implDoExecute 
(this=0x1d986e0) at /data/lo/core/sfx2/source/dialog/filedlghelper.cxx:1306
#27 0x760f7f39 in sfx2::FileDialogHelper_Impl::execute (this=0x1d986e0, 
rpURLList=@0x7fff7fc0, rpSet=@0x7fff8268, rFilter="") at 
/data/lo/core/sfx2/source/dialog/filedlghelper.cxx:1481
#28 0x760fd16f in sfx2::FileDialogHelper::Execute (this=0x1d8c2b0, 
rpSet=@0x7fff8268, rFilter="") at 
/data/lo/core/sfx2/source/dialog/filedlghelper.cxx:2374
#29 0x762214dc in ModelData_Impl::OutputFileDialog 
(this=0x7fff8880, nStoreMode=32 ' ', aPreselectedFilterPropsHM=..., 
bSetStandardName=0 '\000', aSuggestedName=..., bPreselectPassword=0 '\000', 
aSuggestedDir=..., nDialog=0, rStandardDir=..., rBlackList=...) at 
/data/lo/core/sfx2/source/doc/guisaveas.cxx:997
#30 0x76225600 in SfxStoringHelper::GUIStoreModel (this=0x7fff9700, 
xModel=..., aSlotName=..., aArgsSequence=..., bPreselectPassword=0 '\000', 
aSuggestedName=..., nDocumentSignatureState=0) at 
/data/lo/core/sfx2/source/doc/guisaveas.cxx:1506
#31 0x76242d53 in SfxObjectShell::ExecFile_Impl (this=0x158c330, 
rReq=...) at /data/lo/core/sfx2/source/doc/objserv.cxx:631
#32 0x76240d73 in SfxStubSfxObjectShellExecFile_Impl (pShell=0x158c330, 
rReq=...) at /data/lo/core/workdir/unxlngx6/SdiTarget/sfx2/sdi/sfxslots.hxx:151
#33 0x760acd04 in SfxShell::CallExec (this=0x158c330, pFunc=0x76240d50 
, rReq=...) at 
/data/lo/core/sfx2/inc/sfx2/shell.hxx:202
#34 0x760a57fd in SfxDispatcher::Call_Impl (this=0x18e4670, rShell=..., 
rSlot=..., rReq=..., bRecord=1 '\001') at 
/data/lo/core/sfx2/source/control/dispatch.cxx:278
#35 0x760a8d15 in SfxDispatcher::PostMsgHandler (this=0x18e4670, 
pReq=0x1d8cbb0) at /data/lo/core/sfx2/source/control/dispatch.cxx:1373
#36 0x760a8bc3 in SfxDispatcher::LinkStubPostMsgHandler 
(pThis=0x18e4670, pCaller=0x1d8cbb0) at 
/data/lo/core/sfx2/source/control/dispatc

Re: [Libreoffice] Kubuntu Oneiric "Qt4 Libraries"

[Bjoern Michaelsen]

On Thu, Oct 20, 2011 at 06:31:23PM -0200, Olivier Hallot wrote:
> I get stuck with autogen.sh, asking for "Qt4 Libraries" when I
> --enable-kde4.
> I am on a Kubuntu Oneiric machine and it seems I cannot find the
> right package to install. Must be stupid, but I just don't get it.

apt-get build-dep libreoffice

should take cae of deps for you.

Best,

Bjoern

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

Re: [Libreoffice] make experts: progress information?

[Bjoern Michaelsen]

Hi all,

On Fri, Oct 21, 2011 at 10:16:07AM +0100, Michael Meeks wrote:
>   Try running a no-op incremental make in tail_build :-) it's more like
> 30+ seconds: 

Only with gb_CHECKOBJECTOWNER=T otherwise its down to 10 seconds in tail_build,
which is likely mostly stat'ing.

Anyway: I implemented a "make countoutdated" proof-of-concept:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=05a33692a084f59f2fae0a535131133d2a3f6b72
http://cgit.freedesktop.org/libreoffice/core/commit/?id=8ee4e99a78a7a7f16bafa56e08ef9649cc69dbdb

which does not add much complexity to the existing build system by being an 
extension.
Now you can do:

 make countoutdated
 make countoutdated check
 make countoutdated build

to quickly check etc. how many files would get rebuild in workdir right now. Of
course, that _could_ be easily used to create some progress counters, if one
doesnt mind the ten extra seconds.

For example it shows that touching sw/inc/doc.hxx causes:

 $ make countoutdated -W `readlink -f sw/inc/doc.hxx`
 CxxObject: 393
 Module: 39
 LinkTarget: 9
 RdbTarget: 8
 CppunitTest: 9

to be rebuild. It also shows there is still something very wrong about 
generated headers in oox.

Best,

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

[Libreoffice] [REVIEW-3-4] Fix fdo#41995 fallout - recognize .svg in odf container

[Thorsten Behrens]

Hi there,

it seems, though the filter is there, we don't read .svg files from
the Pictures stream inside the odf zip container. Easy fix attached,
could someone please review & commit to -3-4?

Cheers,

-- Thorsten
From abc156890a8cb64094f5d668274559203ae188b5 Mon Sep 17 00:00:00 2001
From: Thorsten Behrens 
Date: Fri, 21 Oct 2011 11:14:32 +0200
Subject: [PATCH] Fix fdo#41995 fallout - recognize .svg in odf container

Seems the graphic load code is stupid and not using the path name /
file extension to guess file type, but only "magic byte" detection.
Giving filter framework the path now, so that .svg actually loads.
---
 svx/source/svdraw/svdograf.cxx |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/svx/source/svdraw/svdograf.cxx b/svx/source/svdraw/svdograf.cxx
index e51a268..56d0643 100644
--- a/svx/source/svdraw/svdograf.cxx
+++ b/svx/source/svdraw/svdograf.cxx
@@ -1299,8 +1299,11 @@ IMPL_LINK( SdrGrafObj, ImpSwapHdl, GraphicObject*, pO )
 mbIsPreview = sal_True;
 }
 
-if( !GraphicFilter::GetGraphicFilter()->ImportGraphic( aGraphic, String(), *pStream,
-GRFILTER_FORMAT_DONTKNOW, NULL, 0, pFilterData ) )
+if( !GraphicFilter::GetGraphicFilter()->ImportGraphic( aGraphic,
+   aStreamInfo.maUserData,
+   *pStream,
+   GRFILTER_FORMAT_DONTKNOW,
+   NULL, 0, pFilterData ) )
 {
 const String aUserData( pGraphic->GetUserData() );
 
-- 
1.7.1



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

Re: [Libreoffice] Python on Windows

[Caolán McNamara]

On Fri, 2011-10-21 at 09:25 +0100, Michael Meeks wrote:
>   What would be -really- excellent to nail this permanently would be to
> have a during-compile unit test that exercises pyuno, clearly getting
> that working on Linux first would be ideal.

> Which reminds me - do we not have bridge-test code for each of the bindings 
> already ?

IIRC there is indeed a python bridge test,
testtools/source/bridgetest/pyuno. IIRC it also disabled because it
failed on some platforms back in the day when I last played with it.
Would indeed be worth trying to activate it for at least the platforms
where it does currently pass. I *think* the failures were under solaris
intel and macosx powerpc or something like that.

Most immediately useful thing currently using pyuno out of the box is
the email merge stuff.

C.

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

Re: [Libreoffice] [PATCH] Frac function in calc/BASIC

[Regina Henschel]

Hi August,

August Sodora schrieb:

I came across this feature request today and decided to try my hand at
it. Is the attached patch an appropriate solution?


I'm not sure about it. It seems you are mixing up BASIC functions and 
CALC interpreter.


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

Re: [Libreoffice] Unexpected failures (eg. segfaults) using PyUNO and LibreOffice/OpenOffice

[Michael Stahl]

On 19/10/11 10:17, Dag Wieers wrote:

Hi,

During the course of the LibreOffice conference in Paris, we (the
unoconv and cloudooo projects) found that some of the issues our users
were having while doing document conversions using PyUNO and OpenOffice
and LibreOffice were not related to our own project, but have a
root-cause in either PyUNO or LibreOffice/OpenOffice.

The result of these issues are various and individual:

- segfaults
- various error codes
- PyUNO crashes
- memory leaks
- xslt problems

And while some of them are reproducable (and consistent), others are
not, which makes me believe they are related to internal state or timing
issues of LibreOffice/OpenOffice or related to import/export filters.

Since these issues are very common and can be triggered very quickly, we
would like to have developers look at them to see what is the cause and
how we can fix them.


it is well known that the threading implementation in the OOo 
applications is rather unreliable.


currently for thread safety the implementers of UNO APIs are required to 
explicitly use low-level synchronization primitives such as mutexes.


not doing it correctly (such as locking a mutex while it should not be 
locked, or forgetting to lock a mutex while it should be locked) lead to 
very subtle problems that do not show up during ordinary office use, and 
are extremely difficult to reproduce.


basically the only way for developers to find these issues is via the 
subsequenttests, which currently are mostly implemented in Java and 
connect to the OOo instance via a UNO remote bridge.


and the only issues that are half-way easy do debug are deadlocks; in 
case of missing locks you may get a memory corruption _somewhere_ which 
causes some later test to crash, but it is very difficult to track down 
the root cause.


also, most of the developers who work on the applications are not 
experts in multi-threading issues (those who are tend to work on the 
lower-level layers like the URE).  for example i discovered once that in 
Writer almost all destructors of UNO objects do not lock a mutex but 
then call into the Writer core (have partially fixed this for OOo 3.3).


so as a result of all of this driving OOo/LO via remote bridges is 
rather unreliable.


some have suggested the best way out of this is to find a way so that 
implementers of UNO APIs do not have to care about thread safety 
themselves, but instead there should be a framework that does it 
automatically.  such a framework actually exists for many years now (Kay 
Ramme's "UNO threading framework"), but most of OOo/LO does not make use 
of it (iirc it is used for only some database drivers).


of course there may also be problems in PyUNO on top of that; back at 
Sun we had nothing that depended on PyUNO so i guess nobody spent much 
time debugging it...



The cloudooo project has tested about 100.000 conversions and
implemented some techniques to overcome the issues by monitoring the
libreoffice process for memory leaks and 'endless loops', and retrying
on failure. In the end this brought the failure rate down from about 10%
tot 1.1%.
(http://git.erp5.org/gitweb/cloudooo.git)


yes, there are various ways to minimize the risk of failure, no doubt 
you are already doing most of these:

- monitor the OOo instance and restart it
- only connect to an OOo instance from a single thread (should result in 
fewer problems, but e.g. with a JVM you still effectively get multiple 
connections, don't know about PyUNO)



Both the cloudooo and unoconv presentations will become available and
contain some information on both projects and the PyUNO/LO unreliabilities.



Below is some
example failure output from a single run, LibreOffice does seem a bit
more stable than OpenOffice though.


there are a lot of XSLT errors; LO (at least in 3.4) ships a different 
XSLT implementation, perhaps that has helped...


regards,
 michael

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

Re: [Libreoffice] make experts: progress information?

[Kevin Hunter]

At 5:16am -0400 Fri, 21 Oct 2011, Michael Meeks wrote:

On Thu, 2011-10-20 at 14:20 -0400, Kevin Hunter wrote:

That said, I anecdotally note on my limited-in-hardware machine,
that a consecutive run of make is almost instantaneous. Would a
make -pn really be that expensive?


Try running a no-op incremental make in tail_build :-) it's more
like 30+ seconds: now that of course also needs some love, and it is
some reasonably fun pure comp-sci type problem with no real need to
understand any of the LibO code-base; if someone wants an easy hack
;-)


Kevin: 0
Everyone else: 1

Touché,

Kevin

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

Re: [Libreoffice] make experts: progress information?

[Michael Meeks]

On Thu, 2011-10-20 at 14:20 -0400, Kevin Hunter wrote:
> That said, I anecdotally note on my limited-in-hardware machine, that a 
> consecutive run of make is almost instantaneous.  Would a make -pn 
> really be that expensive?

Try running a no-op incremental make in tail_build :-) it's more like
30+ seconds: now that of course also needs some love, and it is some
reasonably fun pure comp-sci type problem with no real need to
understand any of the LibO code-base; if someone wants an easy hack ;-)

ATB,

Michael.

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

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

[Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

[Michael Meeks]

Hi August,

On Thu, 2011-10-20 at 15:01 -0400, August Sodora wrote:
> On Tue, Oct 18, 2011 at 3:01 PM, August Sodora  wrote:
> > I've attached a new patch that includes some tests for the BASIC
> > scanner. Most of the test cases are just to get an idea of how the
> > scanner handles certain situations but I tried to make sure I included
> > ones that specifically trigger where the GetBufferAccess was.

Ooh ! :-) this is really nice. I was previously fooled by the subject
into not noticing that this was some sexy code cleanup + unit testing
patch.

Lovely work ! I added a doc. header for the new sal/ method, and since
I have: (setq-default show-trailing-whitespace t) in my ~/.emacs I see
red warnings of trailing whitespace - so removed a bit of that. One
thing I tweaked in one place is using sal_Int32 indexes into
rtl::OUStrings where previously sal_uInt16 indexes were adequate, one
benefit of your cleanup is that we can handler bigger scripts of course.

Anyhow - a lovely job :-) I'm really looking forward to see what you
touch next :-)

Many thanks !

Michael.

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

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

Re: [Libreoffice] minutes of tech. steering call ...

[Kevin Hunter]

At 4:11am -0400 Fri, 21 Oct 2011, Stephan Bergmann wrote:

On 10/21/2011 02:06 AM, Kevin Hunter wrote:

5. That API definition will be a *lot* of work, but hopefully somewhat
thought out already through only a mild reengineering of the current
binary API.


The UNO API is already there. Or what do you mean?


I was talking about an API that is not dependent on an ABI.  But I 
freely admit I know very little about ABIs, so I may have just conflated 
that term.  See below.



The upside is that if we're talking a major version change, /now/ would
be the time to do this.


A downside is that you would still need to maintain (and build!) the UNO
runtime for the MSVC ABI.


This may be the crux of what I'm not getting, but why?  Why can't a 
protocol be, say, text-based via (local, or other) socket?  In my mind, 
I see two independent programs, from two different compilers, using the 
OS and something akin to pipes to communicate.  I admit it might a 
smidgen slower to do it that way, but do people actually use LO in HPC 
scenarios?  (And I fully accept that they might, I just haven't seen it 
yet in my various interactions.)


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

Re: [Libreoffice] minutes of tech. steering call ...

[Kevin Hunter]

At 4:39am -0400 Fri, 21 Oct 2011, Michael Meeks wrote:

[one /could/ work toward interprocess extensions ... ] But of course,
I personally think there is much lower hanging fruit in the calc core
;-)


Noted and agreed!  I'm just sticking my nose in all things LO, probably 
stepping on toes as I do (sorry!).  I was more posing the question that 
I wasn't aware had gone by.  However, it sounds like y'all've already 
thought about that, or it's a "everyone already knows this" answer.


Cheers,

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

Re: [Libreoffice] Kubuntu Oneiric "Qt4 Libraries"

[Olivier Hallot]

Hi Jonathan

Em 21-10-2011 03:46, Jonathan Aquilina escreveu:
On 20/10/2011 22:31, Olivier Hallot wrote: 


I am taking a stab in the dark here, but have you tried installing the 
qt4-dev-tools package?


Yes, it is installed.

Peeking at configure.in, it seems that the test for Qt4 Libraries is 
done here:

...
qt_test_include="Qt/qobject.h"
qt_test_library="libQtCore.so"
kde_test_include="kwindowsystem.h"
kde_test_library="libsolid.so"
...
so looking for libQtCore.so, I found it in

/usr/lib/x86_64-linux-gnu/libQtCore.so

which belongs to package

libqt4-dev

which is installed...

sad... It worked well on Natty... Must be a twaek missing.


--
Olivier Hallot
Founder, Steering Commitee Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812

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

Re: [Libreoffice] minutes of tech. steering call ...

[Michael Meeks]

Hi Kevin,

On Thu, 2011-10-20 at 20:06 -0400, Kevin Hunter wrote:
>  From the wiki page, one of the concerns is "binary incompatibility".  I 
> assume this is in reference to extensions?

Sure; of course we only export a reasonably small ABI, the 'ure' (big
chunks of which are in-lined C++ methods that call SAL_CALL C functions
that we havn't changed and should cross-compile nicely). The
C++ helper classes (it is hoped) due to windows direct linking, and a
different ABI anyway shouldn't conflict.

My hope was(is) that UNO can shine here (with some tweaks) as a
bridging technology between the ABIs - at some fairly minimal
performance cost. At least, given Stephan's expertise & a little
testing, it "might just work". That would of course mean shipping some
duplicate legacy MSVC++ compiled libraries, but ... surely do-able.

> Question: is there merit to moving toward an enforced sub-process model 
> for extensions ?

It is an interesting idea; of course in theory UNO makes this easy, in
reality - I would scream and run away from cross-process component
usage. Debugging reference leaks / cycles / etc. is bad enough
in-process, never-mind cross-process; or worse between many (external)
components.

> 3. It would allow extensions to still be built with MSVC, regardless of
> what compiler the LO core project uses.

It may well solve this problem of course.

My experience with the debuggability and lifecycle management of the
Bonobo component model (which was heavily cross-process), was really an
extremely negative one, and that on Linux with really fast IPC.

Naturally, if people want to write their extensions that way, they can,
currently I imagine the only related grief is prolly around deployment.
If you're interested in it as a model, it would prolly be worth playing
with the deployment of such extensions. But of course, I personally
think there is much lower hanging fruit in the calc core ;-)

ATB,

Michael.

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

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

Re: [Libreoffice] Python on Windows

[Michael Meeks]

On Thu, 2011-10-20 at 23:21 +0200, Stephan Bergmann wrote:
> I must confess ...

Heh :-) seems reasonable enough.

> Anyway, if anybody less Windows-phobic than me would like to check out 
> whether pyuno still works on Windows, that would be great:

In the past I've had similar problems with finding and testing python
components, and the python3 work also subtly broke things without people
noticing.

What would be -really- excellent to nail this permanently would be to
have a during-compile unit test that exercises pyuno, clearly getting
that working on Linux first would be ideal. Which reminds me - do we not
have bridge-test code for each of the bindings already ? I wonder if
that is / could be cppunit-test-iszed :-)

Thanks for the heads up though,

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] Python on Windows

[Stephan Bergmann]

On 10/21/2011 01:20 AM, Miklos Vajna wrote:

On Thu, Oct 20, 2011 at 11:21:52PM +0200, Stephan Bergmann 
 wrote:

(c) pyuno as run from an external python process might no longer work.
An easy way to test that is to start the interactive python executable
from the LibO program directory and execute "include uno" (and/or
"include pyuno"; not sure right now which one is the more interesting,
but if both work I'd guess that's good).


You mean "import" in both cases, not "include", right?


Yes, sure, sorry.

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

Re: [Libreoffice] minutes of tech. steering call ...

[Stephan Bergmann]

On 10/21/2011 02:06 AM, Kevin Hunter wrote:

At 4:52pm -0400 Thu, 20 Oct 2011, Michael Meeks wrote:

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



+ getting stuck into Windows / mingw build etc.


 From the wiki page, one of the concerns is "binary incompatibility". I
assume this is in reference to extensions?

Question: is there merit to moving toward an enforced sub-process model
for extensions? My first thought is that this would do a couple of things:

[...]

5. That API definition will be a *lot* of work, but hopefully somewhat
thought out already through only a mild reengineering of the current
binary API.


The UNO API is already there.  Or what do you mean?

[...]

The upside is that if we're talking a major version change, /now/ would
be the time to do this.


A downside is that you would still need to maintain (and build!) the UNO 
runtime for the MSVC ABI.


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

Re: [Libreoffice] config & register toolbar controller in adddon

[Laurent Godard]

Hi

> 
> why? is it impossible to configure a custom toolbar in addon using
> controller.xcu ? and how to get it work in my addon?
>  does OOO  provides an API to give advanced custom toolbar configuration in
> a addon.
> 
> can someone help on this please?

you may have a look at the sdk, there are some example of custom toolbar
/sdk/examples/cpp/complextoolbarcontrols/

IIRC, Noel did some presentation about it at Paris

HTH

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

Re: [Libreoffice] [PATCH] Frac function in calc/BASIC

[Andor E]

Interestingly enough there seem to be two definitions for the frac
function. Your implementation is the one seemingly used by all
programming languages, which implement it. But the correct
mathematical definition seems to be y = x - floor(x)
(http://mathworld.wolfram.com/FractionalPart.html), which gives
different values for positive and negative numbers.

Other than that I believe the patch is fine.

Greetings

eymux

On Fri, Oct 21, 2011 at 5:19 AM, August Sodora  wrote:
> I came across this feature request today and decided to try my hand at
> it. Is the attached patch an appropriate solution?
>
> August Sodora
> aug...@gmail.com
> (201) 280-8138
>
> ___
> 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