Re: [Libreoffice] css::table::BorderLine vs BorderLine2

2011-01-15 Thread David Tardon
On Fri, Jan 14, 2011 at 02:45:06PM +0100, Cédric Bosdonnat wrote:
 Hello David, all,
 
 I just saw this commit:
 http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=0d209ac289dd5c79da6950b4c01b0cec9b7fbe6d
 
 I would like to have no BorderLine object created, but only BorderLine2:
 this new BorderLine2 is here only because I couldn't change the API to
 add one more property to BorderLine. Creating BorderLine objects means
 skipping all the new border styles and the future ones I'm working on.
Yes, but css::table::BorderLine is used by css::table::TableBorder.

 
 David could you provide some more details on the initial bug you wanted
 to fix?
 

I noticed a missing color borders of a table in a docx file. Debugging
this lead to an exception in SwXCell::setPropertyValue for property
LeftBorder, caused by the fact that the value was of type
css::table::BorderLine. I further tracked this to
writerfilter::dmapper::DomainMapperTableHandler::endTableGetTableStyle,
where css::table::TableBorder's members (of type css::table::BorderLine,
not BorderLine2) were used as an intermediary for the property values
(incidentally, I forgot to push that part of the fix...)

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


Re: [Libreoffice] Change executable/sh names

2011-01-15 Thread Jesús Corrius
On Fri, Jan 14, 2011 at 12:59 PM, Michael Meeks
michael.me...@novell.com wrote:

 On Fri, 2011-01-14 at 02:37 -0800, plino wrote:
 Every time I update LibO or OOo (and like me most users who are experimenting
 with LibO but want to keep up with the currently more stable OOo) the file
 associations get messed up for the reasons explained by Jesús.

 Have the devs reached any decision on this?

        Didn't Jesus have a patch ? if so, we can merge it of course; it won't
 get into 3.3.0, but 3.3.1 might be a good target, failing that 3.4 I
 suppose.

I have made a full build with my patch, so anyone can test it. You can
download it here:

http://dl.dropbox.com/u/193133/LibO_3.3.0rc2_Win_x86_install_en-US.exe

This build is from the current master unstable branch, not the stable
3.3, but it doesn't matter as the only thing that has to be tested is
the installation and the file associations.

With those changes the user will be prompted to reboot the system in
many circumstances when OOo is also installed in the system (the same
will happen to OOo users who want both programs installed at the same
time) as there are now two different programs updating the same
registry values. Before people start complaining, this is the way
Windows works and I can't do nothing about it.

The sooner this build is properly tested, the faster the code will be
merged in the appropiate branches.

Thanks,

-- 
Jesús Corrius je...@softcatala.org
Document Foundation founding member
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Change executable/sh names

2011-01-15 Thread Jesús Corrius
On Fri, Jan 14, 2011 at 1:12 PM, plino pedl...@gmail.com wrote:

 Michael, please don't regard this as a personal complaint.

 I think many users who are currently using OOo will have this problem when
 they try LO (and update any of them).

 I think it's a bad idea to cause grievance to users who are giving it a go.
 IMO it will make them stick to OOo...

 Changing this now would be a wiser option.

 As I mentioned in a previous post, I can manually change the exe names to
 l*.exe (as long as I don't rename soffice.exe which must be fixed
 internally) without any loss in functionality. I think this proves that it's
 a minor change for the program but a major change for usability.

 Just my 2 cents.

No, it's not a minor change as there are also many changes in the
registry to be done.

And also it doesn't fix the problem that when you uninstall OOo, the
current LibO installation gets broken, which in my opinion is a lot
more serious than the file association.

-- 
Jesús Corrius je...@softcatala.org
Document Foundation founding member
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice] desktop menu entries broken without compat-oowrapper

2011-01-15 Thread Andreas Radke
The ArchLinux package does not use the --with-unix-wrapper=foo nor the
new --with-compat-oowrappers switches.

In RC3 the lo-wrapper changes seem to break stuff:

* startcenter seems ok,
* base,calc,impress,draw menu entries are shown but won't start oobase
  %U missing. their TryExec entry seems ok but the Exec entry needs to
  be changed to lo...
* math, template also need that Exec change though they are hidden
* writer,web have the proper Exec entry but the TryExec is the old
  oowriter that makes the menu not showing this entry


Why are these files installed? Are they of any use? They look very
different to the ones in /usr/share/applications/:

libreoffice /usr/lib/ooo-3.3/share/xdg/base.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/calc.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/draw.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/impress.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/javafilter.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/math.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/printeradmin.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/qstart.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/startcenter.desktop
libreoffice /usr/lib/ooo-3.3/share/xdg/writer.desktop

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


[Libreoffice] LibO Programmatic Identifier on Windows

2011-01-15 Thread Jesús Corrius
Hi all,

I guess this is the right list for this message. Don't worry, I will
not go into many technical details ;)

On Windows, every application has his own programmatic Identifier for
a concrete type of documents (or extension). The identifiers use the
following format acording the the Microsoft documentation:

ApplicationVendor.MyProgram.Version

Although this is obsolete as many programs now can open many different
kinds of documents. For example, this is the way Microsoft Word uses
them:

Word.Document.12 -- .doc files opened by Microsoft Word version 12
(Office 2007)
Word.OpenDocumentText.12 --  .odt files opened by Microsoft Word
version 12 (Office 2007)

In the case of OpenOffice.org, the identifier is this one (version
numbers are not used):

opendocument.WriterDocument.1 -- .odt files opened by OpenOffice.org
(any version).

(This identifier is wrong as it is too generic. But well, we can't do
anything about it)

We need our own identifier. For now I have been using this one for no reason:

libreoffice.WriterDocument.1

Cheers,

-- 
Jesús Corrius je...@softcatala.org
Document Foundation founding member
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Basic/newbie how to build questions

2011-01-15 Thread Rene Engelhard
On Sat, Jan 15, 2011 at 01:23:23AM +0100, Lionel Elie Mamane wrote:
 Hi,
 
 1)
 When I run ./autogen.sh with --enable-ext-FOO, it complains that
 extension is not there and asks me if I have downloaded the -ext
 tarball. But

That tarball doesn't exist, really.
This is now the extensions/ repository, and yes, ./download should have given
it to you.

But I didn't really do builds from master yet with all configure options..

 When the build fails, I get an icon in my notification area (and a
 pop-up). That's nice, but when the build fails a second time, a second
 icon is added, then a third, etc. Is there a better way to dismiss
 that icon than killall zenity? I use Xfce.

Yep, noticed that too. Not only that, afaics the icon doesn't vanish anymore
and can't be gotten rid of (even if the one build was successful)

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] desktop menu entries broken without compat-oowrapper

2011-01-15 Thread Rene Engelhard
On Sat, Jan 15, 2011 at 01:15:39PM +0100, Andreas Radke wrote:
 The ArchLinux package does not use the --with-unix-wrapper=foo nor the
 new --with-compat-oowrappers switches.

And apparently libreoffice-builds .desktop files and not those from sysui..

 * base,calc,impress,draw menu entries are shown but won't start oobase
   %U missing. their TryExec entry seems ok but the Exec entry needs to
   be changed to lo...
 * math, template also need that Exec change though they are hidden
 * writer,web have the proper Exec entry but the TryExec is the old
   oowriter that makes the menu not showing this entry

Maybe, I don't use them.

 Why are these files installed? Are they of any use? They look very
 different to the ones in /usr/share/applications/:
[...]

Without being able to have a look, that might be those from sysui, no?

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Change executable/sh names

2011-01-15 Thread plino

Jesús, thank you for the new build. Unfortunately it doesn't fix the problem.
Even if it did, the next time a user installs an OOo update wouldn't the
problem appear again? If you add your fix to LO only, OOo updates won't
unfix it?

I can't see any other permanent solution than renaming the exes...

BTW I have NEVER said it's a minor change. I'm just saying that it's better
to do this change sooner than later. 

And my only argument for changing this now is that I think the first
impression is really important.  If the first release is successful most
people will stick with LO from the beginning. 
-- 
View this message in context: 
http://nabble.documentfoundation.org/Change-executable-sh-names-tp2108193p2261836.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 31865] [Task]: LibreOffice 3.3 release blockers / stoppers

2011-01-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=31865

--- Comment #69 from Rainer Bielefeld libreoff...@bielefeldundbuss.de 
2011-01-15 07:09:30 PST ---
I nominate Bug 33151 - Onlinehelp: Danish and Hungarian contents

-- 
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 31865] [Task]: LibreOffice 3.3 release blockers / stoppers

2011-01-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=31865

Rainer Bielefeld libreoff...@bielefeldundbuss.de changed:

   What|Removed |Added

 Depends on||33151

