Re: [Libreoffice] pdf import extention

2010-12-23 Thread Lior Kaplan
Hi Guys,

Sorry for nagging, but I'm interested in seeing these fixes in LibO 3.3.

Could you integrate  http://hg.services.openoffice.org/cws/pdfextfix04 ?

On Mon, Dec 13, 2010 at 2:40 PM, Michael Meeks michael.me...@novell.comwrote:

 Hi Thorsten,

 On Mon, 2010-12-13 at 12:57 +0100, Thorsten Behrens wrote:
  Lior Kaplan wrote:
   Could we import changes made in the PDF import extension ?
   See http://hg.services.openoffice.org/cws/pdfextfix04
  
  Yep, makes sense - if someone could second this, I'll commit it to
  -3-3.

 Code changes look sensible to me; #2 ...

Thanks,

Michael.

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



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


Re: [Libreoffice] Better wording for 'Update links' question

2010-12-23 Thread Cor Nouws

Octavio Alvarez wrote (23-12-10 01:20)

On Wed, 22 Dec 2010 14:36:57 -0800, Cor Nouws oo...@nouenoff.nl wrote:


And the contrary:
- user has some data, that is known to be updated,
- opens a file that uses the data and wants to update it immediately.
Isn't that how the dialog is meant to be used?


What is the point of the dialog, if he STILL has to click yes?


That it offers a quick choice?


If he already knows he wants to update immediately and he still has
to take action to manually choose yes, it is not more difficult
to click on a toolbar button named Update all links or to set up
a key combination for that, after the document has loaded.

It is a usability issue, not a functionality issue.


Yes, I agree.


OTOH, the dialog blocks a user from opening a file and forces him to
make a decision he might not know at all at the moment. The document
isn't even displayed before the dialog shows up. It's a decision to
be taken completely in the blind.

The only case where the dialog would be useful is to prevent the user
from forgetting to update links, but there are (or may be) other ways
to accomplish this without obstructing file loading.



Cor

--
 - giving openoffice.org its foundation :: The Document Foundation -

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


[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers

2010-12-23 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=31865

Bug 31865 depends on bug 32133, which changed state.

Bug 32133 Summary: [RC1] overlapping controls on Tools - Options - General panel
https://bugs.freedesktop.org/show_bug.cgi?id=32133

   What|Old Value   |New Value

 Resolution|FIXED   |
 Status|RESOLVED|REOPENED

-- 
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] Don't change the naming scheme for rc2 please - keep windows at *install*_all_lang.exe

2010-12-23 Thread Christian Lohmaier
Hi *,

Windows installer with all_lang did lose the install from the filename.

Please change the name/create an appropriate symlink.

If such a name-change is planned, then please announce it (but as is
is inconsistent with the multi installer, I think it is just a
mistake).

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


Re: [Libreoffice] Don't change the naming scheme for rc2 please - keep windows at *install*_all_lang.exe

2010-12-23 Thread Christian Lohmaier
On Thu, Dec 23, 2010 at 1:43 PM, Christian Lohmaier
lohmaier+ooofut...@googlemail.com wrote:

 Windows installer with all_lang did lose the install from the filename.

 Please change the name/create an appropriate symlink.

Oh, and I forgot:
please provide a readme_multi or similar that lists the languages
contained in multi, or provide some other way to easily tell what
languages are available in the download.

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


Re: [Libreoffice] Request review for 3.3

2010-12-23 Thread Caolán McNamara
On Wed, 2010-12-22 at 23:19 -0500, Kohei Yoshida wrote:
 Hi there,
 
 Just fixed the following bug on master
 
 https://bugs.freedesktop.org/show_bug.cgi?id=32523
 
 The fix was rather simple, as this commit shows
 
 http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=90c9dcfde572f227eae0760066af5b8a9d5d9218
 

Looks sane. Worth the risk I say. Ideal would be a cppunit test to
lock-this-down in svl :-)

C.

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


Re: [Libreoffice] Don't change the naming scheme for rc2 please - keep windows at *install*_all_lang.exe

2010-12-23 Thread Fridrich Strba
This is a bug.

When building the installer for all languages, the build system calls it
multi. I just renamed it so that the upload could be done, just maybe I
replaced too much :). Will be different for rc3 if exists.

Cheers

Fridrich

On Thu, 2010-12-23 at 13:43 +0100, Christian Lohmaier wrote:
 Hi *,
 
 Windows installer with all_lang did lose the install from the filename.
 
 Please change the name/create an appropriate symlink.
 
 If such a name-change is planned, then please announce it (but as is
 is inconsistent with the multi installer, I think it is just a
 mistake).
 
 ciao
 Christian
 ___
 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] Don't change the naming scheme for rc2 please - keep windows at *install*_all_lang.exe

2010-12-23 Thread Fridrich Strba
Here are the languages of the multi installer for documentation writers:
en-US,af,ar,as,be-BY,bn,bo,ca,cs,da,de,dz,el,en-GB,es,eu,fi,fr,gl,gu,he,hi,hr,hu,it,ja,ko,mr,nb,nl,nn,oc,om,or,pl,pt,pt-BR,ru,sh,si,sk,sl,sr,sv,ta,te,th,tr,ug,uk,uz,vi,xh,zh-CN,zh-TW,zu

Cheers

F.

On Thu, 2010-12-23 at 13:46 +0100, Christian Lohmaier wrote:
 On Thu, Dec 23, 2010 at 1:43 PM, Christian Lohmaier
 lohmaier+ooofut...@googlemail.com wrote:
 
  Windows installer with all_lang did lose the install from the filename.
 
  Please change the name/create an appropriate symlink.
 
 Oh, and I forgot:
 please provide a readme_multi or similar that lists the languages
 contained in multi, or provide some other way to easily tell what
 languages are available in the download.
 
 ciao
 Christian
 ___
 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] configure --without-git is broken, fetch_tarballs.sh is renamed to download

2010-12-23 Thread Gökçen Eraslan
Hello,

To build RC2, I cannot get tarballs when I use configure --without-git. In 
download_external_sources.sh script line 18[1]:

wget 
http://cgit.freedesktop.org/libreoffice/bootstrap/plain/fetch_tarballs.sh?id=$GIT_TAG
 
-O fetch_tarballs.sh  chmod 755 fetch_tarballs.sh

