Re: [Libreoffice] [PATCH] set RPATH correctly in the internal ICU
Hi Petr, At first glance it looks OK to me, but I'm no build script expert... I may have missed some important stuffs. -- Cedric On Wed, 2011-01-05 at 20:22 +0100, Petr Mladek wrote: Hi, our build service found broken RPATH in libicudata.so.42.1; it is fixed by the attached patch Cedric, could you please sign it off for libreoffice-3-3. It works well on Linux with bash. I think that it can't be worse on other systems ;-) Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Re: Annoying cursor behavior on sw tables
Hello Octavio, I just checked again the problem I remembered and couldn't reproduce it again... let's agree that it's OK. We could hack that area again if someone finds it again later. I just pushed your patch, many thanks for your help and continue with those great contributions :) Regards, On Mon, 2011-01-03 at 09:00 -0800, Octavio Alvarez wrote: On Mon, 03 Jan 2011 01:52:01 -0800, Cedric Bosdonnat cbosdon...@novell.com wrote: The thing is that Window::Invalidate() gets called if I move or if I type inside a table cell, which almost any key triggers, which is wrong. bUpdatedTable gets set to True inside SwCallLink::~SwCallLink() after some tests. Another option would be to correct those tests, but that would be far beyond my knowledge. The problem I tried to fix was that the whole row wasn't redrawn in some cases... I can't remember those for sure now but it was something like that: Make sure to have tables like this: +-+---+ |+---+| | || || | |+---+| | | | | +-+---+ Place your cursor in the right cell and go to the left: the cursor should go in the blank paragraph after the nested cell and show it. In that kind of cases some part of the border of the right cell wasn't redrawn IIRC. Did you test with a case similar to the one above? Well, I did try several different combinations including different column sizes and nesting levels. The case you point out was also tested and I just retested it now. It works. I would say it performs better. In the patch included I also remove all uses and declaration of bUpdatedTable because it was only used on the removed if(). -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] BrOffice RC2
Hi Andras, On Wed, 2011-01-05 at 16:55 +0100, Andras Timar wrote: Have you also solved https://bugs.freedesktop.org/show_bug.cgi?id=32389 (MSI installer is always in English regardless of regional settings in Windows)? Actually a dup of an existing blocker: https://bugs.freedesktop.org/show_bug.cgi?id=32435 really, our last real / repeatable blocker. I've outlined an (easy) suggested solution in there, which requires some more de-branded artwork - which shouldn't be so hard. I hope to get it closed today. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Petr Mladek pmla...@suse.cz changed: What|Removed |Added Depends on|31820 | --- Comment #52 from Petr Mladek pmla...@suse.cz 2011-01-06 02:55:50 PST --- Removing the bug #31820. The extensions registration fails only in some strange circumstances. It does not affect the base function... -- 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] Localizations of UI and help - what languages does LibO support?
2010/12/29 Andras Timar tima...@gmail.com Hi, I tested RC2 in regards of localization and I think it needs to be reviewed. 110 languages (including en-US) are selectable as UI language and help packs are provided for those. However, * Asturian (ast), Catalan (Valencian) (ca-XV), and Indonesian (id) are not included. Asturian and Catalan (Valencian) are especially important, because they are actively participating in LibreOffice localization. * Gaelic (Scots) (gd), Kirghiz (ky), Lao (lo), Malay (ms), Papiamento (pap), Pushto (ps), ??? (sc), Tigrinya (ti), and Urdu (ur) are included despite the fact that in the source there are no translations at all in these languages, so you basically package en-US strings. Gaelic (Scots) (gd) translation exists at ftp://ftp.linux.cz/pub/localization/OpenOffice.org/devel/build/Files/OOO330/GSI_gd.sdf.bz2- maybe it can be added. * It makes no sense to provide help pack for those languages which have 0% of the help translated. See this table for reference: http://wiki.documentfoundation.org/Translation_for_3_3#Language_pack_.2F_Help_pack_coverage This table was made from the RC2 sources. Best regards, Andras Nobody answered, maybe you missed my mail between Christmas and New Year. Missing Asturian language pack is also reported in Bugzilla. https://bugs.freedesktop.org/show_bug.cgi?id=32193 Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed dependencies on tools/solar.h in drawpage.hxx/.cxx
On Wed, 2011-01-05 at 19:56 +0100, Soeren Moeller wrote: It is not an attachment as I used git send-email Heh - the kernel guys prefer in-line patches it seems; they find them easier to review and comment on that way; personally - I don't care, its easy enough to save a file as an mbox and throw it at either patch or git-am ;-) but - worth pleasing Kohei of course. thanks for your nice work ! ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Remove DECLARE_LIST( EditList, AppWIn*)
On Wed, Jan 05, 2011 at 11:05:02AM +, Noel Power wrote: Hi Joseph On -10/01/37 20:59, Joseph Powers wrote: The attached patch compiles and stands up to my limited testing; however, it's a large patch and touches a lot of sensitive code so I want someone with better knowledge of the Basic Macro Editor environment to review test it before I try pushing it. Thanks, Joe P. I wouldn't claim to have much knowledge of the Basic Macro editor but I suppose at least I have touched it in the past ;-) Firstly congratulations on this is great work, getting rid of those horrific macro lists and replacing with something more modern surely will make things easier for new developers to understand. As far as I can see the changes as they stand shouldn't cause any problems and could be committed. My only comment would be that mostly the opportunity to simplify the code using the power of the vector has not being taken advantage of which is a pity ( and would be great to fix here ) e.g. @@ -627,17 +627,15 @@ void BasicFrame::LoadIniFile() if ( pBasic ) pBasic-LoadIniFile(); -for ( i = 0 ; i pList-Count() ; i++ ) -pList-GetObject( i )-LoadIniFile(); +for ( i = 0 ; i pList-size() ; i++ ) +pList-at( i )-LoadIniFile(); } Another nitpick: std::vector::at (as opposed to std::vector::operator[]) checks its argument and throws an exception if it is out of bounds. This check is absolutely useless inside a loop (well, unless the end condition is wrong) and only adds to run time. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Andras Timar tima...@gmail.com changed: What|Removed |Added Depends on||32563, 32193 --- Comment #54 from Andras Timar tima...@gmail.com 2011-01-06 03:57:53 PST --- Added License Dialog Added missing langpacks -- 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] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Phil, On Wed, 2011-01-05 at 13:19 -0500, Phil Turmel wrote: :-) so - as I say; the DPI is a constant of 75 across the Linux desktop, so this is not a switch but a hard coded setting :-) I think you are over-reaching here: :-) So - I'm talking the Xft.dpi setting which is used by GNOME and LibreOffice; cf. $ xrdb | grep Xft scorpius pturmel ~ $ xdpyinfo | egrep (dimensions|dots per inch) dimensions:3600x1080 pixels (905x272 millimeters) resolution:101x101 dots per inch Sure; and these numbers have (traditionally) been notorious for their unreliability - but perhaps that has improved in recent times. Thanks though :-) Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set RPATH correctly in the internal ICU
On Thu, 2011-01-06 at 09:47 +, Michael Meeks wrote: On Wed, 2011-01-05 at 20:13 +, Caolán McNamara wrote: On Wed, 2011-01-05 at 20:22 +0100, Petr Mladek wrote: our build service found broken RPATH in libicudata.so.42.1 That libicudata is the biggest nuisance, causes all sorts of problems on different platforms. Rather an odd use of an elf file as data storage IIRC and manually created by icu rather than by the normal compiler +linker chain. It is also huge; the biggest single files we have in our install (on Windows at least): I *think* icu can be configured to use a different format for the icudata, I've never tried this, but fiddling configure options for it might cause some different format to be generated, which at least for testing/dumping purposes might be easier to work with. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] icons - we should use the native theme's icon size by default.
Hi guys, On Wed, 2011-01-05 at 18:59 +0100, Christian Lohmaier wrote: On GNOME it follows the theme, wich in turn follows the gconf-setting /desktop/gnome/interface/toolbar_icons_size Right - which should be propagated via x-settings and magic to avoid the need for a gconf dependency. Thanks Christian for digging that out. so whatever your theme defines in the gtk-icon-sizes property will be used. Right; we should hook out and use this in salnativewidgets-gtk.c if that is not so, lets add an easy hack for it, or perhaps someone can jump in with some code of this form to decisively end the discussion :-) NB. this will still be only for the Automatic / default setting - the user can override it easily. 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] [PATCH] set the icons size based on the DPI just like we do on Mac
On Wednesday 05 of January 2011, Robert Nagy wrote: Oh well then Linux is broken, again. :) In gedit the icons are bigger than the small ones but not as huge as in LibreOffice. Here you can see (LO with small icons): http://blade2k.humppa.hu/2011-01-05-182917_1920x1080_scrot.png (ws robert 22435)$ xdpyinfo | egrep (dimensions|dots per inch) dimensions:1920x1080 pixels (518x291 millimeters) resolution:94x94 dots per inch It is strange for me tho that linux *hardcodes* 75. Where is taht hardcoded? I think that is the default value for X.Org if it can't find out the real value from the hardware or configuration options. Normally X should find out the real DPI, although desktops also have options for various misguided attempts at forcing a specific DPI. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Localizations of UI and help - what languages does LibO support?
Hi Andras, On Thu, 2011-01-06 at 12:14 +0100, Andras Timar wrote: Nobody answered, maybe you missed my mail between Christmas and New I read it, and added it to my mail of things for Fridrich to sort out when he gets back on Monday ;-) Missing Asturian language pack is also reported in Bugzilla. https://bugs.freedesktop.org/show_bug.cgi?id=32193 Great, the way to get attention best is to add it to the blocker bug, which I believe you've now done ? :-) 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] [PATCH] use libreoffice and lo* wrappers
On Wed, Jan 05, 2011 at 07:59:06PM +0100, Petr Mladek wrote: Rene, could you please review it for libreoffice-3-3 branch? Looks OK, but why did you leave oo* in? package-ooo still generates it. Regards, Rene ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] use libreoffice and lo* wrappers
On Thu, Jan 06, 2011 at 02:13:44PM +0100, Rene Engelhard wrote: On Wed, Jan 05, 2011 at 07:59:06PM +0100, Petr Mladek wrote: Rene, could you please review it for libreoffice-3-3 branch? Looks OK, but why did you leave oo* in? package-ooo still generates it. To answer myself after discussion on IRC, compat with old habits calling oowriter etc. Pushed. 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] Oracle wordbook in LibO
On 01/05/2011 06:28 PM, Petr Mladek wrote: Kálmán „KAMI” Szalai píše v St 05. 01. 2011 v 17:39 +0100: Hi! 2011-01-05 17:01 keltezéssel, Petr Mladek írta: Ah, we use Novell.dic in our build. It includes just language-independent names of Novell products, so it should not cause any harm to anyone. I attached different patches to the issue. KAMI, could you please review them? Can we introduce here some other technical, and distibution related files here, not just Novell related, words from Ubuntu, Debian, etc. I think we should have only one extra dic file, or is is a performance killer thing? Great idea! I would call it technical.dic or so. KAMI, could you please cook up something? Best Regards, Petr May we include vendor specific sfuffs from oracle.dic? http://cgit.freedesktop.org/libreoffice/extras/commit/?h=libreoffice-3-3id=7fbdfd0a0d2af30af92839ebf8bcf97c465519e8 KAMI signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix passing distro specific branding via configure
Thank you for the patch :o) KAMI On 01/05/2011 07:46 PM, Petr Mladek wrote: Hi, the configure options --with-intro-bitmaps, --with-about-bitmaps did not longer worked. I think that nobody needs more pictures. The attached patches rename the above options to pass only one picture and fix the stuff to work. KAMI, could you sign it off for libreoffice-3-3 branch? Best Regards, Petr signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Oracle wordbook in LibO
Kálmán „KAMI” Szalai píše v Čt 06. 01. 2011 v 15:40 +0100: On 01/05/2011 06:28 PM, Petr Mladek wrote: Kálmán „KAMI” Szalai píše v St 05. 01. 2011 v 17:39 +0100: Hi! 2011-01-05 17:01 keltezéssel, Petr Mladek írta: Ah, we use Novell.dic in our build. It includes just language-independent names of Novell products, so it should not cause any harm to anyone. I attached different patches to the issue. KAMI, could you please review them? Can we introduce here some other technical, and distibution related files here, not just Novell related, words from Ubuntu, Debian, etc. I think we should have only one extra dic file, or is is a performance killer thing? Great idea! I would call it technical.dic or so. KAMI, could you please cook up something? Best Regards, Petr May we include vendor specific sfuffs from oracle.dic? http://cgit.freedesktop.org/libreoffice/extras/commit/?h=libreoffice-3-3id=7fbdfd0a0d2af30af92839ebf8bcf97c465519e8 Looks good to me. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Got an error while compiling latest libreoffice code
Entering /home/grega/osebno/source/libo/sc/source/core/data Compiling: sc/source/core/data/conditio.cxx /home/grega/osebno/source/libo/clone/calc/sc/source/core/data/conditio.cxx: In function 'BOOL lcl_IsDuplicate(ScDocument*, double, const String, const ScAddress, const ScRangeListRef)': /home/grega/osebno/source/libo/clone/calc/sc/source/core/data/conditio.cxx:748: error: 'class ScRangeList' has no member named 'Count' /home/grega/osebno/source/libo/clone/calc/sc/source/core/data/conditio.cxx:751: error: 'class ScRangeList' has no member named 'GetObject' ../../../inc/address.hxx: At global scope: ../../../inc/address.hxx:80: warning: 'SCCOLROW_MAX' defined but not used ../../../inc/address.hxx:81: warning: 'SCSIZE_MAX' defined but not used ../../../inc/address.hxx:105: warning: 'SC_TAB_APPEND' defined but not used ../../../inc/address.hxx:106: warning: 'TABLEID_DOC' defined but not used ../../../inc/address.hxx:108: warning: 'SCCOL_REPEAT_NONE' defined but not used ../../../inc/address.hxx:109: warning: 'SCROW_REPEAT_NONE' defined but not used dmake: Error code 1, while making '../../../unxlngx6.pro/slo/conditio.obj' Forcing regeneration of dependency info Retrying /home/grega/osebno/source/libo/sc/source/core/data Making:all_data.dpslo Compiling: sc/source/core/data/conditio.cxx /home/grega/osebno/source/libo/clone/calc/sc/source/core/data/conditio.cxx: In function 'BOOL lcl_IsDuplicate(ScDocument*, double, const String, const ScAddress, const ScRangeListRef)': /home/grega/osebno/source/libo/clone/calc/sc/source/core/data/conditio.cxx:748: error: 'class ScRangeList' has no member named 'Count' /home/grega/osebno/source/libo/clone/calc/sc/source/core/data/conditio.cxx:751: error: 'class ScRangeList' has no member named 'GetObject' ../../../inc/address.hxx: At global scope: ../../../inc/address.hxx:80: warning: 'SCCOLROW_MAX' defined but not used ../../../inc/address.hxx:81: warning: 'SCSIZE_MAX' defined but not used ../../../inc/address.hxx:105: warning: 'SC_TAB_APPEND' defined but not used ../../../inc/address.hxx:106: warning: 'TABLEID_DOC' defined but not used ../../../inc/address.hxx:108: warning: 'SCCOL_REPEAT_NONE' defined but not used ../../../inc/address.hxx:109: warning: 'SCROW_REPEAT_NONE' defined but not used dmake: Error code 1, while making '../../../unxlngx6.pro/slo/conditio.obj' -- Grega Fajdiga Hacquetova 5 1113 Ljubljana Slovenia GSM: +386 40 923 635 E-pošta: gregor.fajd...@guest.arnes.si ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Got an error while compiling latest libreoffice code
On Thu, 2011-01-06 at 17:04 +0100, Grega Fajdiga wrote: Entering /home/grega/osebno/source/libo/sc/source/core/data Compiling: sc/source/core/data/conditio.cxx /home/grega/osebno/source/libo/clone/calc/sc/source/core/data/conditio.cxx: In function 'BOOL lcl_IsDuplicate(ScDocument*, double, const String, const ScAddress, const ScRangeListRef)': /home/grega/osebno/source/libo/clone/calc/sc/source/core/data/conditio.cxx:748: error: 'class ScRangeList' has no member named 'Count' Yes, this was broken earlier today for a few hours. Should be fixed again now if you ./g pull again. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removed dependencies on tools/solar.h in drawpage.hxx/.cxx
On Thu, 2011-01-06 at 11:27 +, Michael Meeks wrote: On Wed, 2011-01-05 at 19:56 +0100, Soeren Moeller wrote: It is not an attachment as I used git send-email Heh - the kernel guys prefer in-line patches it seems; they find them easier to review and comment on that way; personally - I don't care, its easy enough to save a file as an mbox and throw it at either patch or git-am ;-) Ah ok. Fair enough. ;-) but - worth pleasing Kohei of course. Nah, I didn't mean to set a rule that all patches must be attachments. Rather, I was just curious because his last patch was an attachment and this one wasn't. It's fine by me as long as I can save the email itself and 'git am' works fine with that. Let's be flexible. I'm sure it's easier to just run 'git send-mail' than sending a patch as an attachment which is an extra step. :-) (though that means I need to avoid using the attachment symbols to look for incoming patches, but I can adopt.) Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] sign off for cherry-pick fix for crash on exit after using search in calc
i.e. see bug: https://bugzilla.redhat.com/show_bug.cgi?id=666088 for
details.
Attached is the proposed fix. Don't let the fancy-pants rtl::Static put
you off, its just making the maCache from a global to a static local.
Globals/static locals have their dtors called in reverse order of the
completion of their ctors. Leaving the complex global at its current
scope means it gets shutdown too late on final dlclose of libunotools,
at a point after which all the runtime structure that it needs has been
shutdown. Changing it to a local static ensures it gets dtored before
that.
C.
From b79c4f7daf165e4190b12a19382f4e5615b43163 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= caol...@redhat.com
Date: Thu, 6 Jan 2011 17:05:14 +
Subject: [PATCH] Resolves: rhbz#666088 clean up search cache singleton in correct order
---
unotools/inc/unotools/textsearch.hxx |9
unotools/source/i18n/textsearch.cxx | 37 +
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/unotools/inc/unotools/textsearch.hxx b/unotools/inc/unotools/textsearch.hxx
index 0aaa123..16ae82f 100644
--- a/unotools/inc/unotools/textsearch.hxx
+++ b/unotools/inc/unotools/textsearch.hxx
@@ -128,15 +128,6 @@ public:
class UNOTOOLS_DLLPUBLIC TextSearch
{
-struct CachedTextSearch
-{
-::osl::Mutex mutex;
-::com::sun::star::util::SearchOptions Options;
-::com::sun::star::uno::Reference ::com::sun::star::util::XTextSearch xTextSearch;
-};
-
-static CachedTextSearch maCache;
-
static ::com::sun::star::uno::Reference ::com::sun::star::util::XTextSearch
getXTextSearch( const ::com::sun::star::util::SearchOptions rPara );
diff --git a/unotools/source/i18n/textsearch.cxx b/unotools/source/i18n/textsearch.cxx
index 8f8f780..8085045 100644
--- a/unotools/source/i18n/textsearch.cxx
+++ b/unotools/source/i18n/textsearch.cxx
@@ -36,6 +36,7 @@
#include unotools/charclass.hxx
#include comphelper/processfactory.hxx
#include unotools/textsearch.hxx
+#include rtl/instance.hxx
using namespace ::com::sun::star::util;
using namespace ::com::sun::star::uno;
@@ -86,13 +87,6 @@ SearchParam::SearchParam( const SearchParam rParam )
nTransliterationFlags = rParam.nTransliterationFlags;
}
-// Klasse zum Suchen eines Strings in einem Text. Es wird genau nach
-// dem String gesucht.
-// ( Die Unterscheidung der Gross/Klein-Schreibung kann mit einen Flag
-// unterdrueckt werden )
-
-TextSearch::CachedTextSearch TextSearch::maCache;
-
static bool lcl_Equals( const SearchOptions rSO1, const SearchOptions rSO2 )
{
return rSO1.algorithmType == rSO2.algorithmType
@@ -108,27 +102,42 @@ static bool lcl_Equals( const SearchOptions rSO1, const SearchOptions rSO2 )
rSO1.transliterateFlags == rSO2.transliterateFlags;
}
+namespace
+{
+struct CachedTextSearch
+{
+::osl::Mutex mutex;
+::com::sun::star::util::SearchOptions Options;
+::com::sun::star::uno::Reference ::com::sun::star::util::XTextSearch xTextSearch;
+};
+
+struct theCachedTextSearch
+: public rtl::Static CachedTextSearch, theCachedTextSearch {};
+}
+
ReferenceXTextSearch TextSearch::getXTextSearch( const SearchOptions rPara )
{
-osl::MutexGuard aGuard(maCache.mutex);
+CachedTextSearch rCache = theCachedTextSearch::get();
+
+osl::MutexGuard aGuard(rCache.mutex);
-if ( lcl_Equals(maCache.Options, rPara) )
-return maCache.xTextSearch;
+if ( lcl_Equals(rCache.Options, rPara) )
+return rCache.xTextSearch;
try
{
Reference XMultiServiceFactory xMSF = ::comphelper::getProcessServiceFactory();
-maCache.xTextSearch.set( xMSF-createInstance(
+rCache.xTextSearch.set( xMSF-createInstance(
::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM(
com.sun.star.util.TextSearch ) ) ), UNO_QUERY_THROW );
-maCache.xTextSearch-setOptions( rPara );
-maCache.Options = rPara;
+rCache.xTextSearch-setOptions( rPara );
+rCache.Options = rPara;
}
catch ( Exception )
{
DBG_ERRORFILE( TextSearch ctor: Exception caught! );
}
-return maCache.xTextSearch;
+return rCache.xTextSearch;
}
TextSearch::TextSearch(const SearchParam rParam, LanguageType eLang )
--
1.7.3.3
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Strange sorting of top level menu
When I see the Startcenter I see the Insert to the most right position and not as expected between View and Tools. This occurs only when the start center is visible. When I start or open a document the position is correct. Screendump: http://picasaweb.google.com/lh/photo/LroFAuzV1Wmj04_1mY8cIQ?feat=directlink Using Ubuntu Linux. I just changed from manual installation to http://ppa.launchpad.net/libreoffice/ppa/ubuntu . I'm not sure that the problem was before. Tomorrow I will check with my computer at work if it occurs consequent. Cheers, Leif Lodahl Danish Team ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Strange sorting of top level menu
On Thu Jan 06 2011 10:33:05 GMT-0800 (PST) leif wrote: When I see the Startcenter I see the Insert to the most right position and not as expected between View and Tools. This occurs only when the start center is visible. When I start or open a document the position is correct. Screendump: http://picasaweb.google.com/lh/photo/LroFAuzV1Wmj04_1mY8cIQ?feat=directlink Using Ubuntu Linux. I just changed from manual installation to http://ppa.launchpad.net/libreoffice/ppa/ubuntu . I'm not sure that the problem was before. Tomorrow I will check with my computer at work if it occurs consequent. Cheers, Leif Lodahl Danish Team I has to be something that is being added by Ubuntu. Here using the LibO download there is no Insert on the Startcenter, see attached. inline: sc-ss.png___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Again cppcheck cleanliness
Hi everybody, A new patch which correct cppcheck warnings in base/. To be continued with other modules. Regards, Guillaume 0002-Clean-resourceleak-warning-in-cppcheck.patch Description: Binary data 0001-cppcheck-cleanliness.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Updates for Lightproof
Kálmán „KAMI” Szalai píše v St 05. 01. 2011 v 20:52 +0100: Hi Michael, Sorry for bugging you but it seems I sent it two times, and David already pushed in: Re: [Libreoffice] [PATCH] [PUSHED] Updates for LightProof extension handling It is required If someone packs LightProof because of changed extension installation in 3.3. Does it mean that LightProof is broken in libreoffice-3-3 branch? If it is true, I would commit it even to the branch. It looks safe enough. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] sign off for cherry-pick fix for crash on exit after using search in calc
On Thu, 2011-01-06 at 17:23 +, Caolán McNamara wrote: i.e. see bug: https://bugzilla.redhat.com/show_bug.cgi?id=666088 for details. Attached is the proposed fix. Don't let the fancy-pants rtl::Static put you off, its just making the maCache from a global to a static local. Globals/static locals have their dtors called in reverse order of the completion of their ctors. Leaving the complex global at its current scope means it gets shutdown too late on final dlclose of libunotools, at a point after which all the runtime structure that it needs has been shutdown. Changing it to a local static ensures it gets dtored before that. I can sign off on this. I believe this code was originally my patch and Eike changed it a bit. I remember this one. Nothing weird about this change, so looks good to me. :-) Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Fix configure check for BerkleyDB where db_create is macro
Hi, this fixed the problem described in the attached mail. Gökçen, Robert, could you please test it and sign it out for libreoffice-3-3 branch? It works here and it should be more safe than the current solution. Analyze: db_create function is defined by macro in some db version. I did a lot of googling and have not found any ultimate solution. Some people try to check all db_create variants, e.g. db_create_4002, db_create_4001, see http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/mail-filter/maildrop/files/maildrop-2.5.1-db.patch?view=diffr1=texttr1=1.1r2=texttr2=1.1diff_format=s The problem is that there exists too many variants. Gökçen would need db_create_4008, ... I have found only one other variant for dbopen that is __db185_open. This symbol has been introduced in db-3.x and seems to be provided by any newer version for compatibility reasons. See also http://lists.debian.org/debian-devel/2001/04/msg01770.html Solution: - LibO requires db = 4.4. All these version should provide the symbol __db185_open for compatibility reasons. Of course, it is better to check for the original symbol dbopen, so I used __db185_open just as fallback. I am not 100% sure that it would work on all archaic systems but it should be better than the current state. Best Regards, Petr ---BeginMessage--- Çarşamba 01 Aralık 2010 günü (saat 20:35:22) Petr Mladek şunları yazmıştı: Hi Robert, Robert Nagy píše v St 01. 12. 2010 v 11:27 +0100: Hi, So this is a modified versio nof patches/dev300/system-db-check.diff to find the proper berkeley db headers and libs. I really would like to get this into bootstrap so please test and comment. It looks reasonable and works here. Feel free to commit it. With this patch (in RC2) I can no longer pass configure: checking which db to use... external checking for db-5.1/db.h... no checking for db5.1/db.h... no checking for db-5.0/db.h... no checking for db5.0/db.h... no checking for db-5/db.h... no checking for db5/db.h... no checking for db-4.8/db.h... no checking for db4.8/db.h... no checking for db-4.7/db.h... no checking for db4.7/db.h... no checking for db-4/db.h... no checking for db4/db.h... no checking for db/db.h... no checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking whether db is at least 4.1... yes checking for db_create in -ldb... no checking for db_create in -ldb-5.1... no checking for db_create in -ldb5.1... no checking for db_create in -ldb-5.0... no checking for db_create in -ldb5.0... no checking for db_create in -ldb-5... no checking for db_create in -ldb5... no checking for db_create in -ldb-4.8... no checking for db_create in -ldb4.8... no checking for db_create in -ldb-4.7... no checking for db_create in -ldb4.7... no checking for db_create in -ldb-4... no checking for db_create in -ldb4... no checking for db_create... no configure: error: db not installed or functional I'm using db4 version 4.8.30, and db4-devel package is installed. I can compile RC1 without any errors. When I try to compile this test file that configure generates: /* confdefs.h */ #define PACKAGE_NAME #define PACKAGE_TARNAME #define PACKAGE_VERSION #define PACKAGE_STRING #define PACKAGE_BUGREPORT #define PACKAGE_URL #define STDC_HEADERS 1
Re: [Libreoffice] [PATCH] Updates for Lightproof
Hi Michael, Petr, Please review the new rules of extension integration for 3.3. I did the necessary changes for extensions except Lightproof and SUN templates pack. I did it after RC stage started. I hope this was the last patch for it. David has already comited it: http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-3id=a1fc860c638a072924fd7733b4c09769acfa8ca3 All the best, KAMI 2011-01-06 20:39 keltezéssel, Petr Mladek írta: Kálmán „KAMI” Szalai píše v St 05. 01. 2011 v 20:52 +0100: Hi Michael, Sorry for bugging you but it seems I sent it two times, and David already pushed in: Re: [Libreoffice] [PATCH] [PUSHED] Updates for LightProof extension handling It is required If someone packs LightProof because of changed extension installation in 3.3. Does it mean that LightProof is broken in libreoffice-3-3 branch? If it is true, I would commit it even to the branch. It looks safe enough. Best Regards, Petr signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix configure check for BerkleyDB where db_create is macro
Hi, I just checked for my db version. I, too, use [IP-] [ ] sys-libs/db-4.8.30:4.8 which works just fine. So I wonder what differs. Regards, Hanno ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] segfault in libqa_unit.so test
On Tue, Jan 04, 2011 at 03:01:53PM +, Caolán McNamara wrote:
One horrific temporary hack to test a theory would be to call _exit to
skip calling the massive dtor chain which OOo builds up. Though that's
not a cure, just a temp hack, but maybe it'll help isolate this.
I'm confused why, but with this patch applied, I get failure much
earlier.
Module 'odk' delivered successfully. 3 files copied, 1 files unchanged
---
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 /disk/2/archive/libreoffice/tools/qa
it seems that the error is inside 'tools', please re-run build
inside this module to isolate the error and/or test your fix:
---
rm -Rf /disk/2/archive/libreoffice/tools/unxbsdx3.pro # optional module 'clean'
/bin/bash
cd /disk/2/archive/libreoffice
source ./NetBSDX86-64Env.Set.sh
cd tools
build
when the problem is isolated and fixed exit and re-run 'make' from the top-level
when I do that:
Making:test_tools.so
../unxbsdx3.pro/slo/test_reversemap.o: In function `(anonymous
namespace)::Test::testEncoding(unsigned short)':
test_reversemap.cxx:(.text+0x3f0): undefined reference to
`getBestMSEncodingByChar(unsigned short)'
dmake: Error code 1, while making '../unxbsdx3.pro/lib/test_tools.so'
Forcing regeneration of dependency info
--
- start unit test #1 on library
--
:
LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/disk/2/archive/libreoffice/clone/libs-gui/tools/unxbsdx3.pro/lib:/disk/2/archive/libreoffice/solver/330/unxbsdx3.pro/lib
/disk/2/archive/libreoffice/solver/330/unxbsdx3.pro/bin/cppunittester
Usage: cppunittester shared-library-path
dmake: Error code 1, while making 'test1'
Retrying /disk/2/archive/libreoffice/tools/qa
Making:all_qa.dpslo
Making:test_tools.so
../unxbsdx3.pro/slo/test_reversemap.o: In function `(anonymous
namespace)::Test::testEncoding(unsigned short)':
test_reversemap.cxx:(.text+0x3f0): undefined reference to
`getBestMSEncodingByChar(unsigned short)'
dmake: Error code 1, while making '../unxbsdx3.pro/lib/test_tools.so'
---
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
it seems that the error is inside 'tools', please re-run build
inside this module to isolate the error and/or test your fix:
---
rm -Rf /disk/2/archive/libreoffice/tools/unxbsdx3.pro # optional module 'clean'
/bin/bash
cd /disk/2/archive/libreoffice
source ./NetBSDX86-64Env.Set.sh
cd tools
build
How can the diff cause that?
Thomas
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] segfault in libqa_unit.so test
On Thu, 2011-01-06 at 22:44 +0100, Thomas Klausner wrote: On Tue, Jan 04, 2011 at 03:01:53PM +, Caolán McNamara wrote: One horrific temporary hack to test a theory would be to call _exit to skip calling the massive dtor chain which OOo builds up. Though that's not a cure, just a temp hack, but maybe it'll help isolate this. I'm confused why, but with this patch applied, I get failure much earlier. Unrelated I feel. Making:test_tools.so ../unxbsdx3.pro/slo/test_reversemap.o: In function `(anonymous namespace)::Test::testEncoding(unsigned short)': test_reversemap.cxx:(.text+0x3f0): undefined reference to `getBestMSEncodingByChar(unsigned short)' dmake: Error code 1, while making '../unxbsdx3.pro/lib/test_tools.so' Forcing regeneration of dependency info export VERBOSE=true here to get the command lines used. fiddle with the equivalent of nm -D ../unxbsdx3.pro/lib/libtl*so | c++filt|grep getBest to see if the symbol in in libtl*.so like it should be to help find out if we're linking against the right libtl locally e.g. as opposed to the one inside the solver. If its not then see if ../unxbsdx3.pro/bin/bestreversemap exists, and see if ../unxbsdx3.pro/inc/reversemap.hxx exists with getBestMSEncodingByChar inside it. That reversemap.hxx should be generated by bestreversemap and included by source/string/reversemap.cxx and built into the libtl.so My *guess* is that for some reason ../unxbsdx3.pro/inc/reversemap.hxx exists but is empty. Is that the case ? 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
Like I said earlier, I submitted also this bug to OpenOffice.org and it was marked as RESOLVED yesterday. See http://www.openoffice.org/issues/show_bug.cgi?id=116164 http://www.openoffice.org/issues/show_bug.cgi?id=116164 I don't know how are the contacts (if any) between LO developers and OOo developers, but the bug was solved. Maybe someone there will give you a hint ;-) Raymond -- View this message in context: http://nabble.documentfoundation.org/A-file-to-show-8192-discontinuities-crashes-Calc-tp2135015p2208563.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] segfault in libqa_unit.so test
On Thu, 2011-01-06 at 22:07 +, Caolán McNamara wrote: On Thu, 2011-01-06 at 22:44 +0100, Thomas Klausner wrote: On Tue, Jan 04, 2011 at 03:01:53PM +, Caolán McNamara wrote: One horrific temporary hack to test a theory would be to call _exit to skip calling the massive dtor chain which OOo builds up. Though that's not a cure, just a temp hack, but maybe it'll help isolate this. I'm confused why, but with this patch applied, I get failure much earlier. Unrelated I feel. Bah, let me rethink that. I guess its very possible that _exit doesn't flush standard I/O on NetBSD which might indeed cause an empty generated .hxx. I've just pushed a fflush into that generator to help test the theory. Try a pull and build again of tools. reversemap.obj depends on reversemap.hxx which depends on bestreversemap which I've added the extra fflush to so the rebuild should re-generate it without any manual intervention. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] 1st try of translating German comments into English
Tried hard and hope it's acceptable. Please check. Criticism welcome. From ab9c6699645c17d1743e94a8af77685415db688b Mon Sep 17 00:00:00 2001 From: Christoph Herzog rho...@googlemail.com Date: Fri, 7 Jan 2011 00:22:24 +0100 Subject: [PATCH] First try of translating German comments into English. --- sw/inc/IDocumentContentOperations.hxx | 73 +--- 1 files changed, 30 insertions(+), 43 deletions(-) diff --git a/sw/inc/IDocumentContentOperations.hxx b/sw/inc/IDocumentContentOperations.hxx index 040b09c..4a5c0ee 100644 --- a/sw/inc/IDocumentContentOperations.hxx +++ b/sw/inc/IDocumentContentOperations.hxx @@ -74,20 +74,20 @@ }; public: -/** Kopieren eines Bereiches im oder in ein anderes Dokument ! -Die Position kann auch im Bereich liegen !! -*/ +/** Copying of a range within or to another document. +The position can also be within the range! + */ virtual bool CopyRange(SwPaM, SwPosition, const bool bCopyAll ) const = 0; -/** Loesche die Section, in der der Node steht. +/** Delete section containing the node. */ virtual void DeleteSection(SwNode* pNode) = 0; -/** loeschen eines BereichesSwFlyFrmFmt +/** Delete a range SwFlyFrmFmt. */ virtual bool DeleteRange(SwPaM) = 0; -/** loeschen gesamter Absaetze +/** Delete full paragraphs. */ virtual bool DelFullPara(SwPaM) = 0; @@ -100,19 +100,15 @@ virtual bool DeleteAndJoin( SwPaM, const bool bForceJoinNext = false ) = 0; -/** verschieben eines Bereiches -*/ virtual bool MoveRange(SwPaM, SwPosition, SwMoveFlags) = 0; -/** verschieben ganzer Nodes -*/ virtual bool MoveNodeRange(SwNodeRange, SwNodeIndex, SwMoveFlags) = 0; -/** verschieben eines Bereiches +/** Move a range. */ virtual bool MoveAndJoin(SwPaM, SwPosition, SwMoveFlags) = 0; -/** Ueberschreiben eines Strings in einem bestehenden Textnode. +/** Overwrite string in an existing text node. */ virtual bool Overwrite(const SwPaM rRg, const String rStr) = 0; @@ -125,26 +121,24 @@ */ virtual void TransliterateText(const SwPaM rPaM, utl::TransliterationWrapper) = 0; -/** Einfuegen einer Grafik, Formel. Die werden kopiert. +/** Insert graphic or formula. The are copied. */ virtual SwFlyFrmFmt* Insert(const SwPaM rRg, const String rGrfName, const String rFltName, const Graphic* pGraphic, const SfxItemSet* pFlyAttrSet, const SfxItemSet* pGrfAttrSet, SwFrmFmt*) = 0; -/** -*/ virtual SwFlyFrmFmt* Insert(const SwPaM rRg, const GraphicObject rGrfObj, const SfxItemSet* pFlyAttrSet, const SfxItemSet* pGrfAttrSet, SwFrmFmt*) = 0; -/** austauschen einer Grafik (mit Undo) +/** Transpose graphic (with undo) */ virtual void ReRead(SwPaM, const String rGrfName, const String rFltName, const Graphic* pGraphic, const GraphicObject* pGrfObj) = 0; -/** Einfuegen eines DrawObjectes. Das Object muss bereits im DrawModel -angemeldet sein. +/** Insert a DrawObject. The object must be already registered +in DrawModel. */ virtual SwDrawFrmFmt* Insert(const SwPaM rRg, SdrObject rDrawObj, const SfxItemSet* pFlyAttrSet, SwFrmFmt*) = 0; -/** Einfuegen von OLE-Objecten. +/** Insert OLE-objects. */ virtual SwFlyFrmFmt* Insert(const SwPaM rRg, const svt::EmbeddedObjectRef xObj, const SfxItemSet* pFlyAttrSet, const SfxItemSet* pGrfAttrSet, SwFrmFmt*) = 0; @@ -152,43 +146,36 @@ virtual SwFlyFrmFmt* InsertOLE(const SwPaM rRg, const String rObjName, sal_Int64 nAspect, const SfxItemSet* pFlyAttrSet, const SfxItemSet* pGrfAttrSet, SwFrmFmt*) = 0; -/** Aufspalten eines Nodes an rPos (nur fuer den TxtNode implementiert) +/** Split a node at rPos (implemented only for TxtNode). */ virtual bool SplitNode(const SwPosition rPos, bool bChkTableStart) = 0; -/** -*/ virtual bool AppendTxtNode(SwPosition rPos) = 0; -/** Ersetz einen selektierten Bereich in einem TextNode mit dem -String. Ist fuers SuchenErsetzen gedacht. -bRegExpRplc - ersetze Tabs (\\t) und setze den gefundenen String - ein ( nicht \ ) -z.B.: Fnd: zzz, Repl: xx\t\\t\ --- xx\tTab..zzz.. +/** Replace selected range in a TxtNode with string. +Intended for search replace. +bRegExpRplc - replace tabs (\\t) and insert the found string +( not \ ). E.g.: Find: zzz, Replace: xx\t\\t\ +-- xx\tTab..zzz.. */ virtual bool ReplaceRange(SwPaM rPam, const String rNewStr, const bool bRegExReplace) = 0; -/** Einfuegen eines Attributs. Erstreckt sich rRg ueber -mehrere Nodes, wird das Attribut aufgespaltet,
Re: [Libreoffice] Oracle wordbook in LibO
On 06/01/2011 Petr Mladek wrote: Kálmán „KAMI” Szalai píše v Čt 06. 01. 2011 v 15:40 +0100: May we include vendor specific sfuffs from oracle.dic? http://cgit.freedesktop.org/libreoffice/extras/commit/?h=libreoffice-3-3id=7fbdfd0a0d2af30af92839ebf8bcf97c465519e8 Looks good to me. I might have lost track of changes due to the multiple patches here and in https://bugs.freedesktop.org/show_bug.cgi?id=31798, but there are a few things that make little sense to me: - This would remove OpenOffice.org and everything that used to be in oracle.dic - ...but it adds the word MySQL - It adds the whole family tree of Ubuntu - ...but it doesn't add GNU/Linux or just GNU and Linux, and it removes Linux instead - It removes Oracle and it adds Novell, but it ignores all the companies listed in http://www.documentfoundation.org/supporters/ - It removes all the application names: Writer, Calc, Impress... Are these choices deliberate? Regards, Andrea. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Standard-color-palette-updates
Hi Kami, all, Kálmán „KAMI” Szalai schrieb: Hi All, Some colors of LibO are already part of palette, I just wanted to update it to follow the latest colors in wiki. If not required to provide LibO colors with the product (as a main or separated palette) then I we can leave the current situation or roll back. I would like to provide these colors but this is one opinion :o) My personal opinion is near to Christoph's position: We can't grant that the present LibO colors will stay the official branding colors when the community based branding will be developed (planned for LibO 3.5). Changing colors while keeping their names is a no-go IMHO, because this would lead to modified documents when opening them with different versions of LibO. As Christoph mentions, the LibO colors are relevant for all the people trying to create documents and artwork following the present LibO branding, but these people are a minority against all our standard users. Therefore I would love to see these colors in an additional palette, but not in the main palette (perhaps except the main color LibreOffice_Green1). Best regards Bernhard PS: If we provide the colors, we should ship the final version you got from the wiki - thanks for your work on this topic! ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] segfault in libqa_unit.so test
On Thu, Jan 06, 2011 at 10:18:38PM +, Caolán McNamara wrote: Bah, let me rethink that. I guess its very possible that _exit doesn't flush standard I/O on NetBSD which might indeed cause an empty generated .hxx. I've just pushed a fflush into that generator to help test the theory. Try a pull and build again of tools. With a new pull and your patch applied, I get to: No EPM: do no packaging at this stage Multiprocessing build is finished Maximal number of processes run: 1 Is that the end of the build? (Where did the nice graphics go? ;) ) Thank you! How do we continue with this? Thomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
