[Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
Hello, this patch might be a bit to big for 3-4, but who knows: http://cgit.freedesktop.org/libreoffice/core/commit/?id=04d2e6469529b6187900659517d6f6dd5ea2cca5 We have three related problems: -database range tokens must be adjusted when we copy between different documents -global/local range name tokens must be updated when we copy between different documents -local range name tokens must be updated when we copy them between different sheets If we don't update the tokens in the formula cells they may point to different entries after the copy process. I think we have an additional related problem that might be gone with this patch. If we have an external sheet it will be copied when we load the file. This seems to result in some corner case that the range names in formulas are messed up. I haven't found the bug report for this problem at the moment. The idea behind this patch is quite simple. For every ScNameToken we need to update the index and for all range names also set the flag for local/global range names. For range names we first extract the name and then search for the name in the local and global range name container, then we can set the token to the correct index and set the local/global flag. For database ranges we only have a global container, so we just need to get the database data name and then search for this name in the new database range container. I plan to use this as a base for changing the copy/paste code in master: we can use this code to remove the part that copies all range names to the new document/sheet. Instead we can now only copy the relevant range names to the new document. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to call from one component to another (sw-starmath)
On Monday 15 of August 2011, Miklos Vajna wrote: On Mon, Aug 15, 2011 at 05:16:17PM +0200, Lubos Lunak l.lu...@suse.cz wrote: I'm implementing .docx OOXML support for writing math formulas. As this is something that could be used not only by Writer but also by other components, I want to implement the writing of the formula in Starmath. And even if I didn't want, Sm* classes (which implement and store the formulas) are in starmath/ , and sw-starmath do not link against each other. So, the question is, how do I call from sw to starmath without linking them together? I checked how the binary .doc filter does it, and it goes via ~10 calls deep [1] that call some UNO interfaces and store the result in some private stream or whatever. But I find that needlessly complicated, as I already have a pointer to SmModel and SmDocShell (I can get it the same way the .doc code does) and just need to call their method, passing the XML serializer object as an argument, that's it. The best I've come up with creating let's say offapi/com/sun/star/starmath/WriteMath.idl with the function, make SmModel inherit from that and castcall using it in sw. But I have not much idea about UNO, so I don't know what the stuff under offapi/ actually really is about. Is this a good solution or does somebody know something better? That looks fine, that's how the rest of writerfilter can live without the Sw* classes. Did you check if the existing uno api is enough for you? See the output of 'git ls-files starmath|grep uno'. If yes, then you don't have to mess with offapi. :) You missed two important parts :). I'm implementing, so this is new code and thus no existing UNO API, and more importantly, needlessly complicated, which means I'll probably still rather go with those 10 nested calls than introduce the hard-to-develop-and-debug UNO writerfilter nightmare to new code. Trying with offapi has turned out to be equally complicated, all the involved classes need to be based on UNO interfaces and then comes trouble with refcounting (no wonder some places in the codebase are such messed up hacks, when trying to do things properly makes one realize it's just not worth the effort). For now I've just linked sw to starmath locally so that I can actually develop something. If no better solution turns up, I think I'll eventually go for the simple and working way of introducing a plain C++ interface class in some library that both sw and starmath use and go with that. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Remove duplicated chunk in windows.mk
Attached patch will remove the duplicated chunk from windows.mk. The original one is above my delete. Applied, and pushed, thanks! --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] UNO API reference?
Hi Kevin, Kevin Hunter wrote (16-08-11 01:07) Do we have, or is there a canonical reference for the UNO API? Specifically with Python bindings? The various references I've been able to find online seem haphazard at best. Is that what we have to work with, or is there an obvious link I've overlooked? The obvious (start for) reference of course is http://api.openoffice.org/ So I guess you must have investigated that one.. -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Base fdo#40079 file / save (as) inoperant
Hello Lionel On 15/08/11 13:10, Lionel Elie Mamane wrote: When the Standard Basic Macro Library for the document is loaded (which happens implicitly as soon as a macro is executed), but not the Standard Dialog Library, the File / Save action (or the equivalent toolbar button) does nothing, without error message. I would like to have a look at this, be a little patient as I never looked too deeply into this part of the code you are patching ( although the embeddedimages part seems like something I added :-) ) Two questions, a) did you try this on master ( I did and it appeared to work as expected ) but I am pretty 'base' disabled so I fear I may have missed something in trying to recreate it b) is this behaviour specific to base documents? ( again I tested against master ) and it appears not and if so then I wonder what does base do differently from 'normal' documents and why sigh I also tried this on 3.4 but it appears even loading base documents causes some core ( but perhaps this is due to a stale build/install ) - I will build from clean later Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Updated extensions
Kálmán „KAMI” Szalai píše v Po 15. 08. 2011 v 18:41 +0200: Hi Petr, AFAIK the LO is not affected by these changes. None of these extensions is packed by LibreOffice. They might be already used by distro builds. Your changes might bring them regressions. How much did you test the new extensions? ;-) The updates of LightProof was: - support multiple options in the same line in the Options dialog - new functions: stem(), generate() This sounds like features. Google Docs extension is hosted here: http://code.google.com/p/ooo2gd/ You can check the changes here. I am unable to find the changes easily :-( SmART is hosted here: https://ooop.svn.sourceforge.net/svnroot/ooop/trunk/extensions/smart/ * four new diagrams * keyboard shorcuts * preview for edit * more color themes * convertion of diagrams * editing text from edit bar This sounds like bigger changes. I still quite scared by the update. I do not want to decide it by myself, so proposed to discuss this on TSC meeting on Thursday. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Base fdo#40079 file / save (as) inoperant
probably I should have read further before replying ;-) ( sorry excuse for a mind is elsewhere at the moment ) On 15/08/11 13:10, Lionel Elie Mamane wrote: So probably what happened is that the // Can we simply copy the storage? optimisation / fast path was added and suddenly SfxLibraryContainer::storeLibrariesToStorage does not anymore load the libraries, as the rest of the code in SfxDialogLibraryContainer::storeLibrariesToStorage expected, which would suggest that my patch is the right fix. this sounds very plausible The remaining question is: if xSourceLibrariesStor-copyElementTo was called, does the code under: // we need to export out any embedded image object(s) // associated with any Dialogs. First, we need to actually gather any such urls // for each dialog in this container still need to be run? In other words, has copyElementsTo copied these embedded image objects, or not? not at all sure but it should be easy enough to test, in your dialog create an image control, right click to get the property sheet for the control, under the general tab scroll down to the Graphics property, click on the '...' to select a graphic, make sure you unselect the 'link' check box to ensure the image is embedded. After saving, the image should be stored in it's own document stream. After testing with your 'modification' scenario ( e.g. run macro, make change, re-save ) when you open the dialog the image should be still there ( best of course to check that after restarting libreoffice and re-opening the document ) Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Remove duplicated chunk in windows.mk
Add PUSHED tag to subject... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to call from one component to another (sw-starmath)
On Mon, 2011-08-15 at 17:16 +0200, Lubos Lunak wrote: Hello, I'm implementing .docx OOXML support for writing math formulas. As this is something that could be used not only by Writer but also by other components, I want to implement the writing of the formula in Starmath. And even if I didn't want, Sm* classes (which implement and store the formulas) are in starmath/ , and sw-starmath do not link against each other. So, the question is, how do I call from sw to starmath without linking them together? I checked how the binary .doc filter does it, and it goes via ~10 calls deep [1] that call some UNO interfaces and store the result in some private stream or whatever. SvxMSExportOLEObjects::ExportOLEObject seems to have blown out of control but the first and last branches are the typical ones. If it's a generic object then copy it's storage under the destination storage unchanged. If it's one of the special things that have an analogue in the destination format save it to a temporary storage in another format and copy that into the destination format instead. //export to temporary stream pStream ::uno::Reference io::XOutputStream xOut = new ::utl::OOutputStreamWrapper( *pStream ); aSeq[0].Value = xOut; xStor-storeToURL( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( private:stream )), aSeq ); //copy result to destination ole2 storage SotStorageRef xOLEStor = new SotStorage( pStream, sal_True ); xOLEStor-CopyTo( rDestStg ); I already have a pointer to SmModel and SmDocShell (I can get it the same way the .doc code does) and just need to call their method, passing the XML serializer object as an argument, that's it. Probably matters what the destination format is like ? Is it a standalone thing and/or exists in a substorage/folder of the parent format where it doesn't care about what it is inside ? i.e. I'd sort of expect to basically just add another export filter to starmath for whatever that format is, add it to SmDocShell::ConvertTo and call that directly/indirectly. And have a save as... entry for the format if it makes sense to have it standalone ? That's not going to work if the destination format needs hooks back into its surrounding container. Is that the problem ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to call from one component to another (sw-starmath)
On Tuesday 16 of August 2011, Caolán McNamara wrote:
On Mon, 2011-08-15 at 17:16 +0200, Lubos Lunak wrote:
I already have a pointer to SmModel and SmDocShell (I can get it the same
way the .doc code does) and just need to call their method, passing the
XML serializer object as an argument, that's it.
Probably matters what the destination format is like ? Is it a
standalone thing and/or exists in a substorage/folder of the parent
format where it doesn't care about what it is inside ? i.e. I'd sort of
expect to basically just add another export filter to starmath for
whatever that format is, add it to SmDocShell::ConvertTo and call that
directly/indirectly. And have a save as... entry for the format if it
makes sense to have it standalone ?
The destination format is OOXML, and the formula is a part of one .xml file.
It is standalone in the way that the whole formula is stored by starmath
using Sm* classes and the XML subtree can be written out independently on the
rest of the file. It is not standalone in the way that is it part of the .xml
file and needs to be positioned inside the proper XML elements of the writer
document.
So using private streams is either not possible or only a complication
depending on whether two sax_fastparser::FastSerializerHelper objects can be
nested (I don't feel like trying, for these reasons). A standalone export
file also wouldn't be right, as the formula needs to be inside a valid
document.
That's not going to work if the destination format needs hooks back into
its surrounding container. Is that the problem ?
No, starmath doesn't need to call back to writer. The problem is that this is
still needlessly complicated. How about the attached patch?
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/filter/inc/filter/msfilter/ooxmlexport.hxx b/filter/inc/filter/msfilter/ooxmlexport.hxx
new file mode 100644
index 000..6ec0594
--- /dev/null
+++ b/filter/inc/filter/msfilter/ooxmlexport.hxx
@@ -0,0 +1,46 @@
+/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+/*
+ *
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * Copyright 2000, 2010 Oracle and/or its affiliates.
+ *
+ * OpenOffice.org - a multi-platform office productivity suite
+ *
+ * This file is part of OpenOffice.org.
+ *
+ * OpenOffice.org is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License version 3
+ * only, as published by the Free Software Foundation.
+ *
+ * OpenOffice.org is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License version 3 for more details
+ * (a copy is included in the LICENSE file that accompanied this code).
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * version 3 along with OpenOffice.org. If not, see
+ * http://www.openoffice.org/license.html
+ * for a copy of the LGPLv3 License.
+ *
+ /
+#ifndef _OOXMLEXPORT_HXX
+#define _OOXMLEXPORT_HXX
+
+#include sax/fshelper.hxx
+#include filter/msfilter/msfilterdllapi.h
+
+/**
+ Interface class, StarMath will implement writeFormulaOoxml() to write out OOXML
+ representing the formula.
+ */
+class MSFILTER_DLLPUBLIC OoxmlFormulaExportBase
+{
+public:
+virtual void writeFormulaOoxml( ::sax_fastparser::FSHelperPtr m_pSerializer ) = 0;
+};
+
+#endif
+
+/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/starmath/Library_sm.mk b/starmath/Library_sm.mk
index 034bf60..ce22bc5 100644
--- a/starmath/Library_sm.mk
+++ b/starmath/Library_sm.mk
@@ -47,7 +47,9 @@ $(eval $(call gb_Library_add_linked_libs,sm,\
cppuhelper \
editeng \
i18npaper \
+msfilter \
sal \
+sax \
sfx \
sot \
svl \
diff --git a/starmath/inc/unomodel.hxx b/starmath/inc/unomodel.hxx
index 693ea3b..15ada7b 100644
--- a/starmath/inc/unomodel.hxx
+++ b/starmath/inc/unomodel.hxx
@@ -37,6 +37,7 @@
#include sfx2/sfxbasemodel.hxx
#include comphelper/propertysethelper.hxx
#include vcl/print.hxx
+#include filter/msfilter/ooxmlexport.hxx
class SmFormat;
@@ -63,7 +64,8 @@ public:
class SmModel : public SfxBaseModel,
public comphelper::PropertySetHelper,
public com::sun::star::lang::XServiceInfo,
-public com::sun::star::view::XRenderable
+public com::sun::star::view::XRenderable,
+public OoxmlFormulaExportBase
{
SmPrintUIOptions* m_pPrintUIOptions;
protected:
@@ -100,6 +102,9 @@ public:
virtual void SAL_CALL setParent( const ::com::sun::star::uno::Reference ::com::sun::star::uno::XInterface xParent ) throw(
Re: [Libreoffice] Fix crash when selecting target after inserting hyperlink to database document
On Fri, 2011-07-08 at 12:25 -0700, Skeld Stu wrote: Creating,an hyperlink to a document in a FTP... That is probably/hopefully related to a different ftp specific thing, e.g. https://bugs.freedesktop.org/show_bug.cgi?id=39376 https://bugs.freedesktop.org/show_bug.cgi?id=34880 i.e. if the file on ftp doesn't happen to be a round multiple of bytes of the buffer-size of the temp file copy loop then it ends up being considered corrupt. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [review] load of ftp-hosted documents fails
i.e. http://cgit.freedesktop.org/libreoffice/core/commit/?id=3ae98a0ca5329a0205728a46b4e5dd0d4b46a9f3 proposing for 3-4 old code will basically not distinguish between eof and error, and throw an exception on all short reads. probably fixes https://bugs.freedesktop.org/show_bug.cgi?id=34880 and probably https://bugs.freedesktop.org/show_bug.cgi?id=39376 as well. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Suggestion and patch for Confirmation of save format dialog
Hi Josh, On Thu, 2011-08-11 at 12:29 +0930, Josh Heidenreich wrote: I have made some additional changes to the dialog. I am considering these changes stage 1 of the process. wow - this is cool :-) I've hated that dialog with a passion for its highly confusing choice, and the text above it which I've had to read again and again each time I see it ;-) [ and seen my wife struggle over too ]. Your patch makes it much better. I suspect this also ties into button ordering: I expect the sensible choice to be the bottom right button under gnome etc. Another hint we have from the user over what they want to do is probably the auto-selected filter from the 'Save As' dialog - ie. if someone typed: foo.doc in there, to select the .doc type - almost inevitably they know what they are doing, and shouldn't be bothered ;-) [ but perhaps the don't bother me again check-box copes with them ]. Anyhow - fantastic to have you polishing the UI like this, most encouraging. FWIW - it is good practise to CC the: libreoffice-ux-adv...@lists.freedesktop.org list on this sort of thing, so the UI guys can easily track and give advice on this sort of thing without needing to scan the list. Thanks again, 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 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 36547, which changed state. Bug 36547 Summary: Impress: Rendering problems with some .odp files https://bugs.freedesktop.org/show_bug.cgi?id=36547 What|Old Value |New Value Resolution||DUPLICATE Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Improve the alien save dialog (part one)
By which (I hope) you mean: LGPLv3+/MPL ? :-) Yes, my bad. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Cherry-pick in 3.4.2?
Caolán McNamara wrote: On Thu, 2011-08-11 at 15:36 +0200, Cedric Bosdonnat wrote: I fixed fdo#37403 a while ago, and Rainer asked if we could cherry-pick http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=21ec661d09ed9d7bbbec5e52ee2b382d8c465324 to 3.4.2. Forgot all about that one. Don't you end up with one single mpXPoly polygon shared between two different SdrRectObj so changes to the held polygon in one SdrRectObj is seen in the other ? i.e. should give SdrRectObj a proper copy ctor/assignment operator instead/additionally rather than using the compiler generated one, which is presumably why two SdrRects ended up holding the same raw mpXPoly in the first place. Indeed that remembers me of a discussion like that with Lubos... though I'm not good enough in C++ to see those subtleties. I reverted the above mentioned patch and replaced it by http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3852d41a419331277d0b98b02792f0bbf704d5b All is now working fine, and that later commit could be applied to 3.4 safely. Thanks for the reminder -- Cedric -- View this message in context: http://nabble.documentfoundation.org/REVIEW-Cherry-pick-in-3-4-2-tp3245931p3258528.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 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #187 from Olivier Hallot olivier.hal...@documentfoundation.org 2011-08-16 05:53:54 PDT --- Nominate bug 40113 in 3.4.x branch. Spreadsheet header/footer background does not display color or image. -- 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] [GSoc] Mentors: Final Evaluation Questions
Hello fellow mentors, I'm just forwarding you an email from Carol Smith handling the GSoc at Google. It contains all the questions for the final evaluation if you want to think about them in advance. Remember: the final evaluations are next week from Monday to Friday. Forwarded Message From: Carol Smith car...@google.com To: Google Summer of Code Mentors List google-summer-of-code-mentors-l...@googlegroups.com Subject: [Announce] GSoC 2011 Mentors/Org Admins: Final Evaluation Questions Date: Mon, 15 Aug 2011 09:55:18 -0700 Hi everyone, As promised, here are the questions for the final evaluations next week. Final evaluations are due 26 August at 19:00 UTC. Mentor evaluations, as always, are required for all mentors with assigned students participating in the program. Co-mentors may edit and modify the evaluations as they see fit during the evaluation window. Please let me know if you have any further questions. Cheers, Carol 1. How would you rate the student’s performance on his/her project since the midterm evaluations? 1. It has improved since the midterm 2. It has stayed the same since the midterm 3. It has gotten worse since the midterm 2. Considering your student’s original project proposal, how closely does the project produced reflect the project proposed? 1. It’s almost exactly the same - there have been very few changes to the project 2. It’s similar - there have been some changes over the course of the summer 3. It’s different - we changed the goals or scope of the project 4. It’s different - the student diverged from the project plan 3. How much time have you spent on Google Summer of Code since the midterm evaluations (again, take into consideration both time mentoring the student and working on the program as a whole)? 1. 10-15 hours per week 2. 15-20 hours per week 3. 20-25 hours per week 4. 25-30 hours per week 5. 30-35 hours per week 6. 35-40 hours per week 7. 40+ hours per week 4. How does this amount of time compare to before the midterms? 1. It’s less then before the midterms 2. It’s about the same 3. It’s more than before the midterms 5. How would you rate your student’s performance overall? 1. Excellent - amongst the best performers I’ve ever worked with 2. Strong, solid performance 3. Okay 4. Poor 6. How would you rate your experience with the program overall? 1. Excellent - one of the best programs I’ve ever participated in 2. Very good 3. Okay 4. Poor 7. Did you have a co-mentor in the program this year? If so, would you consider this a help or a hindrance? Why? 8. What one thing would you tell mentors for your organization to do in the future to help the students’ experience with the program? 9. What was the most rewarding and/or difficult part of the program for you this year? 10. Anything else you’d like to tell us? -- You received this message because you are subscribed to the Google Groups Google Summer of Code Mentors List group. To post to this group, send email to google-summer-of-code-mentors-l...@googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to call from one component to another (sw-starmath)
Hi Lubos, On Tue, 2011-08-16 at 12:09 +0200, Lubos Lunak wrote: No, starmath doesn't need to call back to writer. The problem is that this is still needlessly complicated. How about the attached patch? I like it's simplicity personally :-) though of course we should use core/TEMPLATE.SOURCECODE.HEADER in new files, and I'm not the world's biggest fan of dynamic_cast but ... Go for it, if someone wants to overcomplicate and slow it down later, they can always do 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] [REVIEW] Cherry-pick in 3.4.2?
On Tuesday 16 of August 2011, cbosdonnat wrote:
Caolán McNamara wrote:
On Thu, 2011-08-11 at 15:36 +0200, Cedric Bosdonnat wrote:
Indeed that remembers me of a discussion like that with Lubos... though I'm
not good enough in C++ to see those subtleties. I reverted the above
mentioned patch and replaced it by
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3852d41a419331277d
0b98b02792f0bbf704d5b
+SdrRectObj SdrRectObj::operator=(const SdrRectObj rCopy)
+{
+if ( this == rCopy )
+return *this;
+
+SdrTextObj::operator=( rCopy );
+
+if ( rCopy.mpXPoly )
+mpXPoly = new XPolygon( *rCopy.mpXPoly );
This is not completely correct. This is not copy ctor, so mpXPoly does not
have any default value, but instead whatever was there before the assignment.
You need to handle the else case as well.
If this is fixed, you have my ACK.
+
+return *this;
+}
All is now working fine, and that later commit could be applied to 3.4
safely.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Cherry-pick in 3.4.2?
On Tue, 2011-08-16 at 05:48 -0700, cbosdonnat wrote: All is now working fine, and that later commit could be applied to 3.4 safely. Sorry, not trying to be a pain or anything, but that assignment operator now leaks the original mpXPoly of the SdrRectObj that's assigned to if there was one. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] l10n and translations
On Thu, 2011-08-04 at 13:38 +0400, Dmitry A. Ashkadov wrote: I don't understand what is a difference between «l10n» and «translations» repositories. Can You explain me? I plan to go through add update the repo descriptions to add this information there at some stage soon :-) 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] Template for copyright headers is cumbersome (was Re: How to call from one component to another (sw-starmath))
On Tuesday 16 of August 2011, Michael Meeks wrote: Hi Lubos, On Tue, 2011-08-16 at 12:09 +0200, Lubos Lunak wrote: No, starmath doesn't need to call back to writer. The problem is that this is still needlessly complicated. How about the attached patch? I like it's simplicity personally :-) though of course we should use core/TEMPLATE.SOURCECODE.HEADER in new files I simply copypasted from other file, I didn't notice we have this. I'll fix. However, I can't help noticing that the template layout is ... er, not suitable for easy use: - Since by the time a file is created there is usually only the initial developer, there are not major contributors. The major contributors section, as it is worded, cannot be left in with an empty list, so it needs to be removed. Whoever becomes a major contributor later has to re-add the section. - Besides the above problem, the Portions created by the Ted are Copyright (C) 2010 Ted. All Rights Reserved. section makes it likely to overlook that a number of our new files will be copyrighted by Ted, whoever that is. - Similarly, the 2010 is quite well hidden in there and unlikely to make it to 2011 or beyond :). I don't know who's responsible for the template, but can it be made more simple to use? Preferably so that adding a new contributor is just adding one line, and updating the year is done in one visible place? Either the copyright header matters, and in that case it shouldn't be made easy for developers to mess it up, or the copyright header doesn't really matter much, and then changes making it easy to fill it in don't really matter much either. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] development summary: year 2011, week 31
Hi, this time a brief summary of what happened during the 31th week in 2011 on LibreOffice repositories and the living branches: + master:LO-3.5 development + libreoffice-3-3: fixes for LO-3.3.4 bug fix release + libreoffice-3-4: fixes for LO-3.4.2 bug fix release There are two logs for each branch: + bugfixes-branch-week-year-week.txt lists all commits that reference a proper bug id from a variety of trackers, i.e. #i... referring to the OpenOffice issuezilla, fdo# to freedesktop, rhbz# to RedHat bugzilla + commit-log-branch-week-year-week.txt lists all relevant commits on the actual source repositories Many thanks to all contributors - you make all the difference! Best Regards, Petr Nothing this week + calc + [PATCH] fix for defining named ranges should be case insensitiv (fdo#39915) [Markus Mohrhard] + fix for changes to range names invalidate stream too (fdo#39792) [Markus Mohrhard] + fix for check for empty local range names (fdo#39728) [Markus Mohrhard] + fix for crash with hidden column in Data-Form (fdo#39773) [Markus Mohrhard] + fix for don't write password algorithm in odf 1.0 and 1.1 (fdo#39678) [Markus Mohrhard] + fix for set correct table number in local db data (fdo#39151) [Markus Mohrhard] + the previous commit is for not for fdo#. (bnc#707486) [Kohei Yoshida] + use the correct clip doc instance to copy to. (fdo#707486) [Noel Power] + components + related changes in split components repository to support LCID changes (fdo#38956) [Eike Rathke] + impress + missing icon in Styles and Formatting dialog in Impress (fdo#38382) [Andras Timar] + libs-core + fix memory exhaustion with String length of STRLEN_MAX (fdo#39869) [Eike Rathke] + related changes in split libs-core repository to support LCID changes (fdo#38956) [Eike Rathke] + libs-gui + fix discarding bracketed prefixes in number formats, such as [RED] (fdo#38956) [Eike Rathke] + writer + backport fix (fdo#32899) [os] + it really is a LineBorder not a LineBorder2 (fdo#37693) [Caolán McNamara] + related: crash in new field code (i#38880) [Caolán McNamara] + bootstrap + add one more libdir path for detection with qt4 on 32b platform to be same with 64b. Fixes gentoo bug . (#377377) [Tomáš Chvátal] + calc + fix for check for empty local range names (fdo#39728) [Markus Mohrhard] + fix for crash with hidden column in Data-Form (fdo#39773) [Markus Mohrhard] + fix for set correct table number in local db data (fdo#39151) [Markus Mohrhard] + components + related changes in split components repository to support LCID changes (fdo#38956) [Eike Rathke] + impress + clean-up of bugfix for the master branch (fdo#32895) [Peter Rabi] + missing icon in Styles and Formatting dialog in Impress (fdo#38382) [Andras Timar] + styles import: Improve speed as well as fix/avoid (bnc#708518) [Muthu Subramanian] + libs-core + clean-up of bugfix for the master branch (fdo#32895) [Peter Rabi] + fix memory exhaustion with String length of STRLEN_MAX (fdo#39869) [Eike Rathke] + related changes in split libs-core repository to support LCID changes (fdo#38956) [Eike Rathke] + libs-extern-sys + backport fix for (py#4768, fdo#36763) [Caolán McNamara] + libs-gui + fix crash from unhandled exception (rhbz#693265) [Caolán McNamara] + fix discarding bracketed prefixes in number formats, such as [RED] (fdo#38956) [Eike Rathke] + preserve time when editing even if only date was displayed (fdo#34977) [Eike Rathke] + writer + related: crash in new field code (i#38880) [Caolán McNamara] + common + version 3.3.4.1, tag libreoffice-3.3.4.1 (3.3.4-rc1) [Petr Mladek] + bootstrap + bump product version to 3.3.4-rc1, release number to 401 [Petr Mladek] + build + version 3.3.4.1, tag libreoffice-3.3.4.1-buildfix1 (3.3.4-rc1) [Petr Mladek] + artwork + why backing_rtl_left.png contained BrOffice? [Andras Timar] + calc + [PATCH] fix for defining named ranges should be case insensitiv (fdo#39915) [Markus Mohrhard] + fix for changes to range names invalidate stream too (fdo#39792) [Markus Mohrhard] + fix for check for empty local range names (fdo#39728) [Markus Mohrhard] + fix for crash with hidden column in Data-Form (fdo#39773) [Markus Mohrhard] + fix for don't write password algorithm in odf 1.0 and 1.1 (fdo#39678) [Markus Mohrhard] + fix for set correct table number in local db data (fdo#39151) [Markus Mohrhard] + the previous commit is for not for fdo#. (bnc#707486) [Kohei Yoshida] + use the correct clip doc instance to copy to. (fdo#707486) [Noel Power] + components + related changes in split components repository to support LCID changes (fdo#38956) [Eike Rathke] + impress + missing icon in Styles and Formatting dialog in Impress (fdo#38382) [Andras Timar] + libs-core + fix memory exhaustion with String length
[Libreoffice] development summary: year 2011, week 32
Hi, this time a brief summary of what happened during the 32nd week in 2011 on LibreOffice repositories and the living branches: + master:LO-3.5 development + libreoffice-3-3: fixes for LO-3.3.4 bug fix release + libreoffice-3-4: fixes for LO-3.4.2 bug fix release There are two logs for each branch: + bugfixes-branch-week-year-week.txt lists all commits that reference a proper bug id from a variety of trackers, i.e. #i... referring to the OpenOffice issuezilla, fdo# to freedesktop, rhbz# to RedHat bugzilla + commit-log-branch-week-year-week.txt lists all relevant commits on the actual source repositories Many thanks to all contributors - you make all the difference! Best Regards, Petr Nothing this week. + calc + [PATCH] fix for defining named ranges should be case insensitiv (fdo#39915) [Markus Mohrhard] + correctly import from Excel charts with multiple ranges. (i#107275) [Kohei Yoshida] + fix for don't write password algorithm in odf 1.0 and 1.1 (fdo#39678) [Markus Mohrhard] + impress + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + libs-core + add a modification listener on new XDocumentProperties (fdo#32177) [Caolán McNamara] + fix for - no update preview (fdo#34768) [Peter Rabi] + libs-extern-sys + backport fix for (py#4768, fdo#36763) [Caolán McNamara] + ure + related: on windows find the openssl libs that _ssl.pyd needs (fdo#34184) [Caolán McNamara] + writer + don't restore original view settings on temp documents (fdo#39159) [Caolán McNamara] + core + import/export xrefs to numbered paras (fdo#33960) [Troy Rollo] + add a modification listener on new XDocumentProperties (fdo#32177) [Caolán McNamara] + change the UI for PDF hybrid files export (fdo#39167) [Gabor Jenei] + correctly import from Excel charts with multiple ranges. (i#107275) [Kohei Yoshida] + don't restore original view settings on temp documents (fdo#39159) [Caolán McNamara] + fix (fdo#39561) [Christophe Strobbe] + fix for - no update preview (fdo#34768) [Peter Rabi] + fix for defining named ranges should be case insensitive (fdo#39915) [Markus Mohrhard] + fix for don't write invalid references to files (fdo#37391) [Markus Mohrhard] + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + implement new rule for xref to numbered paragraphs (fdo#33960) [Troy Rollo] + implement saving/loading PROPVARIANT::DATE ole2 property (fdo#38981) [Caolán McNamara] + improve column/table width when table width pagewidth (bnc#693477) [Noel Power] + initial support for the textbox shape (fdo#37691) [Miklos Vajna] + partially reverted 96336b01a8e2836a3cabe407a92ac5d7b5ac5bf7. (fdo#37391) [Kohei Yoshida] + print current page in the Print dialog, . (fdo#34697) [Ta Duc Tung] + related: avoid segv in ld, this was set to -O0 around 2000 (rhbz#730225) [Caolán McNamara] + restore original semantics of GDIMetaFile::ReplaceAction (fdo#39995) [Caolán McNamara] + write and read [#REF!] in ODFF for reference errors (fdo#37391) [Eike Rathke] + help + updated the help for the UI changes of PDF export dialog (fdo#39167) [Cédric Bosdonnat] + calc + prevent crash at column row boundaries. [Eike Rathke] + bootstrap + use proper switch name for system-sane-headers [Tomáš Chvátal] + calc + [PATCH] fix for defining named ranges should be case insensitiv (fdo#39915) [Markus Mohrhard] + correctly import from Excel charts with multiple ranges. (i#107275) [Kohei Yoshida] + fix for don't write password algorithm in odf 1.0 and 1.1 (fdo#39678) [Markus Mohrhard] + prevent crash at column row boundaries. [Eike Rathke] + use delete[] for arrays allocated with new[] [Markus Mohrhard] + filters + fix build breaker [Noel Power] + fix for valgrind error in msdffimp.cxx [Marc-Andre Laverdiere] + set link text properties [Radek Doulik] + impress + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + libs-core + add a modification listener on new XDocumentProperties (fdo#32177) [Caolán McNamara] + fix for - no update preview (fdo#34768) [Peter Rabi] + libs-extern-sys + backport fix for (py#4768, fdo#36763) [Caolán McNamara] + ure + delete unintentional stray osl_trace [Noel Power] + related: on windows find the openssl libs that _ssl.pyd needs (fdo#34184) [Caolán McNamara] + round allocated struct return space to sizeof(size_t) [Caolán McNamara] + writer + don't restore original view settings on temp documents (fdo#39159) [Caolán McNamara] + fixed invalid array bounds read in ww8scan.cxx [Marc-Andre Laverdiere] + fixed invalid array dereference [Marc-Andre Laverdiere] + fixed invalid pointer dereference [Marc-Andre Laverdiere] + fixed valgrind error [Marc-Andre Laverdiere] + fixes for segfault on an
Re: [Libreoffice] Class Time and its funny ideas about time
On Thu, 2011-08-11 at 16:55 +0200, Thorsten Behrens wrote: It's unclear to me, how valuable it is to fix-up tools/time.hxx all client code, vs. to use e.g. http://www.boost.org/doc/libs/1_47_0/doc/html/chrono.html when you need a sane implementation in new code ... Huh - it is -extremely- valuable to do global cleans that remove unpleasant and hard-to-grok implementations from the code. Just using the latest/newest/trendiest 'time' class from A.B.C. place de jour in new code is a(nother) maintenance nightmare waiting to happen :-) we've had enough of that in the codebase. I like Lubos' attitude. Quite possibly we should have an easy hack to re-work the time code everywhere (along with adding suitable unit-tests). 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] [REVIEW] 4 minutes 27 seconds - 11 seconds
Caolan McNamara wrote: I'm *sure* its good, but the scale of speed-up from 4 minutes 27 seconds to 11 seconds is massively more than I expected. Especially as the insert point is at the end, rather than at the beginning or middle which would have required a lot of memmove type operations. Played with it today, surely ::append is on a critical path, but beats me why exactly this is so much faster. Surely it saves some temporary B2DPolygon instances... ...random theory of the day: does vector::reserve() always ensure factor-of-two growth? Cheers, -- Thorsten pgpRvbiwlxgxa.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Help for a newbie
Hi Can one of the Masters of the Code tell me where should I start digging to fix bug 40113 (spreadsheet header/footer backgorund image/color does not show). Thanks in advance. -- Olivier Hallot Founder and Steering Commitee Member The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] 4 minutes 27 seconds - 11 seconds
On Tue, 2011-08-16 at 16:14 +0200, Thorsten Behrens wrote: Played with it today, surely ::append is on a critical path, but beats me why exactly this is so much faster. Surely it saves some temporary B2DPolygon instances... Were you able to reproduce the difference yourself ? IIRC I sent a sample document which, while horribly busted itself, was useful to trigger it ? C ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
Hello Eike, 2011/8/16 Eike Rathke o...@erack.de Hi Markus, On Tuesday, 2011-08-16 08:07:20 +0200, Markus Mohrhard wrote: this patch might be a bit to big for 3-4, but who knows: http://cgit.freedesktop.org/libreoffice/core/commit/?id=04d2e6469529b6187900659517d6f6dd5ea2cca5 First thing that caught my eye: using toAsciiUpperCase() (or any other ASCII method) on anything that the user inputs as names is a no-no as it doesn't handle Unicode. Use ScGlobal::pCharClass-upper() instead. I think I inherite it from some other places that use range names. So then we need to check for all other places too and adjust them accordingly. The change to the ScFormulaCell ctor apparently unconditionally tries to adjust name tokens, this is completely unnecessary in most situations and should be triggered only if the sheets of new and old position differ. No it's not that easy. If we have the same sheet and two different documents, we need to adjust too. And we can't simply check that the ScDocument instances are different because they will always be. Either we have a pointer to the original ScDocument instance in the copy document or we must always adjust our range names. I used the second approach because I didn't like the other approach. Before looping with pCode-GetNext...() it needs a pCode-Reset() first. Thanks. I forgot that. In ScTable::CopyToClip() all local range names are copied if none exist yet on the target. Best would be if only names used by the formulas to be copied would be copied if not already there, which adjustRangeName attempts to do. So in CopyToClip initialize pTable-mpRangeName = new ScRangeName; Yes, I know. And as I have written I plan to change this in master, at the moment this wouldn't change our behaviour so I don't see a problem with this. I didn't want to introduce more changes than necessary into the stable branch. Btw, please use 'r' prefix for parameters passed as reference, so rNewDoc instead of aNewDoc, and please const as const can, for example it should be const ScDocument* pOldDoc Apart from that, I'm currently somewhat handicapped with equipment and can't check if the change really does what it is supposed to do. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
Hi Markus, On Tuesday, 2011-08-16 16:25:22 +0200, Markus Mohrhard wrote: First thing that caught my eye: using toAsciiUpperCase() (or any other ASCII method) on anything that the user inputs as names is a no-no as it doesn't handle Unicode. Use ScGlobal::pCharClass-upper() instead. I think I inherite it from some other places that use range names. So then we need to check for all other places too and adjust them accordingly. Yes please. The change to the ScFormulaCell ctor apparently unconditionally tries to adjust name tokens, this is completely unnecessary in most situations and should be triggered only if the sheets of new and old position differ. No it's not that easy. If we have the same sheet and two different documents, we need to adjust too. And we can't simply check that the ScDocument instances are different because they will always be. Either we have a pointer to the original ScDocument instance in the copy document or we must always adjust our range names. I used the second approach because I didn't like the other approach. So at least compare document instances and sheets and if both are identical don't do the adjustment, which I think is the most used scenario when copying cells. Sounds plausible? Btw, how well does this all cope with undo/redo? Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpR934zWvnnG.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Class Time and its funny ideas about time
Michael Meeks wrote: Huh - it is -extremely- valuable to do global cleans that remove unpleasant and hard-to-grok implementations from the code. Sure. Just using the latest/newest/trendiest 'time' class from A.B.C. place de jour in new code is a(nother) maintenance nightmare waiting to happen :-) we've had enough of that in the codebase. It's a way to move forward today, without having to fix Time break master quite horribly (or adding a different set of methods to Time). I like Lubos' attitude. Quite possibly we should have an easy hack to re-work the time code everywhere (along with adding suitable unit-tests). Agreed, but beside my point. The question was whether Time should be fixed - what I said is that prolly Time is beyond fixing. ;) Cheers, -- Thorsten pgpVPwZxvd3v1.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
Hello Eike, 2011/8/16 Eike Rathke o...@erack.de Hi Markus, On Tuesday, 2011-08-16 16:25:22 +0200, Markus Mohrhard wrote: First thing that caught my eye: using toAsciiUpperCase() (or any other ASCII method) on anything that the user inputs as names is a no-no as it doesn't handle Unicode. Use ScGlobal::pCharClass-upper() instead. I think I inherite it from some other places that use range names. So then we need to check for all other places too and adjust them accordingly. Yes please. The change to the ScFormulaCell ctor apparently unconditionally tries to adjust name tokens, this is completely unnecessary in most situations and should be triggered only if the sheets of new and old position differ. No it's not that easy. If we have the same sheet and two different documents, we need to adjust too. And we can't simply check that the ScDocument instances are different because they will always be. Either we have a pointer to the original ScDocument instance in the copy document or we must always adjust our range names. I used the second approach because I didn't like the other approach. So at least compare document instances and sheets and if both are identical don't do the adjustment, which I think is the most used scenario when copying cells. Sounds plausible? So just to understand you correctly: You suggest to introduce a new variable ScDocument* pOriginalDoc; in ScDocument and check if this pointer and the address of rNewDoc are the same? I didn't like this very much but I have no strong opinion here. If you think that this would be the better version i will change this. Btw, how well does this all cope with undo/redo? I don't see any problems with undo/redo. Local range names are copied either way and if global range names are not copied then my check that a global ScRangeName exists will fail and don't adjust anything. But I think we can simply add a check for IsUndo. Then we don't have to think about it anymore. Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
Hi Markus, On Tuesday, 2011-08-16 17:08:53 +0200, Markus Mohrhard wrote: The change to the ScFormulaCell ctor apparently unconditionally tries to adjust name tokens, this is completely unnecessary in most situations and should be triggered only if the sheets of new and old position differ. No it's not that easy. If we have the same sheet and two different documents, we need to adjust too. And we can't simply check that the ScDocument instances are different because they will always be. Either we have a pointer to the original ScDocument instance in the copy document or we must always adjust our range names. I used the second approach because I didn't like the other approach. So at least compare document instances and sheets and if both are identical don't do the adjustment, which I think is the most used scenario when copying cells. Sounds plausible? So just to understand you correctly: You suggest to introduce a new variable ScDocument* pOriginalDoc; in ScDocument and check if this pointer and the address of rNewDoc are the same? I didn't like this very much but I have no strong opinion here. If you think that this would be the better version i will change this. No, no new member variable, what I was thinking of is to detect whether the original source document of the clipboard document is identical to the current document. There is a way via the document pool, I'll dig out details. Btw, how well does this all cope with undo/redo? I don't see any problems with undo/redo. Local range names are copied either way and if global range names are not copied then my check that a global ScRangeName exists will fail and don't adjust anything. But I think we can simply add a check for IsUndo. Then we don't have to think about it anymore. Sounds best. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpxOqDnrfiho.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
Hi Markus, On Tuesday, 2011-08-16 17:31:10 +0200, Eike Rathke wrote: No, no new member variable, what I was thinking of is to detect whether the original source document of the clipboard document is identical to the current document. There is a way via the document pool, I'll dig out details. That was easy: if (!pDocument-IsClipboardSource() || sheets_unequal) should do. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpAYZVGQQyvr.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Graphite 1.0.1
On Mon, 2011-08-15 at 16:11 +0200, Petr Mladek wrote: I guess that you need it with the md5sum prefix, so I uploaded it as http://download.go-oo.org/src/3c6b8de6b75eee445b29f1de5fe01f02-graphite2-1.0.1.tgz Shame - I guess this missed the 3.4.3 release deadline (unless we can get the patch, and triple review it soon); but we can get it in for 3.4.4 no doubt - and clearly pushing to master is easy enough. I assume 1.0.1 is mostly just bug fixes Martin ? 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] Class Time and its funny ideas about time
On Tue, 2011-08-16 at 15:13 +0100, Michael Meeks wrote: Hi Terry, If you're discussing code in detail you're much more than welcome here[1] :-) really looking forward to your first patch - do you have problems building that we can help out with ? Harrumph. I started last week to do a `git pull` and then a rebuild. Finally gave up this morning and started a clean build. Resolution: I hereby resolve that I shall ask about my next rebuild problem *before* I confuse things beyond description. [1] - that's very different from an something went wrong or I want XYZ feature mail :-) Isn't it funny that you should mention something went wrong? I am trying to rebuild with recent source just so that I can say confidently that something still goes wrong. I do have another something goes wrong that I have not mentioned here because I cannot say exactly how to make it go wrong. Is there a way that I can make LibreOffice log my actions--keystrokes, mouse clicks--so that I can see exactly what I did? Of course, this go wrong only happens when I am thinking about something else. sigh / Thank you for your encouragement. I shall keep plugging a while longer. Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Series of fixes and migration to One Git for contrib/dev-tools/ubuntu-jenkins
Hi Henrik, On Mon, 2011-08-15 at 23:40 +0100, Henrik Jensen wrote: Feel free to commit to the dev-tools repo directly, improving the jenkins setup even more would be awesome! I appreciate the trust Bjoern :-), but I don't have an freedesktop.org/Libreoffice account yet. Hey - welcome to the project :-) there are obvious historical Jenkins / LibreOffice synergies somewhere here I think; great to have you on board. (AFAIK I can't get partial commit right to contrib/dev-tools/ubuntu-jenkins) We can easily ask you to push only to there without further approval, which I suspect is a stronger force than most access controls out there ;-) but it'd be good to get a few more patches first, as you say. Besides, my git skills are still on the Mickey Mouse level, so I would be a bit fearful 'Goofying' around the source tree ;-). As long as you don't 'git push' randomly you're safe; and the most errors problems should be disallowed by the server so ... Later when I feel more comfortable with the code, I hope to be able to use (resurrect ?) the old GSOC 2006 project http://wiki.services.openoffice.org/wiki/BASIC/UNO_Object_Browser as a stepping stone for pursuing an old dream of adding (at least some primitive kind of) code-completion functionality to the star-basic editor. Ah - that would indeed be nice; unfortunately - queryInterface makes a dogs breakfast of type inference from objects: by the power of 'meta'ness ;-) we have no idea what interfaces are supported, and we are constantly loosing strong type information down 'Any' shaped holes - which is a shame. But - it'd be great to resurrect the object browser get it integrated no doubt. Thanks ! Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [ANNOUNCE] libreoffice-3.4.3.1 tag created (3.4.3-rc1)
Hi, there have been created the libreoffice-3.4.3.1 tag for 3.4.3-rc1 release. The corresponding official builds will be available by the end of the week. See the attached list of changes against 3.4.2-final. I am going to create the libreoffice-3-4-3 branch for the final stabilization. You might switch your current 3-4 source tree to it using: ./g fetch --tags ./g checkout -b tag-libreoffice-3.4.3.1 libreoffice-3.4.3.1 See also the schedule at http://wiki.documentfoundation.org/ReleasePlan#3.4_release and release criteria at http://wiki.documentfoundation.org/Release_Criteria Best Regards, Petr + calc + [PATCH] fix for defining named ranges should be case insensitiv (fdo#39915) [Markus Mohrhard] + allow multi-range copy from VBA. (bnc#707486) [Noel Power] + better way to remove DP objects without reversing order. (fdo#39236) [Kohei Yoshida] + correctly import from Excel charts with multiple ranges. (i#107275) [Kohei Yoshida] + dr78: set app flag in ScGlobal::SetSearchItem, (fdo#33379, i#116250, fdo#33593, fdo#37499) [Niklas Nebel] + fix broken refresh() from UNO API (and Basic). (fdo#37767) [Kohei Yoshida] + fix for SetNamedRanges speedup (fdo#35357) [Laurent Godard] + fix for changes to range names invalidate stream too (fdo#39792) [Markus Mohrhard] + fix for check for empty local range names (fdo#39728) [Markus Mohrhard] + fix for crash with hidden column in Data-Form (fdo#39773) [Markus Mohrhard] + fix for database ranges don't work in formulas (fdo#39333) [Markus Mohrhard] + fix for don't write password algorithm in odf 1.0 and 1.1 (fdo#39678) [Markus Mohrhard] + fix for set correct table number in local db data (fdo#39151) [Markus Mohrhard] + fix for set upper limit for second parameter of tinv to 1E10 (fdo#37128) [Markus Mohrhard] + make strings localizable (fdo#36706) [Andras Timar] + make sure the drawing layer is initialized before use. (fdo#36688) [Kohei Yoshida] + prevent double-deletes during removal of pivot tables. (fdo#39236) [Kohei Yoshida] + set selection request as done for macro recorder (fdo#38955) [Caolán McNamara] + the previous commit is for not for fdo#. (bnc#707486) [Kohei Yoshida] + use the correct clip doc instance to copy to. (fdo#707486) [Noel Power] + components + related changes in split components repository to support LCID changes (fdo#38956) [Eike Rathke] + filters + change 2007 XML to 2007/2010 XML in UI strings (fdo#36735) [Andras Timar] + change 97/XP/2000 to 97/XP/2000/2003 (fdo#36734) [Andras Timar] + related correct import of shared formulas (fdo#39023) [Muthu Subramanian] + help + remove link to non-existing topic (fdo#35823) [Andras Timar] + update the operation of delete and backspace key (fdo#31652) [Korrawit Pruegsanusak] + impress + clean-up of bugfix for the -3-4 branch (fdo#32895) [Peter Rabi] + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + make strings localizable (fdo#36706) [Andras Timar] + missing icon in Styles and Formatting dialog in Impress (fdo#38382) [Andras Timar] + libs-core + add a modification listener on new XDocumentProperties (fdo#32177) [Caolán McNamara] + clean-up of bugfix for the -3-4 branch (fdo#32895) [Peter Rabi] + fix for - no update preview (fdo#34768) [Peter Rabi] + fix for change password button is always disabled (fdo#37628) [Markus Mohrhard] + fix memory exhaustion with String length of STRLEN_MAX (fdo#39869) [Eike Rathke] + fix wrong RTTI baseclass for SfxViewEventHint (fdo#38768) [Thorsten Behrens] + make these entries localizable (fdo#36274) [Andras Timar] + null the display pointer after closing the display, fixes (fdo#37579) [Michael Meeks] + on recovery from an autosave file use DefaultFilter, seems to fix (fdo#34805) [Tor Lillqvist] + related changes in split libs-core repository to support LCID changes (fdo#38956) [Eike Rathke] + related: /short fread isn't an error when its eof (fdo#39376, fdo#34880) [Caolán McNamara] + resolve: post-stl use vector end position not LIST_APPEND (fdo#39392) [Caolán McNamara] + libs-extern + related: force .a files to hidden visibility (fdo#35404) [Caolán McNamara] + libs-extern-sys + backport fix for (py#4768, fdo#36763) [Caolán McNamara] + libs-gui + add Teke-Eboo language (fdo#37275) [Andras Timar] + add gd_GB (Gaelic, Scottish) locale data (i#117857) [Andras Timar] + change 97/XP/2000 to 97/XP/2000/2003 (fdo#36734) [Andras Timar] + change SV_BUTTONTEXT_LESS from More to Less (fdo#36663) [Andras Timar] + eMF+ records don't need payload all the time (fdo#39517) [Caolán McNamara] + fix discarding bracketed prefixes in number formats, such as [RED] (fdo#38956) [Eike Rathke] + halffull width forms need to remain asian (fdo#38095) [Caolán McNamara] + sdk + wrong csh syntax (rhbz#725144) [Caolán McNamara] + ure + related: on windows find
Re: [Libreoffice] [GSOC] how to call python code from the menu
On Mon, 2011-08-15 at 19:02 +0200, Xisco Faulí wrote: Hello everybody, before I merge the gsoc branch into master I'd like to integrate the python code into libo and get rid of the java code. I know i have to edit this file http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Common.xcu but i can't figure out how to call the python code. I've tried to call this file http://opengrok.libreoffice.org/xref/core/pyuno/demo/hello_world_comp.py using this value: valueservice:org.openoffice.comp.pyuno.demo.HelloWorld?insert/value but it doesn't work. Any idea ? Perhaps hello_world_comp.py isn't registered as a service ? Did you look at how the mailmerge.py example is installed ?, i.e. http://opengrok.libreoffice.org/search?q=mailmerge.py for a python component which is bundled into LibreOffice. You may have to do pretty much the same thing for it be available via service:...?foo out-of-the-box. There's some preamble at the top of mailmerge.py about how to manually register that component for testing purposes, which is probably the archaic way to do it these-days, but probably still works. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] fix xml2cmp build with svn gcc
Hi Tom, First - really wonderful to see you here, and a big welcome :-) I'm so sorry you got screwed over by our big one-shot git repository transition / migration. Hopefully the change, while painful in the short term, will make things much easier for new contributors going forward (particularly wrt. updating, tinderboxes, more reliable builds etc.). On Thu, 2011-08-11 at 09:26 -0600, Tom Tromey wrote: Thanks. I must have read some stale document before starting; but unfortunately I don't recall what. I will start over. It'd be great if we could find catch that if your browser history helps. Looking forward to your help ! All the best, 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] Base fdo#40079 file / save (as) inoperant
On Tue, Aug 16, 2011 at 09:41:43AM +0100, Noel Power wrote: On 15/08/11 13:10, Lionel Elie Mamane wrote: When the Standard Basic Macro Library for the document is loaded (which happens implicitly as soon as a macro is executed), but not the Standard Dialog Library, the File / Save action (or the equivalent toolbar button) does nothing, without error message. I would like to have a look at this, (...) Two questions, a) did you try this on master No, not yet. ( I did and it appeared to work as expected ) but I am pretty 'base' disabled so I fear I may have missed something in trying to recreate it You have to be very cautious what you do to reproduce it, it is fragile: for example, if you open the Basic IDE, you have lost, as this, according to my testing, leads to the Dialog library having been loaded at the point I patch. Either bind a macro to the open document event or run the macro from Tools / Macros / Run Macro. The Standard Dialog library also should not be empty; it should contain at least one dialog. Which leads me to another bug: If I remove the librarie's only dialog and save, I restart LO, I reopen the file again, the dialog is back. If the library has two dialogs and I delete one, it is gone after a save and reload. This seems to be Base-specific. b) is this behaviour specific to base documents? Well, this bug is, but that is because the other apps have another bug that hides this one :-( My testing shows that SfxDialogLibraryContainer::storeLibrariesToStorage aborts at the same place for a calc document (an exception is raised), but this does not abort the save. Thus, logically, in the conditions where this bug shows up, Calc looses the embedded images in Dialogs. This is tested. And I guess also looses (the changes to?) anything that is saved *after* the Dialogs, if anything is (this is not tested). I wonder what does base do differently from 'normal' documents and why It (correctly IMHO) aborts the save when the save raises an exception. On Tue, Aug 16, 2011 at 09:51:39AM +0100, Noel Power wrote: On 15/08/11 13:10, Lionel Elie Mamane wrote: The remaining question is: if xSourceLibrariesStor-copyElementTo was called, does the code under: // we need to export out any embedded image object(s) // associated with any Dialogs. First, we need to actually gather any such urls // for each dialog in this container still need to be run? In other words, has copyElementsTo copied these embedded image objects, or not? not at all sure but it should be easy enough to test, (...) After saving, the image should be stored in it's own document stream. After testing with your 'modification' scenario ( e.g. run macro, make change, re-save ) when you open the dialog the image should be still there ( best of course to check that after restarting libreoffice and re-opening the document ) I disabled the export out any embedded image object code by adding a return; before it, and it does not loose the embedded images, even after restarting LO and re-opening the document. I additionally disabled the // Can we simply copy the storage? case, and it seems to have corrupted the document: I cannot anymore edit the dialog :-) It just shows the Basic code or another dialog instead. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] how to call python code from the menu
Thank you for pointing out this file but I don't really understand how it works. The wizard is called here : http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu#441 where MailMergeWizard is the service register in Writer.xcu ( http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Writer.xcu#30 ) but then how libo knows that this service refers to mailmerge.py ? Greetings 2011/8/16 Caolán McNamara caol...@redhat.com On Mon, 2011-08-15 at 19:02 +0200, Xisco Faulí wrote: Hello everybody, before I merge the gsoc branch into master I'd like to integrate the python code into libo and get rid of the java code. I know i have to edit this file http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Common.xcubut i can't figure out how to call the python code. I've tried to call this file http://opengrok.libreoffice.org/xref/core/pyuno/demo/hello_world_comp.pyusing this value: valueservice:org.openoffice.comp.pyuno.demo.HelloWorld?insert/value but it doesn't work. Any idea ? Perhaps hello_world_comp.py isn't registered as a service ? Did you look at how the mailmerge.py example is installed ?, i.e. http://opengrok.libreoffice.org/search?q=mailmerge.py for a python component which is bundled into LibreOffice. You may have to do pretty much the same thing for it be available via service:...?foo out-of-the-box. There's some preamble at the top of mailmerge.py about how to manually register that component for testing purposes, which is probably the archaic way to do it these-days, but probably still works. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSoC] merged library
Hi there, I'm trying to allow using one bigger shared library instead of more, often used small ones. Something like described here: http://tools.openoffice.org/build_env_param.html search for BIG_SVX parameter at the top. Was it ever possible to do one shared library? I'm attaching diff (against gbuild branch in core), not something to apply but to look into if the way I'm doing that is at least partially right. Probably there will be different names for variables, also I'm not sure about change in configure.in ... That way is possible to merge just libraries from gbuildized modules. I have changed creating services.rdb (uri parameter to load merged library if possible) and gb_LIST_LIBS is to control which libraries can link against the merged one. They have to be build in tail_build, now sc, sd, sw. It would be nice to gbuildize desktop (I'm not working on it, it's huge and mess) for this and change linking of sofficeapp library, or even replace it. But this could be also possible if we were just building desktop after tail_build. Of course there are problems: - I had to disable unit test in sc (sc_test_filters) when trying changes because I was getting error which I was not able to debug yet. hmm, but I can't see this problem now, never mind. more serious one: - There are more objects with the same name in different modules. So, is it possible to create one object file for each module and make these variables, classes.. invisible outside object file and then create big library from them? I would guess it's not possible and we have to rename or get rid of them somehow? It is not much to merge now but easy to add when more modules will be gbuildized, so at least something. and gbuild status: I have pushed change of some modules, there were things to repair (my mistakes), thanks goes to Caolán, David and others. Problems are with: sal, salhelper, cppu, cppuhelper, scripting, i18npool, avmedia (still not pushed) (some of them could be merged then) I have began with these when I thought it would be easy to finish, it was not clever but hopefully I will finish that after GSoC. that's all for now, Thanks Matúš diff --git a/Library_merged.mk b/Library_merged.mk new file mode 100644 index 000..a72cc3a --- /dev/null +++ b/Library_merged.mk @@ -0,0 +1,91 @@ +# -*- Mode: makefile; tab-width: 4; indent-tabs-mode: t -*- +# +# Version: MPL 1.1 / GPLv3+ / LGPLv3+ +# +# The contents of this file are subject to the Mozilla Public License Version +# 1.1 (the License); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# http://www.mozilla.org/MPL/ +# +# Software distributed under the License is distributed on an AS IS basis, +# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License +# for the specific language governing rights and limitations under the +# License. +# +# The Initial Developer of the Original Code is +# Matúš Kukan matus.ku...@gmail.com (C) 2011, All Rights Reserved. +# +# Alternatively, the contents of this file may be used under the terms of +# either the GNU General Public License Version 3 or later (the GPLv3+), or +# the GNU Lesser General Public License Version 3 or later (the LGPLv3+), +# in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable +# instead of those above. + + +$(eval $(call gb_Library_Library,merged)) + +$(eval $(call gb_Library_add_linked_libs,merged,$(filter-out $(gb_MERGED_LIBS),\ + avmedia \ + basegfx \ + comphelper \ + cppu \ + cppuhelper \ + drawinglayer \ + editeng \ + fwe \ + i18nisolang1 \ + i18npaper \ + i18nutil \ + jvmfwk \ + lng \ + fwe \ + sal \ + salhelper \ + sax \ + sb \ + sfx \ + sot \ + svl \ + svt \ + svx \ + svxcore \ + tk \ + tl \ + ucbhelper \ + utl \ + vcl \ + xo \ + xcr \ + $(gb_STDLIBS) \ +))) + +$(eval $(call gb_Library_use_externals,merged,\ + icuuc \ + jpeg \ + libxml2 \ +)) + +$(eval $(call gb_Library_add_library_objects,merged,\ + $(gb_MERGED_LIBS) \ +)) + +ifeq ($(OS),WNT) +$(eval $(call gb_Library_add_linked_libs,merged,\ + advapi32 \ + gdi32 \ + ole32 \ + oleaut32 \ + shell32 \ + user32 \ + uuid \ +)) +endif + +ifeq ($(OS),MACOSX) +$(eval $(call gb_Library_add_linked_libs,merged,\ + objc \ + Cocoa \ +)) +endif + +# vim: set noet sw=4 ts=4: diff --git a/Module_tail_build.mk b/Module_tail_build.mk index 6002046..4dde97d 100644 --- a/Module_tail_build.mk +++ b/Module_tail_build.mk @@ -44,4 +44,10 @@ $(eval $(call gb_Module_add_moduledirs,tail_end,\ writerfilter \ )) +ifeq ($(BIGSVX),YES) +$(eval $(call gb_Module_add_targets,tail_end,\ + Library_merged \ +)) +endif + # vim: set noet sw=4 ts=4: diff --git a/Repository.mk b/Repository.mk index 590fd7f..4a47ef6 100644 --- a/Repository.mk +++ b/Repository.mk @@ -149,6 +149,7 @@ $(eval $(call gb_Helper_register_libraries,PLAINLIBS_URE, \ )) $(eval $(call gb_Helper_register_libraries,PLAINLIBS_OOO, \ + merged \ test \ fileacc \ )) diff --git a/configure.in b/configure.in index
[Libreoffice] make check failed because no rule to create the target
Hello, With make check, here's what I got at the end : [ build SCK ] framework make[1]: *** Pas de règle pour fabriquer la cible « /home/maryline/compile-libreoffice/libo/linguistic/qa/unoapi/Test.java », nécessaire pour « /home/maryline/compile-libreoffice/libo/workdir/unxlngi6/JavaClassSet/JunitTest/linguistic_unoapi/done ». Arrêt. (Translation : No rule to create the target ..., required for . Stop) autogen.lastrun : --enable-symbols --enable-ext-barcode --enable-ext-diagram --enable-ext-google-docs --enable-ext-hunart --enable-ext-lightproof --enable-ext-nlpsolver --enable-ext-ct2n --enable-ext-numbertext --enable-ext-oooblogger --enable-ext-pdfimport --enable-ext-presenter-console --enable-ext-presenter-minimizer --enable-ext-report-builder --enable-ext-scripting-beanshell --enable-ext-scripting-javascript --enable-ext-typo --enable-ext-validator --enable-ext-watch-window --enable-ext-wiki-publisher --enable-dbus --enable-graphite --enable-evolution2 --enable-werror --enable-debug --enable-dbgutil --enable-crashdump --enable-kde4 --enable-dependency-tracking Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Graphite 1.0.1
Dear Michael,
Shame - I guess this missed the 3.4.3 release deadline (unless we can
get the patch, and triple review it soon); but we can get it in for
3.4.4 no doubt - and clearly pushing to master is easy enough.
I enclose the patch. It is a simple patch in that it removes the existing bug
fix patching from the graphite source, creates a new patch that only patches
what libo needs to modify in the code, simplifies the libo specific makefile
for graphite and updates the file references.
I assume 1.0.1 is mostly just bug fixes Martin ?
Well we went up to 1.0.2 to fix a windows build bug, but yes. And there are
some memory savings and general all round goodness improvements inside the
graphite engine. There is no actual code change within libo. One particular
improvement is in bidi mirroring which it would be nice to have in 3.4.3 but
not esesential. It should also go into master.
I don't really know how to submit a patch across 2 git repos, but here it is.
Yours,
Martin
diff --git a/ooo.lst.in b/ooo.lst.in
index 3652a39..cbf1fb6 100644
--- a/ooo.lst.in
+++ b/ooo.lst.in
@@ -79,7 +79,7 @@ debc62758716a169df9f62e6ab2bc634-zlib-1.2.3.tar.gz
0ff7d225d087793c8c2c680d77aac3e7-mdds_0.5.3.tar.bz2
f02578f5218f217a9f20e9c30e119c6a-boost_1_44_0.tar.bz2
9ed97fce60a9a65852402248a6659492-hunspell-1.3.1.tar.gz
-0625a7d661f899a8ce263fc8a9879108-graphite2-0.9.2.tgz
+3115c721f5cb7c464f01c2dddccfaba6-graphite2-1.0.2.tgz
http://download.go-oo.org/extern
185d60944ea767075d27247c3162b3bc-unowinreg.dll
b4cae0700aa1c2aef7eb7f345365e6f1-translate-toolkit-1.8.1.tar.bz2
diff --git a/graphite/graphite2-0.9.2.patch b/graphite/graphite2-0.9.2.patch
deleted file mode 100644
index a775c1f..000
--- a/graphite/graphite2-0.9.2.patch
+++ /dev/null
@@ -1,453 +0,0 @@
-diff -r 5369cdd12120 CMakeLists.txt
misc/build/graphite2-0.9.2/CMakeLists.txt Sat Feb 12 22:54:16 2011 +0700
-+++ misc/build/graphite2-0.9.2/CMakeLists.txt Fri Feb 18 16:05:40 2011 +0700
-@@ -61,7 +61,7 @@
- add_subdirectory(gr2fonttest)
- add_subdirectory(tests)
- add_subdirectory(doc)
--set(version 0.0.0)
-+set(version 2.0.0)
- set(libdir ${CMAKE_INSTALL_PREFIX}/lib)
- set(includedir ${CMAKE_INSTALL_PREFIX}/include)
-
-diff -r 5369cdd12120 gr2fonttest/gr2FontTest.cpp
misc/build/graphite2-0.9.2/gr2fonttest/gr2FontTest.cpp Sat Feb 12 22:54:16 2011 +0700
-+++ misc/build/graphite2-0.9.2/gr2fonttest/gr2FontTest.cpp Fri Feb 18 16:05:40 2011 +0700
-@@ -758,13 +758,11 @@
- float advanceWidth = gr_seg_advance_X(pSeg);
- fprintf(log, Advance width = %6.1f\n, advanceWidth);
- unsigned int numchar = gr_seg_n_cinfo(pSeg);
--gr_uint32 *firsts = (gr_uint32 *)malloc(numchar * sizeof(gr_uint32));
--gr_uint32 *lasts = (gr_uint32 *)malloc(numchar * sizeof(gr_uint32));
--gr_seg_char_slots(pSeg, firsts, lasts, 0, 0);
- fprintf(log, \nChar\tUnicode\tBefore\tAfter\n);
- for (unsigned int j = 0; j numchar; j++)
- {
--fprintf(log, %d\t%04X\t%d\t%d\n, j, gr_cinfo_unicode_char(gr_seg_cinfo(pSeg, j)), firsts[j], lasts[j]);
-+const gr_char_info *c = gr_seg_cinfo(pSeg, j);
-+fprintf(log, %d\t%04X\t%d\t%d\n, j, gr_cinfo_unicode_char(c), gr_cinfo_before(c), gr_cinfo_after(c));
- }
- free(map);
- gr_seg_destroy(pSeg);
-diff -r 5369cdd12120 include/graphite2/Segment.h
misc/build/graphite2-0.9.2/include/graphite2/Segment.h Sat Feb 12 22:54:16 2011 +0700
-+++ misc/build/graphite2-0.9.2/include/graphite2/Segment.h Fri Feb 18 16:05:40 2011 +0700
-@@ -135,6 +135,20 @@
- */
- GR2_API int gr_cinfo_break_weight(const gr_char_info* p/*not NULL*/);
-
-+/** Returns the slot index that after this character is after in the slot stream
-+ *
-+ * @return after slot index between 0 and gr_seg_n_slots()
-+ * @param p Pointer to charinfo to return information on.
-+ */
-+GR2_API int gr_cinfo_after(const gr_char_info* p/*not NULL*/);
-+
-+/** Returns the slot index that before this character is before in the slot stream
-+ *
-+ * @return before slot index between 0 and gr_seg_n_slots()
-+ * @param p Pointer to charinfo to return information on.
-+ */
-+GR2_API int gr_cinfo_before(const gr_char_info* p/*not NULL*/);
-+
- /** Returns the number of unicode characters in a string.
- *
- * @return number of characters in the string
-@@ -205,22 +219,6 @@
- */
- GR2_API const gr_slot* gr_seg_last_slot(gr_segment* pSeg/*not NULL*/);//may give a base slot or a slot which is attached to another
-
--/** Calculates the underlying character to glyph associations.
-- *
-- * @param pSeg Pointer to the segment we want information on.
-- * @param begins An array of gr_seg_n_cinfo integers giving slot index for each
-- * charinfo. The value corresponds to which slot a cursor would be before
-- * if an underlying cursor were before the charinfo at this index.
-- * @param ends An array of gr_seg_n_cinfo
Re: [Libreoffice] [PATCH] for Bug 32719
Hi Thorsten, Jan, and Co.
Sorry for the delay. Here is the revised patch that fixes the dimension
problem without all the rough scratch work/comments from last time.
I will look into Rainer's comment.
Jeffrey
On Thu, Aug 11, 2011 at 1:50 AM, Thorsten Behrens
t...@documentfoundation.org wrote:
jeffrey chang wrote:
Here is the patch for EasyHack 32719. I have also discovered another bug
relating to Impress Templates, documented here:
https://bugs.freedesktop.org/show_bug.cgi?id=39705
Hi Jeffrey,
thanks a lot for that patch - we've talked about this bug, glad to
see you tackling this.
I've applied it played a bit with it - the behaviour is changed,
but at least for the scenario Rainer describes in comment #3 in the
bug, not fixed? Maybe I'm missing something, are there other changes
I need?
Cheers,
-- Thorsten
--
--Jeffrey Chang
From 349f813ac3de560a42a3de0138cfed7eaf4162af Mon Sep 17 00:00:00 2001
From: Jeffrey Chang jeffdch...@gmail.com
Date: Wed, 17 Aug 2011 23:30:02 +0800
Subject: [PATCH] Fixed template dimension problem on Impress.
---
sd/source/core/sdpage.cxx |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/sd/source/core/sdpage.cxx b/sd/source/core/sdpage.cxx
index 8af853f..8fc20d8 100644
--- a/sd/source/core/sdpage.cxx
+++ b/sd/source/core/sdpage.cxx
@@ -1070,8 +1070,8 @@ Rectangle SdPage::GetLayoutRect() const
{
aLayoutPos.X() += long( aLayoutSize.Width() * 0.05 );
aLayoutPos.Y() += long( aLayoutSize.Height() * 0.234 );
-aLayoutSize.Width() = long( aLayoutSize.Width() * 0.9 );
-aLayoutSize.Height() = long( aLayoutSize.Height() * 0.66 );
+aLayoutSize.Width() = long( aLayoutSize.Width() * 0.88 );
+aLayoutSize.Height() = long( aLayoutSize.Height() * 0.58 );
aLayoutRect.SetPos(aLayoutPos);
aLayoutRect.SetSize(aLayoutSize);
}
@@ -2416,11 +2416,6 @@ void SdPage::SetObjText(SdrTextObj* pObj, SdrOutliner* pOutliner, PresObjKind eO
aString += String::CreateFromAscii( RTL_CONSTASCII_STRINGPARAM( \n\t\t\t\t\t\t\t ));
aString += String ( SdResId( STR_PRESOBJ_MPOUTLLAYER7 ) );
-aString += String::CreateFromAscii( RTL_CONSTASCII_STRINGPARAM( \n\t\t\t\t\t\t\t\t ));
-aString += String ( SdResId( STR_PRESOBJ_MPOUTLLAYER8 ) );
-
-aString += String::CreateFromAscii( RTL_CONSTASCII_STRINGPARAM( \n\t\t\t\t\t\t\t\t\t ));
-aString += String ( SdResId( STR_PRESOBJ_MPOUTLLAYER9 ) );
}
}
break;
--
1.7.3.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Need advice on #34697: Print Current Page in Print dialog - Calc, Draw, Impress
Hello all,
For the easy hack mentioned in the subject of this email,
the tatung has done it for the writer.
# The coding style must be adapted though.
The next steps are hacking the similar codes for calc and impress.
Can anyone shed us a light on how to do that?
cf.
The bug: https://bugs.freedesktop.org/show_bug.cgi?id=34697
The patch: https://bugs.freedesktop.org/attachment.cgi?id=49235
Thanks in advance.
--
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng )
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype:
vuhung16plus, twitter: vuhung, MSN: vuhung16.
http://www.facebook.com/nguyenvuhung
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
Hello Eike, 2011/8/17 Eike Rathke o...@erack.de Hi Markus, With your latest commit 74070a021389534b9e791980bd33ede45be9fd81 copying to another sheet within the same document to me doesn't work as expected: On Sheet1 on cell B3 define a sheet local range name AAA for that cell ($Sheet1.$B$3). In cell B3 enter value 1, in cell B4 enter formula =AAA result is 1. Copy cells B3 and B4 to clipboard and paste on Sheet2 at position C4. Change C4 to 2, C5 remains with result 1. Open the name dialog and see now a global name AAA pointing to $Sheet1.$B$3 (additionally to AAA local to Sheet1). That was my intention. My idea was that we should create a global range name as default and not a local range name that points to the same cell. But after a talk to Kohei and your impression it seems that this is counter intuitive, so I'll change it. I'd expect a name AAA local to Sheet2 pointing to $Sheet2.$C$4 and the formula in Sheet2.C5 using that name and the result should be 2. In a dbgutil build the shell displays Error: FormulaToken::SetIndex: virtual dummy called From File /lo/core/formula/source/core/api/token.cxx at Line 212 Can it be that a debug build does not include the dgbutil messages? Apparently the FormulaToken used is not a FormulaIndexToken. Oh. I should not only override SetByte but also SetIndex. In calc all formula tokens are derived from ScToken which is derived from FormulaToken and not from FormulaIndexToken. I should no longer finish patchs after learning.c I think best is that I add a unit test before I push any further modifications in this area. Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