But this command does not work since fetch_tarballs.sh is renamed[2] to 
download. Can anybody fix that?

Thanks.

[1] 
http://cgit.freedesktop.org/libreoffice/build/tree/download_external_sources.sh#n18
[2] 
http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=fe225c2eb3236e186983d17c8f5dd83a6bdeb2ec

-- 
Gökçen Eraslan


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


Re: [Libreoffice] Request review for 3.3

2010-12-23 Thread Kohei Yoshida
On Thu, 2010-12-23 at 13:46 +, Caolán McNamara wrote:
 On Wed, 2010-12-22 at 23:19 -0500, Kohei Yoshida wrote:
  Hi there,
  
  Just fixed the following bug on master
  
  https://bugs.freedesktop.org/show_bug.cgi?id=32523
  
  The fix was rather simple, as this commit shows
  
  http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=90c9dcfde572f227eae0760066af5b8a9d5d9218
  
 
 Looks sane. Worth the risk I say.

Thanks.  Pushed to libreoffice-3-3.

 Ideal would be a cppunit test to
 lock-this-down in svl :-)

Haha, yeah I agree.  But the test harness for svl doesn't seem to be
working atm.  We should look into that sometime...

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com

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


[Libreoffice] SfxDocTplService_Impl posable memory leek

2010-12-23 Thread Joseph Powers

Source in question: sfx2/source/doc/doctemplates.cxx

The code looks like this:

//-

struct NamePair_Impl
{
OUString maShortName;
OUString maLongName;
};

DECLARE_LIST( NameList_Impl, NamePair_Impl* )

class SfxDocTplService_Impl
{
...
NameList_Impl   maNames;
...
voidreadFolderList();
OUStringgetLongName( const OUString 
rShortName );
...
}

void SfxDocTplService_Impl::readFolderList()
{
SolarMutexGuard aGuard;

ResStringArray  aShortNames( SfxResId( TEMPLATE_SHORT_NAMES_ARY ) );
ResStringArray  aLongNames( SfxResId( TEMPLATE_LONG_NAMES_ARY ) );

NamePair_Impl*  pPair;

USHORT nCount = (USHORT)( Min( aShortNames.Count(), aLongNames.Count() ) );

for ( USHORT i=0; inCount; i++ )
{
pPair = new NamePair_Impl;
pPair-maShortName  = aShortNames.GetString( i );
pPair-maLongName   = aLongNames.GetString( i );

maNames.Insert( pPair, LIST_APPEND );
}
}

OUString SfxDocTplService_Impl::getLongName( const OUString rShortName )
{
OUString aRet;
NamePair_Impl   *pPair = maNames.First();

while ( pPair )
{
if ( pPair-maShortName == rShortName )
{
aRet = pPair-maLongName;
break;
}
else
pPair = maNames.Next();
}

if ( !aRet.getLength() )
aRet = rShortName;

return aRet;
}

//-

No where in the code can I see where maNames gets cleanup up. The only 
destructor is in the base class which just cleans up the list memory and 
doesn't free the NamePair_Impl memory.

Container::~Container()
{
DBG_DTOR( Container, DbgCheckContainer );

// Alle Bloecke loeschen
CBlock* pBlock = pFirstBlock;
while ( pBlock )
{
CBlock* pTemp = pBlock-GetNextBlock();
delete pBlock;
pBlock = pTemp;
}
}

I'm thinking of just adding code to ~SfxDocTplService_Impl() to free the 
NamePair_Impl items.

What I'd like to know is the following:

1. Am I reading this correctly?
2. Where is this uses, so I can test my changes? (I'm converting the above code 
to use a vector)