-- 
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] [r...@debian.org: Re: desktop menu entries broken without compat-oowrapper]

2011-01-15 Thread Rene Engelhard
oops, wrong Cc ;)

- Forwarded message from Rene Engelhard r...@debian.org -

Date: Sat, 15 Jan 2011 16:38:15 +0100
From: Rene Engelhard r...@debian.org
To: Andreas Radke a.ra...@arcor.de
Cc: libreoff...@lists.debian.org
Subject: Re: [Libreoffice] desktop menu entries broken without
compat-oowrapper
Organization: The Debian Project
User-Agent: Mutt/1.5.20 (2009-06-14)

On Sat, Jan 15, 2011 at 04:31:07PM +0100, Andreas Radke wrote:
 Shouldn't they be removed at all then? I guess they are not used in
 LibO.

Well, *I* use the sysui ones, not the ones from libreoffice-build
(though of course not in share/xdg but in /usr/share/applications)

Besides that, plain LibreOffice is just without patches etc. anyway, so...

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70

- End forwarded message -

Grüße/Regards,

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


Re: [Libreoffice] desktop menu entries broken without compat-oowrapper

2011-01-15 Thread Christian Lohmaier
Hi *,

On Sat, Jan 15, 2011 at 4:31 PM, Andreas Radke a.ra...@arcor.de wrote:

 Right. Those seem to be identical to those in vanilla
 sysui/desktop/menu/*.desktop.

 Shouldn't they be removed at all then? I guess they are not used in

Why not replacing those in sysui instead?

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


Re: [Libreoffice] Change executable/sh names

2011-01-15 Thread Jesús Corrius
On Sat, Jan 15, 2011 at 3:59 PM, plino pedl...@gmail.com wrote:

 Jesús, thank you for the new build. Unfortunately it doesn't fix the problem.
 Even if it did, the next time a user installs an OOo update wouldn't the
 problem appear again? If you add your fix to LO only, OOo updates won't
 unfix it?

Yes, that's my primary purpose: that other updates don't unfix it.
Installing the build and then OOo 3.3 works fine for me.

We are going into the right direction, but it seems it's not ready
yet. What scenario are you testing?


 I can't see any other permanent solution than renaming the exes...

Unfortunately this will only fixes part of the problem. And also it's
different to rename the exes when the program is already installed
than installing the exes with different names. And an update will
unfix everything.

 BTW I have NEVER said it's a minor change. I'm just saying that it's better
 to do this change sooner than later.

 And my only argument for changing this now is that I think the first
 impression is really important.  If the first release is successful most
 people will stick with LO from the beginning.

I agree with that.

I will post another build today night or tomorrow.

-- 
Jesús Corrius je...@softcatala.org
Document Foundation founding member
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[Libreoffice] [PUSHED] Re: [Patch] Cppcheck cleaning on dbaccess

2011-01-15 Thread Caolán McNamara
On Sat, 2011-01-15 at 00:03 +0100, Julien Nabet wrote:
 Hello,
 
 Here is a small patch for  Cppcheck cleaning on dbaccess

Looks good, pushed, thanks for this.

 Question :
 In the last git-updated cppcheck I use, i found this in core part of 
 dbaccess :
 [./api/query.cxx:310]: (error) instance of OAutoActionReset object 
 destroyed immediately


 I took a look and I don't understand what's the use of this class.
 in query.cxx, we have this :

 Could someone explain the meaning of all this ?

Well, first off, if
OAutoActionReset(this);
is changed to 
OAutoActionReset aResetter(this);
does the warning go away ?

I believe the intent is that an OAutoActionReset will set
m_eDoingCurrently to NONE in its dtor, so the idea is that when an
OAutoActionReset goes out of scope that dtor gets called, which would
mean that m_eDoingCurrently gets reset after the if ends in the normal
course of things.

*Or* if an exception is thrown, seeing as dtors are called when an
exception is thrown, which is probably the real meat of the construct,
i.e. make sure to reset m_eDoingCurrently to NONE when this scope ends
whether on epic failure or not

C.

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


Re: [Libreoffice] [Patch] Remove some dead code in sc

2011-01-15 Thread Caolán McNamara
On Sat, 2011-01-15 at 01:01 +0100, Julien Nabet wrote:
 Here is a small patch for dead code cleaning on sc

Looks good, pushed, thanks for this.

C.

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


[Libreoffice] [PATCH] partial easy hack - removal of non-compiled / dead code in sc

2011-01-15 Thread Ed Dean
Trying to keep up with the changes a little better by sending smaller
files.  Hope I didn't mess up this diff as I'm new to git, and I had
to stash to pull in some upstream changes.  Please review!

This is my first attempt at the sc/source/core/tool directory.

Hopefully the diff is attached below properly, but if not it should be
available at the following url for a few days:

http://dl.dropbox.com/u/18377756/topround_20110115_diff.txt

On another note, is there an automated test suite?  If so, I'd love to
know how to kick it off after I make changes.

Regards,


PS: hopefully my name shows up in the email address now, but Topround is fine :)
diff --git a/sc/source/core/tool/addincol.cxx b/sc/source/core/tool/addincol.cxx
old mode 100644
new mode 100755
index 2bc3760..73959cd
--- a/sc/source/core/tool/addincol.cxx
+++ b/sc/source/core/tool/addincol.cxx
@@ -318,37 +318,33 @@ void ScUnoAddInCollection::Initialize()
 while ( xEnum-hasMoreElements() )
 {
 uno::Any aAddInAny = xEnum-nextElement();
-//? if ( aAddInAny.getReflection()-getTypeClass() == 
uno::TypeClass_INTERFACE )
-{
-uno::Referenceuno::XInterface xIntFac;
-aAddInAny = xIntFac;
-if ( xIntFac.is() )
-{
-// #i59984# try XSingleComponentFactory in addition to 
(old) XSingleServiceFactory,
-// passing the context to the component
-
-uno::Referenceuno::XInterface xInterface;
-uno::Referenceuno::XComponentContext xCtx = 
getContext(xManager);
-uno::Referencelang::XSingleComponentFactory xCFac( 
xIntFac, uno::UNO_QUERY );
-if (xCtx.is()  xCFac.is())
-{
-xInterface = 
xCFac-createInstanceWithContext(xCtx);
-if (xInterface.is())
-ReadFromAddIn( xInterface );
-}
-
-if (!xInterface.is())
-{
-uno::Referencelang::XSingleServiceFactory xFac( 
xIntFac, uno::UNO_QUERY );
-if ( xFac.is() )
-{
-xInterface = xFac-createInstance();
-if (xInterface.is())
-ReadFromAddIn( xInterface );
-}
-}
-}
-}
+   uno::Referenceuno::XInterface xIntFac;
+   aAddInAny = xIntFac;
+   if ( xIntFac.is() )
+   {
+   // #i59984# try XSingleComponentFactory 
in addition to (old) XSingleServiceFactory,
+   // passing the context to the component
+   uno::Referenceuno::XInterface 
xInterface;
+   uno::Referenceuno::XComponentContext 
xCtx = getContext(xManager);
+   
uno::Referencelang::XSingleComponentFactory xCFac( xIntFac, uno::UNO_QUERY );
+   if (xCtx.is()  xCFac.is())
+   {
+   xInterface = 
xCFac-createInstanceWithContext(xCtx);
+   if (xInterface.is())
+   ReadFromAddIn( 
xInterface );
+   }
+
+   if (!xInterface.is())
+   {
+   
uno::Referencelang::XSingleServiceFactory xFac( xIntFac, uno::UNO_QUERY );
+   if ( xFac.is() )
+   {
+   xInterface = 
xFac-createInstance();
+   if (xInterface.is())
+   ReadFromAddIn( 
xInterface );
+   }
+   }
+   }
 }
 }
 }
@@ -715,9 +711,6 @@ BOOL lcl_ValidReturnType( const 
uno::Referencereflection::XIdlClass xClass )
 
 switch (xClass-getTypeClass())
 {
-// case uno::TypeClass_VOID:
-//  ???
-
 case uno::TypeClass_ANY:// variable type
 case uno::TypeClass_ENUM:   //! ???
 case uno::TypeClass_BOOLEAN:
diff --git a/sc/source/core/tool/addinlis.cxx b/sc/source/core/tool/addinlis.cxx
old mode 100644
new mode 100755
index 

[Libreoffice] [PUSHED] + review requests i#116187: report left/right page margin setting ignored on Unix 64 bit

2011-01-15 Thread Caolán McNamara
On Sat, 2011-01-15 at 05:59 +0100, Lionel Elie Mamane wrote:
 Does not fit release blocker criteria, but would still be *very* nice
 to have for the release, as it easily fixes / papers over a rather
 annoying / stupid (from the user's point of view) bug:

I pushed this to master and to the stable 3-3 branch, thanks for this.
We'd need some more acks for 3-3-0 however, I'm +1 on that.

 This may not be the real fix attacking the root cause, but it at
 least hides the problem for the user.

Yeah, its the right fix. The properties are sal_Int32, though the
underlying impl supports longs there. 

C.

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


[Libreoffice] [FIXED] Re: debug build fails because graphite ./configure not up to date

2011-01-15 Thread Caolán McNamara
On Sat, 2011-01-15 at 00:43 +0100, Lionel Elie Mamane wrote:
 Hi,
 
 A build with --enable-debug (or is it --enable-dbgutil?) fails in
 graphite... for a problem already corrected in graphite's
 configure.ac, but its configure is outdated and thus the problem
 still surfaces.

Ah, I see. So I've now added a patch into that graphite module to sync
the configure.ac logic into configure.

 Before I got to the point of trying to disable -Werror (and
 understanding why it was enabled in the first place), I fixed one of
 the warnings. Patch attached, still does not hurt to apply janitorialy
 :)

Well, we do occasionally patch those external modules, but try to
avoid it. The ideal place to send patches to graphite would be to the
upstream graphite project and poke them to release a new update at some
stage and then just upgrade to the latest graphite.

We're behind in quite a few modules from the leading edge, we should get
up to date in more of them, e.g. hunspell, icu, hyphen, etc. and try and
reduce the custom patching.

C.

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


Re: [Libreoffice] Build install for DEBS

2011-01-15 Thread Andy Brown

On Fri Jan 14 2011 23:16:21 GMT-0800 (PST)  Jonathan Aquilina wrote:

Icecream allows you to spread the compile across multiple machines.



Thanks for the information.  Icecream will do me no good as my main 
machine is the only one that has the processing power to do the 
compiling.  What I really need to find out is how to make an install 
package, deb, so that I can put what I have on another machine for 
testing and use.


Andy

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


Re: [Libreoffice] [FIXED] Re: debug build fails because graphite ./configure not up to date

2011-01-15 Thread Khaled Hosny
On Sat, Jan 15, 2011 at 08:16:55PM +, Caolán McNamara wrote:
 On Sat, 2011-01-15 at 00:43 +0100, Lionel Elie Mamane wrote:
  Hi,
  
  A build with --enable-debug (or is it --enable-dbgutil?) fails in
  graphite... for a problem already corrected in graphite's
  configure.ac, but its configure is outdated and thus the problem
  still surfaces.
 
 Ah, I see. So I've now added a patch into that graphite module to sync
 the configure.ac logic into configure.
 
  Before I got to the point of trying to disable -Werror (and
  understanding why it was enabled in the first place), I fixed one of
  the warnings. Patch attached, still does not hurt to apply janitorialy
  :)
 
 Well, we do occasionally patch those external modules, but try to
 avoid it. The ideal place to send patches to graphite would be to the
 upstream graphite project and poke them to release a new update at some
 stage and then just upgrade to the latest graphite.

BTW, Graphite engine is being re-written into a more stable engine (the
current engine is crashy, or so I read), so it might be a good time to
consider switching over to the new engine.

Regards,
 Khaled

-- 
 Khaled Hosny
 Arabic localiser and member of Arabeyes.org team
 Free font developer
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Change executable/sh names

2011-01-15 Thread plino

I'm afraid it's not fixed yet. I think the problem is that e.g. ODS is
associated with OOo's scalc as the default application and to LibO's scalc
as an alternate program. These are not stored in the SAME registry Key. 

For xls which is associated with MS Excel (on my system),  both OOo and LibO
are alternate programs. Since there can be only one entry for scalc.exe in
Open With there seems to be no way around this (at least for people who are
still holding to MS Office, that is)
-- 
View this message in context: 
http://nabble.documentfoundation.org/Change-executable-sh-names-tp2108193p2264164.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] [PATCH] ./configure after . *-Env.Set.sh

2011-01-15 Thread Lionel Elie Mamane
In this situation:
 the only db.h on the system is /usr/include/db.h (that is, no db$ver/db.h)
 AND
 ./configure previously called with --with-system-db (or --with-system-libs)
 AND
 The -Env.set.sh file has been sourced in the current shell.
then:
 ./configure --with-system-db
fails saying that db is older than 4.1.

That is because DB_INCLUDES envvar is set by the -Env.set.sh file, and
this disables looking for /usr/include/db.h.

The attached patch uses the db_header shell variable instead to detect
whether a db$vver/db.h has been found and to enable or disable looking
for /usr/include/db.h.

-- 
Lionelx
From 702babf4e4d3f5c36c7dc535ce2a8790b2d10d87 Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane lio...@mamane.lu
Date: Sun, 16 Jan 2011 01:13:32 +0100
Subject: [PATCH] Make configure still work after Env.Set.sh

---
 configure.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.in b/configure.in
index c4982cb..bb8302f 100755
--- a/configure.in
+++ b/configure.in
@@ -4351,7 +4351,7 @@ if test -n $with_system_db -o -n $with_system_libs  \
 AC_MSG_RESULT([no])
 done
 
-if test $DB_INCLUDES = ; then
+if test $db_header = ; then
AC_CHECK_HEADER(db.h, [ DB_INCLUDES=/usr/include; db_header=db.h ],
[ AC_MSG_ERROR(no. install the db4-dev package) ])
 fi
-- 
1.7.2.3

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


Re: [Libreoffice] ICU bloat ...

2011-01-15 Thread Samphan Raruenrom
You can easily minimize the ICU footprint by tweaking the ICU build options.
See http://userguide.icu-project.org/packaging
http://userguide.icu-project.org/packagingThe result will be like this -
http://site.icu-project.org/charts/icu4c-footprint
 http://site.icu-project.org/charts/icu4c-footprint

On Fri, Jan 14, 2011 at 7:27 PM, Michael Meeks michael.me...@novell.comwrote:

 Hi there,

 On Fri, 2011-01-07 at 12:22 -0600, Norbert Thiebaud wrote:
  Which makes me wonder: do we really need everything that is in
 that
   beast ? pmap seems to suggest we use 84K out of the 13Mb on Linux:
 
  Michael: icudata contains, among other things all the supported
  utf16-other-codepage convertion. If your locale is utf8 or iso8859-1/15
  (which is most likely in your case) then sure you just need one or two
  of these conversion table... if any at all (some convertion like
  utf8-utf16 are algorithmic)

Sure. We have a patch for sal:


 http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/size-sal-textenc.diff

sadly still not merged, since it needs re-testing on win32 - that
 chops
 a megabyte of this off of sal (exactly the same text encoding conversion
 tables).

  libicudata also contains stuff about collation and locales...

Right - but it also seems that some (much?) of this data is not
 actually used :-) AFAICS we don't use the charset conversion data at
 all, preferring the sal stuff. There are whole fields of API that are
 simply not touched from ICU:

'ucnv_' (char set conversion !?)
'ures_'
'unorm_'
'utrans_'
'u_shapeArabic'

So - I suspect we could hack some big chunks of code, and data out
 of
 this: the data is the biggest evil size-wise from a distribution
 perspective I suspect: 5.5Mb compressed of our win32 download is data we
 don't use [ one of the bigger lumps of pointlessness there ].

  either way libicudata is big, but there is not that much redundancy in
  it. it just covert and insanely large number of code page (

sure sure :-) and we don't need that AFAICS, since we don't use the
 relevant APIs; and our internal ICU does not have to be a generic useful
 resource for abstract programs (particularly on Win32).

So I added an easy hack here:


 http://wiki.documentfoundation.org/Development/Easy_Hacks#de-bloat_internal_ICU

Thanks,

Michael.

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


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




-- 
_/|\_ Samphan Raruenrom. Open Source Development Co., Ltd.
Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Build install for DEBS

2011-01-15 Thread Jonathan Aquilina
Not sure what distro you use, but if you use irc on freenode they have a 
packaging channel for ubuntu called #ubuntu-packaging if that will help 
any. if not you could probably find Debian help on the oftc irc network 
channel #Debian


On 1/15/11 10:34 PM, Andy Brown wrote:

On Fri Jan 14 2011 23:16:21 GMT-0800 (PST)  Jonathan Aquilina wrote:

Icecream allows you to spread the compile across multiple machines.



Thanks for the information.  Icecream will do me no good as my main 
machine is the only one that has the processing power to do the 
compiling.  What I really need to find out is how to make an install 
package, deb, so that I can put what I have on another machine for 
testing and use.


Andy



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