Re: [Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility
On Tue, Aug 23, 2011 at 07:48:19AM +0200, Lionel Elie Mamane wrote:
On Mon, Aug 22, 2011 at 07:06:59PM -0400, Kohei Yoshida wrote:
BTW, how do you plan to use that m_bFireEvent data member to decide to
skip or fire events in OPropertySetHelper::fire() ? The method that
needs to be influenced by that boolean is still in the
OPropertySetHelper.
class OPropertySetHelper : public ...
{
(...)
virtual void SAL_CALL fire(
sal_Int32 * pnHandles,
const ::com::sun::star::uno::Any * pNewValues,
const ::com::sun::star::uno::Any * pOldValues,
sal_Int32 nCount,
sal_Bool bVetoable );
(...)
}
Ah no, that will break ABI, too, by adding a new function in the
vtable... Sorry, not 100% woken up yet. m_pReserved starts to look
good.
--
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Get rid of unused direct dependencies
On Aug 20, 2011, at 6:18 PM, Péter Rabi wrote: I'm interested in your opinion about the following problem of mine: There are probably libraries and executables in LibO that are dynamically linked to libraries that they do not use. I wrote some c++ code (attached) to find these needless dependencies. I was using `ldd -u foo' to fetch the unused direct dependencies of foo if its build is GnuMake-ified. The tool (libfilter) also removes the entries of these unnecessary libs from the proper makefile. I also attached a patch containing the result I got after running libfilter. Unfortunately, it removed loads of libs that was indispensable for running foo. I'm wondering if you could tell me why did ldd misled me (what did I misunderstood)? First, you would need to use ldd -r -u, otherwise it misses all the lazily resolved symbols (and the resulting dependencies). Second, note that there can be various reasons for those dependencies, apart from observing they are required to resolve symbols for one specific build of LO. (Such reasons could be differences in platform, environment, or configure switches; ABI requirements; one lib depending on .init code in another; … --- granted, some of these are more hypothetical than others…) So, while such lists of useless dependencies are interesting, they need to be inspected more closely than to automatically remove them, I would say. (Also see GNU ld's --as-needed.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] cherry pick graphite into 3.4.4
This is a request for revision 6aed24cc5bc1 to be cherry picked from master into the latest 3.4. TIA, Martin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] partial build and make dev-install
Hi Lionel, On Mon, 2011-08-22 at 18:30 +0200, Lionel Elie Mamane wrote: I just got bitten by the fact that: .. Does not make the libreoffice in ./install use the new changed code; is this to be considered a bug, or are some modules on purpose not symlinked but copied in a dev-install for some reason? Right :-) so - this is down to solenv/bin/linkoo which has: my @exceptions = ( 'cppuhelper', 'sunjavaplugin', 'libjvmfwk' ); Everything should be linked except these libraries. Unfortunately this little lot ;-) do (or used to do) deep black magic - they force the linker to tell them exactly where they are located, and then they locate the rest of the LibreOffice install in relation to that. So - if they are normally in: prefix/ure/lib/libuno_cppuhelper.so.3 Then they look in ../../basis-3.5/program - for their binaries - so if you link them into the solver - then ... you get rather a poor result ;-) Now - having said that - now I look, it seems there are a number of libraries that are not linked in ure/lib/ and some that are - it would be well worth checking why that is I suppose. Also - there are (most likely) ways to fix this in code - using an environment / bootstrap override variable to force the location of the install - that we could whack into 'ooenv' easily enough. If it is to be considered a bug, I'd appreciate hints in where to look to fix it. Ah - it is a feature to fix :-) it just needs a bit more research work to unwind I think. 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] cherry pick graphite into 3.4.4
On Tue, Aug 23, 2011 at 02:49:17PM +0700, Martin Hosken wrote: This is a request for revision 6aed24cc5bc1 to be cherry picked from master into the latest 3.4. I know this s bbroken right now, too, but shouldn't we (if we add this version), then fix the big-endian stuff, too? (As we don't use the cmake build we need to sett he -DWORDS_BIGENDIAN manually, I think we can rsue and export the variable we use in configure anyway. Can come up with a patch tonight...) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Rectangle width
Hello! For example, there is small bug corresponding to this problem. See function «ImplDrawDropdownArrow» in «toolbox.cxx» («vcl» module). A lines long x = rDropDownRect.Left() + (rDropDownRect.getWidth() - width)/2; long y = rDropDownRect.Top() + (rDropDownRect.getHeight() - height)/2; use wrong functions getHeight() and getWidth() , but really should use GetHeight() and GetWidth(). So, this problem causes the dropdown arrows of menubuttons on toolboxes to be shifted left. 18.08.2011 13:21, Michael Meeks пишет: On Wed, 2011-08-17 at 23:08 +0200, Thorsten Behrens wrote: Hi Dmitry - yes, the two different methods are surely confusing. As for the "wrong value", that very much depends on the mental model of rectangles you're using. In a discrete geometry world (aka "pixel"), the GetWidth() is correct. In a continuous geometry world (aka "euclidean plane"), getWidth() is right. Ho ;-) Should we perhaps have some better naming: 'getOuterWidth' vs. 'getWidth' or something ;-) This fundamental, conceptual difference is the historical reason for the two methods (admittedly, not a very clean solution to the problem). True - perhaps we should audit all calls of GetWidth on Rectangle to see how many there are and update them if fewer than a couple of hundred or so ? ATB, Michael. -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [META] nitpicking on cherry-picking review rules
Lionel Elie Mamane píše v Po 22. 08. 2011 v 18:01 +0200: On Mon, Aug 22, 2011 at 02:24:09PM +0200, Jan Holesovsky wrote: On 2011-08-21 at 08:36 +0200, Lionel Elie Mamane wrote: I'm unsure whether the acks needed for cherrypick are any committer or a more restricted group, but in case it is the former: I agree that commit 03e9161e2eca9d389d7ce419495538c31f6aed31 is worthwhile to cherrypick for 3.4.3, as: Any developer counts, so you are welcome to review patches! Only in this case, you are the author of the patch - a self-review does not count ;-) I did not notice that Noel already counted his review as part of the three needed, I had (wrongly) in mind that three *more* than Noel were expected. I thought that if Noel does not count, I ought to; in other words, it should not be the case that both the author and the person asking for cherry-pick be excluded in the count. Sorry for the mix-up in that; if Noel counts as one of the three, it is reasonable that I don't, although if I had to decide on the rule, I'd prefer need three reviews (and author counts) PLUS the person asking for cherry-pick, because this is more regular in the face of I think that the confusion is that it is not clear who is author and who approved the fix in the 3-4 branch. I guess that Noel kept you as the author and used himself as the reviewer. Person asking for cherry picking does not count. It can be Johny Tester who feels that this fix is important enough for the bugfix release. Only people who really review the code counts :-) Regarding this particular commit. You need 1 approval for 3-4 branch and two more approvals for 3-4-3 branch. Noel already committed it into 3-4 branch, so you need two more approvals for the 3-4-3 branch. It is clear that it can be neither Noel nor you. One of you was author and the other was reviewer for the 3-4 branch. the situation where the author does not agree to the cherry-pick; the current rule basically ignores the author's not agree, while my amended rule expects him/her to be replaced by another developer. If the author does not agree with cherry picking, he could simply complain in the mail. I am sure that the fix will not be pushed until all complains are clarified. Anyway, thanks for the fix. I hope that the processes are more clear now. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix for fdo#39510 to backport
Here is an update patch for 3.4 branch with the following fixes:
* Added missing #if OSL_DEBUG_LEVEL 1
* Initialized pPrecede to 0 in constructor
Thanks,
--
Cedric
- Mail original -
Hi all,
Could some of you please review this commit to be backported to the
3.4.3 branch fixing a nasty crasher with loads of dupes (fdo#39510)?
http://cgit.freedesktop.org/libreoffice/writer/commit/?id=9ecab7
Thanks for your reviews.
--
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
From 68b27b713285ddee7b44bb9f57e01066e28eb1b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?C=C3=A9dric=20Bosdonnat?= cedric.bosdonnat@free.fr
Date: Tue, 23 Aug 2011 11:36:42 +0200
Subject: [PATCH] cherry-picked core:cc3d0d and fixed a few things
---
sw/source/core/inc/cntfrm.hxx | 10 ++
sw/source/core/inc/flowfrm.hxx| 12 +++-
sw/source/core/inc/sectfrm.hxx|4
sw/source/core/inc/tabfrm.hxx |4
sw/source/core/layout/flowfrm.cxx | 15 ++-
sw/source/core/text/xmldump.cxx | 25 +
6 files changed, 60 insertions(+), 10 deletions(-)
diff --git a/sw/source/core/inc/cntfrm.hxx b/sw/source/core/inc/cntfrm.hxx
index 898715b..5aab722 100644
--- a/sw/source/core/inc/cntfrm.hxx
+++ b/sw/source/core/inc/cntfrm.hxx
@@ -84,6 +84,8 @@ public:
inline const SwCntntFrm *GetFollow() const;
inline SwCntntFrm *GetFollow();
+inline const SwCntntFrm *GetPrecede() const;
+inline SwCntntFrm *GetPrecede();
SwTxtFrm* FindMaster() const;
//Layoutabhaengiges Cursortravelling
@@ -147,6 +149,14 @@ inline SwCntntFrm *SwCntntFrm::GetFollow()
{
return (SwCntntFrm*)SwFlowFrm::GetFollow();
}
+inline const SwCntntFrm *SwCntntFrm::GetPrecede() const
+{
+return (const SwCntntFrm*)SwFlowFrm::GetPrecede();
+}
+inline SwCntntFrm *SwCntntFrm::GetPrecede()
+{
+return (SwCntntFrm*)SwFlowFrm::GetPrecede();
+}
#endif
diff --git a/sw/source/core/inc/flowfrm.hxx b/sw/source/core/inc/flowfrm.hxx
index da3e5ca..bc9557a 100644
--- a/sw/source/core/inc/flowfrm.hxx
+++ b/sw/source/core/inc/flowfrm.hxx
@@ -115,6 +115,7 @@ class SwFlowFrm
protected:
SwFlowFrm *pFollow;
+SwFlowFrm *pPrecede;
sal_Bool bIsFollow :1; //Ist's ein Follow
sal_Bool bLockJoin :1; //Join (und damit deleten) verboten wenn sal_True!
@@ -171,7 +172,10 @@ public:
const SwFlowFrm *GetFollow() const { return pFollow; }
SwFlowFrm *GetFollow() { return pFollow; }
sal_Bool IsAnFollow( const SwFlowFrm *pFlow ) const;
-inline void SetFollow( SwFlowFrm *pNew ) { pFollow = pNew; }
+inline void SetFollow( SwFlowFrm *pNew );
+
+const SwFlowFrm *GetPrecede() const { return pPrecede; }
+ SwFlowFrm *GetPrecede() { return pPrecede; }
sal_Bool IsJoinLocked() const { return bLockJoin; }
sal_Bool IsAnyJoinLocked() const { return bLockJoin || HasLockedFollow(); }
@@ -249,6 +253,12 @@ inline sal_Bool SwFlowFrm::IsFwdMoveAllowed()
return rThis.GetIndPrev() != 0;
}
+inline void SwFlowFrm::SetFollow( SwFlowFrm *pNew )
+{
+pFollow = pNew;
+if ( pFollow != NULL )
+pFollow-pPrecede = this;
+}
#endif
diff --git a/sw/source/core/inc/sectfrm.hxx b/sw/source/core/inc/sectfrm.hxx
index f9f7a2e..20f68f6 100644
--- a/sw/source/core/inc/sectfrm.hxx
+++ b/sw/source/core/inc/sectfrm.hxx
@@ -128,6 +128,10 @@ public:
bool IsBalancedSection() const;
+#if OSL_DEBUG_LEVEL 1
+virtual void dumpAsXmlAttributes(xmlTextWriterPtr writer);
+#endif
+
DECL_FIXEDMEMPOOL_NEWDEL(SwSectionFrm)
};
diff --git a/sw/source/core/inc/tabfrm.hxx b/sw/source/core/inc/tabfrm.hxx
index a81b25b..8e2e507 100644
--- a/sw/source/core/inc/tabfrm.hxx
+++ b/sw/source/core/inc/tabfrm.hxx
@@ -216,6 +216,10 @@ public:
sal_uInt16 GetBottomLineSize() const;
// -- collapsing
+#if OSL_DEBUG_LEVEL 1
+virtual void dumpAsXmlAttributes(xmlTextWriterPtr writer);
+#endif
+
DECL_FIXEDMEMPOOL_NEWDEL(SwTabFrm)
};
diff --git a/sw/source/core/layout/flowfrm.cxx b/sw/source/core/layout/flowfrm.cxx
index 9ba8202..51cb49b 100644
--- a/sw/source/core/layout/flowfrm.cxx
+++ b/sw/source/core/layout/flowfrm.cxx
@@ -81,7 +81,8 @@ sal_Bool SwFlowFrm::bMoveBwdJump = sal_False;
SwFlowFrm::SwFlowFrm( SwFrm rFrm ) :
rThis( rFrm ),
-pFollow( 0 )
+pFollow( 0 ),
+pPrecede( 0 )
{
bLockJoin = bIsFollow = bCntntLock = bOwnFtnNum =
bFtnLock = bFlyLock = sal_False;
@@ -691,16 +692,12 @@ SwTxtFrm* SwCntntFrm::FindMaster() const
{
OSL_ENSURE( IsFollow(), SwCntntFrm::FindMaster(): !IsFollow );
-const SwCntntFrm* pCnt = GetPrevCntntFrm();
+const
Re: [Libreoffice] [PATCH][REVIEW] fix missing DESTDIR variable in chmod call
Tomáš Chvátal píše v St 17. 08. 2011 v 11:56 +0200: Should be applied to master and 3-4-3 branch for which we need two more sign offs. It is in the 3-4 branch, see http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4id=aabeb64cc0be9fe0eb840323b835ace956bdb65f We still need two more approvals for the 3-4-3 branch. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Enable CUPS unconditionally
On Mon, 2011-08-22 at 20:25 +0200, Francois Tigeot wrote: However, it is my intention to make the print code link with cups normally, Probably a good thing. As an aside see http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg03549.html for the horrors of cups+libgcrypt+neon C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build failing in tail_build module
Hi swagat, swagat sharma wrote (23-08-11 11:30) Hi I got the following error. Any ideas? Did you try to do what was advised by the output? -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] build dependencies, removing headers and getting away with it. (was build errors on Ubuntu)
On Mon, 2011-08-22 at 23:37 +0200, Cor Nouws wrote: ERROR: error 65280 occurred while making /home/cono/src/git/libo_core/rsc/prj /home/cono/src/git/libo_core/xmloff/prj Well, firstly these don't really include the actual error, but I'm going to guess that its very likely the problem is header files that used to exist, got removed, and whose references in .cxx files also got removed correctly, but there are stale dependencies that still depend on the removed headers. Even if this isn't the problem here, is such a common problem that its generally the case. So.. I suggest we add -MP to our gcc dependency generation, that makes extra fake rules for each dependency so that a missing header is considered ok, i.e. http://www.makelinux.net/make3/make3-CHP-8-SECT-3 and (also attached) patch from https://bugs.freedesktop.org/show_bug.cgi?id=40099 Testing here shows that it allows a rebuild to survive a removed header and rebuild without annoying halt and spew, so the problem just goes away. Bigger dependencies I guess, but I think its worth a lot to just be able to make. Unless someone knows a good reason why this is a really stupid idea I'll push it later today. Non-gcc platforms might be able to hack up the same sort of support with the sed example from the make book above. C. diff --git a/solenv/gbuild/platform/ios.mk b/solenv/gbuild/platform/ios.mk index 1039497..4a93587 100644 --- a/solenv/gbuild/platform/ios.mk +++ b/solenv/gbuild/platform/ios.mk @@ -147,7 +147,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(1) \ - -MF $(4) \ + -MP -MF $(4) \ -I$(dir $(3)) \ $(INCLUDE)) endef @@ -166,7 +166,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(1) \ - -MF $(4) \ + -MP -MF $(4) \ -I$(dir $(3)) \ $(INCLUDE_STL) $(INCLUDE)) endef @@ -184,7 +184,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(1) \ - -MF $(4) \ + -MP -MF $(4) \ -I$(dir $(3)) \ $(INCLUDE_STL) $(INCLUDE)) endef @@ -201,7 +201,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(call gb_ObjCObject_get_target,$(2)) \ - -MF $(call gb_ObjCObject_get_dep_target,$(2)) \ + -MP -MF $(call gb_ObjCObject_get_dep_target,$(2)) \ -I$(dir $(3)) \ $(INCLUDE_STL) $(INCLUDE)) endef diff --git a/solenv/gbuild/platform/macosx.mk b/solenv/gbuild/platform/macosx.mk index 5f9fe9e..1c62144 100644 --- a/solenv/gbuild/platform/macosx.mk +++ b/solenv/gbuild/platform/macosx.mk @@ -176,7 +176,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(1) \ - -MF $(4) \ + -MP -MF $(4) \ -I$(dir $(3)) \ $(INCLUDE)) endef @@ -195,7 +195,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(1) \ - -MF $(4) \ + -MP -MF $(4) \ -I$(dir $(3)) \ $(INCLUDE_STL) $(INCLUDE)) endef @@ -213,7 +213,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(1) \ - -MF $(4) \ + -MP -MF $(4) \ -I$(dir $(3)) \ $(INCLUDE_STL) $(INCLUDE)) endef @@ -230,7 +230,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(call gb_ObjCObject_get_target,$(2)) \ - -MF $(call gb_ObjCObject_get_dep_target,$(2)) \ + -MP -MF $(call gb_ObjCObject_get_dep_target,$(2)) \ -I$(dir $(3)) \ $(INCLUDE_STL) $(INCLUDE)) endef diff --git a/solenv/gbuild/platform/unxgcc.mk b/solenv/gbuild/platform/unxgcc.mk index 74276dd..35975e4 100644 --- a/solenv/gbuild/platform/unxgcc.mk +++ b/solenv/gbuild/platform/unxgcc.mk @@ -199,7 +199,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(1) \ - -MF $(4) \ + -MP -MF $(4) \ -I$(dir $(3)) \ $(INCLUDE)) endef @@ -218,7 +218,7 @@ $(call gb_Helper_abbreviate_dirs,\ -c $(3) \ -o $(1) \ -MMD -MT $(1) \ - -MF $(4) \ + -MP -MF $(4) \ -I$(dir $(3)) \ $(INCLUDE_STL) $(INCLUDE)) endef @@ -240,7 +240,7 @@ $(call gb_Helper_abbreviate_dirs,\ # -c $(3) \ # -o $(1) \ # -MMD -MT $(1) \ - # -MF $(4) \ + # -MP -MF $(4) \ # -I$(dir $(3)) \ # $(INCLUDE)) endef ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build failing in tail_build module
Hello Swagat, As Cor suggested try to follow the instructions in the output, go to root dir of your source and 'source Env.Host.sh' after running this: 'cd tail_build', 'make clean', 'make -sr' I had the same problem and it resolved me the issue,however I don't know why this error occured, it should be investigated. Gabor 2011. 08. 23. 11:30 keltezéssel, swagat sharma írta: Hi I got the following error. Any ideas? I didn't make any changes in the code, just trying to build the master. Error -- scripting deliver Module 'scripting' delivered successfully. 5 files copied, 30 files unchanged odk deliver [ build CXX ] sd/source/ui/dlg/TemplateScanner Module 'odk' delivered successfully. 1 files copied, 3 files unchanged /home/eswagsh/Documents/LibreOffice_Sourc_Code/libreoffice-3.5.0/libo/sd/source/ui/dlg/TemplateScanner.cxx: In member function 'sd::TemplateScanner::State sd::TemplateScanner::ScanEntry()': /home/eswagsh/Documents/LibreOffice_Sourc_Code/libreoffice-3.5.0/libo/sd/source/ui/dlg/TemplateScanner.cxx:268: error: 'ConvertResourceString' is not a member of 'SfxDocumentTemplates' [ build CUT ] hwpfilter_test_hwpfilter [ build CUT ] lotuswordpro_test_lotuswordpro make[1]: *** Waiting for unfinished jobs dmake: Error code 2, while making 'all' --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 65280 occurred while making /home/eswagsh/Documents/LibreOffice_Sourc_Code/libreoffice-3.5.0/libo/tail_build/prj it seems that the error is inside 'tail_build', please re-run build inside this module to isolate the error and/or test your fix: --- rm -Rf /home/eswagsh/Documents/LibreOffice_Sourc_Code/libreoffice-3.5.0/libo/tail_build/unxlngx6.pro http://unxlngx6.pro # optional module 'clean' /bin/bash cd /home/eswagsh/Documents/LibreOffice_Sourc_Code/libreoffice-3.5.0/libo source ./Env.Host.sh http://Env.Host.sh cd tail_build make -r when the problem is isolated and fixed exit and re-run 'make' from the top-level make: *** [all] Error 1 -- Swagat ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Enable CUPS unconditionally
On Mon, Aug 22, 2011 at 11:32:50PM +0200, Francois Tigeot wrote: That was just the configure check beeing too zealous. I've fixed it. Mark as pushed -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fix for fdo#39510 to backport
On Tue, 23 Aug 2011 11:40:35 +0200 (CEST) cedric.bosdonnat@free.fr wrote: Could some of you please review this commit to be backported to the 3.4.3 branch fixing a nasty crasher with loads of dupes (fdo#39510)? http://cgit.freedesktop.org/libreoffice/writer/commit/?id=9ecab7 Here is an update patch for 3.4 branch with the following fixes: * Added missing #if OSL_DEBUG_LEVEL 1 * Initialized pPrecede to 0 in constructor Patch looks good to me. I am not absolutely sure all FindMaster bugs are killed for good with it, but it is a lot better than before and seems low risk to me. Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] cherry pick graphite into 3.4.4
Hi Martin, On Tue, 2011-08-23 at 14:49 +0700, Martin Hosken wrote: This is a request for revision 6aed24cc5bc1 to be cherry picked from master into the latest 3.4. By which I assume you mean: commit 977bc66a2a641c809cbb152960f1fb691eb77b63 Author: Martin Hosken martin_hos...@sil.org Date: Tue Aug 23 09:22:29 2011 +0700 Upgrade graphite to 1.0.2 and simplify patches I've extracted applied it to libreoffice-3-4 (in two separate pieces for the different repos) ;-) 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] cherry pick graphite into 3.4.4
On Tue, 2011-08-23 at 14:49 +0700, Martin Hosken wrote: This is a request for revision 6aed24cc5bc1 to be cherry picked from master into the latest 3.4. Needs the additional patch of http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3bf28445af8080b7daace1b536fbc289b175bdd to build under msvc. Is there a bug-tracker for graphite2 ? and/or can you add that trivial #include new for the placement new usage for the next upstream graphite2 release. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Remove unused globals from make_installer.pl
On Mon, 2011-08-22 at 22:29 -0500, Jordan Ayers wrote: Another minor cleanup, related to fdo#39747. Nice work :-) the more of these we knock out of the code, the better life will be when we start to need to add features there :-) I just pushed the patch. eg. our cross-compiling work is going to have quite some excitement around building MSI files using wine I think - so re-factoring of the (hugely cut/pasted) msi execution would be good too - though intricate would need doing rather carefully I guess. Anyhow - good to see it getting the long overdue love it needs. Thanks ! Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Make pyuno work with system python
On Mon, 2011-08-22 at 19:12 +0200, Petr Mladek wrote: Is the hack with uno.py needed at all? Do I test the python stuff a wrong way? Nothing to do with emailmerge, that's used from inside LibreOffice itself, this just matters for external python scripts that want to communicate/use LibreOffice stuff. IIRC i.e. that python import uno should pass is sufficient to demo. bibus is an example of a real-world python pyuno-using program for bigger-scale testing of out-of-proecss pyuno C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Remove an unused perl module
Hi Jordan, On Mon, 2011-08-22 at 23:53 -0500, Jordan Ayers wrote: Another one related to fdo#39747. Another nice catch :-) pushed it. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Make pyuno work with system python
On Mon, 2011-08-22 at 22:35 +0200, Lionel Elie Mamane wrote:
if uno.py is being loaded (presumably from its place in
@libdir@/@OOOINSTALLDIRNAME@/basis-link/program), it means the python
load path already contains that. If the python load path does not
contain that directory, adding it from within uno.py does not help
because of chicken-and-egg problem of python finding uno.py in the
first place.
Unless we want to allow distributions to install uno.py in
%{python_sitearch}, but *not* the other things it needs, such as
pyuno.so; I'm not sure I get the rationale for wanting to do that.
Yeah, I (distros in general, I suppose) for the part-of-a-distro case
anyway, want to install uno.py and unohelper.py in site-packages and
have import uno just work out-of-the-box for stuff like bibus without
them (or their down stream packagers) caring where or what version of
LibreOffice etc are installed.
Easiest thing to do was to leave pyuno.so inside the /foo/libreoffice
tree to be in the right place for its $ORIGIN:$ORIGIN/foo/ rpath to find
the libs it links to and munge uno.py to tell it where that is, and
something similar for the URE_BOOTSTRAP whose purpose I forget at the
moment.
C.
___
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 39510, which changed state. Bug 39510 Summary: CRASH closing document with footnotes https://bugs.freedesktop.org/show_bug.cgi?id=39510 What|Old Value |New Value Resolution||FIXED 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
[Libreoffice] [PATCH] make graphite2 work on bigendian (was: Re: cherry pick graphite into 3.4.4)
Hi, On Tue, Aug 23, 2011 at 11:19:29AM +0200, Rene Engelhard wrote: I know this s bbroken right now, too, but shouldn't we (if we add this version), then fix the big-endian stuff, too? (As we don't use the cmake build we need to sett he -DWORDS_BIGENDIAN manually, I think we can rsue and export the variable we use in configure anyway. Can come up with a patch tonight...) There we go now already. trvial :) Can commit to master tonight, and if someone agres I can also cherry-pick to -3-4 then... Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 From 1b0f75050095fe7ce6d09720c63825883a94be29 Mon Sep 17 00:00:00 2001 From: Rene Engelhard r...@debian.org Date: Tue, 23 Aug 2011 11:35:15 +0200 Subject: [PATCH] export WORDS_BIGENDIAN in set_soenv and make graphite2 use it --- graphite/graphite_make.patch |6 +- set_soenv.in |1 + 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/graphite/graphite_make.patch b/graphite/graphite_make.patch index 73b6205..c137c12 100644 --- a/graphite/graphite_make.patch +++ b/graphite/graphite_make.patch @@ -1,6 +1,6 @@ --- misc/build/graphite2-1.0.2/src/makefile.mk Fri Mar 4 10:20:30 2011 +0700 +++ misc/build/graphite2-1.0.2/src/makefile.mk Fri Mar 4 10:20:30 2011 +0700 -@@ -1,1 +1,34 @@ +@@ -1,1 +1,38 @@ -dummy +EXTERNAL_WARNINGS_NOT_ERRORS := TRUE + @@ -18,6 +18,10 @@ +CFLAGS+=-O3 -DNDEBUG +.ENDIF + ++.IF $(WORDS_BIGENDIAN) == yes ++CFLAGS += -DWORDS_BIGENDIAN ++.ENDIF ++ +_NS := GR2 + +GR2_MACHINE=call diff --git a/set_soenv.in b/set_soenv.in index 03edbcf..2d97ff2 100755 --- a/set_soenv.in +++ b/set_soenv.in @@ -1826,6 +1826,7 @@ ToFile( ALIGNOF_SHORT,@ALIGNOF_SHORT@, e ); ToFile( ALIGNOF_INT, @ALIGNOF_INT@, e ); ToFile( ALIGNOF_LONG, @ALIGNOF_LONG@, e ); ToFile( ALIGNOF_DOUBLE, @ALIGNOF_DOUBLE@, e ); +ToFile( WORDS_BIGENDIAN, @WORDS_BIGENDIAN@, e ); ToFile( HAVE_GCC_NO_LONG_DOUBLE, @HAVE_GCC_NO_LONG_DOUBLE@, e ); ToFile( HAVE_GCC_AVX, @HAVE_GCC_AVX@, e ); ToFile( HAVE_GCC_VISIBILITY_FEATURE, -- 1.7.5.4 ___ 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 Alex Thurgood alex.thurg...@gmail.com changed: What|Removed |Added Depends on||39950 --- Comment #191 from Alex Thurgood alex.thurg...@gmail.com 2011-08-23 05:32:31 PDT --- Nominating 39950 - regression with regard to 3.3.3 and 3.3.4. Copy/pasting report designer objects (fields, labels, etc) between sections causes systematic crash. Alex -- 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] [PATCH] build errors
Hello,
As I tried to build a fully debug version I saw several errors in
different source files, finally I made the build to work, but I still
cannot do make dev-install (I'm going to work on this now). Here is a
patch that contains all the necessary modifications of sources.
Gabor
From 98e221820a0474dee27ce18396f1b5cae8a7f168 Mon Sep 17 00:00:00 2001
From: Gabor jen...@elte.hu
Date: Tue, 23 Aug 2011 14:25:38 +0200
Subject: [PATCH] debug build errors
---
automation/source/server/statemnt.cxx |4 ++--
automation/source/simplecm/simplecm.cxx|4 ++--
.../source/model/main/ChartModel_Persistence.cxx |2 +-
chart2/source/model/template/ChartTypeTemplate.cxx |4 ++--
cppcanvas/source/mtfrenderer/emfplus.cxx |1 +
sc/source/core/data/attarray.cxx |1 +
6 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/automation/source/server/statemnt.cxx
b/automation/source/server/statemnt.cxx
index ed0e110..12a00e3 100644
--- a/automation/source/server/statemnt.cxx
+++ b/automation/source/server/statemnt.cxx
@@ -692,7 +692,7 @@ StatementCommand::StatementCommand( StatementList
*pAfterThis, sal_uInt16 Method
if( nParams PARAM_UINT16_2 ) {m_pDbgWin-AddText( n2:
);m_pDbgWin-AddText( String::CreateFromInt32( nNr2 ) );}
if( nParams PARAM_UINT16_3 ) {m_pDbgWin-AddText( n3:
);m_pDbgWin-AddText( String::CreateFromInt32( nNr3 ) );}
if( nParams PARAM_UINT16_4 ) {m_pDbgWin-AddText( n4:
);m_pDbgWin-AddText( String::CreateFromInt32( nNr4 ) );}
-if( nParams PARAM_UINT32_1 ) {m_pDbgWin-AddText( nl1:
);m_pDbgWin-AddText( String::CreateFromInt64( nLNr1 ) );}
+if( nParams PARAM_UINT32_1 ) {m_pDbgWin-AddText( nl1:
);m_pDbgWin-AddText( String::CreateFromInt64( nLNr1_and_Pointer.nLNr1 ) );}
if( nParams PARAM_STR_1 ) {m_pDbgWin-AddText( s1:
);m_pDbgWin-AddText( aString1 );}
if( nParams PARAM_STR_2 ) {m_pDbgWin-AddText( s2:
);m_pDbgWin-AddText( aString2 );}
if( nParams PARAM_BOOL_1 ){m_pDbgWin-AddText( b1:
);m_pDbgWin-AddText( bBool1 ? TRUE : FALSE );}
@@ -739,7 +739,7 @@ StatementCommand::StatementCommand( SCmdStream *pCmdIn )
if( nParams PARAM_UINT16_2 ) {m_pDbgWin-AddText( n2:
);m_pDbgWin-AddText( String::CreateFromInt32( nNr2 ) );}
if( nParams PARAM_UINT16_3 ) {m_pDbgWin-AddText( n3:
);m_pDbgWin-AddText( String::CreateFromInt32( nNr3 ) );}
if( nParams PARAM_UINT16_4 ) {m_pDbgWin-AddText( n4:
);m_pDbgWin-AddText( String::CreateFromInt32( nNr4 ) );}
-if( nParams PARAM_UINT32_1 ) {m_pDbgWin-AddText( nl1:
);m_pDbgWin-AddText( String::CreateFromInt64( nLNr1 ) );}
+if( nParams PARAM_UINT32_1 ) {m_pDbgWin-AddText( nl1:
);m_pDbgWin-AddText( String::CreateFromInt64( nLNr1_and_Pointer.nLNr1 ) );}
if( nParams PARAM_STR_1 ) {m_pDbgWin-AddText( s1:
);m_pDbgWin-AddText( aString1 );}
if( nParams PARAM_STR_2 ) {m_pDbgWin-AddText( s2:
);m_pDbgWin-AddText( aString2 );}
if( nParams PARAM_BOOL_1 ){m_pDbgWin-AddText( b1:
);m_pDbgWin-AddText( bBool1 ? TRUE : FALSE );}
diff --git a/automation/source/simplecm/simplecm.cxx
b/automation/source/simplecm/simplecm.cxx
index 39f8643..2cc5b93 100644
--- a/automation/source/simplecm/simplecm.cxx
+++ b/automation/source/simplecm/simplecm.cxx
@@ -43,10 +43,10 @@
#include stdio.h
void debug_printf( const char *chars )
{
-static BOOL bPrint = (getenv(DEBUG) != NULL);
+static bool bPrint = (getenv(DEBUG) != NULL);
if ( bPrint )
{
-printf( %c\n, chars );
+printf( %s\n, chars );
fflush( stdout );
}
}
diff --git a/chart2/source/model/main/ChartModel_Persistence.cxx
b/chart2/source/model/main/ChartModel_Persistence.cxx
index b1cbbd0..809419b 100644
--- a/chart2/source/model/main/ChartModel_Persistence.cxx
+++ b/chart2/source/model/main/ChartModel_Persistence.cxx
@@ -503,7 +503,7 @@ void SAL_CALL ChartModel::initNew()
#if OSL_DEBUG_LEVEL = CHART_TRACE_OSL_DEBUG_LEVEL
OSL_TRACE( ChartModel::initNew: Showing ChartDocument structure );
OSL_TRACE( );
-debug::ChartDebugTraceDocument( Reference chart2::XChartDocument ( this
));
+::chart::debug::ChartDebugTraceDocument( Reference chart2::XChartDocument
( this ));
#endif
}
diff --git a/chart2/source/model/template/ChartTypeTemplate.cxx
b/chart2/source/model/template/ChartTypeTemplate.cxx
index 9fee9b3..77d2b3f 100644
--- a/chart2/source/model/template/ChartTypeTemplate.cxx
+++ b/chart2/source/model/template/ChartTypeTemplate.cxx
@@ -322,7 +322,7 @@ void SAL_CALL ChartTypeTemplate::changeDiagramData(
#if OSL_DEBUG_LEVEL = CHART_TRACE_OSL_DEBUG_LEVEL
OSL_TRACE( ChartTypeTemplate::changeDiagramData: Showing Diagram
structure );
OSL_TRACE(
--- );
-debug::ChartDebugTraceDiagram( xDiagram );
+::chart::debug::ChartDebugTraceDiagram(
[Libreoffice] [PUSHED][PATCH] build errors
On Tue, 2011-08-23 at 14:33 +0200, Jenei Gábor wrote: Hello, As I tried to build a fully debug version I saw several errors in different source files Looks good, pushed, thanks for this. Can you verify that your patches are under the preferred LGPLv3+/MPLv1.1 combo ? (can also do a all my patches will be under this unless I say otherwise to keep it simple) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] DrawPolyLine on Windows
Hello!
I tried to draw polyline But on Windows... the end point is not
drawn... the main problem is WinAPI LineTo() function. MSDN says:
The *LineTo* function draws a line from the current position up to,
but not including, the specified point.
I think WinAPI Polyline() function uses LineTo() to draw a polyline. I
see a hack in VCL module in WinSalgraphics::drawLine():
// we must paint the endpoint
But there is no such hack for drawPolyLine() function. A possible
solution is same as for drawLine():
--- a/vcl/win/source/gdi/salgdi.cxx
+++ b/vcl/win/source/gdi/salgdi.cxx
@@ -1346,10 +1346,45 @@ void WinSalGraphics::drawPolyLine( sal_uLong
nPoints, const SalPoint* pPtAry )
WinSalGraphics::DrawPolyLine(): POINT != SalPoint );
POINT* pWinPtAry = (POINT*)pPtAry;
+
+// we assume there are at least 2 points (Polyline requres at least
2 point, see MSDN)
+// we must paint the endpoint for last line
+BOOL bPaintEnd = TRUE;
+if ( pWinPtAry[nPoints-2].x == pWinPtAry[nPoints-1].x )
+{
+bPaintEnd = FALSE;
+if ( pWinPtAry[nPoints-2].y = pWinPtAry[nPoints-1].y )
+pWinPtAry[nPoints-1].y++;
+else
+pWinPtAry[nPoints-1].y--;
+}
+if ( pWinPtAry[nPoints-2].y == pWinPtAry[nPoints-1].y )
+{
+bPaintEnd = FALSE;
+if ( pWinPtAry[nPoints-2].x = pWinPtAry[nPoints-1].x )
+pWinPtAry[nPoints-1].x++;
+else
+pWinPtAry[nPoints-1].x--;
+}
+
// Wegen Windows 95 und der Beschraenkung auf eine maximale Anzahl
// von Punkten
if ( !Polyline( mhDC, pWinPtAry, (int)nPoints ) (nPoints
MAX_64KSALPOINTS) )
Polyline( mhDC, pWinPtAry, MAX_64KSALPOINTS );
+
+if ( bPaintEnd !mbPrinter )
+{
+if ( mbXORMode )
+{
+HBRUSH hBrush = CreateSolidBrush( mnPenColor );
+HBRUSH hOldBrush = SelectBrush( mhDC, hBrush );
+PatBlt( mhDC, (int)(pWinPtAry[nPoints-1].x),
(int)(pWinPtAry[nPoints-1].y), (int)1, (int)1, PATINVERT );
+SelectBrush( mhDC, hOldBrush );
+DeleteBrush( hBrush );
+}
+else
+SetPixel( mhDC, (int)(pWinPtAry[nPoints-1].x),
(int)(pWinPtAry[nPoints-1].y), mnPenColor );
+}
}
// ---
--
Best Regards,
Dmitry
--
Best Regards,
Dmitry
attachment: dmitry_ashkadov.vcf___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED 3.4.3] Re: [PUSHED][REVIEW] Cherry-pick in 3.4.2?
Hi all, On 2011-08-22 at 18:08 +0200, Petr Mladek wrote: Aggregated the various fixes together, and pushed complete work as http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4id=05e819b26a47089f56c1084302d4afcff3f66de7 to 3-4 which should make it easier to review for a further cherry-pick back to the current 3.4.X-de-jour. Looks good to me. We need one more approval for the 3-4-3 branch. You have my :-) I have pushed that to the libreoffice-3-4-3 branch too. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] make graphite2 work on bigendian (was: Re: cherry pick graphite into 3.4.4)
On Tue, 2011-08-23 at 14:08 +0200, Rene Engelhard wrote: Can commit to master tonight, and if someone agres I can also cherry-pick to -3-4 then... Looks good to me :-) if I was paranoid, I'd point out that I'd prefer the options to be TRUE vs. empty rather than: WORDS_BIGENDIAN=$ac_cv_c_bigendian but its just fine for 3.4. Thanks ! Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][PUSHED-3-4-3] fix missing DESTDIR variable in chmod call
Looks good, cherry-picked to 3-4-3 Cheers, -- Thorsten pgpENYBZDsl23.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility
Hi Kohei, On Monday, 2011-08-22 18:46:22 -0400, Kohei Yoshida wrote: But we still need to modify the original base class to have the additional boolean member (m_bFireEvent) in order for the fire() method to see that member and use it in that method. I suppose there is no way around it (?) The m_pReserved you mentioned earlier in this thread seems to be a viable approach. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSOC][patch] Multiline inputbar
Hello Kohei,
This is a fix to some of the things you mentioned in last patch.
Setting the paper size inside the Resize() of ScMultiTextWnd solves
two issues
1: Prevents premature wrapping which was happening before.
2: The paperSize is recalculated as per the window size.
Regards
--
Anurag Jain
Final yr B.Tech CSE
SASTRA University
Thanjavur(T.N.)-613402
From 14b16dbef8b57c87ec7e077c27ae5f74a26ed449 Mon Sep 17 00:00:00 2001
From: Anurag Jain anuragjain...@gmail.com
Date: Tue, 23 Aug 2011 20:19:39 +0530
Subject: [PATCH] Fixed premature wrapping, black spot in A1 and scrollbar and button position.
---
sc/source/ui/app/inputwin.cxx | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx
index bff10cb..9c1879f 100644
--- a/sc/source/ui/app/inputwin.cxx
+++ b/sc/source/ui/app/inputwin.cxx
@@ -835,8 +835,8 @@ void ScInputBarGroup::Resize()
}
SetSizePixel(aSize);
-aButton.SetPosPixel(Point(aSize.Width()-4*LEFT_OFFSET,0));
-aScrollBar.SetPosPixel(Point(aSize.Width()-2*LEFT_OFFSET,0));
+aScrollBar.SetPosPixel(Point(aSize.Width()-4*LEFT_OFFSET,0));
+aButton.SetPosPixel(Point(aSize.Width()-2*LEFT_OFFSET,0));
Invalidate();
aMultiTextWnd.Resize();
@@ -902,7 +902,7 @@ IMPL_LINK( ScInputBarGroup, ClickHdl, PushButton*, pBtn )
pParent-SetMultiLineStatus(false);
}
pParent-Resize();
-pParent-CalcWindowSizePixel(); // TODO: changed from RecalcItems(). check if this does the same thing.
+//pParent-CalcWindowSizePixel(); // TODO: changed from RecalcItems(). check if this does the same thing.
return 0;
}
@@ -934,8 +934,8 @@ void ScMultiTextWnd::Paint( const Rectangle rRec )
{
// We always use edit engine to draw text at all times.
if (!pEditEngine)
-//InitEditEngine(SfxObjectShell::Current());
-StartEditEngine();
+InitEditEngine(SfxObjectShell::Current());
+//StartEditEngine();
if (pEditView)
{
@@ -979,6 +979,8 @@ void ScMultiTextWnd::Resize()
pEditView-SetOutputArea(
PixelToLogic(Rectangle(aPos1, aPos2)));
+ pEditEngine-SetPaperSize( PixelToLogic(Size(aOutputSize.Width() - 2*LEFT_OFFSET, 1 ) ));
+
}
}
@@ -998,6 +1000,8 @@ void ScMultiTextWnd::Resize()
pEditView-SetOutputArea(
PixelToLogic(Rectangle(aPos1, aPos2)));
+
+pEditEngine-SetPaperSize( PixelToLogic(Size(aOutputSize.Width() - 2*LEFT_OFFSET, 1 ) ));
}
}
SetSizePixel(aTextBoxSize);
@@ -1084,9 +1088,9 @@ void ScMultiTextWnd::InitEditEngine(SfxObjectShell* pObjSh)
Size barSize=GetSizePixel();
barSize.Width() -= (2*nTextStartPos-4);
-printf(bar size width %ld,barSize.Width());
+printf(bar size width %ld\n,barSize.Width());
pEditEngine-SetUpdateMode( false );
-pEditEngine-SetPaperSize( PixelToLogic(Size(994-4*LEFT_OFFSET,1)) );
+pEditEngine-SetPaperSize( PixelToLogic(Size(barSize.Width(),1)) );
pEditEngine-SetWordDelimiters(
ScEditUtil::ModifyDelimiters( pEditEngine-GetWordDelimiters() ) );
--
1.7.0.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] build errors
Yes,naturally, however I've already certified,but all my codes are under the mentioned license unless I state something else. Thanks, Gabor 2011. 08. 23. 15:07 keltezéssel, Caolán McNamara írta: On Tue, 2011-08-23 at 14:33 +0200, Jenei Gábor wrote: Hello, As I tried to build a fully debug version I saw several errors in different source files Looks good, pushed, thanks for this. Can you verify that your patches are under the preferred LGPLv3+/MPLv1.1 combo ? (can also do a all my patches will be under this unless I say otherwise to keep it simple) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build break in module basic
Hi Regina, On Tuesday, 2011-08-23 01:43:09 +0200, Regina Henschel wrote: In IRC erAck guesses, that the reason might be blanks in the pathes and missing quotes. I'll try his advise: it _might_ help to change solenv/gbuild/platform/windows.mk in line 360 from $(ML_EXE) to $(ML_EXE) And did that help? Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] DrawPolyLine on Windows
I tried to draw polyline But on Windows... the end point is not drawn... I am not saying your patch is not useful, but just out of interest, how do you interpret the word point in the GDI documentation for LineTo()? Does it in fact simply mean pixel? But what if the current pen is wider than one pixel? Or is the vagueness intentional and any expectation of pixel-perect repeatable results with different graphics devices and drivers is futile? Compared to how strictly mathematically X11 graphics is defined for wide lines, the GDI specification is just horrible. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED:3-4-3][REVIEWED] Cherry-pick in 3.4.2?
Petr Mladek píše v Po 22. 08. 2011 v 18:08 +0200: Caolán McNamara píše v Po 22. 08. 2011 v 15:00 +0100: On Wed, 2011-08-17 at 14:03 +0200, Cedric Bosdonnat wrote: Ok, after some details on the list, this is an additional fix for this and Lubos' comment: Aggregated the various fixes together, and pushed complete work as http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4id=05e819b26a47089f56c1084302d4afcff3f66de7 to 3-4 which should make it easier to review for a further cherry-pick back to the current 3.4.X-de-jour. Looks good to me. We need one more approval for the 3-4-3 branch. I has been approved and pushed into 3-4-3 branch by Kendy. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility
On Tue, 2011-08-23 at 17:00 +0200, Lionel Elie Mamane wrote: Any better idea? I'm still holding on to my earlier evil idea. To me making a duplicate is starting to feel like lesser of an evil. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kohei.yosh...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility
On Tue, 2011-08-23 at 17:09 +0200, Lionel Elie Mamane wrote: On Mon, Aug 22, 2011 at 11:53:59PM +0200, Eike Rathke wrote: Maybe due to some overzealous introduction of such helper implementations into the UDK. Sure, it eases development of applications, but at the costs we're facing now. The more helper we give to extensions, the less bugs they will have and the more they will conform to interfaces we want them to conform to. Looks like it can be worth the cost. No, that's a wrong way to put it. The whole purpose of having common interfaces is to give implementation a freedom to implement as long as it conforms to the agreed-upon interfaces. Exposing the *implementation* of the interface to the extensions basically throws away that freedom, and we are paying for that now. So, no, it's definitely NOT worth the cost. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kohei.yosh...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED][PATCH] Remove unnecessary parameter to IDocumentStatistics::UpdateDocStat
On Sun, 2011-08-21 at 20:41 +0200, Arnaud Versini wrote: Hi, New version of the patch. I have added a method : IDocumentStatistic::GetUpdatedDocStat wich check state before returning. I left some UpdateDocStat but I will continue it later. Looks basically good to me. We can distinguish between the two purposes of the old call, to get updated stats because something wants to use them, and to force updating of cached statistics for e.g. updating fields. I paused for a bit seeing as I got a bit confused, and wrote a regression test for SwDocStat e.g. sw/qa/core/swdoc-test.cxx SwDocTest::testDocStat So, pushed now. I took the liberty of adding a GetUpdatedDocStat to EditShell as well and making those additional changes. There's probably no good reason to want possibly out-dated stats is there ?, so... a) We/you should remove any remaining GetDocStat calls and replace them with the GetUpdatedDocStat when they want to get current stats or UpdateDocStat when they might want to update the internal stats only b) Remove GetDocStat entirely and remove it from the new regression test too c) remove that bModified member from SwDocStat and move it into SwDoc as m_bStaleStats or something d) I'm not sure there's any good reason to set the DocStat in the (current) rtf filter. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC][patch] Multiline inputbar
Hi Anurag, On Tue, 2011-08-23 at 20:25 +0530, Anurag Jain wrote: Hello Kohei, This is a fix to some of the things you mentioned in last patch. Setting the paper size inside the Resize() of ScMultiTextWnd solves two issues 1: Prevents premature wrapping which was happening before. 2: The paperSize is recalculated as per the window size. Thanks for your patch. Before I apply your patch, could you confirm that your patch is submitted under LGPLv3+/MPL 1.1 licenses? Actually, confirming that for all your previous patches would be great. I should've asked that before, but I forgot. :-P Thanks a lot, -- Kohei Yoshida, LibreOffice hacker, Calc kohei.yosh...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Licensing for my work
Hello everyone, I'd like to say that all my contribution towards Libre office suite codebase can be licensed under LGPSv3/MPL dual license. My work will includes all the patches which I've submitted under GSOC program and apart from that , and LGPLv3/MPL can be applied to all of them. Thanks and regards, -- Anurag Jain Final yr B.Tech CSE SASTRA University Thanjavur(T.N.)-613402 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] patch for Bug 39468 - translate German comments, removing redundant ones
Hi Florian, On Mon, 2011-08-22 at 21:52 +0200, Florian Allmann-Rahn wrote: I have attached a patch for Bug 39468 translate German comments, removing redundant ones for the directories (in core) accessibility to (incl.) basemp. So in these directories there should be no more German comments after applying the patch. Wow - this is -really- nice work :-) thank you ! This is my first contribution to Libreoffice development and my first mail to this list, so I'm not used to all the processes here. You're doing great - often we'd write [PATCH] in the subject, which encourages people to review it (unless there is a [PUSHED] in reply like this mail), but otherwise you got everything right - nice git format-patch output, easy to review, smooth to apply - lovely. I hope that my patch still works and is useful at all. I've just read about that on the EasyHacks-wikipage and thought I could do that to get a first idea of Libreoffice development. So I've sent my work now even if I've not finished so many directories yet to avoid that I've spent much time on something that maybe might not even be needed after all. No worries - this work is really useful - especially when it is complete for a given directory - and you've cleaned up some nice big pieces. I assume you're using Miklos' bin/find-german-comments script ? But if it's useful, I'll keep on working on German-comments-translating and -removing and will regularly send you my work. Wonderful; incidentally - we ask people to specify that their code changes are under the MPL/LGPLv3+ dual-license - as we hope to go in this direction in future, can you confirm that ? (it saves time to have it with each patch mail). Thank you for an amazing program anyway! Hey - your thanks is much appreciated, especially as it comes in the form of code. Looking forward to your next move :-) 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] Bug 38882 - [EasyHack] Make it easier to select/deselect UI languages in the Windows installer
Hi Cato, On Mon, 2011-08-22 at 20:35 +0200, Cato Auestad wrote: Oh, I totally agree, but when I saw the bug report I worked from the same perspective as I do in my work. We aren't usually provided with the source, just a vendor MSI, so we make transforms. Ah :-) I don't think I can be of much assistance when it comes to modifying the installer in the sense you are proposing. It is pretty far beyond my knowledge and it seems like it would be quite the complex operation do change anything in that script. Sounds like an exciting opportunity to learn I think; though of course you'd really need a windows build to be able to test your changes. Ultimately, if you research a single problem enough - it is easy to collect the skills to hack on and improve almost anything: though it clearly takes time, and writing of a lot of notes. Given that we have to have as simple and repeatable build as possible, would you still be interested in working on this ? :-) 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.2 tag created (3.4.3-rc2)
Hi, there have been created the libreoffice-3.4.3.2 tag for 3.4.3-rc2 release. The corresponding official builds will be available by the end of the week. It will be used as final if no blocker is found. See the attached list of changes against 3.4.3-rc1. Now, you might switch your current 3-4 source tree to it using: ./g fetch --tags ./g checkout -b tag-libreoffice-3.4.3.2 libreoffice-3.4.3.2 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 + libs-core + backport collection of operator= fixes (fdo#37403) [Caolán McNamara] + writer + cherry-picked core:cc3d0d and fixed a few things (fdo#39510) [Cédric Bosdonnat] + common + branch libreoffice-3-4-3 [Petr Mladek] + version 3.4.3.2, tag libreoffice-3.4.3.2 (3.4.3-rc2) [Petr Mladek] + bootstrap + bump product version to 3.4.3-rc2, release number to 302 [Petr Mladek] + fixup non-respecting DESTDIR for DOCDIR chmod. [Tomáš Chvátal] + libs-core + backport collection of operator= fixes (fdo#37403) [Caolán McNamara] + translations + update translations from Pootle (and sl) for LibO 3.4.3 rc2 [Andras Timar] + update translations from Pootle for LibO 3.4.3 rc1 [Andras Timar] + writer + cherry-picked core:cc3d0d and fixed a few things (fdo#39510) [Cédric Bosdonnat] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] (no subject)
Hi all, After a fresh clone, I'm still seeing the following build breakage in globlmn.hrc on Mac OSX : svx 0 #define ITEM_FORM_CONTROL_PROPERTIES !defined _GLOBLMN_HRC 3 all Con~trol... 20110821 20:34:29 ^ f640: /Users/alex/DevHack/git/libo/workdir/unxmacxi.pro/inc/svx/globlmn.hrc, line 1: Error: syntax error f256: Error: !! 1 Error found!! I seemed to recall that Caolàn indicated this had been fixed, but either it has crept back in, or it was incomplete. My autogen options : ./autogen.sh 'CC=ccache gcc-4.0' 'CXX=ccache g++-4.0' --with-max-jobs=4 --with-num-cpus=2 --with-lang=en-US --with-distro=LibreOfficeMacOSX --enable-python=auto --enable-ext-mysql-connector --with-libmysql-path=/Users/alex/DevHack/mysql-connector-c-6.0.2-osx10.5-x86-32bit --disable-systray --with-sun-templates --enable-extra-gallery --enable-extra-template --enable-extra-sample --enable-extra-font --enable-ext-numbertext --enable-ext-oooblogger --enable-ext-google-docs --enable-ext-diagram --enable-ext-barcode Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility
On Tue, 2011-08-23 at 11:11 -0400, Kohei Yoshida wrote: On Tue, 2011-08-23 at 17:00 +0200, Lionel Elie Mamane wrote: Any better idea? I'm still holding on to my earlier evil idea. To me making a duplicate is starting to feel like lesser of an evil. Anyway, don't listen to my ramblings. You already have a good idea to follow up on, so my suggestion is to follow your idea. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kohei.yosh...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] development summary: year 2011, week 33
Hi, this time a brief summary of what happened during the 33rd week in 2011 on LibreOffice repositories and the living branches: + master:LO-3.5 development + libreoffice-3-3: fixes for LO-3.3.5 bug fix release + libreoffice-3-4: fixes for LO-3.4.4 bug fix release + libreoffice-3-4-3: final stabilization of the LO-3.4.3 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 + impress + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + libs-core + related: /short fread isn't an error when its eof (fdo#39376, fdo#34880) [Caolán McNamara] + components + toggling grammar checkbox deletes sentence (fdo#39348) [Caolán McNamara] + impress + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + libs-core + backport collection of operator= fixes (fdo#37403) [Caolán McNamara] + load Dialog library before trying to get embedded images (fdo#40079) [Lionel Elie Mamane] + related: /short fread isn't an error when its eof (fdo#39376, fdo#34880) [Caolán McNamara] + core + adding proper assignment operator to SdrRectObj (fdo#37403) [Cédric Bosdonnat] + additional patch for (fdo#39167) [Aaron Strontsman] + allow also access to StringList resources (fdo#37290) [Bjoern Michaelsen] + avoid single-point filled polygons (fdo#37559) [Thorsten Behrens] + even better SdrRectObj::operator= thanks to Stephan (fdo#37403) [Cédric Bosdonnat] + fix for - more conservative graphic replacemement (bnc#684784) [Noel Power] + fix how table style is applied (bnc#705991) [Radek Doulik] + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + fixed regression of a57a4078fcd9a0490bd661e3ced6fcbbe69fae73 (bnc#705991) [Radek Doulik] + fixed template dimension problem on Impress. (fdo#32719) [Jeffrey Chang] + fixed the SdrRectObj::operator = to avoid leaks (fdo#37403) [Cédric Bosdonnat] + hide staroffice filters when binfilter unavailable (fdo#36127) [Caolán McNamara] + improve column/table width when table width pagewidth (bnc#693477) [Noel Power] + load Dialog library before trying to get embedded images (fdo#40079) [Lionel Elie Mamane] + make CSV import ignore leading spaces before quoted field content (fdo#32703) [Eike Rathke] + migrate Basic to new resource service (fdo#37290) [Xisco Fauli] + migrate Java to new resource service (fdo#37290) [Bjoern Michaelsen] + related: /short fread isn't an error when its eof (fdo#39376, fdo#34880) [Caolán McNamara] + related: Add Estonian Kroon to Euro converter (fdo#33160) [Caolán McNamara] + revert Fixed crasher by using boost::shared_ptr (fdo#37403) [Cédric Bosdonnat] + sfxPickList singleton wasn't instantiated (fdo#39026) [Caolán McNamara] + toggle default config to false for crash-reporter installed (fdo#37206) [Caolán McNamara] + toggling grammar checkbox deletes sentence (fdo#39348) [Caolán McNamara] + write out *newly* empty library (fdo#40173) [Lionel Elie Mamane] nothing this week + common + branch libreoffice-3-4-3 [Petr Mladek] + version 3.4.3.1, tag libreoffice-3.4.3.1 (3.4.3-rc1) [Petr Mladek] + bootstrap + bump product version to 3.4.3-rc1, release number to 301 [Petr Mladek] + use proper switch name for system-sane-headers [Tomáš Chvátal] + filters + set link text properties [Radek Doulik] + impress + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + libs-core + related: /short fread isn't an error when its eof (fdo#39376, fdo#34880) [Caolán McNamara] + translations + update translations from Pootle (and sl) for LibO 3.4.3 rc2 [Andras Timar] + update translations from Pootle for LibO 3.4.3 rc1 [Andras Timar] + common + branch libreoffice-3-4-3 [Petr Mladek] + version 3.4.3.1, tag libreoffice-3.4.3.1 (3.4.3-rc1) [Petr Mladek] + bootstrap + bump product version to 3.4.3-rc1, release number to 301 [Petr Mladek] + fixup non-respecting DESTDIR for DOCDIR chmod. [Tomáš Chvátal] + use proper switch name for system-sane-headers [Tomáš Chvátal] + components + toggling grammar checkbox deletes sentence (fdo#39348) [Caolán McNamara] + filters + set link text properties [Radek Doulik] + impress + fix ruler to not generate negative left indent (bnc#707779) [Thorsten Behrens] + libs-core + backport collection of operator= fixes (fdo#37403) [Caolán McNamara] + janitorial: deduplicate code; no
Re: [Libreoffice] (no subject)
Le 22/08/11 12:44, Alexander Thurgood a écrit : Please ignore this particular message, which has appeared elsewhere already, just Gmane and/or Thunderbird doing some strange things to my reply to list button. Caolan has already suggested something on this elsewhere. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] old releases available as tags in core [was: Merging old tags]
Hi all, I just executed the corereleasebranch script from dev-tools. The intent is to reduce the number of tags in core and make at least the released versions (without all commits between them) available in core too. You can now do a: git checkout libreoffice-3.3.0.4 or a git diff libreoffice-3.3.0.4 The old releases have been whitespace-adjusted with Norberts script too, so diff should still be sensible. The old per-repo-tags have been converted to notes (see man git notes) -- to pull those, you need to explicitly pull push refs/notes/*:refs/notes/*. I have not yet killed all the ~2000 old per-repo tags on core, but here is the script to do that: http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/corereleasebranches/killtags.sh If nothing serious comes up, Ill do that the next days. When that happens we will be down to ~100 tags in core, relieving us from the need to always use grep on git log. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] smoke test failed
Hello, I just wanted to do make dev-install after a successful make -sr debug=true dbglevel=2. I have already posted so patches,because I met problems even in making, but finally I made it all. Now smoke-test fails with the error messages: invokeComponentFactory envDcp:gcc3 implName:com.sun.star.comp.filter.config.FilterFactory modPath:file:///home/LOff/libo/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/program/libfilterconfig1.so Trace 2733/8: inserting new mapping: ;gcc3[909c6e0];gcc3[909c6e0] Trace 2733/8: revoking mapping ;gcc3[909c6e0];gcc3[909c6e0] Error: File /home/LOff/libo/filter/source/config/cache/filtercache.cxx, Line 225: Who disturb our fill cache on demand feature and force loading of ALL data during office startup? Please optimize your code, so a full filled filter cache is not realy needed here! Exited with code '-1' toUNOname(): N3com3sun4star4lang17DisposedExceptionE = com.sun.star.lang.DisposedException c++ exception occurred: com.sun.star.lang.DisposedException uno exception occurred: com.sun.star.lang.DisposedException Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught runtime exception 'Binary URP bridge already disposed' Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught runtime exception 'Binary URP bridge already disposed' Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught runtime exception 'Binary URP bridge already disposed' toUNOname(): N3com3sun4star4lang17DisposedExceptionE = com.sun.star.lang.DisposedException c++ exception occurred: com.sun.star.lang.DisposedException toUNOname(): N3com3sun4star4lang17DisposedExceptionE = com.sun.star.lang.DisposedException toUNOname(): N3com3sun4star4lang17DisposedExceptionE = com.sun.star.lang.DisposedException c++ exception occurred: com.sun.star.lang.DisposedException uno exception occurred: com.sun.star.lang.DisposedException toUNOname(): N3com3sun4star4lang17DisposedExceptionE = com.sun.star.lang.DisposedException c++ exception occurred: com.sun.star.lang.DisposedException toUNOname(): N3com3sun4star4lang17DisposedExceptionE = com.sun.star.lang.DisposedException ##Failure Location unknown## : Error Test name: N12_GLOBAL__N_14TestE::test An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge disposed during call ##Failure Location unknown## : Error Test name: N12_GLOBAL__N_14TestE::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed Failures !!! Run: 1 Failure total: 2 Failures: 0 Errors: 2 Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught runtime exception 'Binary URP bridge already disposed' Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught runtime exception 'Binary URP bridge already disposed' Trace 1986/2: revoking mapping ;gcc3[40ad3c18];uno[40ad3b58] Trace 1986/2: revoking mapping ;uno[40ad3b58];gcc3[40ad3c18] dmake: Error code 1, while making 'cpptest' could someone help in this problem? it seems to me that filtercache.cxx has a function which has an optional bool parameter, but on call load function the parameter is not given even in debug version, so maybe I should give this parameter,but I don't know how it gets true or false. Thanks for your help, Gabor ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility
On Aug 23, 2011, at 5:16 PM, Kohei Yoshida wrote: On Tue, 2011-08-23 at 17:09 +0200, Lionel Elie Mamane wrote: On Mon, Aug 22, 2011 at 11:53:59PM +0200, Eike Rathke wrote: Maybe due to some overzealous introduction of such helper implementations into the UDK. Sure, it eases development of applications, but at the costs we're facing now. The more helper we give to extensions, the less bugs they will have and the more they will conform to interfaces we want them to conform to. Looks like it can be worth the cost. No, that's a wrong way to put it. The whole purpose of having common interfaces is to give implementation a freedom to implement as long as it conforms to the agreed-upon interfaces. Exposing the *implementation* of the interface to the extensions basically throws away that freedom, and we are paying for that now. Think of OPropertySetHelper as a helper to get your implementation of the abstract interfaces XPropertySet etc. done. That makes it necessary to expose its implementation to its clients, which in turn makes it problematic to extend it. I think what we pay here is OK, and largely understood. I still think it is good to re-use OPropertySetHelper in the implementation of OPropertySetHelper2 as DRY-ly as possible (and thanks to m_pReserve it appears to indeed be possible in not too inelegant a way). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility
On Aug 23, 2011, at 5:09 PM, Lionel Elie Mamane wrote: On Mon, Aug 22, 2011 at 11:53:59PM +0200, Eike Rathke wrote: On Monday, 2011-08-22 15:30:04 -0400, Kohei Yoshida wrote: What this tells me is that, we can't change OPropertySetHelper implementation, at least not in a way that changes its virtual function table (until LibreOffice 4 I suppose), which cripples us since there are still opportunities to improve that code. There may be a way out of it: _append_ the new virtual function after all existing. This works only though if new code using it is not mixed with old implementation. Old code using the new implementation shouldn't see a problem as it expects the vtable to be shorter, unless someone derived from OPropertySetHelper then there may be problems again. Maybe too vague. And won't *other* stuff be moved around? For example, because the vtable is longer, m_pReserved is at another offset in the class, breaking ABI again? The offset of m_pReserved would not be affected by changes to the vtable's size (with de-facto standard C++ ABIs). But what could indeed break is if old code (that is not recompiled) derives classes from OPropertySetHelper---which is likely, given that OPropertySetHelper is designed to be derived from. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build break in module basic
Hi Eike, Eike Rathke schrieb: Hi Regina, On Tuesday, 2011-08-23 01:43:09 +0200, Regina Henschel wrote: In IRC erAck guesses, that the reason might be blanks in the pathes and missing quotes. I'll try his advise: it _might_ help to change solenv/gbuild/platform/windows.mk in line 360 from $(ML_EXE) to $(ML_EXE) And did that help? It comes behind module basic, so your suggestion seams to be right. But now it breaks in tail_build. I try 'make clean' and 'make -r' in tail_build. Perhaps then it is visible, what goes wrong. Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build failing in tail_build module
Hi Swagat, swagat sharma wrote (23-08-11 20:36) I did as the output suggested but still landed up at the same place. Might have something to do with the version ofmake 3.81in combination withwith-num-cpus larger then 1 However I solved by commenting some lines which were calling that function :P (which was not a member function of that class. I have some basic idea. :P) Sounds good! :-) I know it can have some adverse effect, but I was interested in packaging with epm, and I succeeded in getting a deb installation of libreoffice. :) Thanks for reporting. I am sure other devs can give more useful feedback on your report, handling, than I could. Best, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build failing in tail_build module
Cor Nouws wrote (23-08-11 20:57) Might have something to do with the version of make 3.81 in combination with with-num-cpus larger then 1 I knew I had seen a mail about that. Found it in the archives: http://lists.freedesktop.org/archives/libreoffice/2011-August/016470.html ;-) -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] smoke test failed
On Aug 23, 2011, at 7:09 PM, Jenei Gábor wrote:
Hello,
I just wanted to do make dev-install after a successful make -sr
debug=true dbglevel=2. I have already posted so patches,because I met
problems even in making, but finally I made it all. Now smoke-test fails
with the error messages:
invokeComponentFactory envDcp:gcc3
implName:com.sun.star.comp.filter.config.FilterFactory
modPath:file:///home/LOff/libo/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/program/libfilterconfig1.so
Trace 2733/8: inserting new mapping: ;gcc3[909c6e0];gcc3[909c6e0]
Trace 2733/8: revoking mapping ;gcc3[909c6e0];gcc3[909c6e0]
Error: File /home/LOff/libo/filter/source/config/cache/filtercache.cxx,
Line 225: Who disturb our fill cache on demand feature and force
loading of ALL data during office startup? Please optimize your code, so
a full filled filter cache is not realy needed here!
Exited with code '-1'
toUNOname(): N3com3sun4star4lang17DisposedExceptionE =
com.sun.star.lang.DisposedException
c++ exception occurred: com.sun.star.lang.DisposedException
uno exception occurred: com.sun.star.lang.DisposedException
Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught
runtime exception 'Binary URP bridge already disposed'
Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught
runtime exception 'Binary URP bridge already disposed'
Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught
runtime exception 'Binary URP bridge already disposed'
toUNOname(): N3com3sun4star4lang17DisposedExceptionE =
com.sun.star.lang.DisposedException
c++ exception occurred: com.sun.star.lang.DisposedException
toUNOname(): N3com3sun4star4lang17DisposedExceptionE =
com.sun.star.lang.DisposedException
toUNOname(): N3com3sun4star4lang17DisposedExceptionE =
com.sun.star.lang.DisposedException
c++ exception occurred: com.sun.star.lang.DisposedException
uno exception occurred: com.sun.star.lang.DisposedException
toUNOname(): N3com3sun4star4lang17DisposedExceptionE =
com.sun.star.lang.DisposedException
c++ exception occurred: com.sun.star.lang.DisposedException
toUNOname(): N3com3sun4star4lang17DisposedExceptionE =
com.sun.star.lang.DisposedException
##Failure Location unknown## : Error
Test name: N12_GLOBAL__N_14TestE::test
An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge disposed during call
##Failure Location unknown## : Error
Test name: N12_GLOBAL__N_14TestE::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed
Failures !!!
Run: 1 Failure total: 2 Failures: 0 Errors: 2
Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught
runtime exception 'Binary URP bridge already disposed'
Trace 1986/2: /home/LOff/libo/binaryurp/source/bridge.cxx:504; caught
runtime exception 'Binary URP bridge already disposed'
Trace 1986/2: revoking mapping ;gcc3[40ad3c18];uno[40ad3b58]
Trace 1986/2: revoking mapping ;uno[40ad3b58];gcc3[40ad3c18]
dmake: Error code 1, while making 'cpptest'
could someone help in this problem? it seems to me that filtercache.cxx
has a function which has an optional bool parameter, but on call load
function the parameter is not given even in debug version, so maybe I
should give this parameter,but I don't know how it gets true or false.
filtercache.cxx should probably be changed like
diff --git a/filter/source/config/cache/filtercache.cxx
b/filter/source/config/cache/filtercache.cxx
index b3f5c91..5d1c72b 100644
--- a/filter/source/config/cache/filtercache.cxx
+++ b/filter/source/config/cache/filtercache.cxx
@@ -214,13 +214,7 @@ void FilterCache::load(EFillState eRequired,
return;
#if OSL_DEBUG_LEVEL 1
-if (
-(!bByThread)
-(
-((eRequired E_CONTAINS_FILTERS) == E_CONTAINS_FILTERS) ||
-((eRequired E_CONTAINS_ALL) == E_CONTAINS_ALL)
-)
- )
+if (!bByThread ((eRequired E_CONTAINS_ALL) == E_CONTAINS_ALL))
{
OSL_FAIL(Who disturb our \fill cache on demand\ feature and force
loading of ALL data during office startup? Please optimize your code, so a
full filled filter cache is not realy needed here!);
}
(The bByThread bool is true when called from lateinitthread.cxx, and what this
debug check obviously shall do is ensure that only that late-init thread
requests to load expensive data; however, type detection.cxx has
non-late-init-thread loads that demand E_CONTAINS_FILTERS with comment That
can disturb our 'load on demand feature'. But we have no other chance!, so the
debug check is apparently broken. All rather stinky and pathetic…)
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about Easyhack 37007 Add Math symbol There does not exist
Hi, 2011/8/23 julien2412 serval2...@yahoo.fr: Hello again, First, thank you Jan for your help. Now i'm almost at the end, the symbol There does not exist appears in dialog window. The pb is when I select it, it appears correctly very quickly (0,5s) the first time then I've got a rectangle. Then if i test again, it doesn't appear anymore correctly. I must restart LO to have it correctly 0,5s. I don't know why. Please send your patch as it is now. It is easier to help, when we see the modified code. Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about Easyhack 37007 Add Math symbol There does not exist
Le 23/08/2011 22:22, Andras Timar a écrit :
Hi,
2011/8/23 julien2412serval2...@yahoo.fr:
Hello again,
First, thank you Jan for your help.
Now i'm almost at the end, the symbol There does not exist appears in
dialog window. The pb is when I select it, it appears correctly very quickly
(0,5s) the first time then I've got a rectangle. Then if i test again, it
doesn't appear anymore correctly. I must restart LO to have it correctly
0,5s. I don't know why.
Please send your patch as it is now. It is easier to help, when we see
the modified code.
Thanks,
Andras
I put the patch as it is now. (i haven't git updated my libo repository
since 2 days).
In addition of this patch, there are the 2 png files.
Julien.
diff --git a/hwpfilter/source/hwpeq.cxx b/hwpfilter/source/hwpeq.cxx
index 0808d51..16b8c27 100644
--- a/hwpfilter/source/hwpeq.cxx
+++ b/hwpfilter/source/hwpeq.cxx
@@ -184,6 +184,7 @@ static hwpeq eq_tbl[] = {
{ exarrow, NULL, 0, 0 },
{ exist,\\exists, 0, 0 },
{ exists, NULL, 0, 0 },
+ { notexists, NULL, 0, 0 },
{ exp, NULL, 0, EQ_CASE },
{ for, NULL, 0, 0 },
{ forall, NULL, 0, 0 },
diff --git a/hwpfilter/source/mapping.h b/hwpfilter/source/mapping.h
index 89e29c9..2c238cd 100644
--- a/hwpfilter/source/mapping.h
+++ b/hwpfilter/source/mapping.h
@@ -181,6 +181,7 @@ const struct FormulaEntry FormulaMapTab[] = {
{because, 0x2235},
{identical, 0x2237},
{exists, 0x2203},
+{notexists, 0x2204},
{noteq, 0x2260}, // !=
{neq, 0x2260},
{doteq, 0x2250},
diff --git a/ooo_custom_images/classic/classic_images.tar.gz
b/ooo_custom_images/classic/classic_images.tar.gz
index e9578d9..0a10102 100644
Binary files a/ooo_custom_images/classic/classic_images.tar.gz and
b/ooo_custom_images/classic/classic_images.tar.gz differ
diff --git a/starmath/inc/helpids.h b/starmath/inc/helpids.h
index f27b47e..1da4029 100644
--- a/starmath/inc/helpids.h
+++ b/starmath/inc/helpids.h
@@ -160,6 +160,7 @@
#define HID_SMA_LIMINFX
STARMATH_HID_SMA_LIMINFX
#define HID_SMA_LIMSUPX
STARMATH_HID_SMA_LIMSUPX
#define HID_SMA_EXISTS
STARMATH_HID_SMA_EXISTS
+#define HID_SMA_NOTEXISTS
STARMATH_HID_SMA_NOTEXISTS
#define HID_SMA_FORALL
STARMATH_HID_SMA_FORALL
#define HID_SMA_NABLA
STARMATH_HID_SMA_NABLA
#define HID_SMA_INTX
STARMATH_HID_SMA_INTX
diff --git a/starmath/inc/parse.hxx b/starmath/inc/parse.hxx
index 43c0992..43283d8 100644
--- a/starmath/inc/parse.hxx
+++ b/starmath/inc/parse.hxx
@@ -97,7 +97,7 @@ enum SmTokenType
TMINUSPLUS, TOPLUS, TOMINUS,TDIV, TOTIMES,
TODIVIDE, TTRANSL,TTRANSR,TIINT, TIIINT,
TLINT, TLLINT, TLLLINT,TPROD, TCOPROD,
-TFORALL,TEXISTS,TLIM, TNABLA, TTOWARD,
+TFORALL,TEXISTS,TNOTEXISTS, TLIM, TNABLA,
TTOWARD,
TSINH, TCOSH, TTANH, TCOTH, TASIN,
TACOS, TATAN, TLN,TLOG, TUOPER,
TBOPER, TBLACK, TWHITE, TRED, TGREEN,
diff --git a/starmath/inc/starmath.hrc b/starmath/inc/starmath.hrc
index f7aa0f2..4d7509b 100755
--- a/starmath/inc/starmath.hrc
+++ b/starmath/inc/starmath.hrc
@@ -390,6 +390,7 @@
#define RID_UPARROW (RID_APP_START + 2018)
#define RID_DOWNARROW (RID_APP_START + 2019)
#define RID_EXISTS (RID_APP_START + 1608)
+#define RID_NOTEXISTS (RID_APP_START + 1618)
#define RID_FORALL (RID_APP_START + 1612)
// new menue resource ID's
diff --git a/starmath/inc/types.hxx b/starmath/inc/types.hxx
index 8353f6e..d3f30d5 100644
--- a/starmath/inc/types.hxx
+++ b/starmath/inc/types.hxx
@@ -120,6 +120,7 @@ enum MathSymbol
MS_IN = (sal_Unicode) 0x2208,
MS_NOTIN= (sal_Unicode) 0x2209,
MS_EXISTS = (sal_Unicode) 0x2203,
+MS_NOTEXISTS= (sal_Unicode) 0x2204,
MS_BACKEPSILON = (sal_Unicode) 0x220D,
MS_ALEPH= (sal_Unicode) 0x2135,
MS_IM = (sal_Unicode) 0x2111,
diff --git a/starmath/qa/cppunit/test_nodetotextvisitors.cxx
b/starmath/qa/cppunit/test_nodetotextvisitors.cxx
index f7b282c..234e87d 100644
--- a/starmath/qa/cppunit/test_nodetotextvisitors.cxx
+++ b/starmath/qa/cppunit/test_nodetotextvisitors.cxx
@@ -353,6 +353,7 @@ void Test::SimpleMisc()
parseandparseagain(partial, Partial);
parseandparseagain(nabla, Nabla);
parseandparseagain(exists, There exists);
+parseandparseagain(notexists, There not exists);
parseandparseagain(forall, For all);
Re: [Libreoffice] DrawPolyLine on Windows
23.08.2011 19:06, Tor Lillqvist пишет: I tried to draw polyline But on Windows... the end point is not drawn... I am not saying your patch is not useful, but just out of interest, how do you interpret the word point in the GDI documentation for LineTo()? Does it in fact simply mean pixel? But what if the current pen is wider than one pixel? Or is the vagueness intentional and any expectation of pixel-perect repeatable results with different graphics devices and drivers is futile? Compared to how strictly mathematically X11 graphics is defined for wide lines, the GDI specification is just horrible. --tml Hello, Tor! Very good questions! I think «point» means «pixel». Line as an object is described in MSDN only for «raster» devices (pixels on screen or dots on paper). Moreover word «point» is used as set of parameters (x and y coordinated) for function. Maybe I'm wrong, but in case of continuous space (maybe vector graphics) we have line without end point (open line at its end) that causes problem when we try to show such line on raster device. Should we draw last pixel or not? it contains both an end of line and an end point. I don't know how this function [LineTo()] may be used to create a continuous line. Windows metafile seems as packed script, it doesn't represent a really vector graphics format. In case of wider pen, another overloaded function «drawPolyLine()» is called that uses GDI+ or thick lines is represented as polygons. So, for thick lines my solution [patch] doesn't work and no additional pixel is drawn (patch doesn't break drawing thick lines). Moreover I tried to draw thick polyline. the thick polylines on Windows and on Linux are the same. -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build failing in tail_build module
On 23/08/2011 20:57, Cor Nouws wrote: Hi Swagat, swagat sharma wrote (23-08-11 20:36) I did as the output suggested but still landed up at the same place. Might have something to do with the version ofmake 3.81in combination withwith-num-cpus larger then 1 I can confirm this as it has failed in tail build for me as well the following is partial out put of the issue /bin/bash: line 1: 5279 Segmentation fault make -s -r -j2 dmake: Error code 139, while making 'all' version i have on Ubuntu lucid 10.04 is make 3.81 not sure if that is useful for anything However I solved by commenting some lines which were calling that function :P (which was not a member function of that class. I have some basic idea. :P) Sounds good! :-) I know it can have some adverse effect, but I was interested in packaging with epm, and I succeeded in getting a deb installation of libreoffice. :) Thanks for reporting. I am sure other devs can give more useful feedback on your report, handling, than I could. Best, ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] Remove unnecessary parameter to IDocumentStatistics::UpdateDocStat
On Tue, Aug 23, 2011 at 04:41:59PM +0100, Caolán McNamara caol...@redhat.com
wrote:
d) I'm not sure there's any good reason to set the DocStat in the
(current) rtf filter.
You mean something like this? Given that the idl says these properties
are readonly (I did not notice that so far), I don't think there is a
reason to set them.
diff --git a/writerfilter/source/rtftok/rtfdocumentimpl.cxx
b/writerfilter/source/rtftok/rtfdocumentimpl.cxx
index 0fef1e8..4d91514 100644
--- a/writerfilter/source/rtftok/rtfdocumentimpl.cxx
+++ b/writerfilter/source/rtftok/rtfdocumentimpl.cxx
@@ -2416,34 +2416,7 @@ int RTFDocumentImpl::dispatchValue(RTFKeyword nKeyword,
int nParam)
case RTF_NOFWORDS:
case RTF_NOFCHARS:
case RTF_NOFCHARSWS:
-if (m_xDocumentProperties.is())
-{
-uno::Sequencebeans::NamedValue aSet =
m_xDocumentProperties-getDocumentStatistics();
-OUString aName;
-switch (nKeyword)
-{
-case RTF_NOFPAGES: aName =
OUString(RTL_CONSTASCII_USTRINGPARAM(PageCount)); break;
-case RTF_NOFWORDS: aName =
OUString(RTL_CONSTASCII_USTRINGPARAM(WordCount)); break;
-case RTF_NOFCHARS: aName =
OUString(RTL_CONSTASCII_USTRINGPARAM(CharacterCount)); break;
-case RTF_NOFCHARSWS: aName =
OUString(RTL_CONSTASCII_USTRINGPARAM(NonWhitespaceCharacterCount)); break;
-default: break;
-}
-if (aName.getLength())
-{
-bool bFound = false;
-int nLen = aSet.getLength();
-for (int i = 0; i nLen; ++i)
-if (aSet[i].Name.equals(aName))
-aSet[i].Value = uno::makeAny(sal_Int32(nParam));
-if (!bFound)
-{
-aSet.realloc(nLen + 1);
-aSet[nLen].Name = aName;
-aSet[nLen].Value = uno::makeAny(sal_Int32(nParam));
-}
-m_xDocumentProperties-setDocumentStatistics(aSet);
-}
-}
+// Ignore document statistics, Writer will calculate them.
break;
case RTF_VERSION:
if (m_xDocumentProperties.is())
pgp9sbG0VgV90.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 Wednesday, 2011-08-17 14:14:18 +0200, Eike Rathke wrote: 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 [...] Actually the new ScNameToken implemented would belong to formula/* instead, but there is already FormulaIndexToken, which also now has changes for local/global names, so ScNameToken is superfluous and can be removed. ScRawToken::CreateToken() needs to be changed back to return a FormulaIndexToken. I did the necessary changes in http://cgit.freedesktop.org/libreoffice/core/commit/?id=fcac4e3eb4df6dcd4d6f6955a5d369262bcd1ea4 Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