The use path is:
NamePair_Impl
SfxDocTplService_Impl
Updater_Impl
SfxDocTplService_Impl (yes, it's a circular definition)
SfxDocTplService

SfxDocTplService is registered as com.sun.star.frame.DocumentTemplates

which gets used in:
svtools/source/contnr/templwin.cxx
sd/source/ui/dlg/TemplateScanner.cxx

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


[Libreoffice] Request for review for 3.3

2010-12-23 Thread Kohei Yoshida
Hi,

It's me again.

I just fixed the following bug:
https://bugs.freedesktop.org/show_bug.cgi?id=32570

and would like to port the fix to 3.3.  Here is the relevant commit
http://cgit.freedesktop.org/libreoffice/calc/commit/?id=98764831e3b6c02d7630c61a6c389ce4318787bd

Here is some risk analysis.

The worst case this change would cause is that some formula strings that
should have been flagged bad may be accepted (e.g. 100.A1 where the 100
is a sheet name).

But I would say the risk of that happening is quite low since we already
automatically detect numerical sheet names and quote them, so chances
are that we won't run into an unquoted numerical sheet name followed by
a '.'.  Plus, the current code breaks legitimate cases as evident in the
bug report.

Also, we support multiple formula syntaxes and a '.' is not always the
sheet-to-reference separator, which makes this check totally wrong in
our code base.

A review and a sign-off would be great.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com

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


Re: [Libreoffice] BrOffice RC2

2010-12-23 Thread Andras Timar
2010/12/23 Olivier Hallot olivier.hal...@documentfoundation.org

 Hi

 Although not accessible from the download page, there is a Windows package
 named BrOffice (only on windows)


 http://download.documentfoundation.org/libreoffice/testing/3.3.0-rc2/win/x86/BrOffice_3.3.0rc2_Win_x86_all_lang.exe

 Which is nice from you guys and I thank you so much for that.

 I am testing it, so, shall I report bugs under this specific package?
 Thanks again


Hi Olivier,

I compared BrOffice_3.3.0rc2_Win_x86_all_lang.exe to
LibO_3.3.0rc2_Win_x86_all_lang.exe, they are identical. So this is not a
special package, only the file name is different.

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


Re: [Libreoffice] SfxDocTplService_Impl posable memory leek

2010-12-23 Thread Kohei Yoshida
On Thu, 2010-12-23 at 07:56 -0800, Joseph Powers wrote:

[...]
 No where in the code can I see where maNames gets cleanup up. The only
 destructor is in the base class which just cleans up the list memory
 and doesn't free the NamePair_Impl memory.

Indeed.  This is bad.


 1. Am I reading this correctly?

IMO yes.  That's how I'm reading this too.  This guy is probably leaking
memory.

 2. Where is this uses, so I can test my changes? (I'm converting the
 above code to use a vector)

I believe this code is used to manage templates (File - Templates -
Organize) or somewhere in that neighborhood.  But please do
double-check.  Beyond that, I don't know for sure.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com

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


Re: [Libreoffice] Better wording for 'Update links' question

2010-12-23 Thread Joe Smith

On 12/22/2010 03:11 PM, Kohei Yoshida wrote:

On Wed, 2010-12-22 at 13:06 -0500, Joe Smith wrote:

...

Believe me, I'm no fan of this cryptic prompt, but I'm afraid this won't
be an improvement. The wording of the prompt is not the primary problem.


I'm not sure if I agree with that view.  This *will* be an improvement,
and although the wording alone will not be enough to fix this
*completely*, improving the wording itself is a step in the right
direction.


Sure, it's hard to argue that an incremental improvement is not worth 
while, but if you go to the doctor with a broken arm and you get a 
Band-Aid and a pat on the back, is that an improvement? Better than 
nothing? How about 10 Band-Aids? 100?


If 100 Band-Aids won't help, does it still make sense to do one?

If we did a trial with the old prompt and the improved prompt and found 
that both groups performed the same (that's my prediction), would it be 
worth the cost in making the change? Would some users actually do worse 
when faced with an unfamiliar prompt?


Even small changes incur some cost. You know better than I what cost is 
involved in making even a simple string change: updating translations, 
help text, etc. Retraining people who are confused by the change?


You're doing the work: if you feel it's worth the cost, then make the 
change. We've already spent more time discussing it than it's worth--sorry.



...

The decision at hand is too complex for an accurate prompt, given the
way OOo uses links: links may point not only to external data, but also
to internal data,


Links that point to internal data!?  Can you give us an example of how
the app links to an internal data?  I can't think of any such example,
and it's not supposed to include internal data as external links.


If you want to make labels, and choose the synchronize option so that 
all labels share the same set of fields, you get a Writer document with 
one editable master label, and the others automatically following the 
master through linked sections, i.e., internal links.


If you then merge in data to generate a sheet full of different 
addresses and send the output to a new document, then open that document 
to check the results, you get the Update links? prompt. If you answer 
yes, then Writer copies the address data from the master label to all 
the others, and it looks like the merge has failed and only the first 
record was processed.


The old prompt will be more accurate than the new one in this case.

I'll send a sample document if you want to try it.

You might say this is an unusual and inconsequential case, but 
generating labels in this way is a very common task, and people do 
actually trip over it.


Look, I'm not a UI guy. This is just my $0.02. I'm sorry to butt in; the 
UX people can surely provide better advice.


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


[Libreoffice] cppcheck: Invalid Character errors fix

2010-12-23 Thread Andy Holder
 I not sure if this fixes the Invalid number of character ({) when
 these macros are defined error from cppcheck but the start of a
 namespace declaration being inside a #if without it's closing } has to
 be wrong.

AndyFrom f0146a90f638cac49ef2f6020515adde4da4b1ce Mon Sep 17 00:00:00 2001
From: Andy Holder andy.m.hol...@gmail.com
Date: Thu, 23 Dec 2010 17:31:49 +
Subject: [PATCH] cppcheck: Invalid Character errors fix

There are a number of Invalid number of character ({) when these
macros are defined error from cppcheck, I think these are
caused by the start of a namespace
declaration being inside a #if without it's closing }.
---
 binfilter/bf_sw/source/core/text/sw_porlay.cxx |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/binfilter/bf_sw/source/core/text/sw_porlay.cxx b/binfilter/bf_sw/source/core/text/sw_porlay.cxx
index b0e8d3b..3ae98df 100644
--- a/binfilter/bf_sw/source/core/text/sw_porlay.cxx
+++ b/binfilter/bf_sw/source/core/text/sw_porlay.cxx
@@ -56,6 +56,7 @@ using namespace ::com::sun::star::i18n::ScriptType;
 
 #ifdef BIDI
 #include unicode/ubidi.h
+#endif
 namespace binfilter {
 
 /*
@@ -72,7 +73,6 @@ namespace binfilter {
  */
 
 
-#endif
 
 
 /*
-- 
1.7.3.4

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


Re: [Libreoffice] SfxDocTplService_Impl posable memory leek

2010-12-23 Thread Caolán McNamara
On Thu, 2010-12-23 at 07:56 -0800, Joseph Powers wrote:

 
 2. Where is this uses, so I can test my changes? (I'm converting the
 above code to use a vector)

This should be File-Templates-Organize. 

A quick hack to the the UI from some code is to dig out the resource
ids, e.g. there's a use of TEMPLATE_SHORT_NAMES_ARY in there, and
grep/opengrok for that to find what text is in there, e.g. My
Templates, Business Correspondence, etc. 

You'll find those strings listed in File-Templates-Organize.

C.


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


Re: [Libreoffice] A file to show 8192 discontinuities crashes Calc

2010-12-23 Thread Kohei Yoshida
On Wed, 2010-12-22 at 20:48 -0800, r_ouellette wrote:

 Calc 3.3 will freeze forever with this file set to use even or odd numbers
 only, you need to kill the process.

Yup, I did a quick profile, and there are several issues at play here.
I'll look into unwinding this but it will need a bit of work.

Let me look into this.  I already have some ideas to make the filtering
faster, but I need to experiment a bit.

Thanks for the use case.  Performance issue happens to be my sore
spot. :-)

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com

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


[Libreoffice] [PUSHED] Re: cppcheck: Invalid Character errors fix

2010-12-23 Thread Caolán McNamara
On Thu, 2010-12-23 at 18:21 +, Andy Holder wrote:
 I not sure if this fixes the Invalid number of character ({) when
  these macros are defined error from cppcheck but the start of a
  namespace declaration being inside a #if without it's closing } has to
  be wrong.

Yeah, that makes no sense. Pushed your fix, thanks for this. Clearly
this only ever worked because BIDI is always defined.

C.

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


Re: [Libreoffice] configure --without-git is broken, fetch_tarballs.sh is renamed to download

2010-12-23 Thread Miklos Vajna
Hi Gökçen,

On Thu, Dec 23, 2010 at 04:14:30PM +, Gökçen Eraslan gok...@pardus.org.tr 
wrote:
 To build RC2, I cannot get tarballs when I use configure --without-git. In 
 download_external_sources.sh script line 18[1]:
 
 wget 
 http://cgit.freedesktop.org/libreoffice/bootstrap/plain/fetch_tarballs.sh?id=$GIT_TAG
  
 -O fetch_tarballs.sh  chmod 755 fetch_tarballs.sh
 
 But this command does not work since fetch_tarballs.sh is renamed[2] to 
 download. Can anybody fix that?

What is the error message you get?

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

This commit is in master only, while you're trying to build RC2 which is
from the libreoffice-3-3 branch.

I just built today RC2 from tarballs successfully. (Though we do not use
./download since sources are downloaded before the build by the package
builder.)


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


Re: [Libreoffice] Suggestions

2010-12-23 Thread Olivier Hallot

Hi

Em 23-12-2010 18:36, Michel Basilieres escreveu:

Hi

There are two big areas which I feel need to be addressed - although I'm
sure I'm not the only one to mention them. First, and most important, MS
Office compatibility. Frankly, in OO this is crap. The transfer from OO
(I know it's not LO, but as far as I know, no one has said this is an
issue for LO) to Word and back again is so bad I finally had to migrate
to Word.


The easiest way to fix Microsoft compatibility issues in your workplace 
is to buy Microsoft licences. LibreOffice will never do better than 
Microsoft. Not even Microsoft do better than Microsoft. And frankly, do 
we want to be tied to Microsoft rules forever?


Consider dropping doc, xls format and adopt ODF format with LibreOffice. 
I can assure that you will not run into troubles with file opening and 
saving within LibreOffice users.


Using LibreOffice as cheap replacement of costly MSOffice licences, 
disregarding ODF format is a common mistake and recipe for failure in 
any migration program I ran into. If you cannot avoid it, my advise is 
to stick with Microsoft.




Second, the interface. It desperately needs an overhaul to bring it into
the 21st century. I'm not asking for it to be prettier (although it
should be), but for a rearrangement of options and tools so that the
ones that are used together are found together in the interface. Again,
MS Office understands this.


Thanks God, Microsoft Office 2007 migration costs (workforce 
re-training) for the new interface was one of the reasons to move away 
from Microsoft 2003 and adopt OpenOffice and ODF on a 120.000 desktop 
enterprise with stocks in NYSE I am working for. Believe me, average 
users *hate* changes in their cheese. Managers *hate* unhappy users and 
hefty vendor bills.


That does not means that the user interface cannot evolve, it just can't 
be a sharp u-turn.


Kind regards from sunny Rio
--
Olivier Hallot
Founder, Steering Commitee Member - The Document Foundation
Translation Leader for Brazilian Portuguese
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice] rc2 only partially uploaded - many languagepacks missing

2010-12-23 Thread Christian Lohmaier
Hi *,

it seems the upload process was interrupted and thus lots of files
didn't make it to the mirror network.

http://download.documentfoundation.org/libreoffice/testing/3.3.0-rc2/deb/x86_64/
- languagepacks only up to lo

Please restart the upload (and if possible also rename the windows
all_lang installer).

Thanks a lot, and Merry Christmas to everyone

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


Re: [Libreoffice] Suggestions

2010-12-23 Thread Wols Lists
On 23/12/10 23:44, Olivier Hallot wrote:
 Hi

 Em 23-12-2010 18:36, Michel Basilieres escreveu:
 Hi

 There are two big areas which I feel need to be addressed - although I'm
 sure I'm not the only one to mention them. First, and most important, MS
 Office compatibility. Frankly, in OO this is crap. The transfer from OO
 (I know it's not LO, but as far as I know, no one has said this is an
 issue for LO) to Word and back again is so bad I finally had to migrate
 to Word.

 The easiest way to fix Microsoft compatibility issues in your
 workplace is to buy Microsoft licences. LibreOffice will never do
 better than Microsoft. Not even Microsoft do better than Microsoft.
 And frankly, do we want to be tied to Microsoft rules forever? 

Microsoft has a WELL DOCUMENTED history of DELIBERATELY BREAKING
compatibility with other programs. If you want compatibility between
LO/OOo and Word, you will need to stop MS breaking it.

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


Re: [Libreoffice] pdf import extention

2010-12-23 Thread Thorsten Behrens
Lior Kaplan wrote:
 Sorry for nagging, but I'm interested in seeing these fixes in LibO 3.3.
 
 Could you integrate  http://hg.services.openoffice.org/cws/pdfextfix04 ?
 
Hi Lior,

yes, I know - but this fix needs somewhat deeper changes in vcl (a
text mirroring service), which I sadly did not get around reviewing.
It would be great if someone could provide a final, complete patch
(including the necessary service) - otherwise, I'll look into this
in the new year.

Cheers,

-- Thorsten


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


Re: [Libreoffice] rc2 only partially uploaded - many languagepacks missing

2010-12-23 Thread Thorsten Behrens
Christian Lohmaier wrote:
 it seems the upload process was interrupted and thus lots of files
 didn't make it to the mirror network.
 
 http://download.documentfoundation.org/libreoffice/testing/3.3.0-rc2/deb/x86_64/
 - languagepacks only up to lo
 
 Please restart the upload (and if possible also rename the windows
 all_lang installer).
 
Hi Cloph,

good catch, indeed - seems both rpm  deb x86_64 langpacks where
late when the syncing was started. Updating mirrors now.

Cheers,

-- Thorsten


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


Re: [Libreoffice] [UX] [PATCH] EasyHacks 3.27 Change Sheet copy process

2010-12-23 Thread Christoph Noack
Hi all!

Since the rest of my family is sleeping now, there are some minutes
left ... but I expect my nieces to get me out of the bed in a (very) few
hours. Thus, shortened answer :-)

Am Mittwoch, den 22.12.2010, 11:03 -0500 schrieb Kohei Yoshida:
[...]
  Another thing would be helpful ... a more instant feedback on name
  conflicts: showing a comment below the name text field, deactivating the
  OK button. The /!\ symbolizes a small warning sign.
 
 Ah, good.  Great minds think alike. :-)
 
 Regarding the /!\ warning symbol, can you think of any existing dialog
 that does that?  I like the idea itself, but I don't know how that could
 be (easily) implemented.  Looking at an existing dialog code would help
 me figure out how to do this.

At the moment, I don't know any existing dialog within LibO ... maybe
(sort of) the Tools -- Options dialog that (if I remember correctly)
shows some messages if certain options are locked down by
administrators.

But, maybe the ongoing effort within the OOo UX team might help us. It
doesn't fit perfectly, because the invalid name is persistent but the
info bubble is designed to appear temporarily:
http://wiki.services.openoffice.org/wiki/User_Experience/Projects/NonModalMessageSystem#Step_2_-_Message_Style_2a

* Think about the Insert Before thing ... it is not that obvious
  what this means. Is there any way to make this more
  understandable? 
 
 Hmm.  This needs some thinking.

I'll comment on Joost's proposals in his mail ...

* Does any data / experience prove that the default (new) position
  of the sheet should be directly after the source sheet?
 
 I didn't see any usage data in the spreadsheet file I downloaded from
 here
 
 http://wiki.services.openoffice.org/wiki/File:OOo31_Usage_Feedback_Data.ods
 
 Anyone is welcomed to double-check it though.

I downloaded the file at the top of the list and had a look at the Calc
sheet. It seems that most of the stuff is still German - so I just
looked for items that contain move.

For example (sorry, no deep-dive), I found the following (seems to be
checking the button copy within the dialog):
TabelleVerschiebenKopieren-Kopieren
sc:CheckBox:RID_SCDLG_MOVETAB:BTN_COPY  Check
2352

  Did that help ... even if I just throw in some late ideas? ;-)
 
 Yes, it did.  I guess we have some further work to do in this
 dialog. :-)

Wait, wait ... I have more ideas for even more dialogs ;-)))

Thanks a lot to both you Kohei, and Joost!

Cheers,
Christoph

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


Re: [Libreoffice] [UX] [PATCH] EasyHacks 3.27 Change Sheet copy process

2010-12-23 Thread Christoph Noack
Hi all!

I'd like to comment the button up/down idea ... maybe the questions
are already solved somehow, but just to be sure ...

Am Mittwoch, den 22.12.2010, 11:22 -0500 schrieb Kohei Yoshida:
 My preferred approach is to create two buttons to move the insertion
 position up or down, instead of relying on the user clicking on the
 sheet name in the list.  To me 1) that makes more sense, and 2) is
 easier to implement than handling mouse click events on the list
 control. 

Here we face the ease of use vs. efficiency issue ... the proposed
approach might fall short for the power users.

Ease of use: If a document has a limited number of sheets, and the user
is rather mouse-driven, then clicking three times or so is okay. As we
said before, the result is directly visible and, thus, an
improvement ...

Efficiency: Some users (more advanced users) that work in large tables
might simply prefer to scroll down via the mouse-wheel, and to directly
click on the target position.

Concerning the latter, if we want to have something like that (and there
will be requests to mimic the today's behavior), we require space
consuming placeholder lines between the real sheets. This somehow
disturbs the known sheet mapping ... and even for our ease of use
proposal, the users have to re-think the mapping (horizontal vs.
vertical).

Furthermore, let's assume that a less experienced user misses the
current dialog design and moves a sheet to the wrong position. Then both
the actions move/copy are non-destructive (looking at the data that is
kept after all). So correcting this issues might a smaller problem - in
comparison to what we can gain for power users.

Finally, the current design is not that bad ... if we want to go for a
design that suits the non-experts, then we also have to keep in mind the
power users.

Does that make sense to you? I'll try to think a bit more about this
issue ...

By the way, if buttons get added, please consider to add them at the
right hand side (if possible, I'll double-check this with other specs).
And, they should be in close relationship - to make sure that the
required mouse movement is minimized, e.g. if the user wants to correct
the usual one click too far issue.

Cheers,
Christoph

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


[Libreoffice] starmath / cppunit breakage in master

2010-12-23 Thread Miklos Vajna
Hi,

Currently I'm getting:

/usr/include/cppunit/TestAssert.h:101:5: error: no matching function for call 
to 'CppUnit::Asserter::failNotEqual(_STL::string, _STL::string, 
CppUnit::SourceLine, const std::string)'
/usr/include/cppunit/Asserter.h:114:27: note: candidate is: static void 
CppUnit::Asserter::failNotEqual(std::string, std::string, const 
CppUnit::SourceLine, const CppUnit::AdditionalMessage, std::string)

in starmath when building master.

I'm attaching the full output of 'build' in starmath.

I'm using system-cppunit and internal stlport, and I'm almost sure the
breakage is somehow related to the std vs _STL differences.

The strange thing is that this is usually handled by the extstl headers,
but preextstl.h and postextstl.h is already included before/after the
cppunit headers in qa/cppunit/test_nodetotextvisitors.cxx.

Do you have an idea what can be wrong here? This is with gcc-4.5.2, but
IIRC I already had this with 4.5.1 already.

I tried removing the preextstl.h / postextstl.h headers from the above
file, but that just turned the compile error to a linker one. ;)

Thanks.
build -- version: 275224


=
Building module starmath
=
Entering /home/vmiklos/git/libreoffice/master/starmath/inc

Entering /home/vmiklos/git/libreoffice/master/starmath/sdi

Entering /home/vmiklos/git/libreoffice/master/starmath/source

Entering /home/vmiklos/git/libreoffice/master/starmath/util

Entering /home/vmiklos/git/libreoffice/master/starmath/qa/cppunit

Compiling: starmath/qa/cppunit/test_nodetotextvisitors.cxx
/home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/test_nodetotextvisitors.cxx:
 In static member function 'static _STL::string 
CppUnit::assertion_traitsString::toString(const String)':
/home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/test_nodetotextvisitors.cxx:73:16:
 error: cannot bind 'std::basic_ostreamchar' lvalue to 
'std::basic_ostreamchar'
/usr/include/c++/4.5.2/ostream:579:5: error:   initializing argument 1 of 
'std::basic_ostream_CharT, _Traits 
std::operator(std::basic_ostream_CharT, _Traits, const _Tp) [with _CharT 
= char, _Traits = std::char_traitschar, _Tp = _STL::basic_stringchar, 
_STL::char_traitschar, _STL::allocatorchar ]'
/home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/test_nodetotextvisitors.cxx:74:24:
 error: conversion from 'std::basic_ostringstreamchar::__string_type' to 
non-scalar type '_STL::string' requested
In file included from /usr/include/cppunit/TestCase.h:6:0,
 from 
/home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/test_nodetotextvisitors.cxx:41:
/usr/include/cppunit/TestAssert.h: In function 'void 
CppUnit::assertEquals(const T, const T, CppUnit::SourceLine, const 
std::string) [with T = String, std::string = std::basic_stringchar]':
/home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/test_nodetotextvisitors.cxx:492:5:
   instantiated from here
/usr/include/cppunit/TestAssert.h:101:5: error: no matching function for call 
to 'CppUnit::Asserter::failNotEqual(_STL::string, _STL::string, 
CppUnit::SourceLine, const std::string)'
/usr/include/cppunit/Asserter.h:114:27: note: candidate is: static void 
CppUnit::Asserter::failNotEqual(std::string, std::string, const 
CppUnit::SourceLine, const CppUnit::AdditionalMessage, std::string)
dmake:  Error code 1, while making 
'../../unxlngi6.pro/slo/test_nodetotextvisitors.obj'
Forcing regeneration of dependency info

--
- start unit test #1 on library
--
:  
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/vmiklos/git/libreoffice/master/clone/writer/starmath/unxlngi6.pro/lib:/home/vmiklos/git/libreoffice/master/solver/330/unxlngi6.pro/lib
  
/home/vmiklos/git/libreoffice/master/solver/330/unxlngi6.pro/bin/cppunittester  
-headless -invisible \

-env:UNO_SERVICES=file:///home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/../../unxlngi6.pro/misc/qa_cppunit/services.rdb
 \

-env:UNO_TYPES=file:///home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/../../unxlngi6.pro/misc/qa_cppunit/types.rdb
 
file:///home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/../../unxlngi6.pro/misc/qa_cppunit/udkapi.rdb
 \

-env:OOO_BASE_DIR=file:///home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/../../unxlngi6.pro/misc/qa_cppunit
 \

-env:BRAND_BASE_DIR=file:///home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/../../unxlngi6.pro/misc/qa_cppunit
 \

-env:UNO_USER_PACKAGES_CACHE=file:///home/vmiklos/git/libreoffice/master/clone/writer/starmath/qa/cppunit/../../unxlngi6.pro/misc/qa_cppunit
terminate called after throwing an instance of 
'CppUnit::DynamicLibraryManagerException'
  what():  Failed to load dynamic library: -headless

/bin/sh: line 1:  5462 

[Libreoffice] [PATCH] Custom-intro-and-about-files-now-defaultly-png-files

2010-12-23 Thread Kálmán „KAMI” Szalai
Hi All,

Please review the attached files and integrate into libreoffice-3-3

Background:
Now png files are default as intro and about picture files. It seems
only intro.png and about.png used. These patches are:
* force tu specify png files
* rename and pack custom definied intro as intro.png and about as about.png.


TODO:
Convert the currently available custom intro and about files from bmp
format to png.
-- 
KAMI
From 9d228f63430452e52cf23c15eaf722c596128683 Mon Sep 17 00:00:00 2001
From: Kalman Szalai - KAMI kami...@gmail.com
Date: Fri, 24 Dec 2010 03:26:44 +0100
Subject: [PATCH] Custom intro and about files now defaultly png files

Prefer intro.png and about.png files following the OOo changes:
44d020db548943777b4b72334dc1b5d087e7fe02
Custom intro file renamed to intro.png
Custom about file renamed to about.png
---
 configure.in |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/configure.in b/configure.in
index 266f7e3..5442178 100644
--- a/configure.in
+++ b/configure.in
@@ -1097,14 +1097,14 @@ AC_ARG_WITH(intro-bitmaps,
   commas), the order means priority of fallback if the
   first does not exist (in the installed tree).
 
-  Usage: --with-intro-bitmaps=/path/my_ooo_intro.bmp
+  Usage: --with-intro-bitmaps=/path/my_ooo_intro.png
 ],,)
 
 AC_ARG_WITH(about-bitmaps,
 [  --with-about-bitmapsSimilarly to --with-intro-bitmaps, this allows
   specification of bitmaps for the About box.
 
-  Usage: --with-about-bitmaps=/path/my_ooo_about.bmp
+  Usage: --with-about-bitmaps=/path/my_ooo_about.png
 ],,)
 
 AC_ARG_WITH(vendor,
@@ -7783,8 +7783,8 @@ if test -z $with_intro_bitmaps -o $with_intro_bitmaps = no ; then
 else
for bitmap in `echo $with_intro_bitmaps | tr ',' ' '` ; do
   case $bitmap in
- *.bmp) ;;
- *) bitmap= ; AC_MSG_WARN([Intro bitmaps should be .bmp files!]) ;;
+ *.png) ;;
+ *) bitmap= ; AC_MSG_WARN([Intro bitmaps should be .png files!]) ;;
   esac
   if test -n $bitmap ; then
  INTRO_BITMAPS=$INTRO_BITMAPS $bitmap
@@ -7802,8 +7802,8 @@ if test -z $with_about_bitmaps -o $with_about_bitmaps = no ; then
 else
for bitmap in `echo $with_about_bitmaps | tr ',' ' '` ; do
   case $bitmap in
- *.bmp) ;;
- *) bitmap= ; AC_MSG_WARN([About bitmaps should be .bmp files!]) ;;
+ *.png) ;;
+ *) bitmap= ; AC_MSG_WARN([About bitmaps should be .png files!]) ;;
   esac
   if test -n $bitmap ; then
  ABOUT_BITMAPS=$ABOUT_BITMAPS $bitmap
-- 
1.7.1

From 060d1df775aca8493501ace3292e57f4baef6aba Mon Sep 17 00:00:00 2001
From: Kalman Szalai - KAMI kami...@gmail.com
Date: Fri, 24 Dec 2010 03:13:51 +0100
Subject: [PATCH 2/2] Custom intro and about files now defaultly png files

Prefer intro.png and about.png files following the OOo changes:
44d020db548943777b4b72334dc1b5d087e7fe02
Custom intro file renamed to intro.png
Custom about file renamed to about.png
---
 desktop/util/makefile.mk |8 
 desktop/zipintro/makefile.mk |8 
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/desktop/util/makefile.mk b/desktop/util/makefile.mk
index 3d4950c..cad11d5 100644
--- a/desktop/util/makefile.mk
+++ b/desktop/util/makefile.mk
@@ -262,3 +262,11 @@ $(MISC)$/binso_created.flg :
 @@-$(MKDIRHIER) $(BIN)$/so  $(TOUCH) $@
 
 .ENDIF
+.IF $(INTRO_BITMAPS)!=
+- $(MKDIRHIER) $(BIN)$/brand_new$/
+@$(COPY) $(INTRO_BITMAPS) $(BIN)$/brand_new$/intro.png
+.ENDIF
+.IF $(ABOUT_BITMAPS)!=
+- $(MKDIRHIER) $(BIN)$/brand_new$/
+@$(COPY) $(ABOUT_BITMAPS) $(BIN)$/brand_new$/about.png
+.ENDIF
diff --git a/desktop/zipintro/makefile.mk b/desktop/zipintro/makefile.mk
index d15f2de..aa9fef7 100644
--- a/desktop/zipintro/makefile.mk
+++ b/desktop/zipintro/makefile.mk
@@ -33,11 +33,11 @@ TARGET=zipintro
 .INCLUDE :  settings.mk
 
 ZIP1LIST= \
-$(null,$(INTRO_BITMAPS) $(MISC)$/$(RSCDEFIMG)$/brand$/intro.png $(INTRO_BITMAPS)) \
-$(null,$(ABOUT_BITMAPS) $(MISC)$/$(RSCDEFIMG)$/brand$/about.png $(ABOUT_BITMAPS))
+$(null,$(COMMONBIN)$/brand_new$/intro.png $(MISC)$/$(RSCDEFIMG)$/brand$/intro.png $(COMMONBIN)$/brand_new$/intro.png) \
+$(null,$(COMMONBIN)$/brand_new$/about.png $(MISC)$/$(RSCDEFIMG)$/brand$/about.png $(COMMONBIN)$/brand_new$/about.png)
 ZIP2LIST= \
-$(null,$(INTRO_BITMAPS) $(MISC)$/$(RSCDEFIMG)$/brand_dev$/intro.png $(INTRO_BITMAPS)) \
-$(null,$(ABOUT_BITMAPS) $(MISC)$/$(RSCDEFIMG)$/brand_dev$/about.png $(ABOUT_BITMAPS))
+$(null,$(COMMONBIN)$/brand_new$/intro.png $(MISC)$/$(RSCDEFIMG)$/brand_dev$/intro.png $(COMMONBIN)$/brand_new$/intro.png) \
+$(null,$(COMMONBIN)$/brand_new$/about.png $(MISC)$/$(RSCDEFIMG)$/brand_dev$/about.png $(COMMONBIN)$/brand_new$/about.png)
 ZIP3LIST= \
 

Re: [Libreoffice] Change executable/sh names

2010-12-23 Thread NoOp
On 12/18/2010 03:48 AM, Jesús Corrius wrote:
 Right-click the .odt and select 'Open With' (WinXPPro); the 'Programs'
 window shows only option for LibO, not OOo. It does show options for
 Word if MS Word is installed and has the odf converter installed. I've
 repeated this on my WinXPro VM by:

 1. Uninstalling all instances of OOo and LibO.
 2. Reinstall OOo (3.2.1 OOO320m18) and verify that the .odt's are
 associated with OOo.
 3. Reinstall LibORC1 (OOO330m18). The .odt's are now associated *only*
 with LibO *and* cannot be reassociated with OOo from right-clicking and
 'Open With' from Windows Explorer.
 
 I was expecting to find some problem with the merge of the
 SupportedTypes in the registry during the installation, but everything
 worked fine in my Windows XP SP2. I've followed your instructions and
 I now have two entries in the Open With context menu, one for
 OpenOffice.org and the other one for LibreOffice.
 
 Anyone else is able to reproduce this?
 
 My guess is that the problem is with the common swriter.exe (et al)
 executable name. If I get time over the weekend I'll modify the names in
 the Windows registry to see if I can cause the situation to change.
 
 As I mentioned before, in the registry there's the full path of the
 executable, so it doesn't matter if they have the same name provided
 that the path is different.
 
 Here you have info on how this works:
 
 http://msdn.microsoft.com/en-us/library/ee872121(v=VS.85).aspx

Nope. That's not how it works. Sorry for the delay in responding, but
your system does not work the same as mine (WinXPPro SP3). I went back
and repeated my initial. Here are screenshots of those:

http://img27.imageshack.us/img27/5827/screenshotwithnly.png
Only OOo 3.2.1 installed.

Now I install LibO - and in this case I installed LibORC2 just to be
sure that the test is current. And this is the result:
http://img825.imageshack.us/img825/4994/screenshotwithliborc2.png
http://img408.imageshack.us/img408/9178/screenshotwithliborc22.png
Notice that all references to OOo are now missing.

So now I do the open with  browse to OOo swriter.exe and use that -
guess what happens... the .doc file opens in LibO.

As a test I rename the swriter.exe in C:\Program Files\OpenOffice.org
3\program
to ooowriter.exe
and guess what happens when I use the choose program on the next go
around? Yep, the .doc now opens with OOo. And guess what now shows up in
the 'open with' dialog window... OOo:
http://img69.imageshack.us/img69/4567/screenshotoootwrite.png

I'm happy to swap stories/tests, but IMO the problem still exists,




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


Re: [Libreoffice] Change executable/sh names

2010-12-23 Thread NoOp
On 12/23/2010 08:49 PM, NoOp wrote:
 On 12/18/2010 03:48 AM, Jesús Corrius wrote:
 Right-click the .odt and select 'Open With' (WinXPPro); the 'Programs'
 window shows only option for LibO, not OOo. It does show options for
 Word if MS Word is installed and has the odf converter installed. I've
 repeated this on my WinXPro VM by:

 1. Uninstalling all instances of OOo and LibO.
 2. Reinstall OOo (3.2.1 OOO320m18) and verify that the .odt's are
 associated with OOo.
 3. Reinstall LibORC1 (OOO330m18). The .odt's are now associated *only*
 with LibO *and* cannot be reassociated with OOo from right-clicking and
 'Open With' from Windows Explorer.
 
 I was expecting to find some problem with the merge of the
 SupportedTypes in the registry during the installation, but everything
 worked fine in my Windows XP SP2. I've followed your instructions and
 I now have two entries in the Open With context menu, one for
 OpenOffice.org and the other one for LibreOffice.
 
 Anyone else is able to reproduce this?
 
 My guess is that the problem is with the common swriter.exe (et al)
 executable name. If I get time over the weekend I'll modify the names in
 the Windows registry to see if I can cause the situation to change.
 
 As I mentioned before, in the registry there's the full path of the
 executable, so it doesn't matter if they have the same name provided
 that the path is different.
 
 Here you have info on how this works:
 
 http://msdn.microsoft.com/en-us/library/ee872121(v=VS.85).aspx
 
 Nope. That's not how it works. Sorry for the delay in responding, but
 your system does not work the same as mine (WinXPPro SP3). I went back
 and repeated my initial. Here are screenshots of those:
 
 http://img27.imageshack.us/img27/5827/screenshotwithnly.png
 Only OOo 3.2.1 installed.
 
 Now I install LibO - and in this case I installed LibORC2 just to be
 sure that the test is current. And this is the result:
 http://img825.imageshack.us/img825/4994/screenshotwithliborc2.png
 http://img408.imageshack.us/img408/9178/screenshotwithliborc22.png
 Notice that all references to OOo are now missing.
 
 So now I do the open with  browse to OOo swriter.exe and use that -
 guess what happens... the .doc file opens in LibO.
 
 As a test I rename the swriter.exe in C:\Program Files\OpenOffice.org
 3\program
 to ooowriter.exe
 and guess what happens when I use the choose program on the next go
 around? Yep, the .doc now opens with OOo. And guess what now shows up in
 the 'open with' dialog window... OOo:
 http://img69.imageshack.us/img69/4567/screenshotoootwrite.png
 
 I'm happy to swap stories/tests, but IMO the problem still exists,

Sorry, forgot to add the screenshot of where I'd changed OOo swriter.exe
to ooowriter.exe - here it is:
http://img194.imageshack.us/img194/93/screenshotooowriter.png

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


[Libreoffice] Annoying cursor behavior on sw tables

2010-12-23 Thread Octavio Alvarez


Hi, all.

There is this really annoying behavior:
0. Open Writer.
1. Create a table, say 3 x 3.
2. Place the cursor in a cell.
3. Type some text, like asdfasdfasdfasdf.
4. Using the mouse, place the cursor in the middle of the asdf-word.
5. Using the keyboard go left and right and left and right...

Notice how the cursor disappears. You don't know where exactly are you
at a particular moment.

This also happens when jumping cells, which becomes annoying if you
are fast-moving between the cells... suddenly you don't know where
you are.

It does not happen if left/right-ing on a regular paragraph. In that
case, the cursor stays on during the move. However, looking at the
code, it may happen on other cases.

I have managed to eliminate the issue by eliminating the following line:

diff --git a/sw/source/core/crsr/crsrsh.cxx
b/sw/source/core/crsr/crsrsh.cxx
index 5b92560..cbf39f3 100644
--- a/sw/source/core/crsr/crsrsh.cxx
+++ b/sw/source/core/crsr/crsrsh.cxx
@@ -344,7 +344,6 @@ BOOL SwCrsrShell::LeftRight( BOOL bLeft, USHORT nCnt,
USHORT nMode,
 if( IsTableMode() )
 return bLeft ? GoPrevCell() : GoNextCell();

-SwCallLink aLk( *this );// Crsr-Moves ueberwachen, evt. Link
callen
 BOOL bRet = FALSE;

 // #i27615# Handle cursor in front of label.

Beware of word wrapping. The word üeberwachen translated to monitor
using Google Translate.

Of course, I don't have the slightest idea of what an SwCallLink is or
does and what its side effects are.

I have tried to follow the call deeper, but I seem to get nowhere. Removing
lines start to behave inconsistently. In that function, aLk is not used, so
I'm starting to get the idea that it registers something instead of
creating
an object for use on the function, and so, the bug gets triggered by a
delayed, asynchronous action.

I have no choice but to request for help. :-)

This is the relevant part of the backtrace:

#0  SwCrsrShell::LeftRight (this=0xacaab1e8, bLeft=1 '\001', nCnt=1,
nMode=1, bVisualAllowed=1 '\001') at
~/$CLONE/writer/sw/source/core/crsr/crsrsh.cxx:344

#1  0xae3978fd in SwCrsrShell::Left (this=0xacaab1e8, nCnt=1, nMode=1,
bAllowVisual=1 '\001') at ../../../inc/crsrsh.hxx:356

#2  0xaecd90d8 in SwWrtShell::Left (this=0xacaab1e8, nMode=1, bSelect=0
'\000', nCount=1, bBasicCall=0 '\000', bVisual=1 '\001') at
~/$CLONE/writer/sw/source/ui/wrtsh/move.cxx:122

#3  0xaebf67e3 in SwTextShell::ExecBasicMove (this=0xaff04134, rReq=...)
at ~/$CLONE/writer/sw/source/ui/shells/txtcrsr.cxx:96

#4  0xaebe2f2c in SfxStubSwTextShellExecBasicMove (pShell=0xaff04134,
rReq=...) at ../../../unxlngi6.pro/inc/swslots.hxx:2408

#5  0xb73c3f38 in SfxShell::CallExec (this=0xaff04134, pFunc=0xaebe2f08
SfxStubSwTextShellExecBasicMove(SfxShell*, SfxRequest), rReq=...) at
../../inc/sfx2/shell.hxx:201

#6  0xb73bcd1c in SfxDispatcher::Call_Impl (this=0xacadeb94, rShell=...,
rSlot=..., rReq=..., bRecord=1 '\001') at
~/$CLONE/libs-core/sfx2/source/control/dispatch.cxx:281
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice] Bugzilla target information

2010-12-23 Thread Rainer Bielefeld

Hi,

can the developers please leave information concerning target version 
where they expect the fix to be integrated into a public build

due to
http://wiki.documentfoundation.org/BugReport_Details#Whiteboard?
That might avoid permanent reopening of a Bug if the fix has not ben 
integrated into the very next build.


Thanks

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