[Libreoffice] patch for a few German to English translations

[Mike Whiteley]

I'm probably not doing this right, but I took a bit of time
and decided to help out a bit here.

Attached is a small patch for a few German to English
translations for some comments.  If this all goes well,
I plan on doing more, but this is a test of some.

Please let me know if there is a more preferred way
to submit these kinds of patches.

Mike
From 26eb32142a3ddd2415628fcb1bc600fe6ce48b2a Mon Sep 17 00:00:00 2001
From: mikew 
Date: Thu, 24 Nov 2011 23:56:22 -0800
Subject: [PATCH] Some German to English comment translations.

---
 UnoControls/source/base/basecontainercontrol.cxx |4 ++--
 automation/source/simplecm/simplecm.cxx  |   14 +++---
 automation/source/testtool/cmdstrm.cxx   |4 ++--
 basctl/source/basicide/basidesh.cxx  |3 +--
 basctl/source/basicide/tbxctl.cxx|4 ++--
 basctl/source/inc/svheader.hxx   |2 +-
 basic/inc/basic/testtool.hxx |2 +-
 basic/source/app/textedit.cxx|4 ++--
 basic/source/classes/sbunoobj.cxx|2 +-
 basic/source/comp/symtbl.cxx |2 +-
 basic/source/runtime/props.cxx   |2 +-
 11 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/UnoControls/source/base/basecontainercontrol.cxx b/UnoControls/source/base/basecontainercontrol.cxx
