Re: [Libreoffice] minutes of tech steering call ...
(I would also suggest release on Thursday so that feedback from the second week-end have a chance to be fixed before the next release) Marketing wise, release on Thursday is risky, because one day later (what happens) makes it Friday.. The important release, marketing wise, is the Final one. The final one is typically a RC that has not seen any serious problem. so, the rational to delay release to Thursday (allow time for week-end bug to be fixed) must be moot for that last cycle. The decision to promote a RC to Final can therefore still be done on Monday and the release still be on Wednesday... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Do we still need to support non-XKB X11 systems ?
Hi, The file libs-gui/tools/inc/tools/prex.h tries to detect the presence of the X11 keyboard extension (XKB) in a completely bogus way - by hardcoding a value depending on the operating system it is build for: // FIXME: should really check for xfree86 or for X11R6.1 and higher #if defined(LINUX) || defined(FREEBSD) || defined(MACOSX) || defined(NETBSD) || \ defined(OPENBSD) || defined(DRAGONFLY) #define __XKeyboardExtension__ 1 #else #define __XKeyboardExtension__ 0 #endif It has been done that way since this file was created. Now, I could try to use something less brain damaged to detect the presence of the XKB extension but it has been part of X since X11R6.1 which has been released in March 1996 ... Would anybody object if I remove the test and consider XKB present on all X11 systems ? -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Patch for Bug 38936
Hi, Proposed patch for https://bugs.freedesktop.org/show_bug.cgi?id=38936, Bug 38936. Many different locations for Hori~zontal Ruler, but it seems like only WriterCommands.xcu in officecfg/registry/data/org/openoffice needed to be modified. Now the toolbar tab matches the title on the box when the box pops up. Thanks, -- --Jeffrey Chang From b99ae25f50fcb1f4aa846fbaa46611fa873aba7d Mon Sep 17 00:00:00 2001 From: Jeffrey jeffdch...@gmail.com Date: Sat, 9 Jul 2011 02:25:33 +0800 Subject: [PATCH] Change Menuitem Insert Ruler to Rule --- .../org/openoffice/Office/UI/WriterCommands.xcu|2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu b/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu index 07346a9..9153d94 100644 --- a/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu +++ b/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu @@ -57,7 +57,7 @@ /node node oor:name=.uno:InsertGraphicRuler oor:op=replace prop oor:name=Label oor:type=xs:string -value xml:lang=en-USHori~zontal Ruler.../value +value xml:lang=en-USHori~zontal Rule.../value /prop /node node oor:name=.uno:SetAnchorAtChar oor:op=replace -- 1.7.3.4 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] [PUSHED] fdo#38457: Crash in DataPilot on moving the fields
On Wed, 2011-06-29 at 22:24 +0200, Markus Mohrhard wrote: Kohei, I think, as this is mostly your area, you might want to have a closer look at the whole code around the offset problem. So, everything comes down to what PivotField::nCol is expected to contain; is it a (always 0-based) dimension index, or a column index whose smallest index may not be always 0. The column offset variable was there because PivotField::nCol was expected to contain a column index rather than a dimension index if the data source was a sheet, while for the other data source types it was expected to contain a dimension index. First things first, Bubli's fix appears to work just fine. This is all good. Now, that would also imply that in the latest pivot table code, PivotField::nCol always contain a dimension index even for the internal sheet data source type. I remember I fixed some bugs some time ago in this area because nCol didn't contain a column index, so I know for a fact that this was not always the case. Maybe my re-work of the dialog changed this, my cache table re-work did this. I don't know for sure. But I have to keep this fact in mind going forward, in case I come across any old code that may still expect PivotField::nCol to contain a column index. But that's fine since I personally prefer it always containing a dimension index anyway. :-) Regards, 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] [PUSHED] CONVERT_ADD() fixes
Hi András, Many thanks for your help. If you don't bother, I send a new patch (1 line) to fix the sometimes bad capitalization in non-standard hyphenation (a few years old, recently recognized bug from me): http://www.numbertext.org/tmp/hyphencap.patch A test file with some bad Hungarian hyphenation (ÖCs-csük, ÖSz-sze instead of Öcs-csük, Ösz-sze): http://www.numbertext.org/tmp/ccs.odt Thanks, László 2011/7/7 Andras Timar tima...@gmail.com: Hi Laci, 2011/7/7 Németh László nem...@numbertext.org: Hi, Could you integrate this patch to fix some measurement conversion factors of Calc? http://www.numbertext.org/tmp/gallon.patch I pushed this to master. Thanks for the patch. Cheers, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Do we still need to support non-XKB X11 systems ?
Hi Francois, On Fri, 2011-07-08 at 08:10 +0200, Francois Tigeot wrote: The file libs-gui/tools/inc/tools/prex.h tries to detect the presence of the X11 keyboard extension (XKB) in a completely bogus way - by hardcoding a value depending on the operating system it is build for: Lol ;-) // FIXME: should really check for xfree86 or for X11R6.1 and higher #if defined(LINUX) || defined(FREEBSD) || defined(MACOSX) || defined(NETBSD) || \ defined(OPENBSD) || defined(DRAGONFLY) #define __XKeyboardExtension__ 1 So - reading the above it really looks like an: #ifndef defined(SOLARIS) which is somewhat odd, since it should have XKB too. Now, I could try to use something less brain damaged to detect the presence of the XKB extension but it has been part of X since X11R6.1 which has been released in March 1996 ... Lets kill that :-) 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][PUSHED: master; 3-4] Additional fix for bug fdo#33781
Roland Baudin píše v Čt 23. 06. 2011 v 22:09 +0200: Le 21/06/2011 21:10, Petr Mladek a écrit : Roland Baudin píše v Út 21. 06. 2011 v 09:26 +0200: Hi Petr, I've tested your patch with my test docs and for me it's OK. I've just noticed a small issue when inserting a chart in Calc : when switching out from edit mode, the top line of the graphic becomes blurred. I attach a test file, so you can judge the issue. I see this even without your patch, so it is most likely another issue. Or do you see it different? If it is not a regression caused by your or mine change, I am happy to cherry-pick your fix with mine additions to the libreoffice-3-4 branch. Best Regards, Petr I tested with and without the patch and the issue with the top line of the chart is there. So I can confirm this issue is not introduced by our patch. Thanks for testing. I have committed my changes into master and cherry-picked both changes to the libreoffice-3-4 branch: http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4id=262261c39dc68ba7fb8d846fb3dacfa6b4fc98ba http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4id=c703b311c907b4c97850b5c81ae6a9d3ef47954c I am sorry that it took so long. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] RTF support
On Tue, Jul 05, 2011 at 03:46:06AM -0700, comunesanfior informat...@comune.san-fior.tv.it wrote: I'm not sure if there is already a solution to my bug https://bugs.freedesktop.org/show_bug.cgi?id=38966 It's already assigned, we'll soon have a look at it. Thank you for your patience. pgpbsKlWnQm3X.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] right way to control libs and flags on the link line
On Thu, 2011-07-07 at 18:21 +0200, Bjoern Michaelsen wrote: The real solution would be to use gb_LinkTarget_add_libs ... Indecently this is what is being done very well with the rework of external linking in gnumake4, centralizing it so that the external-linking-foo is done in one file, and not all over place. see: Great, so proper fix is in hand then, and awaits gnumake4 integration. Hopefully I'll remember to fix up temp hack at that stage. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix for fdo#30550 Character count without spaces
Hi John, Korrawit, On Wed, 2011-07-06 at 22:51 +0700, Korrawit Pruegsanusak wrote: On Fri, Jun 24, 2011 at 14:38, John LeMoyne Castle lemoyne.cas...@gmail.com wrote: -- you (and others) cannot reproduce fdo#37584 (redlined text disappears) in 3-3 or 3-3-3 because my patch referenced in your original post [OP] is not in the 3-3 branches. Hmm? I think it's caused by casting var: String rTextCopy = const_castString(m_Text); which Cedric fixed in http://cgit.freedesktop.org/libreoffice/writer/commit/?id=135cf4fdbec71e8d93edc0339e8617d50766f151 Anyway, if it can't be reproduced, so let it be. (should not have further fix for -3-3) You're both right... blame me for leading you into error because I haven't had a look at the 3-3 branch code before writing my first email. The copy mentioned by Korrawit isn't in the 3-3 branch... which explains why the bug can't be reproduced there ;) -- 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] Single Git repository migration plan
On Mon, Jul 4, 2011 at 11:47 PM, Simos Xenitellis simos.li...@googlemail.com wrote: On Mon, Jul 4, 2011 at 10:14 PM, Sophie Gautier gautier.sop...@gmail.com wrote: Hi all, [please follow up on projects@ list] There is an planed effort to reduce and consolidate the number of git repositories in use (up to 20 currently) and migrate them using a git fetch, however it has some drawbacks with history being unusable. A clean up will be necessary too (the main one being tab/space clean-up). You'll find a C program for that indicated on the wiki page bellow. As a result also, the development pages will need to be updated on the wiki, so you'll have to monitor the changes done there. The script onegit.sh, which is located in contrib/dev-tools, implement the steps described above. The migration is intrusive so please, pay attention to what will be done and the schedule (not confirm yet) on this page http://wiki.documentfoundation.org/Development/One_Git_Conversion Thanks in advance for your help, your feedback and your monitoring on this. If you have any question, don't hesitate to ask (I am for sure the wrong person to answer but I know where the resource is hiding :) Once the migration takes place, each person should clone this single Git repository, right? Yes. this will be 'core' After the migration there are 5 repos left help and translations which are untouched by the migration process binfilter (about 36MB) which contain the binfitler module extracted from the old filters repo. this is an optional repos (i.e not needed if you do not have --enable-binfilter) dictionaries (about 74MB) which contain the dictionaries module extracted from the old libs-extern-sys. this is an optional module (on needed if you have an autogen option that trigger the build of the dictionaries) and core (about 580MB) which contain all the rest Is it possible to create a tarball of the repository so that people can download using a download manager (through HTTP or FTP), and then they can 'git pull' in order to bring in sync? Yes, I'll put that in the to-do list. most likely it will be at http://dev-www.libreoffice.org/bundles/libreffice-core.tar.bz2 Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] RTF import patches for 3-4
Hi all,
Here are two patches to review for the 3.4 branch. I know it's stupid to
hack the RTF import filter... but the new one won't be in 3.4 ;)
Thanks,
--
Cédric Bosdonnat
LibreOffice hacker
http://documentfoundation.org
OOo Eclipse Integration developer
http://cedric.bosdonnat.free.fr
From 49cfac3bdd9876496954ca1d52a714d6b2edd619 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?C=C3=A9dric=20Bosdonnat?= cedric.bosdonnat@free.fr
Date: Mon, 27 Jun 2011 16:46:16 +0200
Subject: [PATCH 1/2] n#695479: Remove properties when removing empty fly frame
---
sw/source/filter/rtf/rtffly.cxx |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sw/source/filter/rtf/rtffly.cxx b/sw/source/filter/rtf/rtffly.cxx
index 3e02399..eb35f2a 100644
--- a/sw/source/filter/rtf/rtffly.cxx
+++ b/sw/source/filter/rtf/rtffly.cxx
@@ -1098,6 +1098,8 @@ void SwRTFParser::ReadFly( int nToken, SfxItemSet* pSet )
// dann zerstoere den FlySave wieder.
aFlyArr.DeleteAndDestroy( --nFlyArrCnt );
+// Remove the properties that have been parsed before in the paragraph
+GetAttrStack().pop_back();
}
else
{
--
1.7.3.4
From b1e022057ba263f5233025e7c0d566dc91080227 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?C=C3=A9dric=20Bosdonnat?= cedric.bosdonnat@free.fr
Date: Fri, 8 Jul 2011 14:49:14 +0200
Subject: [PATCH 2/2] n#695479: basic handling of lines in RTF import
---
sw/source/filter/rtf/swparrtf.cxx | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/sw/source/filter/rtf/swparrtf.cxx b/sw/source/filter/rtf/swparrtf.cxx
index 1b5c076..49a6f77 100644
--- a/sw/source/filter/rtf/swparrtf.cxx
+++ b/sw/source/filter/rtf/swparrtf.cxx
@@ -1173,7 +1173,7 @@ void SwRTFParser::ReadShpTxt(String s)
}
/*
- * Very basic support for the Buchhalternase.
+ * Very basic support for the Z-line.
*/
void SwRTFParser::ReadDrawingObject()
{
@@ -1185,6 +1185,9 @@ void SwRTFParser::ReadDrawingObject()
::basegfx::B2DPoint aPoint;
bool bPolygonActive(false);
+SwFmtHoriOrient aHori( 0, text::HoriOrientation::NONE, text::RelOrientation::PAGE_FRAME );
+SwFmtVertOrient aVert( 0, text::VertOrientation::NONE, text::RelOrientation::PAGE_FRAME );
+
while (level0 IsParserWorking())
{
nToken = GetNextToken();
@@ -1196,6 +1199,12 @@ void SwRTFParser::ReadDrawingObject()
case '{':
level++;
break;
+case RTF_DOBXMARGIN:
+aHori.SetRelationOrient( text::RelOrientation::PAGE_PRINT_AREA );
+break;
+case RTF_DOBYMARGIN:
+aVert.SetRelationOrient( text::RelOrientation::PAGE_PRINT_AREA );
+break;
case RTF_DPX:
aRect.setX(nTokenValue);
break;
@@ -1208,6 +1217,7 @@ void SwRTFParser::ReadDrawingObject()
case RTF_DPYSIZE:
aRect.setHeight(nTokenValue);
break;
+case RTF_DPLINE:
case RTF_DPPOLYCOUNT:
bPolygonActive = true;
break;
@@ -1244,9 +1254,7 @@ void SwRTFParser::ReadDrawingObject()
aAnchor.SetAnchor( pPam-GetPoint() );
aFlySet.Put( aAnchor );
-SwFmtHoriOrient aHori( 0, text::HoriOrientation::NONE, text::RelOrientation::PAGE_FRAME );
aFlySet.Put( aHori );
-SwFmtVertOrient aVert( 0, text::VertOrientation::NONE, text::RelOrientation::PAGE_FRAME );
aFlySet.Put( aVert );
pDoc-GetOrCreateDrawModel();
--
1.7.3.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] [PUSHED] patch for fdo#38963: crash in number format dialog
Hi, this patch fixes a crash in calc when you try to format a cell as currency and hit the 'Negative Numbers Red' or 'Thousands seperator' checkbox. http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=368227ac4416446 02de197ee0d329f3ea997f9ca Reviewed pushed. Thx (for all the fish) hB. -- \ Katarina Machalkova \\\__o LibO developer __\\\'/_ hedgehog painter 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] How to compile LibreOffice 3.3 Calc
On Thu, 2011-07-07 at 03:36 -0700, Mahasen Dehideniya wrote: I'm try to download and compile the LibreOffice 3.3 .. Its source code is very big. In addition to Cor's good advice, I would -strongly- recommend contributing to libreoffice-3-4 or better master - since we can always back-port fixes to include in 3.4.x and 3.3.x if necessary, and master is (strangely) rather easier to build, and we'll be much more able to help you with problems if they occur. Basically , I'm try to contribute to LibreOffice 3.3 calc So anyone can tell me how can I compile LibreOffice 3.3 calc only Compiling calc only is currently only possible after you have compiled all of LibreOffice. Once that is done you can quickly just re-build calc. The best thing to do is to hang out on the #libreoffice-dev IRC channel on irc.freenode.net and ask questions :-) 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] [REVIEW] Better support for distro packaging
Hi Petr, On Fri, 2011-07-08 at 16:00 +0200, Petr Mladek wrote: are you fine with adding the attached changes into master and libreoffice-3-4 branch? So - overall this looks good, particularly if it helps to kill the 'build' module finally and completely. Of course, if it came from build/ perhaps it is not really new stuff anyway :-) Did you mean to change the normal 'make install' rule to use that @ substitution ? Finally - I'm not a huge fan of that mv_file_between_flists cruft - indeed, I did a bit of work to try to straighten some of that out for a few patterns: we should do that in the scp2 itself I think [ now that we can do that easily (surely?) ]. Otherwise I'm ok, but I'd like to hear Rene / Caolan's feedback; I assume it is in master ? :-) 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] Do we still need to support non-XKB X11 systems ?
Hi Michael, On Fri, Jul 08, 2011 at 09:40:44AM +0100, Michael Meeks wrote: On Fri, 2011-07-08 at 08:10 +0200, Francois Tigeot wrote: #if defined(LINUX) || defined(FREEBSD) || defined(MACOSX) || defined(NETBSD) || \ defined(OPENBSD) || defined(DRAGONFLY) #define __XKeyboardExtension__ 1 So - reading the above it really looks like an: #ifndef defined(SOLARIS) And also AIX, even though not many people may try to run X applications on it these days... which is somewhat odd, since it should have XKB too. :-) Lets kill that :-) Done in master. Cheers ! -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Better support for distro packaging
On Fri, Jul 08, 2011 at 04:00:48PM +0200, Petr Mladek pmla...@suse.cz wrote: are you fine with adding the attached changes into master and libreoffice-3-4 branch? Sure, it can't really make things worse. :) 6 files changed, 250 insertions(+), 0 deletions(-) create mode 100644 distro-configs/SUSE-10.1.conf create mode 100644 distro-configs/SUSE-11.1.conf create mode 100644 distro-configs/SUSE-11.2.conf create mode 100644 distro-configs/SUSE-11.3.conf create mode 100644 distro-configs/SUSE-11.4.conf create mode 100644 distro-configs/SUSE.conf Is it a good idea to introduce distro-specific configs here? I thought LO packagers are supposed to put options to packaging scripts, now that the defaults are more-or-less sane. ;) + do not call build-galleries: is anyone using them? + do not install ootool and ooconfig is anyone using them? are they still working? No, last time I tried build-galleries was already broken. pgpo5LMFktMsh.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
Wow, thank Peter for this amazing explanation. I'm currently sumerged into the gsoc project too so I can't give it a try right now but I'm sure I will once I finish it. The problem right now is I don't know most of the things you're talking about so I'll need first to get my feet wet. I'll let you know when I start to work on it. Greetings 2011/7/7 Peter Jentsch pj...@guineapics.de Hi Xisco, one more thing: I looked at at XSLTFilter code again and noticed that although a lot of data get's passed in to the import call, only a tiny fragment of that makes it to the actual transformation, so you won't be able to use any parameters in the transformation. I don't like that situation, and if you'd chose to investigate deeper into the approach I sketched out I'd extend the XSLT Filter call to pass parameters to the transformation. We get a MediaDescriptor struct handed in there, which has a string field FilterOptions that can be passed unmodified to any transformation. That should be sufficient if the total amount of information to get into the transformation remains small. Cheers, Peter Am 04.07.11 12:42, schrieb Michael Meeks: Hi Xisco, Peter - Xisco is working on re-writing the wizards in Java :-) On Fri, 2011-07-01 at 16:05 +0200, Xisco Faulí wrote: Michael wrote: Weelll - so you're both right; but really we need to grub about inside the templates themselves to add some improved translation scheme I think; now we have fast native XSLTs - I guess we could use the native XSLT filters to allow the templates to be self-standing, and yet adapt to the locale nicely. But - your task is primarily the Java - python conversion I guess :-) Xisco wrote: Yes, you're right but if I have some time before gsoc finishes (or even after) I'd like to take a look to it. Who should I get in contact with in order to get my feet wet ? Ah - so the XSLT expert is Peter Jentsch who has done a load of great work in this area, writing the much faster / smaller native C++ filter etc. He can prolly help out with some code pointers, and/or perhaps some simple example XSLTs that might be useful for translating attributes / elements (?), and ways to get feed the required data to them elegantly. HTH, Michael. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Better support for distro packaging
Am Fri, 8 Jul 2011 18:33:45 +0200
schrieb Miklos Vajna vmik...@frugalware.org:
6 files changed, 250 insertions(+), 0 deletions(-)
create mode 100644 distro-configs/SUSE-10.1.conf
create mode 100644 distro-configs/SUSE-11.1.conf
create mode 100644 distro-configs/SUSE-11.2.conf
create mode 100644 distro-configs/SUSE-11.3.conf
create mode 100644 distro-configs/SUSE-11.4.conf
create mode 100644 distro-configs/SUSE.conf
Is it a good idea to introduce distro-specific configs here? I thought
LO packagers are supposed to put options to packaging scripts, now
that the defaults are more-or-less sane. ;)
Yes, no need to add them back again. That should be done in the
packaging scripts.
Right now I don't see the need for any of these patches. I have LibO
pretty good under control with ArchLinux packaging tools.
I'm using make DESTDIR=${pkgdir} install and then do some desktop
integration that worked automatically in old ooo-build days. This could
be improved.
The former man-page is still missing.
The most desired thing I guess are make install targets for splitted
builds(writer,calc,sdk...). I know there're files to get the file lists,
but I'm lazy here.
-Andy
http://projects.archlinux.org/svntogit/packages.git/tree/libreoffice/trunk/PKGBUILD
signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Libre Office
Hello, I installed libre office on my computer, but now it's taking up too much memory on my computer. I was trying to unistall it, and it wont let me uninstall it. How can I unistall it? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Old X11 code cleanup in libs-gui
Hi, I'm a bit puzzled by code using what is almost a complete list of all platforms running X11 to define some features: #if defined DBG_UTIL || defined SUN || defined LINUX || defined FREEBSD || \ defined NETBSD || defined OPENBSD || defined DRAGONFLY nProperties_ |= PROPERTY_FEATURE_Maximize; #endif Am I right in interpreting the above list as everything but AIX ? Non-X11 platforms such as MacOSX don't count in this case. We also have some code dedicated to finding the origin of different X11 implementations and working around their bugs (grep for GetServerVendor). Among it, there is a whole XFree86-related section which I suspect is no longer relevant: the last XFree86 release is dated from 2008 and the project itself appears to be dead. There is no specific code for Xorg and given its history, it should have had the same problems as XFree. Since no one has complained, I suspect the problems it fixed are not even relevant today. They were bit order issues on 8-bit displays. If nobody gives me a reason not to in the next days, I plan to remove both the useless #if defined list and the whole XFree section. -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC 2011][svgexport] set of patches based on master
On Fri, 08 Jul 2011 05:41:11 +0200, Thorsten Behrens t...@documentfoundation.org wrote: Marco wrote: I created a set of patches based on master as it was on Monday. Hi Marco, good work! Hi Thorsten, thanks a lot. :) Applied to master pushed - two minor nits: please keep whitespace changes to a minimum (at least for code you're not directly touching), Well, the problem is that while merging I need to solve several conflict and moreover it complain about tab characters, so while I was solving the conflicts I decided to replace all tab with 4 spaces and removing trailing spaces. At least that should be the last time! (I hope!) and please try to keep extra debug code / commented-out proof of concept stuff out of the main patches. If you're interested in helpful git juggling workflows for those things, please do ask! Yes, definitively I need that! Is there a way to keep a clean version of a source file and one with comment out code and debug code, and be able to switch quickly from one to another ? Can git help me in that ? You could read more details on my logbook as soon as I find a bit of time to update it. :) Much looking forward! :) I updated it up to Wednesday. https://docs.google.com/document/d/12pIrnHkqcUu9xUbI7qblTofx1P-A4gP6J-4D2oEvphE/edit?hl=en_USauthkey=CPmx59wF Cheers, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice (filters) mrcekets * filter/source/svg/ (7 files): Enhancing svg export
Hi Joseph, I applied your patch and works smoothly. I'll integrate it in my next commit/patch-set. Cheers, Marco On Fri, 08 Jul 2011 07:50:56 +0200, Joseph Powers jpower...@cox.net wrote: Can you verify that I didn't break your patch? My compiler (i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5494)) didn't like some of your code: /Users/jpowers27/LibO/clone/filters/filter/source/svg/svgexport.cxx: In member function 'sal_Bool SVGFilter::implExportDocument()': /Users/jpowers27/LibO/clone/filters/filter/source/svg/svgexport.cxx:798: error: call of overloaded 'valueOf(int)' is ambiguous /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1371: note: candidates are: static rtl::OUString rtl::OUString::valueOf(sal_Bool) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1385: note: static rtl::OUString rtl::OUString::valueOf(sal_Unicode) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1399: note: static rtl::OUString rtl::OUString::valueOf(sal_Int32, sal_Int16) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1416: note: static rtl::OUString rtl::OUString::valueOf(sal_Int64, sal_Int16) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1432: note: static rtl::OUString rtl::OUString::valueOf(float) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1448: note: static rtl::OUString rtl::OUString::valueOf(double) /Users/jpowers27/LibO/clone/filters/filter/source/svg/svgexport.cxx:799: error: call of overloaded 'valueOf(int)' is ambiguous /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1371: note: candidates are: static rtl::OUString rtl::OUString::valueOf(sal_Bool) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1385: note: static rtl::OUString rtl::OUString::valueOf(sal_Unicode) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1399: note: static rtl::OUString rtl::OUString::valueOf(sal_Int32, sal_Int16) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1416: note: static rtl::OUString rtl::OUString::valueOf(sal_Int64, sal_Int16) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1432: note: static rtl::OUString rtl::OUString::valueOf(float) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1448: note: static rtl::OUString rtl::OUString::valueOf(double) /Users/jpowers27/LibO/clone/filters/filter/source/svg/svgexport.cxx: In member function 'long int SVGFilter::CalcFieldHdl(EditFieldInfo*)': /Users/jpowers27/LibO/clone/filters/filter/source/svg/svgexport.cxx:1900: error: call of overloaded 'valueOf(sal_Int16)' is ambiguous /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1371: note: candidates are: static rtl::OUString rtl::OUString::valueOf(sal_Bool) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1385: note: static rtl::OUString rtl::OUString::valueOf(sal_Unicode) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1399: note: static rtl::OUString rtl::OUString::valueOf(sal_Int32, sal_Int16) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1416: note: static rtl::OUString rtl::OUString::valueOf(sal_Int64, sal_Int16) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1432: note: static rtl::OUString rtl::OUString::valueOf(float) /Users/jpowers27/LibO/solver/350/unxmacxi.pro/inc/rtl/ustring.hxx:1448: note: static rtl::OUString rtl::OUString::valueOf(double) dmake: Error code 1, while making '../../unxmacxi.pro/slo/svgexport.obj' My patch is: Fix some ambiguous method errors. commit bcf2a91f74e5c9ffe4b2978d53b7031a85d89ae4 (patch) Thanks, Joe P. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix crash when selecting target after inserting hyperlink to database document
Hi I tried to Libreoffice 3.3.2 but for ODB extention is OK, adn there is a problem in .ODT extention. In .ODT the writer crash . This patch can fixe the bug to ODT too? The problem: Creating,an hyperlink to a document in a FTP, the writer crashes and close after press Ctrl + click, for a ODT document. For PDF or TXT for exemple it's OK. So the problem seems to be just for ODT extention. For ODS extention the screen just blink and nothing happens. Steps to reproduce this problem: 1- create files in a ftp, like ftp://ftp-corp.myplace/global/test.odt 2 - right button on the file and option ''copy link 3 - open the writer (new file) , in the blank page option ''insert'' hyperlink 4 - option internet, then select FTP 5 - paste the hyperlink copied 6 - apply and close 7 - on the hyperlink press Ctrl + click 8 - at this point the writer crash and close (this for an ODT file) PS: for an ODS file at this point the screen just blink and do nothing PS2: for an PDF or TXT file it's OK Using: Ubuntu: Ubuntu 10.04 LTS - Lucid Lynx - LibreOffice/Broffice 3.3.2 Correct result: open an ODT document linked to a FTP by an hyperlink on the writer. -- View this message in context: http://nabble.documentfoundation.org/REVIEW-Fix-crash-when-selecting-target-after-inserting-hyperlink-to-database-document-tp3128700p3152885.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] [GSoC 2011][svgexport] set of patches based on master
OK, I get on Windows: Compiling: filter/source/svg/svgexport.cxx c:\master\clone\filters\filter\source\svg\svgscript.hxx(461) : error C2026: string too big, trailing characters truncated c:\master\clone\filters\filter\source\svg\svgscript.hxx(893) : error C2026: string too big, trailing characters truncated c:\master\clone\filters\filter\source\svg\svgscript.hxx(1288) : error C2026: string too big, trailing characters truncated dmake: Error code 2, while making '../../wntmsci12.pro/slo/svgexport.obj' Is there a way to make those strings split into smaller parts, or something. I don't know whether using std::string would not make it pass??? F. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
Hi Peter, sorry for randomly jumping in with just some side-notes ... Am 06.07.2011 22:10, schrieb Peter Jentsch: I'm unsure about where to put the xliff files, because I'm completely ignorant of the translation workflow and the different places where translatable items are put in order to get easily picked up by translators. If we want to go that way, Andras Timar might have an idea about where to store this stuff. Plus, I found xliff allows for a lot of things, and the Xslt script will make a few assumptions on how (simple) the xliff file is structured, so the process might break easily if the translation tools want to do nasty things with the xliff file (that a fully working xliff toolchain would be required to understand). But maybe that's not happening anyway, and in practice it's less complex than it looks on first sight. Afaik there is hardly any fully working FOSS-based xliff toolchain that includes translation editors and complext xliff files. Translate toolkit has a quite good support for XLIFF - po conversion (as long as you do not use advanced xliff features). If we want to go that way, I could test the conversion and how this works for a translator. regards, André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