index 469146b..af1d349 100644
--- a/UnoControls/source/base/basecontainercontrol.cxx
+++ b/UnoControls/source/base/basecontainercontrol.cxx
@@ -208,8 +208,8 @@ Reference< XControlModel > SAL_CALL BaseContainerControl::getModel() throw( Runt
 
 void SAL_CALL BaseContainerControl::dispose() throw( RuntimeException )
 {
-// Zuerst der Welt mitteilen, da� der Container wegfliegt. Dieses ist um einiges
-// schneller wenn die Welt sowohl an den Controls als auch am Container horcht
+// Tell everything that this container is now gone.
+// It's faster if you listen to both the control and the container.
 
 // Ready for multithreading
 MutexGuard aGuard( m_aMutex );
diff --git a/automation/source/simplecm/simplecm.cxx b/automation/source/simplecm/simplecm.cxx
index b5087f2..ba9b799 100644
--- a/automation/source/simplecm/simplecm.cxx
+++ b/automation/source/simplecm/simplecm.cxx
@@ -376,7 +376,7 @@ ByteString CommunicationManager::GetMyName( CM_NameType )
 
 void CommunicationManager::CallConnectionOpened( CommunicationLink* pCL )
 {
-pCL->StartCallback();   // Sollte bereits vor dem Aufruf gerufen werden
+pCL->StartCallback();   // This should already have been called.
 pCL->aStart = DateTime();
 pCL->aLastAccess = pCL->aStart;
 bIsCommunicationRunning = sal_True;
@@ -385,7 +385,7 @@ void CommunicationManager::CallConnectionOpened( CommunicationLink* pCL )
 xLastNewLink = pCL;
 
 INFO_MSG( CByteString("C+:").Append( pCL->GetCommunicationPartner( CM_FQDN ) ),
-CByteString("Verbindung aufgebaut: ").Append( pCL->GetCommunicationPartner( CM_FQDN ) ),
+CByteString("Connection established: ").Append( pCL->GetCommunicationPartner( CM_FQDN ) ),
 CM_OPEN, pCL );
 ConnectionOpened( pCL );
 pCL->FinishCallback();
@@ -393,11 +393,11 @@ void CommunicationManager::CallConnectionOpened( CommunicationLink* pCL )
 
 void CommunicationManager::CallConnectionClosed( CommunicationLink* pCL )
 {
-pCL->StartCallback();   // Sollte bereits vor dem Aufruf gerufen werden
+pCL->StartCallback();   // This should already have been called.
 pCL->aLastAccess = DateTime();
 
 INFO_MSG( CByteString("C-:").Append( pCL->GetCommunicationPartner( CM_FQDN ) ),
-CByteString("Verbindung abgebrochen: ").Append( pCL->GetCommunicationPartner( CM_FQDN ) ),
+CByteString("Connection broken: ").Append( pCL->GetCommunicationPartner( CM_FQDN ) ),
 CM_CLOSE, pCL );
 ConnectionClosed( pCL );
 
@@ -410,9 +410,9 @@ void CommunicationManager::CallConnectionClosed( CommunicationLink* pCL )
 
 void CommunicationManager::CallDataReceived( CommunicationLink* pCL )
 {
-pCL->StartCallback();   // Sollte bereits vor dem Aufruf gerufen werden
+pCL->StartCallback();   // Should have already been called
 pCL->aLastAccess = DateTime();
-CommunicationLinkRef rHold(pCL);// H�lt den Zeiger bis zum Ende des calls
+CommunicationLinkRef rHold(pCL);// Keep the pointer for a bit.
 
 // should be impossible but happens for mysterious reasons
 if ( !pCL->pServiceData )
@@ -494,7 +494,7 @@ void CommunicationManager::CallDataReceived( CommunicationLink* pCL )
 
 void CommunicationManager::CallInfoMsg( InfoString aMsg )
 {
-// Hier wird es wohl kein Housekeeping geben
+// Probably no housekeeping here.
 InfoMsg( aMsg );
 }
 
diff --git a/automation/source/testtool/cmdstrm.cxx b/automation/source/testtool/cmdstrm.cxx
index 023fc4c..6aba838 100644
--- a/automation/source/testtool/cmdstrm.cxx
+++ b/automation/source/testtool/cmdstrm.cxx

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

[Bjoern Michaelsen]

On Thu, 24 Nov 2011 23:38:28 +0100
Bjoern Michaelsen  wrote:

> However, we are not so much interested in interactively working with
> soffice in the subsequenttest. So how about a very old fashioned and
> almost forgotten way to debug: creating a core dump!
> 
> For bonus points one could then even print the stacktrace of a crashed
> test right from "make subsequentcheck".
> 
> Opinions?

One allnigher later, its to late for opinions. Implemented with:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=74f44646ba5b400cc39d78940677f136711459b5
http://cgit.freedesktop.org/libreoffice/core/commit/?id=279473f1ed6cd3bb6f6d2b8b9c75529b91836e39
http://cgit.freedesktop.org/libreoffice/core/commit/?id=1cec66388eac81af2197da4fbf8fd2b00c56c7a5
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a1b57be652ac532ebddb3e3e53dddc35ae420f31

Still might need some tuning (core file location for example,
superfluous gdb output), but it basically works:

 ulimit -c unlimited && make subsequentcheck

gives you a full soffice stacktrace:

> It seems like soffice.bin crashed during the test excution!
> Found a core dump at 
> /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/user,
>  moving it to 
> /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/user/core.SfR2
> [...]
> Program terminated with signal 11, Segmentation fault.
> #0  0x2adaed22ffbd in sw::mark::MarkManager::MarkManager (this=0x325add0, 
> rDoc=..., __in_chrg=, __vtt_parm=) at 
> /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/sw/source/core/doc/docbm.cxx:310
> 310 int i = *(reinterpret_cast(NULL));
> #0 0x2adaed22ffbd in sw::mark::MarkManager::MarkManager (this=0x325add0, 
> rDoc=..., __in_chrg=,
> __vtt_parm=) at 
> /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/sw/source/core/doc/docbm.cxx:310
> [...]

While only showing the essentials of the Java stacktrace:
> 1) contents_flows_to(complex.accessibility.AccessibleRelationSet)
> com.sun.star.lang.DisposedException
> at $Proxy13.loadComponentFromURL(Unknown Source)
> at util.DesktopTools.openNewDoc(DesktopTools.java:247)
> at util.WriterTools.createTextDoc(WriterTools.java:51)
> at 
> complex.accessibility.AccessibleRelationSet.before(AccessibleRelationSet.java:168)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readInt(DataInputStream.java:392)  

and a hint at the full log:
> see full error log at 
> /mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/workdir/unxlngx6.pro/JunitTest/sw_complex/done.log
> make[1]: Leaving directory 
> `/mnt/striped/bjoern/.jenkins/jobs/libreoffice-master/workspace/sw'   

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEWED] Re: identical text for different (but close) locale at scp2/source/ooo

[Lior Kaplan]

On Thu, Nov 24, 2011 at 8:28 PM, Andras Timar  wrote:

> Hi Kaplan,
>
> 2011/11/24 Lior Kaplan :
> > On Thu, Nov 24, 2011 at 1:14 PM, Lior Kaplan 
> wrote:
> >>
> >>
> >> On Thu, Nov 24, 2011 at 1:05 PM, Andras Timar 
> wrote:
> >>>
> >>> Hi Kaplan,
> >>>
> >>> 2011/11/24 Lior Kaplan :
> >>> > Hi,
> >>> >
> >>> > While translating some scp2 strings for 3.5 I notice duplicate
> strings
> >>> > which
> >>> > looks weird (e.g. "Installs the Tamil user interface").
> >>> >
> >>> > I checked the sources and notice this is because we have two locales
> >>> > for
> >>> > Tamil:
> >>> >
> >>> > [STR_NAME_MODULE_LANGPACK_TA]
> >>> > en-US = "Tamil"
> >>> >
> >>> > [STR_DESC_MODULE_LANGPACK_TA]
> >>> > en-US = "Installs the Tamil user interface"
> >>> >
> >>> > [STR_NAME_MODULE_LANGPACK_TA_IN]
> >>> > en-US = "Tamil"
> >>> >
> >>> > [STR_DESC_MODULE_LANGPACK_TA_IN]
> >>> > en-US = "Installs the Tamil user interface"
> >>> >
> >>> > Do we really support two locales or this is a mistake? If we do
> support
> >>> > two
> >>> > locales, the users should have a way to differentiate between the
> two.
> >>> >
> >>>
> >>> We don't support ta_IN, only ta. In fact those lines could be removed
> >>> from scp2 (there are more to clean up I suppose).
> >>> For supported UI locales see
> >>> http://opengrok.libreoffice.org/xref/core/solenv/inc/langlist.mk
> >>>
> >>
> >> Good to know. I'll do the clean up and send a patch...
> >>
> >
> > Attaching two patches to clean the help and language pack translation
> > strings. Also a small clean up patch for the langlist.mk file to have it
> > sorted.
> >
> > Dictionary list is verified and is updated (no changes needed).
> >
>
> Please push 0001 and 0003. In 0002 you were a bit greedy in deleting
> stuff. :) Save at least qtz. I would save all languages in helppack
> file which have an UI pack. So I don't have to remember to re-add them
> and translators don't have to re-translate them when a language team
> decides to translate the help, too.
>

Fair enough. Attaching an updated patch instead of #0002... This time
removing only languages without a translation, not without a help
translation.

qtz saved... ooops.

Kaplan
From 960f0bf33bda537079390f3bad44c6c5979f514e Mon Sep 17 00:00:00 2001
From: Lior Kaplan 
Date: Fri, 25 Nov 2011 04:20:31 +0200
Subject: [PATCH] Clean help pack list based on the current files in the
 translation repository (translations/source/)

---
 scp2/source/ooo/module_helppack.ulf |  180 ---
 1 files changed, 0 insertions(+), 180 deletions(-)

diff --git a/scp2/source/ooo/module_helppack.ulf b/scp2/source/ooo/module_helppack.ulf
index 4737584..18ac86e 100644
--- a/scp2/source/ooo/module_helppack.ulf
+++ b/scp2/source/ooo/module_helppack.ulf
@@ -193,36 +193,18 @@ en-US = "Punjabi"
 [STR_DESC_MODULE_HELPPACK_PA_IN]
 en-US = "Installs Punjabi help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_GU_IN]
-en-US = "Gujarati"
-
-[STR_DESC_MODULE_HELPPACK_GU_IN]
-en-US = "Installs Gujarati help in %PRODUCTNAME %PRODUCTVERSION"
-
 [STR_NAME_MODULE_HELPPACK_TA]
 en-US = "Tamil"
 
 [STR_DESC_MODULE_HELPPACK_TA]
 en-US = "Installs Tamil help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_TA_IN]
-en-US = "Tamil"
-
-[STR_DESC_MODULE_HELPPACK_TA_IN]
-en-US = "Installs Tamil help in %PRODUCTNAME %PRODUCTVERSION"
-
 [STR_NAME_MODULE_HELPPACK_HI]
 en-US = "Hindi"
 
 [STR_DESC_MODULE_HELPPACK_HI]
 en-US = "Installs Hindi help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_HI_IN]
-en-US = "Hindi"
-
-[STR_DESC_MODULE_HELPPACK_HI_IN]
-en-US = "Installs Hindi help in %PRODUCTNAME %PRODUCTVERSION"
-
 [STR_NAME_MODULE_HELPPACK_ST]
 en-US = "Southern Sotho (Sutu)"
 
@@ -253,12 +235,6 @@ en-US = "Afrikaans"
 [STR_DESC_MODULE_HELPPACK_AF]
 en-US = "Installs Afrikaans help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_SW]
-en-US = "Swahili"
-
-[STR_DESC_MODULE_HELPPACK_SW]
-en-US = "Installs Swahili help in %PRODUCTNAME %PRODUCTVERSION"
-
 [STR_NAME_MODULE_HELPPACK_SW_TZ]
 en-US = "Swahili"
 
@@ -283,42 +259,18 @@ en-US = "Bengali"
 [STR_DESC_MODULE_HELPPACK_BN]
 en-US = "Installs Bengali help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_BN_BD]
-en-US = "Bengali (Bangladesh)"
-
-[STR_DESC_MODULE_HELPPACK_BN_BD]
-en-US = "Installs Bengali (Bangladesh) help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPACK_BN_IN]
-en-US = "Bengali (India)"
-
-[STR_DESC_MODULE_HELPPACK_BN_IN]
-en-US = "Installs Bengali (India) help in %PRODUCTNAME %PRODUCTVERSION"
-
 [STR_NAME_MODULE_HELPPACK_OR]
 en-US = "Oriya"
 
 [STR_DESC_MODULE_HELPPACK_OR]
 en-US = "Installs Oriya help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_OR_IN]
-en-US = "Oriya"
-
-[STR_DESC_MODULE_HELPPACK_OR_IN]
-en-US = "Installs Oriya help in %PRODUCTNAME %PRODUCTVERSION"
-
 [STR_NAME_MODULE_HELPPACK_MR]
 en-US = "Marathi"
 
 [STR_DESC_MODULE_HELPPACK_MR]
 en-US = "Installs Marathi help in %PRODUCTNAME %PROD

Re: [Libreoffice] Getting some press about Citrus.

[Olivier Hallot]

Em 24-11-2011 19:24, Michael Meeks escreveu:

On Thu, 2011-11-24 at 20:10 +, Caolán McNamara wrote:

On Thu, 2011-11-24 at 15:01 -0500, Andrew Pullins wrote:

today OMG Ubuntu reported on the Citrus UI [1]. from reading the
comments on the article is for it. course every one is for a new UI,
for the current one sucks.

Its just a picture of a UI, right ? :-)

Right ;-) though, last I looked several pictures; looks nice enough -
and quite possibly do-able as a 'feature-reduced' mode [ IIRC almost all
the toolbars vanished eg. ], side-by-side with what we have if someone
wanted to hack on it I guess.

ATB,

Michael.

It looks like, in a first glimpse, that the new UI pushes for direct 
formatting and not style formatting.

I may be wrong

--
Olivier Hallot
Founder, Board of Directors 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] text:class-names and nested text:span/text:style-name

[Michael Stahl]

On 24/11/11 16:37, Dag Wieers wrote:
> On Thu, 24 Nov 2011, Dag Wieers wrote:
> 
>> Case 1: Using text:class-names
>>
>>bold > text:class-names="strong blue">blue bold
>>
>> No syles seem to have been applied.

i have found some rudimentary processing of text:class-names in the ODF
paragraph import, but even that is incomplete and cannot work.

so this attribute is sadly not supported; please file a bug in bugzilla.

>> Case 2: Using nested text:span/text:style-name
>>
>>bold > text:style-name="blue">blue bold
>>
>> Bold is bold. Blue is blue, but not bold !
> 
> After more experiments I found that Case 2 does work when the styles 
> are defined inside  instead of .
> 
> Which I believe is a bug in LibreOffice.

have reproduced this: the problem only happens with the flat ODT import
filter, the ODT package import does it correctly.

so there is apparently a bug with the import of non-automatic styles in
flat ODT files; please file this also in bugzilla (separate from
class-names issue).

note that there is actually an obscure feature in the UI that allows you
to add multiple character styles:

1. open stylist
2. apply first character style. e.g. Emphasis
3. single click on second character style, e.g. Strong Emphasis
4. shift+double-click on second character style

the stylist cannot display a multi selection (i filed an OOo issue for
that once...), so it will only display one style as selected, but in the
text you can see both are applied.

in the ODF file this is stored as:

 
   Foo
 

which is the same thing you have.

regards,
 michael

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

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

[Bjoern Michaelsen]

On Thu, 24 Nov 2011 20:23:22 +
Caolán McNamara  wrote:

> On Thu, 2011-11-24 at 16:26 +, Michael Meeks wrote:
> > + Bjoern has a nice write-up of how to debug it here:
> i.e. sommat like
> a) just move that out of dev-tools into bin or solenv/bin
> b) tweak it to honour $COLORTERM/$TERM -e
> c) add a handle SIGPIPE nostop noprint pass
> d) get the definitely correct pid in there
> ---
> e) get the tooling to catch the disconnected error and say that
> LibreOffice crashed, rather than the current somewhat obscure error
> f) spit out a line liner to rerun the first failing test in isolation
> with soffice server under gdb

Hmm, I just had another crazy idea, since we are mostly interested in
two things from the junit test:
- does the product work as expected?
  that works reasonably well as long as the test doesnt crash
  however crashes are icky to detect reliable "from the outside"
- if it crashes, we want to have a backtrace

However, we are not so much interested in interactively working with
soffice in the subsequenttest. So how about a very old fashioned and
almost forgotten way to debug: creating a core dump!

For bonus points one could then even print the stacktrace of a crashed
test right from "make subsequentcheck".

Opinions?

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW] libreoffice-3-4 fix of two Windows installer bugs

[Andras Timar]

Hi,

I would like to have the attached two patches applied to libreoffice-3-4.

One is fixing fdo#32112. It is an easy one. LibreOffice creates a
directory but the installer does not know about it. So uninstall
leaves it there. If this directory is created by the installer, then
it will be removed during uninstall, so we can have a clean uninstall.

The second is more complex. It fixes fdo#36677. The bug occurs only
during silent install. During uninstall the installer checks is
LibreOffice is running. However, the check was a bit lame. It tried to
remove a file or folder (depending on Windows version), but Program
Files folder is normally write protected to the user. Silent uninstall
was started with user privileges and uninstall process always failed.
Instead of file manipulation now we check, if there is "soffice.bin"
in the process list.

I tested both patches with LibreOffice 3.4.4 on Windows XP and on
Windows 7. I tested the second one in both scenarios, i.e. when
LibreOffice was running during uninstall and when it was not running.
I pushed the first one to master and I will push the second one there,
too, after some necessary changes.

Thanks,
Andras


0001-create-this-dir-so-uninstall-can-remove-it.patch
Description: Binary data


0001-change-logic-of-IsOfficeRunning-custom-action-fdo-36.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Possible little code simplification

[Michael Stahl]

On 24/11/11 19:07, Ivan Timofeev wrote:
> Hi all,
> 
> we have the field 'SwSortedObjs* pSortedObjs' in the class SwPageFrm.
> And we have the strange management of it:
> 
> For example, sw/source/core/layout/flylay.cxx:734
> 
> if ( pSortedObjs )
> {
> pSortedObjs->Remove( *pToRemove );
> if ( !pSortedObjs->Count() )
> {   DELETEZ( pSortedObjs );
> }
> }
> 
> i.e. we delete pSortedObjs every time it is empty, and create it again
> when we want to add something into it. This entails annoying checks,
> like
> 
> if ( pPage->GetSortedObjs() )
> // [loop over pSortedObjs]
> 
> What do you think about changing the code so that pSortedObjs will be
> alive every time? We will be able to return a reference to pSortedObjs
> in GetSortedObjs() instead of a pointer and remove the mentioned
> checks (there are a lot of such checks). I could do this. :-)

the writer core and layout code is highly optimized, especially for
16-bit windows where memory is scarce :)

i guess for SwPageFrm it doesn't matter at all if the SwSortedObj always
exists.

> Same problem with the field 'SwSortedObjs* pDrawObjs' in the class SwFrm.

since this is the base class of all frames there will be a couple more
instances of it, and most of these probably won't use pDrawObjs; would
be interesting to know how much memory this would uses for a large
document...

> All the best,
> Ivan


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

Re: [Libreoffice] message construction bloat ...

[Marc-André Laverdière]

Can we get the c++ equivalent of logback/slf4j? Avoiding string concat most
of the time is the better option.

Marc-André Laverdière
Sent from a mobile device, please  excuse the brevity

On 23 Nov 2011 11:56, "Lubos Lunak"  wrote:

On Wednesday 23 of November 2011, Michael Meeks wrote:

> On Wed, 2011-11-23 at 14:56 +0100, Lubos Lunak wrote:

> > And some of the arguments are rather weak as well, I can get you easy to
> > use and read, bett...
 I haven't thought it out in detail, but the general idea is attached. It's
just a proof of concept, so there are some obvious problems, but I don't see
a flaw in the design. Since it's also just a single call, the in-place cost
is small and is moved to the bodies of the templates, which can be just in
one place, one per each combination of arguments (and the common instances
of
the template can be externed, so it really will be just one copy). The
template code is relatively small, so I don't expect noticeable impact on
compile time. Also, funnily enough, the generated code in the place of the
call is one instruction shorter, because unlike printf() it does not need
the
terminating NULL for the vararg :).

 I expect it would be even possible to achieve such single in-place call
even
for the LOG( "P is " << p << " and b is " << b ) case, or even do this for
string+string operation, which would turn it into the even better-looking
LOG( "P is " + p + " and b is " b ) or LOG( "P is %1 and b is %2", p, b ),
whichever would suit one's fancy (as in, both would be possible at the same
time). It would require getting a bit more creative with argument and return
types for the operator overloads, but that'd be hidden behind the scenes.

--
 Lubos Lunak
 l.lu...@suse.cz

___
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] Getting some press about Citrus.

[Michael Meeks]

On Thu, 2011-11-24 at 20:10 +, Caolán McNamara wrote:
> On Thu, 2011-11-24 at 15:01 -0500, Andrew Pullins wrote:
> > today OMG Ubuntu reported on the Citrus UI [1]. from reading the
> > comments on the article is for it. course every one is for a new UI,
> > for the current one sucks.  
> 
> Its just a picture of a UI, right ? :-)

Right ;-) though, last I looked several pictures; looks nice enough -
and quite possibly do-able as a 'feature-reduced' mode [ IIRC almost all
the toolbars vanished eg. ], side-by-side with what we have if someone
wanted to hack on it I guess.

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] Question about IAccessibility2

[Michael Meeks]

On Thu, 2011-11-24 at 21:20 +0100, Christophe Strobbe wrote:
> >Those are already strings, which will be localized. I have no 
> >application to test, whether this is sufficient. But I guess it 
> >will, because otherwise people would have complained in a lot of 
> >other places where list boxes are used.

:-)

> Just in case you would like to test this: there are two free options 
> on Windows:

I would recommend asking a friend to test this on Linux, where the
accerciser tool will instantly show you whether you've got the new names
right; and it is native code without any twisted java-ness.

Having said that - simply adding a new accessible name is sufficiently
simple that we can check that at code-review time, I don't think there
is need for detailed testing there.

> OK. And thanks for asking questions about accessibility :-)

Though of course this is cool :-)

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] Setting up a non-intrusive build cluster

[Marc-André Laverdière]

not ubuntu. i logged on two accounts and only one shows...

Marc-André Laverdière
Sent from a mobile device, please  excuse the brevity

On 24 Nov 2011 07:10, "Lionel Elie Mamane"  wrote:

On Wed, Nov 23, 2011 at 06:28:41PM -0500, Marc-André Laverdière wrote:
> I played with the utmp stuf...
My "who" shows *only* interactive sessions... Be they graphical, on
the console or through ssh.

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

[Libreoffice] build break in smoketestoo_native : LibO_*_install-arc_en-US.zip: No such file or directory

[xuanyong.yang]

Hello!

I got the following error in make dev-install . Any ideas? and I didn't make 
any changes in the code, just trying to build the master on winxp 
.---1,
 autogen,./autogen.sh  --disable-build-mozilla  
--with-mozilla-build="/cygdrive/d/mozilla-build"  
--with-ant-home=/cygdrive/c/apache-ant-1.8.2   
--with-directx-home="/cygdrive/d/Program Files/Microsoft DirectX SDK (February 
2010)"  --without-junit --disable-activex --disable-atl --enable-symbols 
--enable-debug2, make is OK now,3, make dev-install:Yangxuanyong@mbp 
/cygdrive/x/lo $ /opt/lo/bin/make dev-install -o build = (1/1) 
Building module smoketestoo_native = Entering 
/cygdrive/x/lo/smoketestoo_native/data Entering 
/cygdrive/x/lo/smoketestoo_native/com/sun/star/comp/smoketest Making:
com_sun_star_comp_smoketest.dpz   adding: content.xml (deflated 77%)   adding: 
meta.xml (deflated 55%)   adding: settings.xml (deflated 79%)   adding: 
styles.xml (deflated 75%)   adding: mimetype (stored 0%)   adding: 
META-INF/manifest.xml (deflated 73%)   adding: Basic/script-lc.xml (deflated 
51%)   adding: Basic/Standard/script-lb.xml (deflated 55%)   adding: 
Basic/Standard/Events.xml (deflated 55%)   adding: Basic/Standard/Global.xml 
(deflated 78%)   adding: Basic/Standard/Test_10er.xml (deflated 82%)   adding: 
Basic/Standard/Test_DB.xml (deflated 68%)   adding: Basic/Standard/Test_Ext.xml 
(deflated 64%)   adding: Dialogs/dialog-lc.xml (deflated 51%)   adding: 
Dialogs/Standard/dialog-lb.xml (deflated 51%)   adding: 
Dialogs/Standard/OptionsDlg.xml (deflated 73%) cp 
../wntmsci12.pro/misc/zip/smoketestdoc.sxw ../wntmsci12.pro/bin/smoketestdoc. 
sxw dmake:  Warning: -- Target [.TARGETS] was made but the time stamp has not 
been u pdated. Making:com_sun_star_comp_smoketest.dpj javadeps dmake:  
Warning: -- Target [.TARGETS] was made but the time stamp has not been u 
pdated. Making:com_sun_star_comp_smoketest.dpj javadeps Compiling: 
TestExtension.idl dmake:  Warning: -- Target 
[../../../../../wntmsci12.pro/class/TestExtension.jar ] was made but the time 
stamp has not been updated. Making:TestExtension.oxt rebuilding zipfiles 
-- Making:com_sun_star_comp_smoketest.dpz 
Making:com_sun_star_comp_smoketest.dpj javadeps Magic: cafebabe Major 50, 
Minor 0 Const_pool_count 66 dmake:  Warning: -- Target [.TARGETS] was made but 
the time stamp has not been u pdated. Making:
com_sun_star_comp_smoketest.dpj javadeps Magic: cafebabe Major 50, Minor 0 
Const_pool_count 66 dmake:  Warning: -- Target 
[../../../../../wntmsci12.pro/misc/com_sun_star_comp_ smoketest.dpj] was made 
but the time stamp has not been updated. dmake:  Warning: -- Target [.TARGETS] 
was made but the time stamp has not been u pdated. Entering 
/cygdrive/x/lo/smoketestoo_native Making:all_smoketest.dpslo ls: cannot 
access X:/lo/instsetoo_native/wntmsci12.pro/LibreOffice/archive/insta 
ll/en-US/LibO_*_install-arc_en-US.zip: No such file or directory dmake:  Error 
code 2, while making 'Shell escape' Retrying /cygdrive/x/lo/smoketestoo_native 
ls: cannot access 
X:/lo/instsetoo_native/wntmsci12.pro/LibreOffice/archive/insta 
ll/en-US/LibO_*_install-arc_en-US.zip: No such file or directory dmake:  Error 
code 2, while making 'Shell escape' Entering /cygdrive/x/lo/smoketestoo_native 
ls: cannot access 
X:/lo/instsetoo_native/wntmsci12.pro/LibreOffice/archive/insta 
ll/en-US/LibO_*_install-arc_en-US.zip: No such file or directory dmake:  Error 
code 2, while making 'Shell escape' Retrying /cygdrive/x/lo/smoketestoo_native 
ls: cannot access 
X:/lo/instsetoo_native/wntmsci12.pro/LibreOffice/archive/insta 
ll/en-US/LibO_*_install-arc_en-US.zip: No such file or directory dmake:  Error 
code 2, while making 'Shell escape' 
--- 
Oh dear - something failed during the build - sorry !   For more help with 
debugging build errors, please see the section in: 
http://wiki.documentfoundation.org/Development   internal build errors: ERROR: 
error 65280 occurred while making /cygdrive/x/lo/smoketestoo_native  it seems 
that the error is inside '', please re-run build  inside this module to isolate 
the error and/or test your fix: 
--- 
/usr/bin/sh cd X:/lo source ./Env.Host.sh cd rm -Rf X:/lo//wntmsci12.pro # 
optional module 'clean' build when the problem is isolated and fixed exit and 
re-run 'make' from the top-level make: *** [dev-install] Error 1 
Yangxuanyong@mbp /cygdrive/x/lo $___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] errors in idl files

[Stephan Bergmann]

On 11/24/2011 08:24 PM, Tomas Hlavaty wrote:

Are there any native implementations of the UNO RPC protocol so far,
e.g. for Java or is everybody going through FFI?


Java has its own, pure Java URP implementation.  (And Java chickens out 
with regard to reading types.rdb, in that it has its own copy of that 
information, in the form of Java class files, one for each relevant 
UNOIDL entity.)


But yes, your "additional languages" scenario is yet another reason why 
the current types.rdb format is a bad idea.  I would really love to get 
this fixed.  Lets see...


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

Re: [Libreoffice] build break in drawinglayer component(unresolved?external in BZPixelRaster)

[xuanyong.yang]

Yeah, It is OK now.
 
-- Original --
From:  "Noel Grandin";
Date:  Tue, Nov 22, 2011 01:17 AM
To:  "Thorsten Behrens"; 
Cc:  "xuanyong.yang"; "Fridrich Strba"; 
"libreoffice"; 
Subject:  Re: [Libreoffice] build break in drawinglayer 
component(unresolved?external in BZPixelRaster)

 
I also saw that error, and I seem to remember Fridrich fixing it.

But I think I had to do a 'make clean' and then 'make' to fix it.


On Mon, Nov 21, 2011 at 18:55, Thorsten Behrens
 wrote:
> xuanyong.yang wrote:
>> I got the following error. Any ideas? and I didn't make any
>> changes in the code, just trying to build the master on winxp .
>>
> Seen this a while ago, Fridrich or someone else fixed it - you may
> want to git pull -r & rerun.
>
> Fridrich, weren't there some known-good-for-windows state in some
> git note?
>
> HTH,
>
> -- 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

[Libreoffice] [PATCH] fdo#42286, do not shrink the selected area

[Pierre-André Jacquod]

hello,
here attached an new patch (hopefully wiser) to solve the mentioned bug. 
This  ensure that the call to ExtendDataArea does as commented in the 
code sc/source/core/tool/dbdata.cxx :

// Extend the DB area to include data rows immediately below.
and does not shrink the original area... So having a smaller area after 
the function is clearly wrong.


If you agree, I will push it to master.

BUT this is a workaround, to compensate the not so correct behaviour of 
GetDataArea :-(


I did this patch in order to bring the correction in time for 3.5.0 & 
3.4.5, but I agree, that this is suppressing a symptom and not the root 
cause.


About the root cause: I am still studing the code of the both mentioned 
functions and their integration with filters and filtered areas. Before 
touching it, I would like to define what should be the desired effect. 
Further some tests have shown me that the behaviour (regarding area) is 
not the same, depending if the filter is activated with 
Data->Filter->AutoFilter or Standard filter. I fear some parts will need 
to be quite overhauled.


As said, won't be ready for 3.5, so first this short term solution.

Thanks toa all for having helped me so far.
Best regards
Pierre-André


0001-fdo-42286-do-not-shrink-the-filtered-area-when-calli.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED][PATCH] SwSelBoxes: svarray -> std::map

[Caolán McNamara]

On Thu, 2011-11-24 at 15:58 +, Caolán McNamara wrote:
> On Thu, 2011-11-24 at 23:19 +0900, Daisuke Nishino wrote:
> > I'm not sure if this is related to the problem, but I found an obvious
> > mistake.
> > I hope this patch fixes it.
> > I'm sorry for inconvenience.
> 
> aha, excellent. That clear's the most obvious one anyway. Will see if it
> fixes everything, or if the remaining glitch I see is preexisting.

Indeed, all looks good now. "make subsequentcheck" just fails now I
believe because we have some conversions to "assert" from DBG_ASSERT or
OSL_ENSURE in
SwIndex::operator< so
 -o sw.SwXTextEmbeddedObject
 -o sw.SwXTextEmbeddedObjects
fail, which is unrelated to the table stuff.

C.

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

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

[Caolán McNamara]

On Thu, 2011-11-24 at 16:26 +, Michael Meeks wrote:
>   + subsequentcheck
>   + number of ways to improve it (Caolan)
>   + Bjoern has a nice write-up of how to debug it here:

i.e. sommat like
a) just move that out of dev-tools into bin or solenv/bin
b) tweak it to honour $COLORTERM/$TERM -e
c) add a handle SIGPIPE nostop noprint pass
d) get the definitely correct pid in there
---
e) get the tooling to catch the disconnected error and say that
LibreOffice crashed, rather than the current somewhat obscure error
f) spit out a line liner to rerun the first failing test in isolation
with soffice server under gdb

C.

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

Re: [Libreoffice] Question about IAccessibility2

[Christophe Strobbe]

Hi Regina,

At 15:31 24-11-2011, Regina Henschel wrote:

Hi Christophe,

Christophe Strobbe schrieb:

(...)


I come across "IAccessibility2" (...) Such string
resources are used in method SetAccessibleName in
/core/cui/source/tabpages/tpline.cxx


SetAccessibleName is a method that exists in several accessibility APIs,
e.g.
* ATK: atk_object_set_name:

* Java:


* Microsoft: :
"IAccessibleObject::SetAccessibleName method"


So it is a comprehensive concept.



(...) if you are referring
to a list box where an author can choose between different
stroke-linecap styles, I would definitely give those options an
accessible name (e.g. butt cap, round cap and square cap, which I found
in the SVG spec).


Those are already strings, which will be localized. I have no 
application to test, whether this is sufficient. But I guess it 
will, because otherwise people would have complained in a lot of 
other places where list boxes are used.


Just in case you would like to test this: there are two free options 
on Windows:


* NVDA: an open-source screen reader: . 
(The portable version can be run from a USB key if you don't want to 
install it.) When testing with a screen reader, you first need to 
installe the Java Access Bridge: 
.


* The Java Accessibility Utilities, which you can (still) find at 
<http://java.sun.com/javase/technologies/accessibility/downloads.jsp>. 
Because LibreOffice on Windows uses the Java Accessibility API, you 
can these inspection tools.
The Java Accessibility Utilities include Java Monitor, Ferret, Monkey 
and AccessibilityMonitor. To use, for example, Java Monitor, one 
should go through the following steps:

1. Add the jar files jaccess.jar and jaccess-examples.jar in the CLASSPATH.
2. Modify the file lib/accessibility.properties in the JDKHOME 
directory to include the following line:

assistive_technologies=JavaMonitor
Note that the README.txt claims that this line should be 
"AWT.assistive_technologies=JavaMonitor", but this is not correct.
3. When you start LibreOffice (or a pure Java application), Java 
Monitor will start automatically.
For checking accessible name, description, role, value and state(s) 
in menus, Ferret is the appropriate tool.
(Oh, and alway close LibreOffice if you want to close the 
accessibility utility; if you try to close the accessibility utility 
first, it will also close LibreOffice.)



I think I postpone this special detail until the rest is finished 
and there is a product that can be tested in connection with an 
accessibility application.


OK. And thanks for asking questions about accessibility :-)

Best regards,

Christophe


--
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Twitter: @RabelaisA11y
---
Open source for accessibility: results from the AEGIS project 
www.aegis-project.eu

---
Please don't invite me to Facebook, Quechup or other "social 
networks". You may have agreed to their "privacy policy", but I haven't.


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

Re: [Libreoffice] Getting some press about Citrus.

[Caolán McNamara]

On Thu, 2011-11-24 at 15:01 -0500, Andrew Pullins wrote:
> today OMG Ubuntu reported on the Citrus UI [1]. from reading the
> comments on the article is for it. course every one is for a new UI,
> for the current one sucks.  

Its just a picture of a UI, right ? :-)

C.

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

[Libreoffice] Getting some press about Citrus.

[Andrew Pullins]

today OMG Ubuntu reported on the Citrus UI [1]. from reading the comments
on the article is for it. course every one is for a new UI, for the current
one sucks.

[1]
http://www.omgubuntu.co.uk/2011/11/citrus-a-libreoffice-interface-for-today/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] message construction bloat ...

[Lubos Lunak]

On Wednesday 23 of November 2011, Lubos Lunak wrote:
>  I expect it would be even possible to achieve such single in-place call
> even for the LOG( "P is " << p << " and b is " << b ) case, or even do this
> for string+string operation, which would turn it into the even
> better-looking LOG( "P is " + p + " and b is " b ) or LOG( "P is %1 and b
> is %2", p, b ), whichever would suit one's fancy (as in, both would be
> possible at the same time). It would require getting a bit more creative
> with argument and return types for the operator overloads, but that'd be
> hidden behind the scenes.

 Oh well, I guess I couldn't resist the temptation to try at least a proof of 
concept. The attached testapp (depending on #define OPT) compiles things like 
string1 + "foo" + string2 + "bar" + string3 into a call to a single function 
which allocates just a single string object for the result of the operation, 
no intermediate string objects or allocations are required.

 So it indeed looks doable and we can have efficient and at the same time not 
ackward to use string operations. Something for the next Hackweek or so.

 Could somebody try that it works with the Windows compiler as well?

-- 
 Lubos Lunak
 l.lu...@suse.cz
#include 
#include 

class string
{
public:
string( const char* str = NULL );
string( const string& );
string( char* data, int len );
string& operator=( const string& );
string& operator+=( const string& );
~string();
const char* str() const;
//private:
int len;
char* data;
};

#define OPT

inline string::string( char* data, int len )
: len( len )
, data( data )
{
}

#ifndef OPT
inline string operator+( const string& str1, const string& str2 )
{
return string( str1 ) += str2;
}
#else
template< typename T1, typename T2 >
class stringplus
{
public:
stringplus( const T1& s1, const T2& s2 );
operator string() const;
//private:
const T1& str1;
const T2& str2;
};

template< typename T1, typename T2 >
inline stringplus< T1, T2 >::stringplus( const T1& s1, const T2& s2 )
: str1( s1 )
, str2( s2 )
{
}

template< typename T1, typename T2 >
inline stringplus< T1, T2 > operator+( const T1& str1, const T2& str2 )
{
return stringplus< T1, T2 >( str1, str2 );
}

template< typename T >
static int len( const T& s );
template< typename T >
static void copydata( char* dest, const T& s );

inline int len( const char* s )
{
return strlen( s );
}
inline void copydata( char* dest, const char* s )
{
strcpy( dest, s );
}

template<>
inline int len( const string& s )
{
return s.len;
}
template<>
inline void copydata( char* dest, const string& s )
{
strcpy( dest, s.data );
}

template< typename T1, typename T2 >
inline int len( const stringplus< T1, T2 >& str )
{
return len( str.str1 ) + len( str.str2 );
}
template< typename T1, typename T2 >
inline void copydata( char* dest, const stringplus< T1, T2 >& str )
{
int len1 = len( str.str1 );
copydata( dest, str.str1 );
copydata( dest + len1, str.str2 );
}

template< typename T1, typename T2 >
string concat( const T1& str1, const T2& str2 )
{
int len1 = len( str1 );
int len2 = len( str2 );
char* newdata = new char[ len1 + len2 + 1 ];
copydata( newdata, str1 );
copydata( newdata + len1, str2 );
printf( "ALLOC %s\n", newdata );
return string( newdata, len1 + len2 );
}

template< typename T1, typename T2 >
inline string make_concat( const stringplus< T1, T2 >& str )
{
return concat( str.str1, str.str2 );
}

// A helper function is needed, because the compiler does not like
// a template that recursively refers to itself, i.e. this:
// template< typename T1, typename T2, typename T3 >
// inline stringplus< stringplus< T1, T2 >, T3 >::operator string() const .
// Not sure whether maybe I'm doing something wrong, but this easily solves it.
template< typename T1, typename T2, typename T3 >
inline string make_concat( const stringplus< T1, T2 >& str1, const T2& str2 )
{
return concat( str1.str1, str1.str2, str2 );
}

template< typename T1, typename T2 >
inline stringplus< T1, T2 >::operator string() const
{
return make_concat( *this );
}
#endif

inline const char* string::str() const
{
return data;
}


string::string( const char* str )
: len( str != NULL ? strlen( str ) : 0 )
, data( new char[ len + 1 ] )
{
if( str != NULL )
strcpy( data, str );
else
*data = '\0';
printf( "ALLOC %s\n", data );
}

string::string( const string& str )
: len( str.len )
, data( new char[ len + 1 ] )
{
strcpy( data, str.data );
printf( "ALLOC %s\n", data );
}

string& string::operator=( const string& str )
{
if( data == str.data )
return *this;
delete[] data;
data = new c

Re: [Libreoffice] errors in idl files

[Tomas Hlavaty]

Hi Michael,

Michael Meeks  writes:
> Ok :-) so you would have a native implementation of the UNO RPC
> protocol?

yes ;-)

>> At the moment, I parse IDL files and hope (or have to make sure) that
>> the installed libreoffice is compatible.
>
> So - in -theory- (for all interesting cases), the UNO API is frozen (at
> the moment). In the future we plan to change that, so we can avoid
> piling up hacks).

Good to know.

>> To an extend, I could probably build the type library dynamically by
>> querying all interfaces instead of reading the RDB file, but I think
>> that would be unnecessarily slow.
>
> You could perhaps introspect them via UNO remotely, and cache the data
> per interface; not sure how many interfaces people typically use -
> but, prolly not -that- many :-)

Yes but I think that remote introspection would be slow.  I could do it
once and then dump it into a persistent cache, something like the RDB
file but in a more suitable format, e.g. using a XML or binary
serializer.

>> There seems to be some Python bridge to libreoffice. Does it use the
>> store code underneath a FFI?
>
> Sure - it links to the URE run-time; we have a stable C ABI that we
> export that has all the basic symbols and type information you need;
> and of course that makes running in-proc. much cleaner.

So so far everything goes through the C ABI.  Is that what is defined in
store/inc/store/store.h and store/inc/store/types.h?

However, I want to avoid any FFI.  I already have a native
implementation of the UNO RPC protocol in Common Lisp and I think other
users of dynamic languages might find it more convenient to implement a
native version too.  Wouldn't it be beneficial for Python users too for
example?

A simpler alternative to RDB file or a fast way to retrieve the type
library via UNO without one by one querying would be very convenient.

Are there any native implementations of the UNO RPC protocol so far,
e.g. for Java or is everybody going through FFI?

Thank you,

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

Re: [Libreoffice] [REVIEWED] Re: identical text for different (but close) locale at scp2/source/ooo

[Andras Timar]

Hi Kaplan,

2011/11/24 Lior Kaplan :
> On Thu, Nov 24, 2011 at 1:14 PM, Lior Kaplan  wrote:
>>
>>
>> On Thu, Nov 24, 2011 at 1:05 PM, Andras Timar  wrote:
>>>
>>> Hi Kaplan,
>>>
>>> 2011/11/24 Lior Kaplan :
>>> > Hi,
>>> >
>>> > While translating some scp2 strings for 3.5 I notice duplicate strings
>>> > which
>>> > looks weird (e.g. "Installs the Tamil user interface").
>>> >
>>> > I checked the sources and notice this is because we have two locales
>>> > for
>>> > Tamil:
>>> >
>>> > [STR_NAME_MODULE_LANGPACK_TA]
>>> > en-US = "Tamil"
>>> >
>>> > [STR_DESC_MODULE_LANGPACK_TA]
>>> > en-US = "Installs the Tamil user interface"
>>> >
>>> > [STR_NAME_MODULE_LANGPACK_TA_IN]
>>> > en-US = "Tamil"
>>> >
>>> > [STR_DESC_MODULE_LANGPACK_TA_IN]
>>> > en-US = "Installs the Tamil user interface"
>>> >
>>> > Do we really support two locales or this is a mistake? If we do support
>>> > two
>>> > locales, the users should have a way to differentiate between the two.
>>> >
>>>
>>> We don't support ta_IN, only ta. In fact those lines could be removed
>>> from scp2 (there are more to clean up I suppose).
>>> For supported UI locales see
>>> http://opengrok.libreoffice.org/xref/core/solenv/inc/langlist.mk
>>>
>>
>> Good to know. I'll do the clean up and send a patch...
>>
>
> Attaching two patches to clean the help and language pack translation
> strings. Also a small clean up patch for the langlist.mk file to have it
> sorted.
>
> Dictionary list is verified and is updated (no changes needed).
>

Please push 0001 and 0003. In 0002 you were a bit greedy in deleting
stuff. :) Save at least qtz. I would save all languages in helppack
file which have an UI pack. So I don't have to remember to re-add them
and translators don't have to re-translate them when a language team
decides to translate the help, too.

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

[Libreoffice] [PATCH] [REVIEW-3-4] fdo#32347 reenable ADO URL helper UI

[Lionel Elie Mamane]

Attached patch is a partial backport of my commit
538190e0ea142d0a7da244809c66241379d4d91b in master.

It reenables the ADO URL helper UI on MS Windows, which makes it
*much* easier to connect to ADO databases. It is a regression compared
to any version compiled with Windows XP SDK, i.e. OO.org.

As I don't have a Windows build, I could not test it, but I tested my
master commit with a tinderbox daily build, and it works well.

The reason that it was disabled with a Vista SDK is that in *early*
versions of the SDK, the necessary headers were simply missing. This
has been fixed for *years* in the SDK: see
https://issues.apache.org/ooo/show_bug.cgi?id=77988#c4 of December
2007!

-- 
Lionel
>From 1f9f4a4bcb36e2ec89c98f83586e7263d2401ae4 Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane 
Date: Thu, 24 Nov 2011 19:01:22 +0100
Subject: [PATCH] fdo#32347: reenable ADO URL helper UI

cleanup obsolete DISABLE_ADO logic
---
 dbaccess/source/ui/dlg/ConnectionHelper.cxx |2 +-
 dbaccess/source/ui/dlg/makefile.mk  |6 +-
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/dbaccess/source/ui/dlg/ConnectionHelper.cxx b/dbaccess/source/ui/dlg/ConnectionHelper.cxx
index 3b70cbe..da2af7e 100644
--- a/dbaccess/source/ui/dlg/ConnectionHelper.cxx
+++ b/dbaccess/source/ui/dlg/ConnectionHelper.cxx
@@ -70,7 +70,7 @@
 #include 
 #include 
 #include 
-#if !defined(WINDOWS_VISTA_PSDK) && defined(WNT)
+#if defined(WNT)
 #define _ADO_DATALINK_BROWSE_
 #endif
 
diff --git a/dbaccess/source/ui/dlg/makefile.mk b/dbaccess/source/ui/dlg/makefile.mk
index 8fa615d..55f9027 100644
--- a/dbaccess/source/ui/dlg/makefile.mk
+++ b/dbaccess/source/ui/dlg/makefile.mk
@@ -128,11 +128,7 @@ SLOFILES=	\
 $(EXCEPTIONSFILES)			\
 $(SLO)$/optionalboolitem.obj 
 
-.IF "$(WINDOWS_VISTA_PSDK)"!="" && "$(PROF_EDITION)"==""
-DISABLE_ADO=TRUE
-.ENDIF # "$(WINDOWS_VISTA_PSDK)"!="" && "$(PROF_EDITION)"==""
-
-.IF "$(GUI)"=="WNT" && "$(DISABLE_ADO)"==""
+.IF "$(GUI)"=="WNT"
 SLOFILES+=		$(SLO)$/adodatalinks.obj
 .ENDIF
 
-- 
1.7.7.3

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

[Libreoffice] Possible little code simplification

[Ivan Timofeev]

Hi all,

we have the field 'SwSortedObjs* pSortedObjs' in the class SwPageFrm.
And we have the strange management of it:

For example, sw/source/core/layout/flylay.cxx:734

if ( pSortedObjs )
{
pSortedObjs->Remove( *pToRemove );
if ( !pSortedObjs->Count() )
{   DELETEZ( pSortedObjs );
}
}

i.e. we delete pSortedObjs every time it is empty, and create it again
when we want to add something into it. This entails annoying checks,
like

if ( pPage->GetSortedObjs() )
// [loop over pSortedObjs]

What do you think about changing the code so that pSortedObjs will be
alive every time? We will be able to return a reference to pSortedObjs
in GetSortedObjs() instead of a pointer and remove the mentioned
checks (there are a lot of such checks). I could do this. :-)

Same problem with the field 'SwSortedObjs* pDrawObjs' in the class SwFrm.

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

Re: [Libreoffice] [PUSHED] Fix bug in build.pl option parser

[Daisuke Nishino]

Thank you for pushing!

Lisence:
All my past and future contributions (including this one) to LibreOffice
are under LGPLv3+/MPL until further notice.

Thanks

On Wed, Nov 23, 2011 at 11:39 PM, Michael Meeks wrote:

> Hi Daisuke,
>
> On Sun, 2011-11-13 at 17:51 +0900, Daisuke Nishino wrote:
> > I'm not much familiar with perl, but I think the previous
> > implementation of build.pl had bugs.
>
> You're quite right, and your version looks nicer too :-) Thanks for
> that, I just pushed it.
>
>Incidentally, it'd be great if you could send a blanket MPL/LGPLv3+
> license mail to the mailing list (you forgot it in this mail eg.), then
> we can link that into:
>
>http://wiki.documentfoundation.org/Development/Developers
>
>And not worry about that :-)
>
>Anyhow - thanks for the nice cleanup,
>
>All the best,
>
>Michael.
>
> --
> michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
>
>


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

Re: [Libreoffice] errors in idl files

[Michael Meeks]

On Thu, 2011-11-24 at 14:42 +0100, Tomas Hlavaty wrote:
> - I write my application in a dynamic programming language with no
>   dependencies on libreoffice code;

Ok :-) so you would have a native implementation of the UNO RPC
protocol?

> - My application reads the type library (RDB or better a simple XML
>   alternative) of the actually installed libreoffice on the target
>   machines (possibly different versions).

Fine.

> - My application communicates with libreoffice via UNO using the correct
>   version of the type library (which I didn't exactly know before
>   installing my application on the target machine).

OK; so you rely on your dynamic language binding to elide / add extra
fields etc. - make sense.

> At the moment, I parse IDL files and hope (or have to make sure) that
> the installed libreoffice is compatible.

So - in -theory- (for all interesting cases), the UNO API is frozen (at
the moment). In the future we plan to change that, so we can avoid
piling up hacks).

> To an extend, I could probably build the type library dynamically by
> querying all interfaces instead of reading the RDB file, but I think
> that would be unnecessarily slow.

You could perhaps introspect them via UNO remotely, and cache the data
per interface; not sure how many interfaces people typically use - but,
prolly not -that- many :-)

> There seems to be some Python bridge to libreoffice. Does it use the
> store code underneath a FFI?

Sure - it links to the URE run-time; we have a stable C ABI that we
export that has all the basic symbols and type information you need; and
of course that makes running in-proc. much cleaner.

HTH,

Michael.

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

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

Re: [Libreoffice] Bug with images in .doc with Writer

[Ivan Timofeev]

Hi Moray,

2011/11/24 moray33 :
> Hi. I found a bug in LibreOffice Writer. I don't know programming, so I post
> the problem here if someone can fix it. I would help me and I'm sure other
> people a lot.
>
> I told the problem here:
> http://nabble.documentfoundation.org/Images-get-smaller-and-deformed-in-doc-td3522341.html
> http://nabble.documentfoundation.org/Images-get-smaller-and-deformed-in-doc-td3522341.html

It seems you have encountered https://bugs.freedesktop.org/show_bug.cgi?id=39928
This bug fixed in LibreOffice 3.4.5 and 3.5. ;)

But the next time when you will find a bug, please go to bug tracker directly.

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

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

[Michael Meeks]

* Present:
+ Thorsten, Stephan, Mitch, Eike, Andras, David,
  Bjoern, Kendy, Caolan, Michael S, Petr, Rainer,
  Lionel, Tor, Markus

* Completed Action Items:
+ add merged msi details to 3.5 release page (Andras)
+ add unexpected mingw regressions to MingW 'most-annoying' (Rainer)
+ send ssh keys for Linux build machine access to Fridrich (Caolan)
+ concrete debug proposal for the public list (Stephan)
+ poke at and 'adopt' some easy hacks:
  
http://wiki.documentfoundation.org/Development/Easy_Hacks_by_required_Skill 
(All)
+ tinderbox owners should change names & Thorsten to prune server (All)
+ looks lots prettier ~done

* Pending Action Items
+ [in progress] default to TM safe (non-TDF) branding (Thorsten)
+ [in progress] enable on-line updates for QA in cross-compiled dailies 
(Kendy)
+ [in progress] extract 64bit build hardware from firewall (Kendy / 
Admins)
+ come up with a list of QA heros for next meeting (Rainer)
+ ask Christian wrt. Mac / PPC (Fridrich)
+ python/wizards merge for 3.5 & strip old versions (Bjoern)

* Action Items

* Release Engineering update (Petr)
+ 3.5.0-beta0
- coming soon, kicking the tires of the build process /
  stabilising
+ commit deadline is Monday Nov 28 (next Monday)
+ feature freeze is 1 week later
+ Please check most annoying 3.5 bugs:
+ https://bugs.freedesktop.org/show_bug.cgi?id=37361
+ Windows error / during installation
+ extension registration / terminal launch issues

* Java 7 (Stephan)
+ requests / concern about it
+ already enabled for Linux
+ we should enable for Windows
+ duplicate the entry from XML file from Linux -> Windows
  & sanity check.
+ rumoured instability with Java 7
+ is it generally fixed / still broken ?
AA: + enable Java 7 for Windows, post qa list to give it a try (Stephan)

* Unit tests issue (Markus [Moggi])
+ calc unit tests take around 30 seconds now
+ move some of them to tinderboxes / defer building
+ we have tons of filter tests - ~20 files to import & calc etc.
+ make subsequentcheck - the solution (Stephan)
+ the JUnit UNO API tests are a pain (Michael)
+ can we use 'make build' instead ?
+ concerned to run some basic tests every time
+ have lots of tests, that are nice, but don't need to
  be executed every time.
+ no need for more different test rules (Bjoern)
+ add them to subsequentcheck
+ if we run just cppunittests in subsequenttests (Bjoern)
+ fast & easier to debug
+ ie. disable Java, and avoid undebuggable uno tests
+ tests should be executed with tinderboxes, useful (Markus)
+ have found problems, l10n issues etc.
+ subsequentcheck
+ number of ways to improve it (Caolan)
+ Bjoern has a nice write-up of how to debug it here:
+ http://sweetshark.livejournal.com/2271.html
+ can't we just run 'make build' and then 'make'
+ want to extend the tests yet further ...
AA: + move some slow tests over to 'make subsequentcheck' (Markus)
+ should be a ~trivial makefile rename / tweak
+ make subsequentcheck afterwards

* Officially kill bit-rotted pch work (Norbert in absentia)
+ eager to kill them, they're unmaintainable, bit-rots
  with each commit (Kendy)
+ tried to use them once 6 momths ago, failed miserably (Tor)
AA: + remove them, or file easy hack for the same (Norbert)

* NlpSolver (Michael)
+ un-maintained, Sun extension, no live up-stream
+ flatten it into git as a module instead

* Cross-compiling MSIs building (Mitch)
+ slow but steady, continuing build.pl etc. re-factor

* QA Update (Rainer)
+ had to leave early.

* bug priority handling (Lionel)
+ https://bugs.freedesktop.org/show_bug.cgi?id=39950
+ vs. wrong icon issue - severity
AA: + help out diving deeper into it next week (Caolan)
+ is it a missing copy-constructor ?

* Cor's bug reporting context ?
+ table of who found what 3.5 bugs, how good they are ?
+ T-shirt prizes ?
+ resources low for triage, can we easily
  assess quality of bug-reports for a fair metric ?
+ discuss with Rainer next time.

* 3.5 most annoying bugs ...
+ 
https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

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

___
LibreOffice mailing list
LibreOffice@lists.

Re: [Libreoffice] [PUSHED][PATCH] SwSelBoxes: svarray -> std::map

[Caolán McNamara]

On Thu, 2011-11-24 at 23:19 +0900, Daisuke Nishino wrote:
> I'm not sure if this is related to the problem, but I found an obvious
> mistake.
> I hope this patch fixes it.
> I'm sorry for inconvenience.

aha, excellent. That clear's the most obvious one anyway. Will see if it
fixes everything, or if the remaining glitch I see is preexisting.

C.

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

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

[bugzilla-daemon]

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

Bug 37361 depends on bug 30467, which changed state.

Bug 30467 Summary: required visual studio 2008 redistributable libraries not 
installed, failed to start
https://bugs.freedesktop.org/show_bug.cgi?id=30467

   What|Old Value   |New Value

 Resolution||FIXED
 Status|NEW |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] text:class-names and nested text:span/text:style-name

[Dag Wieers]

On Thu, 24 Nov 2011, Dag Wieers wrote:


Case 1: Using text:class-names

   bold text:class-names="strong blue">blue bold


No syles seem to have been applied.


Case 2: Using nested text:span/text:style-name

   bold text:style-name="blue">blue bold


Bold is bold. Blue is blue, but not bold !


After more experiments I found that Case 2 does work when the styles 
are defined inside  instead of .


Which I believe is a bug in LibreOffice.

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

[Libreoffice] [REVIEW] Re: identical text for different (but close) locale at scp2/source/ooo

[Lior Kaplan]

On Thu, Nov 24, 2011 at 1:14 PM, Lior Kaplan  wrote:

>
>
> On Thu, Nov 24, 2011 at 1:05 PM, Andras Timar  wrote:
>
>> Hi Kaplan,
>>
>> 2011/11/24 Lior Kaplan :
>> > Hi,
>> >
>> > While translating some scp2 strings for 3.5 I notice duplicate strings
>> which
>> > looks weird (e.g. "Installs the Tamil user interface").
>> >
>> > I checked the sources and notice this is because we have two locales for
>> > Tamil:
>> >
>> > [STR_NAME_MODULE_LANGPACK_TA]
>> > en-US = "Tamil"
>> >
>> > [STR_DESC_MODULE_LANGPACK_TA]
>> > en-US = "Installs the Tamil user interface"
>> >
>> > [STR_NAME_MODULE_LANGPACK_TA_IN]
>> > en-US = "Tamil"
>> >
>> > [STR_DESC_MODULE_LANGPACK_TA_IN]
>> > en-US = "Installs the Tamil user interface"
>> >
>> > Do we really support two locales or this is a mistake? If we do support
>> two
>> > locales, the users should have a way to differentiate between the two.
>> >
>>
>> We don't support ta_IN, only ta. In fact those lines could be removed
>> from scp2 (there are more to clean up I suppose).
>> For supported UI locales see
>> http://opengrok.libreoffice.org/xref/core/solenv/inc/langlist.mk
>>
>>
> Good to know. I'll do the clean up and send a patch...
>
>
Attaching two patches to clean the help and language pack translation
strings. Also a small clean up patch for the langlist.mk file to have it
sorted.

Dictionary list is verified and is updated (no changes needed).

Kaplan
From 89eec88680e37cccd90b4b245357da1ea0f0426d Mon Sep 17 00:00:00 2001
From: Lior Kaplan 
Date: Thu, 24 Nov 2011 15:02:37 +0200
Subject: [PATCH 1/3] Sort languages alphabetically

---
 solenv/inc/langlist.mk |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/solenv/inc/langlist.mk b/solenv/inc/langlist.mk
index 161bc5b..8a79b15 100644
--- a/solenv/inc/langlist.mk
+++ b/solenv/inc/langlist.mk
@@ -31,11 +31,11 @@ ar \
 as \
 ast \
 be \
-bo \
 bg \
+bn \
+bo \
 br \
 brx \
-bn \
 bs \
 ca \
 ca-XV \
@@ -82,19 +82,19 @@ lt \
 lv \
 mai \
 mk \
+ml \
 mn \
 mni \
-ml \
 mr \
 my \
-ne \
 nb \
+ne \
 nl \
 nn \
 nr \
 nso \
-om \
 oc \
+om \
 or \
 pa-IN \
 pl \
@@ -104,27 +104,27 @@ qtz \
 ro \
 ru \
 rw \
-sat \
 sa-IN \
-si \
+sat \
 sd \
-sq \
+sh \
+si \
 sk \
 sl \
-sh \
+sq \
 sr \
 ss \
 st \
 sv \
 sw-TZ \
-te \
 ta \
+te \
+tg \
 th \
+tk \
 tn \
 tr \
-tk \
 ts \
-tg \
 tt \
 ug \
 uk \
-- 
1.7.0.4

From 77f1f5c5e0ddbb966b228d5927bfcc4127892601 Mon Sep 17 00:00:00 2001
From: Lior Kaplan 
Date: Thu, 24 Nov 2011 17:05:49 +0200
Subject: [PATCH 2/3] Clean help pack list based on the current files in the translation repository (translations/source/*/helpcontent2)

---
 scp2/source/ooo/module_helppack.ulf |  486 ---
 1 files changed, 0 insertions(+), 486 deletions(-)

diff --git a/scp2/source/ooo/module_helppack.ulf b/scp2/source/ooo/module_helppack.ulf
index 4737584..06bcac6 100644
--- a/scp2/source/ooo/module_helppack.ulf
+++ b/scp2/source/ooo/module_helppack.ulf
@@ -139,12 +139,6 @@ en-US = "Greek"
 [STR_DESC_MODULE_HELPPACK_EL]
 en-US = "Installs Greek help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_TH]
-en-US = "Thai"
-
-[STR_DESC_MODULE_HELPPACK_TH]
-en-US = "Installs Thai help in %PRODUCTNAME %PRODUCTVERSION"
-
 [STR_NAME_MODULE_HELPPACK_CS]
 en-US = "Czech"
 
@@ -193,150 +187,24 @@ en-US = "Punjabi"
 [STR_DESC_MODULE_HELPPACK_PA_IN]
 en-US = "Installs Punjabi help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_GU_IN]
-en-US = "Gujarati"
-
-[STR_DESC_MODULE_HELPPACK_GU_IN]
-en-US = "Installs Gujarati help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPACK_TA]
-en-US = "Tamil"
-
-[STR_DESC_MODULE_HELPPACK_TA]
-en-US = "Installs Tamil help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPACK_TA_IN]
-en-US = "Tamil"
-
-[STR_DESC_MODULE_HELPPACK_TA_IN]
-en-US = "Installs Tamil help in %PRODUCTNAME %PRODUCTVERSION"
-
 [STR_NAME_MODULE_HELPPACK_HI]
 en-US = "Hindi"
 
 [STR_DESC_MODULE_HELPPACK_HI]
 en-US = "Installs Hindi help in %PRODUCTNAME %PRODUCTVERSION"
 
-[STR_NAME_MODULE_HELPPACK_HI_IN]
-en-US = "Hindi"
-
-[STR_DESC_MODULE_HELPPACK_HI_IN]
-en-US = "Installs Hindi help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPACK_ST]
-en-US = "Southern Sotho (Sutu)"
-
-[STR_DESC_MODULE_HELPPACK_ST]
-en-US = "Installs Southern Sotho (Sutu) help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPACK_TN]
-en-US = "Tswana"
-
-[STR_DESC_MODULE_HELPPACK_TN]
-en-US = "Installs Tswana help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPACK_XH]
-en-US = "Xhosa"
-
-[STR_DESC_MODULE_HELPPACK_XH]
-en-US = "Installs Xhosa help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPACK_ZU]
-en-US = "Zulu"
-
-[STR_DESC_MODULE_HELPPACK_ZU]
-en-US = "Installs Zulu help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPACK_AF]
-en-US = "Afrikaans"
-
-[STR_DESC_MODULE_HELPPACK_AF]
-en-US = "Installs Afrikaans help in %PRODUCTNAME %PRODUCTVERSION"
-
-[STR_NAME_MODULE_HELPPAC

[Libreoffice] text:class-names and nested text:span/text:style-name

[Dag Wieers]

Hi,

Since I don't know if I am doing something wrong, or whether LibreOffice 
simply doesn't support text:class-names or nested text:span styles.


Can someone verify that LibreOffice incorrectly process the following two 
cases ?



The following two styles exists in 


 



 


And attached is a very basic example .fodt to experiment with yourself.


Case 1: Using text:class-names

bold blue bold

No syles seem to have been applied.


Case 2: Using nested text:span/text:style-name

bold blue bold

Bold is bold. Blue is blue, but not bold !


PS If there is a better venue to ask ODF related questions, let me know.

Thanks in advance,
--
-- 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]























 

  

  

 



 

  

 



 

  

 



 

  

 











Case 1:

bold blue bold

Case 2:

bold blue bold







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

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

[Philipp Weissenbacher]

On 24 November 2011 09:27, Petr Mladek  wrote:
>> - docdesc.cxx was a bit tricky:
>>   I didn't understand what "//al la WW: 1 Inch" means, so I left it as
>> is. ("al la" by itself can mean "is like" in German, but I wasn't sure
>> if that is meant here).
>
> "is like" makes perfect sense, so I have added this change.

I saw that Michael improved it even further. Crystal clear now, thanks!

>>   There's an handled else statement In line 712. Someone might want to
>> take a look at it.
>
> If I understand it correctly the code solves the DOC import. The
> import/export filers are always work in progress. I guess that this is a
> less important scenario and it just need to wait for anyone interested
> into fixing it.

Oh, interesting. Thought the code in there was a bit dusty (comments
from '98 and still uInt16 everywhere).

>>   I wasn't sure how I should translate "Ränder" and  "Umrandung", so I
>> used "border" and "border strips". Is that right?
>
> I confronted the words with dictionary and found that the following
> translations might be more appropriate:
>
>        Ränder = margin
>        Umrandung = border
>
> The margin is an empty space between an edge of paper and a text. The
> border is a line around a table or so.

Ah! That makes a lot of sense. Somehow my dictionary didn't suggest any that.

>> Just 37 more files to go!
>
> Thanks a lot for the great work. We are looking forward to see more
> translations.

I'm glad I can help :-).

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

Re: [Libreoffice] doubts with UNO API and image size

[Thorsten Behrens]

Gabriel Monnerat wrote:
> Is possible define custom sizes and custom fonts for this kind of
> conversion?
> 
Hi Gabriel,

would you be able to post a small code snippet that demonstrates
what you're doing?

Thanks,

-- Thorsten


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

Re: [Libreoffice] [PUSHED] [PATCH] Fixed wrong scaling of the anchor icons

[Thorsten Behrens]

Tim Hardeck wrote:
> , the size of the anchor icons, handles and similar were always one
> pixel too small which resulted in a blurry image.
> This should be fixed but I am not sure why 1.0 was subtracted in the
> first place.
> 
Nice catch, pushed - I guess the -1 was wrong from the start,
clearly a bitmap of size 1x1 shouldn't display as 0x0 ...

Cheers,

-- Thorsten


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

Re: [Libreoffice] Question about IAccessibility2

[Regina Henschel]

Hi Christophe,

Christophe Strobbe schrieb:

Hi Regina,

At 23:11 21-11-2011, Regina Henschel wrote:

Hi all,

I have started to implement the attribute "stroke-linecap".


I assume this refers to svg:stroke-linecap (�20.164 in the ODF 1.2 spec,
which refers to stroke properties in the SVG spec:
).


Yes.





I come across "IAccessibility2" in files
/core/cui/source/tabpages/tabline.hrc
/core/cui/source/tabpages/tabline.src
There are some string resources defined like
#define STR_END_LENGTH 41
Some are commented out in lines 125 to 134 in tabline.hrc. Such string
resources are used in method SetAccessibleName in
/core/cui/source/tabpages/tpline.cxx


SetAccessibleName is a method that exists in several accessibility APIs,
e.g.
* ATK: atk_object_set_name:

* Java:


* Microsoft: :
"IAccessibleObject::SetAccessibleName method"


So it is a comprehensive concept.






I see them for some controls but not for all, especially not for
maLBEdgeStyle.

(1) What they are used for?
(2) Why they are set for some controls but not for all?
(3) Do I have to define such a string for my new linecap style list box?



I don't know what the "accessible name" for a stroke-linecap would be
(i.e. when it is present in ODF content). However, if you are referring
to a list box where an author can choose between different
stroke-linecap styles, I would definitely give those options an
accessible name (e.g. butt cap, round cap and square cap, which I found
in the SVG spec).


Those are already strings, which will be localized. I have no 
application to test, whether this is sufficient. But I guess it will, 
because otherwise people would have complained in a lot of other places 
where list boxes are used.


I think I postpone this special detail until the rest is finished and 
there is a product that can be tested in connection with an 
accessibility application.





I hope this helps.


Yes, I had not been aware, that the concept is not special for LibO/OOo.

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

Re: [Libreoffice] [PUSHED][PATCH] SwSelBoxes: svarray -> std::map

[Daisuke Nishino]

I'm not sure if this is related to the problem, but I found an obvious
mistake.
I hope this patch fixes it.
I'm sorry for inconvenience.

This is under under LGPLv3+/MPL too.

Thanks

On Thu, Nov 24, 2011 at 10:30 PM, Caolán McNamara wrote:

> On Thu, 2011-11-24 at 08:21 +0100, Stephan Bergmann wrote:
> > On 11/23/2011 09:00 PM, Stephan Bergmann wrote:
> > > I keep getting crashes from one of the subsequentchecks now,
> > > suspiciously looking like this patch causes them, but am too tired
> right
> > > now to debug myself:
> >
> > btw, the crash happens while making sw_unoapi, at
>
> bah, I'll have a look.
>
> C.
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>



-- 
Daisuke Nishino


0001-Fix-logic-inversion.core.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Need some informations on format attributes

[Michael Stahl]

On 23/11/11 19:06, Maxime de Roucy wrote:
> Hello
> 
> I am the author of the bug number 43067
> ( https://bugs.freedesktop.org/show_bug.cgi?id=43067 ).
> 
> I am trying to solve that bug.
> I tried to insert
> "rWrtShell.ResetAttr();" 
> just before the 
> "rWrtShell.SetAttr(*pTemplateItemSet);"
> line.
> 
> It works but only when I just apply text formatting (hold Ctrl when you
> select the text to format).

i believe the merging is intentional; resetting the attributes is not
desired: think about what should happen if you apply the formatting to a
selection that has non-uniform formatting, surely we want to retain e.g.
different font sizes when the style that is painted only says "bold".

> I would like to know how to differentiate formatting attributes that
> come from style:family="paragraph" and those that come from
> style:family="text".

the paragraph formatting attributes are SfxPoolItems with WhichIds
RES_CHARATR_* contained directly in the SfxItemPool (or was it a writer
specific subclass?) that is stored in the SwTxtNode; there are various
SwTxtNode methods to get/set them, but the UI should not call those
directly.

for spans with automatic styles, we create a text hint SwTxtAttr that
contains a SfxPoolItem with WhichId RES_TXTATR_AUTOFMT, which in turn
contains an SfxItemSet that contains the SfxPoolItems with WhichId
RES_CHARATR_*.
for spans with non-automatic text styles, we create a text hint
SwTxtCharFmt with WhichId  RES_TXTATR_CHARFMT.

the text hints live in the SwpHints instance of the SwTxtNode (a.k.a the
hints array).

regards,
 michael

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

Re: [Libreoffice] Papiamentu spellchecker, doesn't suggest some words with accents (à ò etc)

[Olivier R.]

Hello,


Ace Suares (Suares & Co) wrote
> 
> The problem is that when typing 'ana', which is wrong, the suggestion 
> list does NOT include 'aña' (but more then 10 other useless suggestions).
> 

Use the command MAP to associate affiliated characters:

MAP 1
MAP nñ



Ace Suares (Suares & Co) wrote
> 
> The same with 'toch' which should suggest 'tòg'
> 

REP 1
REP och òg


Did you read this ?
http://freefr.dl.sourceforge.net/project/hunspell/Hunspell/Documentation/hunspell4.pdf

You can also have a look in other dictionaries:
http://extensions.libreoffice.org/extension-center?getCompatibility=any&path=/LibreOffice-Extensions-and-Templates/extension-center&b_start:int=30&portal_type=PSCProject&sort_on=positive_ratings&getCategories=Dictionary&SearchableText=

Regards,
Olivier

--
View this message in context: 
http://nabble.documentfoundation.org/Papiamentu-spellchecker-doesn-t-suggest-some-words-with-accents-a-o-etc-tp3533625p3533676.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] errors in idl files

[Tomas Hlavaty]

Hi Michael,

Michael Meeks  writes:
> No problem, but please reply-to-all so we CC the list, for others to
> find out what is going on & be helped by your questions too :-) [ feel
> free to CC the list on your reply to this ;-].

sorry it wasn't meant to be a private message, I need to check better
next time.

>> So it's roughly something like MS OLE CFB
>> http://msdn.microsoft.com/en-us/library/dd942138%28v=prot.13%29.aspx
>> in-file filesystem for Word and PowerPoint?
>
> Correct; but -much- more broken than OLE ;-)

I see.

>> Is there any plan to move away from RDF files and use something
>> simpler, e.g. XML file describing all those types?
>
> Sure - we'd love to do that; OTOH it requires some concentrated
> hacking for a while.

Good to hear that.

> What are you trying to achieve though ? could you not re-use the store
> code ? and/or (better) the higher level type introspection APIs /
> interfaces ?

The ideal situation would be that

- I write my application in a dynamic programming language with no
  dependencies on libreoffice code;

- I deploy my application on target machines where libreoffice is
  already installed;

- My application reads the type library (RDB or better a simple XML
  alternative) of the actually installed libreoffice on the target
  machines (possibly different versions).

- My application communicates with libreoffice via UNO using the correct
  version of the type library (which I didn't exactly know before
  installing my application on the target machine).

So "the only" intersection between my application and libreoffice would
be the RDB file.  The rest would go over the UNO protocol.

At the moment, I parse IDL files and hope (or have to make sure) that
the installed libreoffice is compatible.

To an extend, I could probably build the type library dynamically by
querying all interfaces instead of reading the RDB file, but I think
that would be unnecessarily slow.

There seems to be some Python bridge to libreoffice. Does it use the
store code underneath a FFI?

Cheers,

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

Re: [Libreoffice] [PUSHED][PATCH] SwSelBoxes: svarray -> std::map

[Caolán McNamara]

On Thu, 2011-11-24 at 08:21 +0100, Stephan Bergmann wrote:
> On 11/23/2011 09:00 PM, Stephan Bergmann wrote:
> > I keep getting crashes from one of the subsequentchecks now,
> > suspiciously looking like this patch causes them, but am too tired right
> > now to debug myself:
> 
> btw, the crash happens while making sw_unoapi, at

bah, I'll have a look.

C.

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

[Libreoffice] Papiamentu spellchecker, doesn't suggest some words with accents (à ò etc)

[Ace Suares (Suares & Co)]

Hi

I've been working on a spellchecker for Papiamento (pap_AN).
You can download it here:

http://www.suares.an/file/papiamentu_dict_v1_0.oxt


Anouncement of release on Software Freedom Day here:

http://opencuracao.com/2011/09/software-freedom-day-17-sept-2011/


I have some understanding of hunspell, here's an article I wrote (and it 
gets hit quite a lot, surprisingly):


http://www.suares.an/index.php?page_id=25&news_id=233

The problem is that when typing 'ana', which is wrong, the suggestion 
list does NOT include 'aña' (but more then 10 other useless suggestions).


The same with 'toch' which should suggest 'tòg'

In the affix file I have

SET UTF-8

SFX P Y 1
SFX P   0 nan

and nothing else.

I did a character count and added

TRY aieonstrkldmuphbgáfvèòcóíyéwñzjùúüABCSKIHEPLGTFxMJRqYXVDç

to the .aff file but that didn't help.

Should I arrange these characters differently, for instance placing the 
à near the a instead of arranging them by frequency?


Help appreciated.

Cheers

ace



--
Suares & Co N.V.
Ace Suares (Director)
Gravenstraat 4
Otrobanda, Willemstad
Curaçao
gsm: +599 (9) 678 00 60
skype: acesuares
email: a...@suares.com
web: www.suares.com, opencuracao.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] errors in idl files

[Tomas Hlavaty]

Hi Michael,

thanks for your reply!

> it is described somewhere on openoffice.org...
> ...but i can't find the well hidden documentation.

Same here:-(

> heh, i fixed that a lot on Monday, after discovering that a lot of its
> files were not listed in the makefile at all; please git pull and try
> again :)

Ah, sorry I didn't have the most recent repo.

However, after pulling, it is still not possible to resolve the
following includes (udkapi/ and offapi/):

   #include  
   #include  
   #include 
   #include 
   #include 
   #include 
   #include 
   #include "com/sun/star/chart2/LegendSymbolStyle.idl"
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 

Thank you,

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

[Libreoffice] [PUSHED] Docuview code cleanup #2

[Michael Meeks]

Hi Matteo,

On Thu, 2011-11-24 at 02:04 +0100, Matteo Casalin wrote:
> * a revised patch, with a new ImplDrawSymbol;

Lovely :-) it reads more nicely now, I pushed it & good work.

> * a picture with the drawings of all symbols, produced by both the old
>and by the new routines. All symbols were drawn with different sides
>of their target rectangle, and for each rectangle size 4 full
>sequences of symbols are drawn:

All looks good to me. I love the improved float icon too :-)

> Yeah, using polygons could reduce that code, but I just begun 
> contributing and I don't feel comfortable with such a big change, at 
> least for now.

Heh :-)

>  Besides, I had a quick look at (rendering of) polygons 
> and it looks a little too complicated for such small symbols and, if you 
> take a look at the circles generated by the original ImplDrawSymbols 
> (which made use of polygons), you'll see that the results were not so 
> precise.

Right; I saw you replaced that.

> No problem, I see that there's a lot of activity in the repository :)
> I'm planning to do some more cleanups in Docuview, I'll post them little 
> by little. Is this kind of activities appreciated or would bug-solving 
> be better ?

Oh - well, everything gratefully received :-) whatever interests you
most is best I think. Of course, some of our bigger, nastier problems
are in the are of user-interface; 

>  I'm asking this because this task was chosen by chance, more 
> for training than for other reason.

Sure; so - you could poke another easy-hack, or carry on cleaning this
up. There are really plenty of interesting tasks - it often helps to
have several on the queue :-)

Of course, things that improve the UI are much appreciated by end
users, and there are a number of open tasks in this area that are not
easy hacks if you're interested (Christophe had a nice idea of making it
rather easier to add notes by clicking on the ruler IIRC that might be
fun) :-)

> Another question on preferred behaviour for future contributions: should 
> I have posted this new patch as a new mail, with an explicit [PATCH] 
> header in its subject?

That's best practise yes, but luckily I was watching for this :-)

On Thu, 2011-11-24 at 12:22 +0100, Matteo Casalin wrote:
> please also note that for SYMBOL_CHECKMARK I kept both normal and 
> mirrored versions of the symbol, as in the original routine, although 
> the comment
> 
> // #106953# never mirror checkmarks

Heh :-)

> seems to mean that this is not desired. But I don't know if the 
> comment is obsolete, misleading (could it mean that the bug was that 
> checkmarks was not mirrored, as they should?) or correct (and in the 
> latter case implementation is wrong). As a beginner I really don't 
> know where to search for such a bug report and, honestly, I'm a bit 
> puzzled by bug identifiers (fdo#, i# or whatelse).

Ah - so - this bug is to a dead & obsolete Sun/Oracle bug tracker that
rides no more: it'd be good (in fact) to come up with a nice regexp to
find them all across the code & remove them.

> I did some internet research about checkmarks in RTL, without results.
> Unless the original bug report is found, this issue should/could
> eventually be clarified with some RTL people.

Sure - poke Lior Kaplan he's the man for RTL queries. I strongly
suspect the comment is right though - I don't think those guys want
backwards ticks in boxes ;-)

Anyhow - thanks for the great work; looking forward to your next steps.

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] Bug with images in .doc with Writer

[Michael Meeks]

Hi Moray,

On Thu, 2011-11-24 at 03:57 -0800, moray33 wrote:
> Hi. I found a bug in LibreOffice Writer. I don't know programming, so I post
> the problem here if someone can fix it. I would help me and I'm sure other
> people a lot.

This is not an appropriate list to post your favorite bug; it is a
place to discuss patches / concrete fixes for your bug. Please file a
clear description of your problem at http://bugs.freekdesktop.org.

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] Problems with mozilla build-tools on WindowsXP

[Regina Henschel]

Hi,

Makoto Takizawa schrieb:

hi
I just success build on windows and wrote a note on wiki.
https://wiki.documentfoundation.org/User:Foral/Build_Win

around Mozilla, needed to download a lot of stuffs.


Perhaps you consolidate your things, which are not yet mentioned, 
directly into

https://wiki.documentfoundation.org/Development/BuildingOnWindowsWithCygwinAndMSVCExpress
and
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies

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

Re: [Libreoffice] how to acquire an ScDocument reference "from scratch"

[Stephan Bergmann]

On 11/24/2011 12:25 PM, Michael Meeks wrote:

I would suggest two things:

a) we can add an environment variable and check for it in
   gnumake such that only one set of tests is run:

make TEST_SUBSET=filters-test unitcheck

or somesuch.

b) we could (try) to hack cppunit to stringify the test-name in
   it's macros; so you could specify just one test to run:

make TEST_SUBSET=filters-test TESTS=testDatabaseRanges unitcheck

And do some cunning filtering somewhere there - might require more
cppunit patching / tweaking [ if that is not there already, perhaps it
is ].


If you want to execute the CppUnit tests in some file like 
sc/CppunitTest_sc_filters_test.mk you can


  cd sc && make -r 
"${SRC_ROOT?}/workdir/${INPATH?}/CppunitTest/sc_filters.test.test


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

Re: [Libreoffice] Setting up a non-intrusive build cluster

[Lionel Elie Mamane]

On Wed, Nov 23, 2011 at 06:28:41PM -0500, Marc-André Laverdière wrote:
> I played with the utmp stuff, and it records the shells only, not the
> interactive sessions...

My "who" shows *only* interactive sessions... Be they graphical, on
the console or through ssh.

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

[Libreoffice] "safe" numeric casts with explicit min/max

[Lionel Elie Mamane]

On Thu, Nov 24, 2011 at 11:25:30AM +0100, Lionel Elie Mamane wrote:
> On Thu, Nov 24, 2011 at 10:56:57AM +0100, Lionel Elie Mamane wrote:

>> I understand we don't want to touch that in stable branch, but anyone
>> opposing me pushing something like that in master, and similar for
>> llimit_cast and limit_cast?

>> // assumptions:
>> // \forall typename Type:
>> // ( (::std::numeric_limits< Type >::min() == 0) XOR ( 
>> ::std::numeric_limits< Type >::min() < 0  && ::std::numeric_limits< Type 
>> >::is_signed ))
>> // &&  (::std::numeric_limits< Type >::max() > 0 )

>> template< typename ReturnType, typename Type >
>> inline ReturnType ulimit_cast( Type nValue, ReturnType nMax )
>> (...)
>>   else if ( ! ::std::numeric_limits< ReturnType >::is_bounded ||
>> ::std::numeric_limits< ReturnType >::max() > 
>> ::std::numeric_limits< Type >::max() )

> That should be:

>   else if ( ! ::std::numeric_limits< ReturnType >::is_bounded ||
> nMax > ::std::numeric_limits< Type >::max() )

And even then it is buggy, because I was thinking only of the case
where nMax is ::std::numeric_limits< ReturnType >::max(), but it can
be an arbitrary (possibly negative!) value.

That thing is devilishly hard to get right... I think I have a correct
version now, but I'm going to unittest the hell out of it before I
commit, that's for sure!

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

[Libreoffice] Bug with images in .doc with Writer

[moray33]

Hi. I found a bug in LibreOffice Writer. I don't know programming, so I post
the problem here if someone can fix it. I would help me and I'm sure other
people a lot.

I told the problem here:
http://nabble.documentfoundation.org/Images-get-smaller-and-deformed-in-doc-td3522341.html
http://nabble.documentfoundation.org/Images-get-smaller-and-deformed-in-doc-td3522341.html
 

I hope someone can fix it. Thank you very much!

--
View this message in context: 
http://nabble.documentfoundation.org/Bug-with-images-in-doc-with-Writer-tp3533449p3533449.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] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||42914, 42979

-- 
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] Setting up a non-intrusive build cluster

[Michael Meeks]

On Wed, 2011-11-23 at 18:28 -0500, Marc-André Laverdière wrote:
> I played with the utmp stuff, and it records the shells only, not the
> interactive sessions...

Ho hum; at least my 'who' command shows:

$ who
michael  :0   2011-11-22 14:26 (console)
michael  console  2011-11-22 14:26 (:0)
michael  pts/02011-11-22 14:26 (:0.0)
...

Of course; since gdm runs it's own session on :0 to facilitate login
you might want to filter the 'gdm' user account. It's prolly worth
working out what pseudo-user kdm, xdm, and lightdm run under, if they do
at all [ I only have a custom 'gdm' user on openSUSE, no kdm one ].

But of course, if it works for your use-case, and your local machines
it should be fine (right) ?

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] how to acquire an ScDocument reference "from scratch"

[Michael Meeks]

Hi Kevin,

On Thu, 2011-11-24 at 01:05 -0500, Kevin Hunter wrote:
> I wanted to create an ScDocument to work with in a new test file.  I was 
> thinking in terms of test driven development and having some tests such 
> that I could execute only them, as something akin to:
> 
> $ make  just_this_set_of_tests

Ah - you just want to run a smaller set of tests, and faster than
running all of the 'make unittest' changes in master ?

> I was educated that because each separate test file needs an entirely 
> separate invocation of soffice (and all that that entails),

Nah - it's not soffice; but a unit test linked with some biggish chunks
of code.

> Thus, the answer to my question boiled down to: during development
> or bug hunting, comment out all superfluous tests in another, existing
> test file.

I would suggest two things:

a) we can add an environment variable and check for it in
   gnumake such that only one set of tests is run:

make TEST_SUBSET=filters-test unitcheck

or somesuch.

b) we could (try) to hack cppunit to stringify the test-name in
   it's macros; so you could specify just one test to run:

make TEST_SUBSET=filters-test TESTS=testDatabaseRanges unitcheck

And do some cunning filtering somewhere there - might require more
cppunit patching / tweaking [ if that is not there already, perhaps it
is ].

But of course; the easy & quick way out is to comment these out I
guess.

HTH,

Michael.

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

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

Re: [Libreoffice] [PUSHED] Docuview code cleanup

[Matteo Casalin]

Hi Michael,
please also note that for SYMBOL_CHECKMARK I kept both normal and 
mirrored versions of the symbol, as in the original routine, although 
the comment

// #106953# never mirror checkmarks

seems to mean that this is not desired. But I don't know if the 
comment is obsolete, misleading (could it mean that the bug was that 
checkmarks was not mirrored, as they should?) or correct (and in the 
latter case implementation is wrong). As a beginner I really don't 
know where to search for such a bug report and, honestly, I'm a bit 
puzzled by bug identifiers (fdo#, i# or whatelse). I did some internet
research about checkmarks in RTL, without results. Unless the original
bug report is found, this issue should/could eventually be clarified 
with some RTL people.

Thanks again
Matteo

--
Matteo Casalin  wrote:
(24/11/2011 02:04)

> Hi Michael,
>  please find attached:
> * a revised patch, with a new ImplDrawSymbol;
> * a picture with the drawings of all symbols, produced by both the old
>and by the new routines. All symbols were drawn with different sides
>of their target rectangle, and for each rectangle size 4 full
>sequences of symbols are drawn:
>- 1st one: target rectangle in red, original symbol
>- 2nd one: target rectangle in green, new symbol
>- 3rd one: original symbol with normal background
>- 4th one: new symbol with normal background
>Please note that the white contour can exceed the symbol rectangle
>"by design", since it's shifted 1 pixel right and 1 pixel down.
>This picture is provided for a simple comparison and not for
>validating the code, which deserves a review and possibly a test on
>the field.
> Please find further comments interleaved.
> 
> The attached patch is contributed under LGPL3+/MPL1.1 license.
> 
> On 11/23/2011 04:02 PM, Michael Meeks wrote:
> > Hi Matteo,
> >
> > On Sun, 2011-11-13 at 19:54 +0100, Matteo Casalin wrote:
> >>   my name's Matteo and this is my first contribution [attempt] to
> >> this wonderful piece of work, besides "spreading the word".
> >
> > Cool - welcome ! and I'm sorry it took so long to get to reviewing this
> > properly.
> >
> >> The attached patch does a little code cleanup in Docuview::DrawSymbol
> >> function and its helper, reducing local variables and calls to "real"
> >> draw functions.
> >
> > :-)
> >
> >> Please note that:
> >> * the results of reworked code was not fully tested, since I really
> >> don't know were all of those symbols are drawn, but those that I was
> >> able to verify look OK to me;
> >
> > Great. We see some 'symbols' drawn on buttons often next/previous
> > buttons that are hidden in various places. Personally I'd prefer to have
> > alpha transparent, themed bitmaps for all of them but ... ;-)
> 
>   :-)
> 
> >> * There are still other cleanups that can be done in that code, but I
> >> would like to have some feedback before working on them. For example,
> >> this patch could include too many changes.
> >
> > So, I -think- (and I've inverted some of the senses here) that:
> >
> > -if ( nMin&  0x01 )
> > -nMin--;
> > ...
> > -if ( !(nMin&  0x01) )
> >
> > Should be replaced by:
> >
> > +const bool bMinSideIsOdd = nMin&  1;
> > ..
> > +if ( bMinSideIsOdd )
> >
> > Rather than !bMinSideIsOdd, since the nMin-- alters the state ;-) yet
> > another reason why this unclear&  unhelful code needs cleaning up
> > IMHO :-)
> >
> > This code is quite amazing ;-)
> >
> >  pDev->DrawPixel( Point( nCenterX, nTop ) );
> >  for ( long i = 1; i<= n2; ++i )
> >  {
> >  nTop++;
> >  pDev->DrawRect( Rectangle (Point( nCenterX-i, nTop ),
> >  Point( nCenterX+i, nTop ) ) );
> >  }
> >
> > As a way to draw a triangle for an up-arrow is really quite amazing ...
> > Particularly when cut/pasted as the down arrow as well. I'd love to see
> > that stuff made common and replaced with pDev->DrawPolygon or similar
> > instead :-) cf. tools/inc/tools/gen.hxx and vcl/inc/vcl/outdev.hxx. We
> > should be able to use Polygon::Rotate() to evaporate lots of this code I
> > hope, possibly we could even set anti-aliasing transiently to get a
> > nicer rendered result too :-)
> 
> Yeah, using polygons could reduce that code, but I just begun 
> contributing and I don't feel comfortable with such a big change, at 
> least for now. Besides, I had a quick look at (rendering of) polygons 
> and it looks a little too complicated for such small symbols and, if you 
> take a look at the circles generated by the original ImplDrawSymbols 
> (which made use of polygons), you'll see that the results were not so 
> precise. This requires further investigation, anyhow, since also "line" 
> routines are quite complex and are called many times for each symbol.
> 
> >   

Re: [Libreoffice] identical text for different (but close) locale at scp2/source/ooo

[Lior Kaplan]

On Thu, Nov 24, 2011 at 1:05 PM, Andras Timar  wrote:

> Hi Kaplan,
>
> 2011/11/24 Lior Kaplan :
> > Hi,
> >
> > While translating some scp2 strings for 3.5 I notice duplicate strings
> which
> > looks weird (e.g. "Installs the Tamil user interface").
> >
> > I checked the sources and notice this is because we have two locales for
> > Tamil:
> >
> > [STR_NAME_MODULE_LANGPACK_TA]
> > en-US = "Tamil"
> >
> > [STR_DESC_MODULE_LANGPACK_TA]
> > en-US = "Installs the Tamil user interface"
> >
> > [STR_NAME_MODULE_LANGPACK_TA_IN]
> > en-US = "Tamil"
> >
> > [STR_DESC_MODULE_LANGPACK_TA_IN]
> > en-US = "Installs the Tamil user interface"
> >
> > Do we really support two locales or this is a mistake? If we do support
> two
> > locales, the users should have a way to differentiate between the two.
> >
>
> We don't support ta_IN, only ta. In fact those lines could be removed
> from scp2 (there are more to clean up I suppose).
> For supported UI locales see
> http://opengrok.libreoffice.org/xref/core/solenv/inc/langlist.mk
>
>
Good to know. I'll do the clean up and send a patch...

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

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

[bugzilla-daemon]

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

--- Comment #30 from Rainer Bielefeld  
2011-11-24 03:10:52 PST ---
Nominate "Bug 42979 - Wrong application icon on the MSVC Master". Such a very
visible problem is not acceptable for a release.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

[bugzilla-daemon]

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

--- Comment #29 from Rainer Bielefeld  
2011-11-24 03:08:54 UTC ---
Nominate Bug 42914 - Terminal (command) window is opened when launching any
executable. Such a very visible problem is not acceptable for a release.

-- 
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] identical text for different (but close) locale at scp2/source/ooo

[Andras Timar]

Hi Kaplan,

2011/11/24 Lior Kaplan :
> Hi,
>
> While translating some scp2 strings for 3.5 I notice duplicate strings which
> looks weird (e.g. "Installs the Tamil user interface").
>
> I checked the sources and notice this is because we have two locales for
> Tamil:
>
> [STR_NAME_MODULE_LANGPACK_TA]
> en-US = "Tamil"
>
> [STR_DESC_MODULE_LANGPACK_TA]
> en-US = "Installs the Tamil user interface"
>
> [STR_NAME_MODULE_LANGPACK_TA_IN]
> en-US = "Tamil"
>
> [STR_DESC_MODULE_LANGPACK_TA_IN]
> en-US = "Installs the Tamil user interface"
>
> Do we really support two locales or this is a mistake? If we do support two
> locales, the users should have a way to differentiate between the two.
>

We don't support ta_IN, only ta. In fact those lines could be removed
from scp2 (there are more to clean up I suppose).
For supported UI locales see
http://opengrok.libreoffice.org/xref/core/solenv/inc/langlist.mk

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

Re: [Libreoffice] [PUSHED] [REVIEW 3-4] Fix for fdo#39589

[Lionel Elie Mamane]

On Thu, Nov 24, 2011 at 10:56:57AM +0100, Lionel Elie Mamane wrote:

> I understand we don't want to touch that in stable branch, but anyone
> opposing me pushing something like that in master, and similar for
> llimit_cast and limit_cast?

> // assumptions:
> // \forall typename Type:
> // ( (::std::numeric_limits< Type >::min() == 0) XOR ( 
> ::std::numeric_limits< Type >::min() < 0  && ::std::numeric_limits< Type 
> >::is_signed ))
> // &&  (::std::numeric_limits< Type >::max() > 0 )

> template< typename ReturnType, typename Type >
> inline ReturnType ulimit_cast( Type nValue, ReturnType nMax )
> {
>   if ( ! ::std::numeric_limits< ReturnType >::is_signed && 
> ::std::numeric_limits< Type >::is_signed && nValue < 0 )
> return nMax;
>  // Due to implicit type conversion, the comparison in the if occurs in 
> the type
>  // that has the biggest ::max()
>  // -> safe; compiler gives a warning for mixed signed/unsigned, though
>  // Assuming unbounded signed types are unbounded towards both infinities.
>   else if ( ! ::std::numeric_limits< ReturnType >::is_bounded ||
> ::std::numeric_limits< ReturnType >::max() > 
> ::std::numeric_limits< Type >::max() )

That should be:

  else if ( ! ::std::numeric_limits< ReturnType >::is_bounded ||
nMax > ::std::numeric_limits< Type >::max() )

Obviously.

> // nValue fits, and it is unsafe to compare nMax to nValue within Type:
> // nMax would be converted
> return static_cast < ReturnType >(nValue);
>   else
> // nMax fits in Type; safe to compare to nValue within Type
> return static_cast< ReturnType >(::std::min(nValue, nMax));
> }

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

Re: [Libreoffice] Setting up a non-intrusive build cluster

[Bjoern Michaelsen]

On Wed, Nov 23, 2011 at 06:43:13PM -0500, Marc-André Laverdière wrote:
> Is GDM the default/standard graphical login in linux distros? 

Not on Ubuntu: http://www.freedesktop.org/wiki/Software/LightDM

Best,

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

[Libreoffice] identical text for different (but close) locale at scp2/source/ooo

[Lior Kaplan]

Hi,

While translating some scp2 strings for 3.5 I notice duplicate strings
which looks weird (e.g. "Installs the Tamil user interface").

I checked the sources and notice this is because we have two locales for
Tamil:

[STR_NAME_MODULE_LANGPACK_TA]
en-US = "Tamil"

[STR_DESC_MODULE_LANGPACK_TA]
en-US = "Installs the Tamil user interface"

[STR_NAME_MODULE_LANGPACK_TA_IN]
en-US = "Tamil"

[STR_DESC_MODULE_LANGPACK_TA_IN]
en-US = "Installs the Tamil user interface"

Do we really support two locales or this is a mistake? If we do support two
locales, the users should have a way to differentiate between the two.

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

Re: [Libreoffice] Bug 39659 - Java 7 not recognised -- missing or adjustment to distribution specific "vendorInfos" needed for the new Oracle JRE

[Tomáš Chvátal]

2011/11/24 Stephan Bergmann :
> On 11/24/2011 09:56 AM, Tomáš Chvátal wrote:
>>
>> Other problem is that hsqldb we bundle does not build with new java
>
> but still runs with it?

Yep runs, just won't build.
>
>> and also some people reported weird runtime erorrs using it.
>
> using Java 7 in general with LO, or using hsqldb with Java 7?
>
Looks like using in general, but sadly i don't know which of these are
actual breakages of gentoo java and which ones are relevant for LO :(

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

Re: [Libreoffice] [PUSHED] [REVIEW 3-4] Fix for fdo#39589

[Lionel Elie Mamane]

On Thu, Nov 24, 2011 at 02:13:57AM -0500, Kohei Yoshida wrote:
> On Thu, 2011-11-24 at 07:50 +0100, Lionel Elie Mamane wrote:
>> On Wed, Nov 23, 2011 at 06:53:53PM -0500, Kohei Yoshida wrote:

>>> I'd like to have

>>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=0215f8b19451ab67c7fdaf91f2da8298a9b89c47

>>> cherry-picked to the 3-4 branch.  It fixes

>> I see how ulimit_cast is the wrong choice there, but:

>> If I understand well, static_cast(a) where a is a signed
>> int returns a+2^n where n is the length of int in bits.

>> Why is that the best solution, rather than 0, which as far as I
>> understand, limit_cast(a) would use?

> Both are 32-bit integers. We are casting long to unsigned long.
> And since the original value is a cell position, it is never
> negative.

OK, if it is never negative, then static_cast is safe at this
point. I'm pushing.

Besides, I now see that limit_cast is buggy in converting positive
values from signed to unsigned, returning 0 when it fits!

> it's better than the current (which "casts" 0 to -1 or 0x).

As I understand things, this is _bug_ in unary
ulimit_cast. Unary ulimit_cast is described in doxygen comment as:

/** Returns the value, if it fits into ReturnType, otherwise the maximum value 
of ReturnType. */

I understand we don't want to touch that in stable branch, but anyone
opposing me pushing something like that in master, and similar for
llimit_cast and limit_cast?

// assumptions:
// \forall typename Type:
// ( (::std::numeric_limits< Type >::min() == 0) XOR ( 
::std::numeric_limits< Type >::min() < 0  && ::std::numeric_limits< Type 
>::is_signed ))
// &&  (::std::numeric_limits< Type >::max() > 0 )

template< typename ReturnType, typename Type >
inline ReturnType ulimit_cast( Type nValue, ReturnType nMax )
{
  if ( ! ::std::numeric_limits< ReturnType >::is_signed && 
::std::numeric_limits< Type >::is_signed && nValue < 0 )
return nMax;
 // Due to implicit type conversion, the comparison in the if occurs in the 
type
 // that has the biggest ::max()
 // -> safe; compiler gives a warning for mixed signed/unsigned, though
 // Assuming unbounded signed types are unbounded towards both infinities.
  else if ( ! ::std::numeric_limits< ReturnType >::is_bounded ||
::std::numeric_limits< ReturnType >::max() >  
::std::numeric_limits< Type >::max() )
// nValue fits, and it is unsafe to compare nMax to nValue within Type:
// nMax would be converted
return static_cast < ReturnType >(nValue);
  else
// nMax fits in Type; safe to compare to nValue within Type
return static_cast< ReturnType >(::std::min(nValue, nMax));
}


Or any C/C++ language lawyer can optimise this into being faster,
while still being safe?

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

Re: [Libreoffice] Problems with mozilla build-tools on WindowsXP

[Fridrich Strba]

On 24/11/11 10:14, Caolán McNamara wrote:
> and configure with --with-mozilla-build=/c/mozilla-tools (or whereever
> it does)

I would use --with-mozilla-build=c:/mozilla-tools which is a path that
cygwin understands and the native Windows too.

Cheers

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

Re: [Libreoffice] how to acquire an ScDocument reference "from scratch"

[Caolán McNamara]

On Wed, 2011-11-23 at 16:59 -0500, Kevin Hunter wrote:
> Hello List,
> 
> I'm trying to get hold of an ScDocument "from scratch".  I have naively 
> attempted to replicate another section of code, but for the life of me 
> can't figure out what I'm missing.  My code crashes with a SIGSEGV on 
> this line:
> 
> aDocShell = new ScDocShell();
> 
> I think I've boiled it down to a null pointer dereference 

Probably boils down to needing the call to
comphelper::setProcessServiceFactory in
test::BootstrapFixtureBase::setUp in
unotest/source/cpp/bootstrapfixturebase.cxx

C.

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

Re: [Libreoffice] Problems with mozilla build-tools on WindowsXP

[Caolán McNamara]

On Thu, 2011-11-24 at 00:10 +0100, Rob Snelders wrote:
> When it failed I downloaded the moztools-static.zip from the 
> mozilla-buildtools-ftp and put that in the buildtools-directory. But 
> that also didn't help.
> 
> Does anybody knows why this error is given?

We need to build "nss", and nss requires the mozilla build tooling under
windows, regardless of whether mozilla itself is built it not. nss is
used by a few things directly by LibreOffice, not just as a build-req
for the mozilla stuff.

Easiest to install the mozilla tools installer from 
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32 and run
it, it will install into something like c:\mozilla-tools

and configure with --with-mozilla-build=/c/mozilla-tools (or whereever
it does)

C.

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

Re: [Libreoffice] [PATCH] Translate German comments

[Caolán McNamara]

On Sat, 2011-11-19 at 12:22 +0100, Philipp Weissenbacher wrote:
>   I didn't understand what "//al la WW: 1 Inch" means

WW in these contexts means "WinWord", so like Microsoft Word: 1 Inch I
would guess is the meaning, and probably isn't German at all, but
already in English :-)

C.


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

Re: [Libreoffice] Bug 39659 - Java 7 not recognised -- missing or adjustment to distribution specific "vendorInfos" needed for the new Oracle JRE

[Stephan Bergmann]

On 11/24/2011 09:56 AM, Tomáš Chvátal wrote:

Other problem is that hsqldb we bundle does not build with new java


but still runs with it?


and also some people reported weird runtime erorrs using it.


using Java 7 in general with LO, or using hsqldb with Java 7?

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

Re: [Libreoffice] Assertions and Logging

[Stephan Bergmann]

On 11/23/2011 06:55 PM, Norbert Thiebaud wrote:

  For production builds, my assumption is they would
routinely log either nothing at all or *all* SAL_WARNs.  So only if a user
would explicitly enable certain area-restricted SAL_INFOs (to find out more
about a reproducible problem he experiences) would the decision to represent
areas as strings necessarily have negative consequences (which IMO would
again be tolerable in that special scenario).


This is a self fulling prophecy. beside in order to exclude them all
you still need to parse your env variable no?
so sure the parsing will be (relatively) fast... but you still get a
couple of prologue, epilogue, a couple of variable initialization, a
get_env
so a no-op operation is still 100x more instructions than necessary.

actually reading the code if env = NULL you force it to +WARN and then
go ahead an parse it...:-(


As I already wrote, nothing keeps us from changing the *implementation* 
if need be.  I see no obstacle that would prevent fast paths for the use 
cases of enabling nothing or enabling all SAL_WARNs.



To that extend, pushing as much or the complexity to the init function
and make the wrapper that trigger the trace as lightweight as possible
is desirable.


yes


Note that I'm arguing from a position where I'd like to have such
facility cheap and usable in release build.. this is above and beyond
what we currently have.


I'm on the same page here.  It's just that I assume a string area can 
still give us good overall performance, so would prefer to stick to that 
design.  Whether my assumption is true only time will tell, of course...


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

Re: [Libreoffice] Bug 39659 - Java 7 not recognised -- missing or adjustment to distribution specific "vendorInfos" needed for the new Oracle JRE

[Tomáš Chvátal]

2011/11/24 Stephan Bergmann :
>
> "Whether to backport this to LO 3.4.5 is another question.  Anybody seeing
> any demand?"
>
> Stephan

Users quite request it so at least in Gentoo we backport that patch.

Other problem is that hsqldb we bundle does not build with new java
and also some people reported weird runtime erorrs using it.

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

Re: [Libreoffice] Bug 39659 - Java 7 not recognised -- missing or adjustment to distribution specific "vendorInfos" needed for the new Oracle JRE

[Stephan Bergmann]

See :

"The most relevant platform here will likely be Windows.  Somebody 
working on Windows would need to adapt 
jvmfwk/distributions/OpenOfficeorg/javavendors_wnt.xml accordingly and 
verify that the result is good."


and

"Whether to backport this to LO 3.4.5 is another question.  Anybody 
seeing any demand?"


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

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

[Petr Mladek]

Philipp Weissenbacher píše v So 19. 11. 2011 v 12:22 +0100:
> Hi all,
> 
> I've continued translating in sw/source/core/doc (find the patch attached).

Thanks for the patch. I have pushed it into master.

> - I missed one sentence in doccomp.cxx. Fixed that.

Great catch.

> - docdesc.cxx was a bit tricky:
>   I didn't understand what "//al la WW: 1 Inch" means, so I left it as
> is. ("al la" by itself can mean "is like" in German, but I wasn't sure
> if that is meant here).

"is like" makes perfect sense, so I have added this change.

>   There's an handled else statement In line 712. Someone might want to
> take a look at it.

If I understand it correctly the code solves the DOC import. The
import/export filers are always work in progress. I guess that this is a
less important scenario and it just need to wait for anyone interested
into fixing it.

>   I wasn't sure how I should translate "Ränder" and  "Umrandung", so I
> used "border" and "border strips". Is that right?

I confronted the words with dictionary and found that the following
translations might be more appropriate:

Ränder = margin
Umrandung = border

The margin is an empty space between an edge of paper and a text. The
border is a line around a table or so.

> Just 37 more files to go!

Thanks a lot for the great work. We are looking forward to see more
translations.

Best Regards,
Petr

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