Re: [Libreoffice] [PATCH] [PUSHED] (was: Re: buglet in 1ec7b6a4 (?))
On Aug 31, 2011, at 3:55 AM, Kohei Yoshida wrote: On Mon, 2011-08-29 at 12:08 +0200, Stephan Bergmann wrote: http://cgit.freedesktop.org/libreoffice/core/commit/autogen.sh?id=3ea37ac7005c64f378756a5dbc3fbfbc3bf8b053 does not fix this for the one-argument case, however, due to an error introduced in http://cgit.freedesktop.org/libreoffice/core/commit/autogen.sh?id=c0b9fdfbbaa46e984dbe6ea9e7f5adc943b9f248. Attached patch would fix that. Thanks. Just pushed to master. BTW, I believe this is your first commit to LibreOffice I believe (aside from your numerous commits to the OOo code base that is)? Can I ask you to confirm that your patch is under LGPLv3+/MPL 1.1 ? Oops, good catch. Yes, this and all forthcoming contributions from me (until further notice) are under LGPLv3+/MPL 1.1. Thanks, -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Windows daily builds of master
Hi all, Finally we have a tinderbox that is producing Windows daily builds of master again: http://dev-builds.libreoffice.org/daily/Windows_XP_SP3/master/ Unfortunately it is quite a slow machine, so it is configured to provide English-only builds, but I hope even that is help for QA :-) Please let me know should there be problems with this box. If you spot regressions against LibreOffice 3.4, please report them as soon as possible, so that we can fix them quickly. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] hooks: update hook should reject obsolete tags
Hi Michael, It already happened two times that an accidental git push --tags or git push --all tried to re-introduce the module_oldtagname tags in core.git. Given that generates huge emails, which end up in the mailbox of Kendy, we talked on IRC it's better to reject those from the git hook. Could you please apply on kemper in core.git the following patch? http://people.freedesktop.org/~vmiklos/hooks-update-reject-obsolete-tags.diff The patch itself is ACK'd by Norbert and Kendy. Thanks. pgpxXSgrxP8BY.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Rectangle width
Di Dmitry On 2011-08-23 at 13:23 +0400, Dmitry. A. Ashkadov wrote: 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. Shifted left dropdown arrow This code got changed a lot in master: http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/permalinks/2011-06-14T10_29_17.html So I hope this wrong computation is gone there ;-) If not, further improvements are welcome! Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
Are there up-to-date instructions somewhere for building on Windows with the new OneGit repos? Well, the aspects that changed with the switch from several git repos to just one (or two, or three, depending on whether you want to include help and dictionaries or not) don't differ between platforms... So just clone the new core repo, and build using old instructions. Please report specific errors you get... --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] http://libreoffice.boldandbusted.com/ cppcheck report jobs stalled... no longer! :)
Hello Jesse, - Git version of cppcheck : OK - LO sources updated : OK - only core repository scanned : OK It's perfect ! Thank you ! Julien. -- View this message in context: http://nabble.documentfoundation.org/http-libreoffice-boldandbusted-com-cppcheck-report-jobs-stalled-tp2745270p3297801.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [review] fdo#36678 Missing user-defined dictionaries with a specified language attribute via Spelling and Grammar
Hi Caolán, On 2011-08-26 at 10:48 +0100, Caolán McNamara wrote: potential cherry-pick candidate for 3-4 Missing user-defined dictionaries with a specified language attribute via Spelling and Grammar F7 https://bugs.freedesktop.org/show_bug.cgi?id=36678 http://cgit.freedesktop.org/libreoffice/core/commit/?id=c9e6df76fffe84da7529d92cba7bb79e36d9cd15 To avoid calling a virtual method on an object (rParent) where rParent hasn't finished its construction yet so virtual methods don't work yet, the spell-check dialog has a hack to use postuserevent and finish the initialization later. Part of the initialization is run first though, and the list of languages to populate the add menu is generated before the second part of initialization is run which determines the languages available. Sounds good, pushed that to libreoffice-3-4 branch. Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [review] fdo#36678 Missing user-defined dictionaries with a specified language attribute via Spelling and Grammar
On 2011-08-31 at 10:57 +0200, Jan Holesovsky wrote: Sounds good, pushed that to libreoffice-3-4 branch. ...and mark it [PUSHED] K. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
Thanks, you're right, with one repo, the checkout and build process is definitely much smoother! (1) I had to comment out some code in qa\osl\security\osl_Security.cxx because it was trying to run a unit test which failed because I'm not logged in as Administrator. Perhaps it should skip that test if the currently logged in user is not Administrator? (2) I have to do export DISABLE_ATL=true because otherwise I get a compile fail in embedserve, I don't appear to have the atlbase.h file on my machine. Perhaps this should be a configure check? (3) Right now I'm struggling to get past a link error in l10ntools helpmerge.obj : error LNK2019: unresolved external symbol __declspec(dllimport) class rtl::OString __cdecl comphelper::string::getToken(class rtl::OString const ,long,char) Any ideas? Thanks, Noel Grandin Tor Lillqvist wrote: Are there up-to-date instructions somewhere for building on Windows with the new OneGit repos? Well, the aspects that changed with the switch from several git repos to just one (or two, or three, depending on whether you want to include help and dictionaries or not) don't differ between platforms... So just clone the new core repo, and build using old instructions. Please report specific errors you get... --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] inconsistency between rtl::OString/rtl::OUString and optimization opportunities ?
So, playing around with the sal string classes I see that... rtl_string_new_WithLength/rtl_uString_new_WithLength create an rtl/String/rtl_uString of the given length, but set the full buffer contents to 0s[1] meanwhile I see that we have x_rtl_uString_new_WithLength in inc/i18nutil/x_rtl_ustring.h which is a non-zeroed out variant of rtl_uString_new_WithLength so there's an uninitialized buffer available to play with. We can assign ownership of the rtl_uString to an OUString with OUString( rtl_uString * str, __sal_NoAcquire ) and skip calling acquire, i.e. OUString has *two* methods to take ownership of a rtl_uString without calling acquire. the public OUString( rtl_uString * str, __sal_NoAcquire ) the private OUString( rtl_uString * value, DO_NOT_ACQUIRE * ) as well as the usual add-add-refcount version of OUString( rtl_uString * str ) While OString has only the private OString( rtl_String * value, DO_NOT_ACQUIRE * ) as well as the usual add-add-refcount version of OString( rtl_String * str ), so the same hack isn't available. I'm vaguely thinking of moving that i18nutil x_rtl stuff into comphelper/string or something, hard-coding its refcount argument to 0 or 1 and fixing up its uses to consistently use one or the other public OUString acquire/noacquire ctors and add a OString variant so that either of the belows is possible to skip copying buffers around the place. #if thinko-one rtl_String *pStr = foo_rtl_string_new_WithLength(nLen/*, refCount=0*/); //call acquire, refCount of 1, OString::dtor destroys buffer rtl::OString aRet(pStr); pStr-length = rStrm.Read(pStr-buffer, nLen); #else rtl_String *pStr = foo_rtl_string_new_WithLength(nLen/*, refCount=1*/); //don't call acquire, refCount stays 1, OString::dtor destroys buffer rtl::OString aRet(pStr, SAL_NO_ACQUIRE); pStr-length = rStrm.Read(pStr-buffer, nLen); #endif //if unlikely length != nLen make deep copy of string to release excess //mem, nobody seems to worry about excess for rtl::O[U]String buffers, //but much less opportunity to have a large chunk of unused //buffer there. C. [1] with a loop, I suppose its no real optimization there to use memset or rtl_allocateMemory for that case ? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
On Wed, 2011-08-31 at 12:04 +0200, Noel Grandin wrote: (3) Right now I'm struggling to get past a link error in l10ntools helpmerge.obj : error LNK2019: unresolved external symbol __declspec(dllimport) class rtl::OString __cdecl comphelper::string::getToken(class rtl::OString const ,long,char) Any ideas? http://cgit.freedesktop.org/libreoffice/core/commit/?id=a967c049a5e6e027850fbbb40a7231ee71551c91 might fix this C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Update of AutoText numbered formula
On Tue, 2011-08-30 at 15:31 -0700, jumbo444 wrote: Thank you for your answer. Caolán McNamara wrote: attaching the replacements (or git binary patch I suppose) to a bug against libreoffice at https://bugs.freedesktop.org/ would work in the interim. I opened bug 40499 https://bugs.freedesktop.org/show_bug.cgi?id=40499 and added each standard.bau as attachment. I could not proceed for bg locale, because 7-zip told me that files were corrupted. Could a bg locale user make the modification? It seems to be bad CRCs, using command line unzip seems to unpack it right. Can you confirm that these submissions are under our preferred LGPLv3+/MPLv1.1 combo ? Its common to do a all my submissions will be unless I say otherwise to keep things simple. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] IDL @since build error if not OOo
Hi all tring to a add a new property to calc document, i had to append it to an idl file (offapi/com/sun/star/sheet/SpreadsheetDocumentSettings.idl) one can read for example /** specifies whether the automatic adjustment of the row height is enabled. @since OOo 3.0 */ [optional, property] boolean IsAdjustHeightEnabled; i modified the @since, putting LO 3.5 and end with a build error, complaining that Version information in @since tag has incorrect format.\n Correct version format: \OOo major.minor[.micro if micro is not 0]\. this is in http://opengrok.libreoffice.org/xref/core/autodoc/source/parser_i/idoc/docu_pe2.cxx so my question is do we care about that ? (ie. specifying LO in the @since) i think we should to make things clear to api users the second question is about solving that : this comes from the test http://opengrok.libreoffice.org/xref/core/autodoc/source/parser_i/idoc/docu_pe2.cxx#517 performed at http://opengrok.libreoffice.org/xref/core/autodoc/source/parser_i/idoc/docu_pe2.cxx#616 so, what should i do to be the cleanest and keep consystency over time ? - drop the test ? - modify the String to also take care about LO and LibreOffice ? I can propose a patch as soon as there is an agreement on the modification to do Thanks Laurent ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] new BUG 36594
Hello Eike,
I made the changes you said, and I resolved the no linefeed issue also,
I hope it is ok now, and can be pushed, actually for me worked fine with
all types of comments. Also I tried to follow the principals you said.
So, push it if you think there is no need to correct something.
Gabor
From 2615b372f0168673b7074f20b41a9301d1acc18e Mon Sep 17 00:00:00 2001
From: Gabor jen...@elte.hu
Date: Wed, 31 Aug 2011 12:53:26 +0200
Subject: [PATCH] comment bug fix
---
connectivity/source/parse/sqlbison.y | 23 +++-
dbaccess/source/ui/querydesign/querycontroller.cxx | 61 +++-
2 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/connectivity/source/parse/sqlbison.y
b/connectivity/source/parse/sqlbison.y
index d7e7c67..b348d72 100755
--- a/connectivity/source/parse/sqlbison.y
+++ b/connectivity/source/parse/sqlbison.y
@@ -4570,6 +4570,24 @@ void OSQLParser::setParseTree(OSQLParseNode *
pNewParseTree)
m_pParseTree = pNewParseTree;
}
//-
+::rtl::OUString delComment(const ::rtl::OUString sQuery){
+const sal_Unicode* sCopy=sQuery.getStr();
+sal_Int32 nQueryLen=sQuery.getLength();
+bool bIsText1=false;
+bool bIsText2=false;
+bool bComment=false;
+::rtl::OUStringBuffer sTemp(nQueryLen);
+for(size_t i=0;inQueryLen;i++){
+if(sCopy[i]=='\' !bIsText2 !bComment) bIsText1=!bIsText1;
+if(sCopy[i]=='\'' !bIsText1 !bComment) bIsText2=!bIsText2;
+if(sCopy[i]=='\n' bComment) bComment=false;
+if(!bIsText1 !bIsText2 (i+1)nQueryLen sCopy[i]=='-'
sCopy[i+1]=='-') bComment=true;
+if(!bIsText1 !bIsText2 (i+1)nQueryLen sCopy[i]=='/'
sCopy[i+1]=='/') bComment=true;
+if(!bComment) sTemp.append(sCopy[i],1);
+}
+return sTemp.makeStringAndClear();
+}
+//-
OSQLParseNode* OSQLParser::parseTree(::rtl::OUString rErrorMessage,
const
::rtl::OUString rStatement,
sal_Bool
bInternational)
@@ -4581,9 +4599,12 @@ OSQLParseNode* OSQLParser::parseTree(::rtl::OUString
rErrorMessage,
// must be reset
setParser(this);
+ //delete comments before parsing
+ ::rtl::OUString sTemp=delComment(rStatement);
+
// defines how to scan
s_pScanner-SetRule(s_pScanner-GetSQLRule()); // initial
- s_pScanner-prepareScan(rStatement, m_pContext, bInternational);
+ s_pScanner-prepareScan(sTemp, m_pContext, bInternational);
SQLyylval.pParseNode = NULL;
// SQLyypvt = NULL;
diff --git a/dbaccess/source/ui/querydesign/querycontroller.cxx
b/dbaccess/source/ui/querydesign/querycontroller.cxx
index 054c854..18a6d10 100644
--- a/dbaccess/source/ui/querydesign/querycontroller.cxx
+++ b/dbaccess/source/ui/querydesign/querycontroller.cxx
@@ -94,6 +94,8 @@
#include vcl/msgbox.hxx
#include vcl/svapp.hxx
#include osl/mutex.hxx
+#include rtl/strbuf.hxx
+#include vector
extern C void SAL_CALL createRegistryInfo_OQueryControl()
{
@@ -1272,7 +1274,61 @@ ReferenceXNameAccess
OQueryController::getObjectContainer() const
OSL_ENSURE( xElements.is(), OQueryController::getObjectContainer: unable
to obtain the container! );
return xElements;
}
-
+//-
+//this struct is for the following functions
+struct QueryComment{
+sal_Int32 nPos;
+::rtl::OUString sComment;
+};
+//-
+std::vectorQueryComment getComment(const ::rtl::OUString sQuery){
+const sal_Unicode* sCopy=sQuery.getStr();
+const sal_uInt32 nQueryLen=sQuery.getLength();
+bool bIsText1=false;
+bool bIsText2=false;
+bool bComment=false;
+std::vectorQueryComment sRet;
+::rtl::OUStringBuffer sTemp;
+QueryComment TempComment;
+sal_Int32 nCommentLen=0;
+for(size_t i=0;inQueryLen;++i){
+if(sCopy[i]=='\' !bIsText2 !bComment) bIsText1=!bIsText1;
+if(sCopy[i]=='\'' !bIsText1 !bComment) bIsText2=!bIsText2;
+if(sCopy[i]=='\n' || i==nQueryLen-1){
+nCommentLen++;
+if(i==nQueryLen-1)sTemp.append(sCopy[i],1);
+if(bComment) bComment=false;
+sTemp.append((sal_Unicode)'\n');
+TempComment.sComment=sTemp.makeStringAndClear();
+sRet.push_back(TempComment);
+}
+if(!bIsText1 !bIsText2 (i+1)nQueryLen sCopy[i]=='-'
sCopy[i+1]=='-'){
+bComment=true;
+TempComment.nPos=i-nCommentLen;
+}
+if(!bIsText1 !bIsText2 (i+1)nQueryLen sCopy[i]=='/'
sCopy[i+1]=='/'){
+bComment=true;
+TempComment.nPos=i-nCommentLen;
+}
+
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 32709, which changed state. Bug 32709 Summary: PPT/PPTX created by LibreOffice can't be opened by MS PowerPoint Viewer and MS Office Web Apps https://bugs.freedesktop.org/show_bug.cgi?id=32709 What|Old Value |New Value Resolution||FIXED Status|REOPENED|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] instructions for building on windows with OneGit
Thanks, it's getting further now, but still throwing the same linker error when linking ulfex.exe -- Noel Caolán McNamara wrote: On Wed, 2011-08-31 at 12:04 +0200, Noel Grandin wrote: (3) Right now I'm struggling to get past a link error in l10ntools helpmerge.obj : error LNK2019: unresolved external symbol __declspec(dllimport) class rtl::OString __cdecl comphelper::string::getToken(class rtl::OString const ,long,char) Any ideas? http://cgit.freedesktop.org/libreoffice/core/commit/?id=a967c049a5e6e027850fbbb40a7231ee71551c91 might fix this C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] latest Hackfest information
Hello, only two more days, and we'll all meet again in Munich! Looking forward to that! :-) Following up on my previous e-mail (http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg15144.html), I just wanted to add some more information. If you haven't read the first message from August 26th, please do so now, as it contains some important information. Good news: The kind folks from DBI team will sponsor a round of food and beverages for all participants, up to 250 €, and they will also attend the Hackfest with some of their developers. Thanks a lot for this generous support, that is really appreciated! I propose we use their donation for Sunday's lunch. With regards to sleeping at Café Netzwerk and couchsurfing: Initially, we only had two or three people booked for Café Netzwerk, so I planned to get them to couchsurf instead. However, right now there are seven people sleeping at Café Netzwerk, so it will be quite a lot of fun, I guess. :-) We have two offers for couchsurfing, up to three or four places, and I propose we determine that Friday evening ad hoc, whether people prefer the Café or couchsurfing. I don't know yet whether I will drive home each day (I live in the Allgaeu, about 100 km from Munich), or if I will stay at Café Netzwerk. If I won't stay, I will give my Café Netzwerk key to one trustworthy Hackfest participant. :) I plan to arrive Friday rather late, since I have a lot of work to do before, and I propose we directly meet at the Hackfest venue in the LiMux project office at Sonnenstraße. In the evening, we can go out to the city, enjoy good Munich food and beer. Probably we should start at about eight, to give participants enough time to arrive? The LiMux folks told us that they are at the office from 1400 on, so those coming earlier can of course already go there. Those who come later can just call someone (my number is in the signature of this e-mail) and we'll tell you where we are. The LiMux team has reserved two parking lots over the weekend near Sonnenstraße that can be used for people who have to transport goods to the venue. In case you need one of these parking lots, please contact the organizers in advance, as special keys are required. I guess that's it. :-) Looking forward to meeting everyone! If you have any questions, just give me a ping. Happy hacking, Florian -- Florian Effenberger flo...@documentfoundation.org Steering Committee and Founding Member of The Document Foundation Tel: +49 8341 99660880 | Mobile: +49 151 14424108 Skype: floeff | Twitter/Identi.ca: @floeff ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
I've attached the build log file for that subcomponent.
Regards, Noel Grandin
Tor Lillqvist wrote:
(1) I had to comment out some code in qa\osl\security\osl_Security.cxx
because it was trying to run a unit test which
failed because I'm not logged in as Administrator.
Are you sure? What was the exact failure message you got?
Disclaimer: http://www.peralex.com/disclaimer.html
=
Building module sal
=
Entering /cygdrive/c/libreoffice/git2/libo/sal/inc
Entering /cygdrive/c/libreoffice/git2/libo/sal/systools/win32/uwinapi
Entering /cygdrive/c/libreoffice/git2/libo/sal/systools/win32/onlineupdate
Entering /cygdrive/c/libreoffice/git2/libo/sal/typesconfig
Entering /cygdrive/c/libreoffice/git2/libo/sal/rtl/source
--- ALWAYSDBGFILES ---
--- ALWAYSDBGFILES OVER ---
Entering /cygdrive/c/libreoffice/git2/libo/sal/textenc
Entering /cygdrive/c/libreoffice/git2/libo/sal/osl/w32
Entering /cygdrive/c/libreoffice/git2/libo/sal/osl/all
Entering /cygdrive/c/libreoffice/git2/libo/sal/util
Entering /cygdrive/c/libreoffice/git2/libo/sal/cppunittester
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/doublelock
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/rtl_doublelocking.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/rtl_doublelocking.dll
OK (2)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/strings
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/qa_rtl_strings.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/qa_rtl_strings.dll
OK (3)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/osl/getsystempathfromfileurl
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/locale
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/rtl_locale.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/rtl_locale.dll
OK (13)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/osl/process
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/osl_Thread.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/osl_Thread.dll
OK (6)
--
- start unit test #2 on library ../../../wntmsci12.pro/bin/osl_process.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/osl_process.dll
OK (0)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/cipher
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/rtl_cipher.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/rtl_cipher.dll
OK (24)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/sal
--
- start unit test #1 on library ../../wntmsci12.pro/bin/qa_sal_types.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../wntmsci12.pro/bin/cppunittester
../../wntmsci12.pro/bin/qa_sal_types.dll
OK (1)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/oustringbuffer
--
- start unit test #1 on library
../../../wntmsci12.pro/bin/qa_rtl_oustringbuffer.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
Re: [Libreoffice] instructions for building on windows with OneGit
On Wed, 2011-08-31 at 14:16 +0200, Noel Grandin wrote: I've attached the build log file for that subcomponent. Test name: osl_Security::getUserIdent::getUserIdent_001 assertion failed - Expression: ( sal_True == strUserID.equals( strID ) ) ( sal_True == bRes ) - #test comment#: get UserID and compare it with names got at the beginning of the test. Seeing as this isn't a really useful message I've now pushed http://cgit.freedesktop.org/libreoffice/core/commit/?id=930e38e16329e4a81dc2dcf185d44a752fbfbf7f to dump the details on failure. give that a re-spin to get some useful info. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
Wow! thanks for the quick response. New build log attached.
This is a 32-bit Windows7-Ultimate machine (fully up to date), if that makes
any difference.
Thanks, Noel Grandin
Caolán McNamara wrote:
On Wed, 2011-08-31 at 14:16 +0200, Noel Grandin wrote:
I've attached the build log file for that subcomponent.
Test name: osl_Security::getUserIdent::getUserIdent_001
assertion failed
- Expression: ( sal_True == strUserID.equals( strID ) ) ( sal_True
== bRes )
- #test comment#: get UserID and compare it with names got at the
beginning of the test.
Seeing as this isn't a really useful message I've now pushed
http://cgit.freedesktop.org/libreoffice/core/commit/?id=930e38e16329e4a81dc2dcf185d44a752fbfbf7f
to dump the details on failure.
give that a re-spin to get some useful info.
C.
Disclaimer: http://www.peralex.com/disclaimer.html
=
Building module sal
=
Entering /cygdrive/c/libreoffice/git2/libo/sal/inc
Entering /cygdrive/c/libreoffice/git2/libo/sal/systools/win32/uwinapi
Entering /cygdrive/c/libreoffice/git2/libo/sal/systools/win32/onlineupdate
Entering /cygdrive/c/libreoffice/git2/libo/sal/typesconfig
Entering /cygdrive/c/libreoffice/git2/libo/sal/rtl/source
--- ALWAYSDBGFILES ---
--- ALWAYSDBGFILES OVER ---
Entering /cygdrive/c/libreoffice/git2/libo/sal/textenc
Entering /cygdrive/c/libreoffice/git2/libo/sal/osl/w32
Entering /cygdrive/c/libreoffice/git2/libo/sal/osl/all
Entering /cygdrive/c/libreoffice/git2/libo/sal/util
Entering /cygdrive/c/libreoffice/git2/libo/sal/cppunittester
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/doublelock
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/rtl_doublelocking.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/rtl_doublelocking.dll
OK (2)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/strings
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/qa_rtl_strings.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/qa_rtl_strings.dll
OK (3)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/osl/getsystempathfromfileurl
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/locale
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/rtl_locale.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/rtl_locale.dll
OK (13)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/osl/process
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/osl_Thread.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/osl_Thread.dll
OK (6)
--
- start unit test #2 on library ../../../wntmsci12.pro/bin/osl_process.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/osl_process.dll
OK (0)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/rtl/cipher
--
- start unit test #1 on library ../../../wntmsci12.pro/bin/rtl_cipher.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
../../../wntmsci12.pro/bin/cppunittester
../../../wntmsci12.pro/bin/rtl_cipher.dll
OK (24)
Entering /cygdrive/c/libreoffice/git2/libo/sal/qa/sal
--
- start unit test #1 on library ../../wntmsci12.pro/bin/qa_sal_types.dll
--
:
PATH=/cygdrive/c/libreoffice/git2/libo/sal/wntmsci12.pro/bin:/cygdrive/c/libreoffice/git2/libo/solver/wntmsci12.pro/bin${PATH:+:${PATH}}
Re: [Libreoffice] instructions for building on windows with OneGit
On Wed, 2011-08-31 at 14:53 +0200, Noel Grandin wrote: New build log attached. strUserID: S-1-5-21-3395787511-4075999146-953599952 comes from qa/osl/security/osl_Security.cxx strID: S-1-5-21-3395787511-4075999146-953599952-1000 comes from osl/w32/security.c so its a matter of seeing which one is right, and which is wrong. I suppose its incredibly unlikely to be the difference between dwSubAuthorities=min(*GetSidSubAuthorityCount(pSid), 5); and dwSubAuthorities=*GetSidSubAuthorityCount(pSid)=5?*GetSidSubAuthorityCount(pSid):5; which looks like it should be equivalent ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] inconsistency between rtl::OString/rtl::OUString and optimization opportunities ?
On Aug 31, 2011, at 12:04 PM, Caolán McNamara wrote: rtl_string_new_WithLength/rtl_uString_new_WithLength create an rtl/String/rtl_uString of the given length, but set the full buffer contents to 0s[1] No idea whether specifying that the values of all characters are set to 0 was meant to be actually useful (and is exploited somewhere) or was misguided overeagerness. meanwhile I see that we have x_rtl_uString_new_WithLength in inc/i18nutil/x_rtl_ustring.h which is a non-zeroed out variant of rtl_uString_new_WithLength so there's an uninitialized buffer available to play with. We can assign ownership of the rtl_uString to an OUString with OUString( rtl_uString * str, __sal_NoAcquire ) and skip calling acquire, i.e. OUString has *two* methods to take ownership of a rtl_uString without calling acquire. the public OUString( rtl_uString * str, __sal_NoAcquire ) the private OUString( rtl_uString * value, DO_NOT_ACQUIRE * ) as well as the usual add-add-refcount version of OUString( rtl_uString * str ) While OString has only the private OString( rtl_String * value, DO_NOT_ACQUIRE * ) as well as the usual add-add-refcount version of OString( rtl_String * str ), so the same hack isn't available. No reason to not add a OString(…, __sal_NoAcquire) variant, too, I would say. I'm vaguely thinking of moving that i18nutil x_rtl stuff into comphelper/string or something, hard-coding its refcount argument to 0 or 1 and fixing up its uses to consistently use one or the other public OUString acquire/noacquire ctors and add a OString variant so that either of the belows is possible to skip copying buffers around the place. #if thinko-one rtl_String *pStr = foo_rtl_string_new_WithLength(nLen/*, refCount=0*/); //call acquire, refCount of 1, OString::dtor destroys buffer rtl::OString aRet(pStr); pStr-length = rStrm.Read(pStr-buffer, nLen); #else rtl_String *pStr = foo_rtl_string_new_WithLength(nLen/*, refCount=1*/); //don't call acquire, refCount stays 1, OString::dtor destroys buffer rtl::OString aRet(pStr, SAL_NO_ACQUIRE); pStr-length = rStrm.Read(pStr-buffer, nLen); #endif I would go with the second choice. foo_rtl_string_new_WithLength creates and returns a new resource that the caller is responsible of eventually releasing again, be it via an explicit rtl_string_release or via the SAL_NO_ACQUIRE trick. Also, that way its behavior is similar to plain rtl_string_new_WithLength, and adding the corresponding optimization for nLen=0 in the future would be straightforward. //if unlikely length != nLen make deep copy of string to release excess //mem, nobody seems to worry about excess for rtl::O[U]String buffers, //but much less opportunity to have a large chunk of unused //buffer there. C. [1] with a loop, I suppose its no real optimization there to use memset or rtl_allocateMemory for that case ? Wouldn't hurt to use memset instead, I'd say. Even if all compilers reduced the loop to something as efficient, using memset would still be shorter than that verbose loop. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [patch] fix linking of ulfex.exe
Patch to make ulfex.exe link correctly. This patch and any further contributions from me are under MPL 1.1 / GPLv3+ / LGPLv3+ Regards, Noel Grandin Noel Grandin wrote: Thanks, it's getting further now, but still throwing the same linker error when linking ulfex.exe -- Noel Caolán McNamara wrote: On Wed, 2011-08-31 at 12:04 +0200, Noel Grandin wrote: (3) Right now I'm struggling to get past a link error in l10ntools helpmerge.obj : error LNK2019: unresolved external symbol __declspec(dllimport) class rtl::OString __cdecl comphelper::string::getToken(class rtl::OString const ,long,char) Any ideas? http://cgit.freedesktop.org/libreoffice/core/commit/?id=a967c049a5e6e027850fbbb40a7231ee71551c91 might fix this C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html From 14ee3187bef8ff8cc4bd8aa2137154ee4cfe727d Mon Sep 17 00:00:00 2001 From: Noel Grandin noelgran...@gmail.com Date: Wed, 31 Aug 2011 15:36:56 +0200 Subject: [PATCH][BUILD] need EXPATASCII3RDLIB for ulfex Signed-off-by: Noel Grandin noelgran...@gmail.com --- l10ntools/source/makefile.mk |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/l10ntools/source/makefile.mk b/l10ntools/source/makefile.mk index 0f3dc66..dd3d2ff 100644 --- a/l10ntools/source/makefile.mk +++ b/l10ntools/source/makefile.mk @@ -97,6 +97,7 @@ APP3TARGET= ulfex APP3OBJS= $(OBJ)$/lngmerge.obj $(OBJ)$/merge.obj $(OBJ)$/export2.obj $(OBJ)$/lngex.obj APP3RPATH= NONE APP3STDLIBS+= \ +$(EXPATASCII3RDLIB) \ $(TOOLSLIB) \ $(COMPHELPERLIB) \ $(SALLIB) -- 1.7.5.1 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH][REVIEW] IDL @since build error if not OOo
Hi all
here is a patch (master branch) that add LibreOffice and LO string
support to @since tag in idl files
this solves a build breakage in odk if an IDL @since tag in offapi
contains LibreOffice or LO
Laurent
From f98d6dbbcf8fbc98d4a64709c6575ce507024cc0 Mon Sep 17 00:00:00 2001
From: Laurent Godard oooc...@free.fr
Date: Wed, 31 Aug 2011 15:26:52 +0200
Subject: [PATCH] allow LibreOffice reference in IDL @since tag
---
autodoc/source/parser_i/idoc/docu_pe2.cxx |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/autodoc/source/parser_i/idoc/docu_pe2.cxx b/autodoc/source/parser_i/idoc/docu_pe2.cxx
index 2f1af7f..d675103 100644
--- a/autodoc/source/parser_i/idoc/docu_pe2.cxx
+++ b/autodoc/source/parser_i/idoc/docu_pe2.cxx
@@ -616,7 +616,9 @@ bool
SapiDocu_PE::CheckVersionSyntax_OOo(const String i_versionPart1)
{
return i_versionPart1 == OOo
-OR i_versionPart1 == OpenOffice.org;
+OR i_versionPart1 == OpenOffice.org
+OR i_versionPart1 == LO
+OR i_versionPart1 == LibreOffice;
}
bool
--
1.7.1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][REVIEW] IDL @since build error if not OOo
Hi Laurent, On Wed, 2011-08-31 at 15:45 +0200, Laurent Godard wrote: Hi all here is a patch (master branch) that add LibreOffice and LO string support to @since tag in idl files this solves a build breakage in odk if an IDL @since tag in offapi contains LibreOffice or LO I think we use LibO, not LO, as the official abbreviation of LibreOffice. So, I would change LO to LibO. BTW great hacking. I'll start considering you a part of the core developers. :-) 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] instructions for building on windows with OneGit
I stuck some debug in the relevant code, and dwSubAuthorities==5 in security.c dwSubAuthorities==4 in osl_Security.cxx So this could be some weird Windows thing because the two modules are using different API calls to retrieve the SID. Caolán McNamara wrote: On Wed, 2011-08-31 at 14:53 +0200, Noel Grandin wrote: New build log attached. strUserID: S-1-5-21-3395787511-4075999146-953599952 comes from qa/osl/security/osl_Security.cxx strID: S-1-5-21-3395787511-4075999146-953599952-1000 comes from osl/w32/security.c so its a matter of seeing which one is right, and which is wrong. I suppose its incredibly unlikely to be the difference between dwSubAuthorities=min(*GetSidSubAuthorityCount(pSid), 5); and dwSubAuthorities=*GetSidSubAuthorityCount(pSid)=5?*GetSidSubAuthorityCount(pSid):5; which looks like it should be equivalent ? C. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Use a custom string to make numbering more flexible
On Wed, 2011-08-31 at 00:12 +0430, Mohammad Elahi wrote: Hi Kohei I was trying to make outline numbering in libreoffice more flexible by using a string to format numbers based on it. To use some escaped strings to represend number from different levels. maybe something like %0 for level 1 number and so on; But ODT standard lacks support for such a field. I would like to know how a new property such as num-prefix can be included in ODT standard? Hi Mohammad, First, let me also CC Thorsten as he is also on the TC and is more active than I. I can barely keep up with the activity of ODF TC these days, so I consider myself a non-active member of the TC. But anyways... Can you explain in detail what actual file format change you propose, and how it is to be used with specific use cases, using real world use cases. The description you gave above is still a bit vague, and for anyone to make a proposal needs a bit more clarity. Also, so far Thorsten and I are the only ones participating on the TC, and I don't think we can handle all our ODF needs for the whole project. We clearly need more people participating the TC. I have to be honest; I have enough things to do even without interacting with the ODF TC stuff, so I don't want to give people the wrong impression that I'm the one to talk to for all ODF needs, to avoid unnecessary frustration on both sides. Thanks, 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] [PATCH][REVIEW] [PUSHED] IDL @since build error if not OOo
I think we use LibO, not LO, as the official abbreviation of LibreOffice. So, I would change LO to LibO. Nah, why bother with abbreviations at all, surely it is not too much to expect people to write LibreOffice in full in *documentation* ? (online chat is another thing) Committed the patch (and then committed a follow-up that dropped the LO) and pushed. (If anybody feels strongly in favour of the abbreviations, feel free to revert etc.) Thanks! --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][REVIEW] [PUSHED] IDL @since build error if not OOo
HI Nah, why bother with abbreviations at all, surely it is not too much to expect people to write LibreOffice in full in *documentation* ? (online chat is another thing) Committed the patch (and then committed a follow-up that dropped the LO) and pushed. (If anybody feels strongly in favour of the abbreviations, feel free to revert etc.) Thanks! i'm fine with that thanks tor (and kohei too, i'm far from core developper ;) ) laurent ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
strUserID: S-1-5-21-3395787511-4075999146-953599952 comes from qa/osl/security/osl_Security.cxx strID: S-1-5-21-3395787511-4075999146-953599952-1000 comes from osl/w32/security.c Hmm, for me, if I add code to just print out the aMessage even if the assertion doesn't fail, I see: strUserID: S-1-5-21-2895500082-1622916122-3903545024-1000, strID: S-1-5-21-2895500082-1622916122-3903545024-1000 weird... --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
Hi This appears to be a windows weirdity related to the fact that my account name and my machine name is the same. Under this situation, the LookupAccountName API call will return the wrong answer. See here: http://archives.neohapsis.com/archives/ntbugtraq/1998-1999/msg00516.html Regards, Noel. Tor Lillqvist wrote: strUserID: S-1-5-21-3395787511-4075999146-953599952 comes from qa/osl/security/osl_Security.cxx strID: S-1-5-21-3395787511-4075999146-953599952-1000 comes from osl/w32/security.c Hmm, for me, if I add code to just print out the aMessage even if the assertion doesn't fail, I see: strUserID: S-1-5-21-2895500082-1622916122-3903545024-1000, strID: S-1-5-21-2895500082-1622916122-3903545024-1000 weird... --tml Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
This appears to be a windows weirdity related to the fact that my account name and my machine name is the same. Under this situation, the LookupAccountName API call will return the wrong answer. Well, wrong or right is a matter of opinion here, I guess... The documentation doesn't exactly mention this for LookupAccountName(),, true, but on the other hand, I guess that in general member computers also are accounts in the domain, or something, so it makes sense from that point of view... Anyway, great catch! Does this help? diff --git a/sal/qa/osl/security/osl_Security.cxx b/sal/qa/osl/security/osl_Security.cxx index ea59027..f5da4d9 100644 --- a/sal/qa/osl/security/osl_Security.cxx +++ b/sal/qa/osl/security/osl_Security.cxx @@ -464,8 +466,11 @@ void MyTestPlugInImpl::initialize( CPPUNIT_NS::TestFactoryRegistry *, // Set the count variables to the buffer sizes and retrieve the SID. cbSid = dwSidBufferSize; cchDomainName = dwDomainBufferSize; +WCHAR wszComputerName[MAX_COMPUTERNAME_LENGTH+1]; +DWORD nComputerNameSize = MAX_COMPUTERNAME_LENGTH + 1; +GetComputerNameW( wszComputerName, nComputerNameSize ); if (LookupAccountNameW( - NULL,// Computer name. NULL for the local computer + wszComputerName, wszAccName, pSid, // Pointer to the SID buffer. Use NULL to get the size needed, cbSid, // Size of the SID buffer needed. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
Hi Thanks for the patch, but no, it doesn't fix the problem. Going home now, but I'll be available tomorrow if you have any more ideas for me to try out :-) Thanks, Noel Grandin Tor Lillqvist wrote: This appears to be a windows weirdity related to the fact that my account name and my machine name is the same. Under this situation, the LookupAccountName API call will return the wrong answer. Well, wrong or right is a matter of opinion here, I guess... The documentation doesn't exactly mention this for LookupAccountName(),, true, but on the other hand, I guess that in general member computers also are accounts in the domain, or something, so it makes sense from that point of view... Anyway, great catch! Does this help? diff --git a/sal/qa/osl/security/osl_Security.cxx b/sal/qa/osl/security/osl_Security.cxx index ea59027..f5da4d9 100644 --- a/sal/qa/osl/security/osl_Security.cxx +++ b/sal/qa/osl/security/osl_Security.cxx @@ -464,8 +466,11 @@ void MyTestPlugInImpl::initialize( CPPUNIT_NS::TestFactoryRegistry *, // Set the count variables to the buffer sizes and retrieve the SID. cbSid = dwSidBufferSize; cchDomainName = dwDomainBufferSize; +WCHAR wszComputerName[MAX_COMPUTERNAME_LENGTH+1]; +DWORD nComputerNameSize = MAX_COMPUTERNAME_LENGTH + 1; +GetComputerNameW( wszComputerName, nComputerNameSize ); if (LookupAccountNameW( - NULL,// Computer name. NULL for the local computer + wszComputerName, wszAccName, pSid, // Pointer to the SID buffer. Use NULL to get the size needed, cbSid, // Size of the SID buffer needed. --tml Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instructions for building on windows with OneGit
Hi I'm really sorry, but it seems like this is just completely my own fault. Apparently MS-Windows works around this issue by preventing people from creating accounts with the same name as the machine. When I installed this machine and ran into that, I assumed it was a bug and found a way to force windows to make my machine name the same as my account name. So I've been wasting your time - sorry about time. I'll rename my machine and that should make this problem go away. Regards, Noel. Tor Lillqvist wrote: This appears to be a windows weirdity related to the fact that my account name and my machine name is the same. Under this situation, the LookupAccountName API call will return the wrong answer. Well, wrong or right is a matter of opinion here, I guess... The documentation doesn't exactly mention this for LookupAccountName(),, true, but on the other hand, I guess that in general member computers also are accounts in the domain, or something, so it makes sense from that point of view... Anyway, great catch! Does this help? diff --git a/sal/qa/osl/security/osl_Security.cxx b/sal/qa/osl/security/osl_Security.cxx index ea59027..f5da4d9 100644 --- a/sal/qa/osl/security/osl_Security.cxx +++ b/sal/qa/osl/security/osl_Security.cxx @@ -464,8 +466,11 @@ void MyTestPlugInImpl::initialize( CPPUNIT_NS::TestFactoryRegistry *, // Set the count variables to the buffer sizes and retrieve the SID. cbSid = dwSidBufferSize; cchDomainName = dwDomainBufferSize; +WCHAR wszComputerName[MAX_COMPUTERNAME_LENGTH+1]; +DWORD nComputerNameSize = MAX_COMPUTERNAME_LENGTH + 1; +GetComputerNameW( wszComputerName, nComputerNameSize ); if (LookupAccountNameW( - NULL,// Computer name. NULL for the local computer + wszComputerName, wszAccName, pSid, // Pointer to the SID buffer. Use NULL to get the size needed, cbSid, // Size of the SID buffer needed. --tml Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Escaped non-ASCII characters from source files.
Hi Eike, Makes sense. Please confirm that you contribute this and possibly further patches under LGPLv3+ and MPL 1.1 licenses. Yes, I agree that this patch and my further contribution is subject to LGPLv3+ and MPL 1.1. I'm also attaching one more patch which solves a similar problem in a different module (pango). Best regards, Takashi Nakamoto (2011/08/30 23:30), Eike Rathke wrote: Hi Takashi, On Tuesday, 2011-08-30 00:27:47 +0900, Takashi Nakamoto wrote: The attached patch solves a compilation error in libxml2 which occurs on Windows with some Asian locales. I would appreciate if someone pushes this. Makes sense. Please confirm that you contribute this and possibly further patches under LGPLv3+ and MPL 1.1 licenses. Thanks Eike From d93d1ec323dc706e041dcf1c8c53e9db3619110a Mon Sep 17 00:00:00 2001 From: Takashi Nakamoto bluedw...@bpost.plala.or.jp Date: Tue, 30 Aug 2011 03:50:07 +0900 Subject: [PATCH 2/2] Escaped non-ASCII characters from source files in pango BUilding pango with VC++ 2008 Express Edition on Windows platform where the locale is Japanese (or maybe Korean, Chinese or others) fails because some files extracted from the pango tarball contains non-ASCII characters. This change escapes those non-ASCII characters with \xff expression. --- pango/makefile.mk |2 +- pango/pango-1.28.3-non-ascii.patch | 528 2 files changed, 529 insertions(+), 1 deletions(-) mode change 100644 = 100755 pango/makefile.mk create mode 100644 pango/pango-1.28.3-non-ascii.patch diff --git a/pango/makefile.mk b/pango/makefile.mk old mode 100644 new mode 100755 index 66bf866..325ff75 --- a/pango/makefile.mk +++ b/pango/makefile.mk @@ -115,7 +115,7 @@ OUT2INC+=pango/pango-utils.h .ELIF $(OS)==WNT -PATCH_FILES=pango-1.28.3-win32.patch +PATCH_FILES=pango-1.28.3-win32.patch pango-1.28.3-non-ascii.patch ADDITIONAL_FILES=config.h msvc_recommended_pragmas.h CONFIGURE_DIR= CONFIGURE_ACTION= diff --git a/pango/pango-1.28.3-non-ascii.patch b/pango/pango-1.28.3-non-ascii.patch new file mode 100644 index 000..1a0ecce --- /dev/null +++ b/pango/pango-1.28.3-non-ascii.patch @@ -0,0 +1,528 @@ +--- misc/pango-1.28.3/pango/pango-language-sample-table.h 2011-08-30 03:35:41.996353700 +0900 misc/build/pango-1.28.3/pango/pango-language-sample-table.h 2011-08-30 03:33:09.885653400 +0900 +@@ -58,13 +58,13 @@ + LANGUAGE( +ar /* Arabic */, +WP-PANG, +- نص حكيم له سر قاطع وذو شأن عظيم مكتوب على ثوب أخضر ومغلف بجلد أزرق. ++ \xd9\x86\xd8\xb5 \xd8\xad\xd9\x83\xd9\x8a\xd9\x85 \xd9\x84\xd9\x87 \xd8\xb3\xd8\xb1 \xd9\x82\xd8\xa7\xd8\xb7\xd8\xb9 \xd9\x88\xd8\xb0\xd9\x88 \xd8\xb4\xd8\xa3\xd9\x86 \xd8\xb9\xd8\xb8\xd9\x8a\xd9\x85 \xd9\x85\xd9\x83\xd8\xaa\xd9\x88\xd8\xa8 \xd8\xb9\xd9\x84\xd9\x89 \xd8\xab\xd9\x88\xd8\xa8 \xd8\xa3\xd8\xae\xd8\xb6\xd8\xb1 \xd9\x88\xd9\x85\xd8\xba\xd9\x84\xd9\x81 \xd8\xa8\xd8\xac\xd9\x84\xd8\xaf \xd8\xa3\xd8\xb2\xd8\xb1\xd9\x82. +/* A wise text which has an absolute secret and great importance, written on a green tissue and covered with blue leather. */ + ) + LANGUAGE( +arn/* Mapudungun */, +WP-PANG, +- Gvxam mincetu apocikvyeh: ñizol ce mamvj ka raq kuse bafkeh mew. ++ Gvxam mincetu apocikvyeh: \xc3\xb1izol ce mamvj ka raq kuse bafkeh mew. +/* Tale under the full moon: the chief chemamull and the clay old woman at the lake/sea. */ + ) + LANGUAGE( +@@ -76,7 +76,7 @@ + LANGUAGE( +bg /* Bulgarian */, +WP-SFD, +- Под южно дърво, цъфтящо в синьо, бягаше малко пухкаво зайче. ++ \xd0\x9f\xd0\xbe\xd0\xb4 \xd1\x8e\xd0\xb6\xd0\xbd\xd0\xbe \xd0\xb4\xd1\x8a\xd1\x80\xd0\xb2\xd0\xbe, \xd1\x86\xd1\x8a\xd1\x84\xd1\x82\xd1\x8f\xd1\x89\xd0\xbe \xd0\xb2 \xd1\x81\xd0\xb8\xd0\xbd\xd1\x8c\xd0\xbe, \xd0\xb1\xd1\x8f\xd0\xb3\xd0\xb0\xd1\x88\xd0\xb5 \xd0\xbc\xd0\xb0\xd0\xbb\xd0\xba\xd0\xbe \xd0\xbf\xd1\x83\xd1\x85\xd0\xba\xd0\xb0\xd0\xb2\xd0\xbe \xd0\xb7\xd0\xb0\xd0\xb9\xd1\x87\xd0\xb5. +/* A little fluffy young rabbit ran under a southern tree blooming in blue */ + ) + LANGUAGE( +@@ -88,37 +88,37 @@ + LANGUAGE( +bn /* Bengali */, +GLASS, +- আমি কাঁচ খেতে পারি, তাতে আমার কোনো ক্ষতি হয় না। ++ \xe0\xa6\x86\xe0\xa6\xae\xe0\xa6\xbf \xe0\xa6\x95\xe0\xa6\xbe\xe0\xa6\x81\xe0\xa6\x9a \xe0\xa6\x96\xe0\xa7\x87\xe0\xa6\xa4\xe0\xa7\x87 \xe0\xa6\xaa\xe0\xa6\xbe\xe0\xa6\xb0\xe0\xa6\xbf, \xe0\xa6\xa4\xe0\xa6\xbe\xe0\xa6\xa4\xe0\xa7\x87 \xe0\xa6\x86\xe0\xa6\xae\xe0\xa6\xbe\xe0\xa6\xb0 \xe0\xa6\x95\xe0\xa7\x8b\xe0\xa6\xa8\xe0\xa7\x8b \xe0\xa6\x95\xe0\xa7\x8d\xe0\xa6\xb7\xe0\xa6\xa4\xe0\xa6\xbf \xe0\xa6\xb9\xe0\xa7\x9f \xe0\xa6\xa8\xe0\xa6\xbe\xe0\xa5\xa4 +/* I can eat glass and it doesn't hurt me. */ + ) + LANGUAGE( +bo /* Tibetan */, +GLASS, +- ཤེལ་སྒོ་ཟ་ནས་ང་ན་གི་མ་རེད། ++
Re: [Libreoffice] [PATCH] Use a custom string to make numbering more flexible
Hi Kohei First, let me also CC Thorsten as he is also on the TC and is more active than I. OK, thanks. Can you explain in detail what actual file format change you propose, and how it is to be used with specific use cases, using real world use cases. The description you gave above is still a bit vague, and for anyone to make a proposal needs a bit more clarity. A replacement for style:num-prefix, style:num-suffix for formatting outline numbering. A link which I found exactly elaborate it: http://wiki.services.openoffice.org/wiki/Number_labels#Label_generation_in_WW Any way do not know whether it has been implemented, I didn't find any thing in Open Document Format for Office Applications (OpenDocument) Version 1.2 (17 March 2011). I have enough things to do even without interacting with the ODF TC stuff, so I don't want to give people the wrong impression that I'm the one to talk to for all ODF needs, to avoid unnecessary frustration on both sides. Thanks for clarity ;) Thanks -Elahi ___ 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 #192 from Aaron Strontsman heinzless...@gmail.com 2011-08-31 12:05:35 PDT --- Can we add Bug 39355 ? This can be rather humiliating when you send a PDF to someone who uses Adobe Reader instead of a free PDF reader. -- 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] Proposal for new file format
I apologize for cross-posting this. ;)Frode 2011/8/19, Frode Severin Hatlevik frodeseve...@gmail.com: Hi all! I am a happy user of ODF, and have been so for a long time. I have a proposal, though, for a new use of ODF. I believe this can be a good advantage in the competition with other file formats. I am currently in the process of applying for jobs, and am veary after entering the same data for education and experience history into a multitude of online resumé bases. How about leveraging the power of ODF to create an open standard for creating CV? Then, if the resumé bases would support import of the file, I would have my CV in said ODF format, and simply upload it and make minor adjustments as needed. Regards ;)Frode Frode Severin Hatlevik -- Da sa Gud: Det bli lys! Og det ble lys. 1. Mosebok 1.3 And God said, Let there be light, and there was light. Genesis 1:3, NIV -- Da sa Gud: Det bli lys! Og det ble lys. 1. Mosebok 1.3 And God said, Let there be light, and there was light. Genesis 1:3, NIV ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Regina Henschel rb.hensc...@t-online.de changed: What|Removed |Added CC||rb.hensc...@t-online.de Depends on||40466 --- Comment #5 from Regina Henschel rb.hensc...@t-online.de 2011-08-31 12:42:42 PDT --- I nominate bug 40466. Import and Export Excel files in format xlsx crashes immediately. Working with spreadsheets in new Excel format is impossible. -- 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] Need help to generate patch with git
Hi all, thanks for all your tips. I had a look at 'StGit', it seems to help me, so I will give it a try. For the workflow with branches, I will start a new build, when I'm back from 'Hackfest München'. Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Escaped non-ASCII characters from source files.
Hi Takashi, On Tuesday, 2011-08-30 00:27:47 +0900, Takashi Nakamoto wrote: The attached patch solves a compilation error in libxml2 which occurs on Windows with some Asian locales. I would appreciate if someone pushes this. Pushed to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=f64c2d59704175940c3451fd28e3166f0f4d6e7c Thanks 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] [PUSHED] Escaped non-ASCII characters from source files.
Hi Takashi, On Thursday, 2011-09-01 01:14:53 +0900, Takashi Nakamoto wrote: Yes, I agree that this patch and my further contribution is subject to LGPLv3+ and MPL 1.1. Good :) I'm also attaching one more patch which solves a similar problem in a different module (pango). Pushed to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=149ff3ecc1d4a37b552eda7f363cf897e42f7ee5 Thanks 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] E Card add on
One thing that I find is missing from linux is a good ecard program, like windows office had with their Greetings 99, we were talking about this on another forum and thought it would be a great add to this program, it could be made as a standalone but it would make a great add to this already great program. I wish I knew how to code because I would do it myself. Maybe leave it open for people to add image packages and frame packages etc etc. Just a thought that hasn't been done yet for linux. I thought I would leave this suggestion in case anyone wanted to take it on. Sam -- View this message in context: http://nabble.documentfoundation.org/E-Card-add-on-tp3299530p3299530.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Unknown property NumberingLevel
Hello,
I took some time to take a look and here is what I found :
When I add SVX_UNOEDIT_OUTLINER_PROPERTIES in sd/source/core/stlsheet.cxx
, I hadn't noticed this line :
static SvxItemPropertySet aPropSet( aFullPropertyMap_Impl,
SdrObject::GetGlobalDrawObjectItemPool() );
So the array of SfxItemPropertyMapEntry is bound with the return of
SdrObject::GetGlobalDrawObjectItemPool().
Ok i go to svx/source/svdraw/svdobj.cxx and see this :
525 SdrItemPool SdrObject::GetGlobalDrawObjectItemPool()
526 {
527 if(!mpGlobalItemPool)
528 {
529 mpGlobalItemPool = new SdrItemPool();
530 SfxItemPool* pGlobalOutlPool = EditEngine::CreatePool();
531 mpGlobalItemPool-SetSecondaryPool(pGlobalOutlPool);
532
mpGlobalItemPool-SetDefaultMetric((SfxMapUnit)SdrEngineDefaults::GetMapUnit());
533 mpGlobalItemPool-FreezeIdRanges();
534 }
535
536 return *mpGlobalItemPool;
537 }
I continue and go to svx/source/svdraw/svdattr.cxx and take a look at the
constructor (line 94)
I'm stuck on this constructor. It's quite long and not very explicit to me.
(Eike, i took a look at editeng/source/editeng/eerdll.cxx, obviously it
seems GlobalEditData::GetDefItems() works the same way)
Any idea ?
--
View this message in context:
http://nabble.documentfoundation.org/Unknown-property-tp3293973p3299554.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Bringing some sanity to interline spacing
Hi Khaled, On Monday, 2011-08-29 20:21:47 +0200, Khaled Hosny wrote: Wow, way cool stuff! :-) #38683[5] is another example of problems caused by this. I'll set that bug to fixed with a remark to verify as I don't have a usable font for this. This only done for 'unx' similar work is needed for 'win' and 'aqua', but I'm not familiar with these platforms and can't test on it. Is handling on those platforms similar broken? Btw, please tag mails with attached patches with [PATCH] in the subject. Thanks 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] [PATCH] More numbering types: one, two, three, ...
Hi
Changed function lcl_formatPersianWord to be more generic, and added support
for some more numbering types:
English word: one, two, three, ...
English cardinal: first, second, third, ...
English cardinal semi-word: 1st, 2nd, 3rd, ...
Persian cardinal word.
I used C++ macros, but do not know whether libreoffice community
likes using it or not?
Any feedback is welcomed.
Thanks
-Elahi
From 094397fd2e5ca6d59b7541aa749212a2e57e2375 Mon Sep 17 00:00:00 2001
From: Mohammad Elahi elahimoham...@gmail.com
Date: Thu, 1 Sep 2011 04:16:47 +0430
Subject: [PATCH] Add more numbering types, English word, English cardinal, ...
Making lcl_formatPersianWord more generic and rename it to lcl_formatNumberWord.
And adding three more numbering types based on it.
English Numbers in word
English cardinal numbers in word
English cardinal numbers in digits with word suffix
Persian cardinal numbers in word
---
.../defaultnumberingprovider.cxx | 344 ++-
offapi/com/sun/star/style/NumberingType.idl| 28 ++
2 files changed, 353 insertions(+), 19 deletions(-)
diff --git a/i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx b/i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx
index 7a02463..4c43d7d 100644
--- a/i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx
+++ b/i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx
@@ -215,8 +215,72 @@ static sal_Unicode lowerLetter[] = {
0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7A
};
+#define DEFINE_WORD_TABLE(X) \
+NumberWordTable X { \
+{\
+{\
+X##_T1[0], X##_T1[1], X##_T1[2], X##_T1[3], X##_T1[4], \
+X##_T1[5], X##_T1[6], X##_T1[7], X##_T1[8], X##_T1[9], \
+X##_T1[10],X##_T1[11],X##_T1[12],X##_T1[13],X##_T1[14], \
+X##_T1[15],X##_T1[16],X##_T1[17],X##_T1[18],X##_T1[19] \
+}, \
+{\
+X##_E1[0], X##_E1[1], X##_E1[2], X##_E1[3], X##_E1[4], \
+X##_E1[5], X##_E1[6], X##_E1[7], X##_E1[8], X##_E1[9], \
+X##_E1[10],X##_E1[11],X##_E1[12],X##_E1[13],X##_E1[14], \
+X##_E1[15],X##_E1[16],X##_E1[17],X##_E1[18],X##_E1[19] \
+}\
+}, \
+{\
+{\
+X##_T2[0], X##_T2[1], X##_T2[2], X##_T2[3], X##_T2[4], \
+X##_T2[5], X##_T2[6], X##_T2[7] \
+}, \
+{\
+X##_E2[0], X##_E2[1], X##_E2[2], X##_E2[3], X##_E2[4], \
+X##_E2[5], X##_E2[6], X##_E2[7] \
+}, \
+}, \
+{\
+{\
+X##_T3[0], X##_T3[1], X##_T3[2], X##_T3[3], X##_T3[4], \
+X##_T3[5], X##_T3[6], X##_T3[7], X##_T3[8] \
+}, \
+{\
+X##_E3[0], X##_E3[1], X##_E3[2], X##_E3[3], X##_E3[4], \
+X##_E3[5], X##_E3[6], X##_E3[7], X##_E3[8] \
+}, \
+}, \
+{\
+{\
+X##_T4[0], X##_T4[1], X##_T4[2] \
+}, \
+{\
+X##_E4[0], X##_E4[1], X##_E4[2] \
+}\
+}, \
+{\
+X##_S[0], X##_S[1], X##_S[2], X##_S[3], X##_S[4]
Re: [Libreoffice] [PATCH] some cleanup of Kashida justification code
Hi Khaled, On Thursday, 2011-09-01 01:28:28 +0200, Khaled Hosny wrote: While trying to fix the eternal brokenness of Kashida justification code, I found some low hanging cleanups. See attached patches. Nice clean-up, pushed to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=6825533b8d93f92a66558a9b6295003ceba52917 Thanks 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] Need help to generate patch with git
Hi Khaled, On Wednesday, 2011-08-31 03:26:30 +0200, Khaled Hosny wrote: `git rebase` is your friend: http://help.github.com/rebase/ It never occurred to me that rebase has this squash functionality. I should read more manpages.. thanks a lot! Just used it on your three joining type patches :-) 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] [PUSHED] some cleanup of Kashida justification code
Hi Khaled, On Thursday, 2011-09-01 02:54:36 +0200, Eike Rathke wrote: Nice clean-up, pushed to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=6825533b8d93f92a66558a9b6295003ceba52917 Forgot to mention [PUSHED] in the subject and that I changed all +#define isAinChar(c)IS_JOINING_GROUP(c, AIN) to have parentheses around the macro parameter's use +#define isAinChar(c)IS_JOINING_GROUP((c), AIN) [otherwise macros are evil anyway ;-] 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] [PUSHED] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 02:13:34AM +0200, Eike Rathke wrote: Hi Khaled, On Monday, 2011-08-29 20:21:47 +0200, Khaled Hosny wrote: Wow, way cool stuff! :-) :) #38683[5] is another example of problems caused by this. I'll set that bug to fixed with a remark to verify as I don't have a usable font for this. This only done for 'unx' similar work is needed for 'win' and 'aqua', but I'm not familiar with these platforms and can't test on it. Is handling on those platforms similar broken? I did no testing, and I'm not familiar with other platforms APIs, but there seem to be a nCJKExtLeading hack in vcl/win/source/gdi/salgdi3.cxx and a comment above it suggests that typo metrics are not currently used. Btw, please tag mails with attached patches with [PATCH] in the subject. Sorry, missed that. Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] some cleanup of Kashida justification code
On Thu, Sep 01, 2011 at 03:07:36AM +0200, Eike Rathke wrote: Hi Khaled, On Thursday, 2011-09-01 02:54:36 +0200, Eike Rathke wrote: Nice clean-up, pushed to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=6825533b8d93f92a66558a9b6295003ceba52917 Forgot to mention [PUSHED] in the subject and that I changed all +#define isAinChar(c)IS_JOINING_GROUP(c, AIN) to have parentheses around the macro parameter's use +#define isAinChar(c)IS_JOINING_GROUP((c), AIN) Thanks [otherwise macros are evil anyway ;-] Indeed, but it looks better this way than having a dozen and half of one line functions each is called at most once. BTW, I see you merged the three patches in one commit, though I thought splitting them into more confined changes would be preferred. Is there any general policy for this that I can follow in future patches? Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] some cleanup of Kashida justification code
On Thu, 2011-09-01 at 03:15 +0200, Khaled Hosny wrote: BTW, I see you merged the three patches in one commit, though I thought splitting them into more confined changes would be preferred. Is there any general policy for this that I can follow in future patches? Well, I started this page http://wiki.documentfoundation.org/Development/Patch_Handling_Guideline hoping to have it as a central place to gather recommended practices for submitting and integrating patches. So, this is probably the closest to what you are asking for. As for whether to combine commits or keep them separate, we generally try to have each commit a distinct purpose. But beyond that, it's really down to the discretion of the individual developers. If you are making complex changes, it's probably a good idea to make the changes separate, to make it easier for the reviewer to review. OTOH, if you are making small-ish and simpli-sh changes here and there for a single purpose, then it may be a good idea to combine them into a single commit. So, it depends on individual cases, I guess. Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] some cleanup of Kashida justification code
On Wed, Aug 31, 2011 at 10:32:35PM -0400, Kohei Yoshida wrote: On Thu, 2011-09-01 at 03:15 +0200, Khaled Hosny wrote: BTW, I see you merged the three patches in one commit, though I thought splitting them into more confined changes would be preferred. Is there any general policy for this that I can follow in future patches? Well, I started this page http://wiki.documentfoundation.org/Development/Patch_Handling_Guideline hoping to have it as a central place to gather recommended practices for submitting and integrating patches. So, this is probably the closest to what you are asking for. As for whether to combine commits or keep them separate, we generally try to have each commit a distinct purpose. But beyond that, it's really down to the discretion of the individual developers. If you are making complex changes, it's probably a good idea to make the changes separate, to make it easier for the reviewer to review. OTOH, if you are making small-ish and simpli-sh changes here and there for a single purpose, then it may be a good idea to combine them into a single commit. So, it depends on individual cases, I guess. Thanks for the reply and the wiki page, I think things are clear enough now. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] New desktop integration modules
Hello all, I have created a patch that adds Trinity Desktop Environment integration to LibreOffice, and would like to get it included in the upstream LibreOffice sources if you are interested. It is based on the old KDE3 integration module, but has been altered to work with the latest version of TDE. It does not damage or replace the existing KDE3 desktop integration modules, and can be turned on/off with a configure flag at compile time. This is an important feature to users of TDE, as the existing KDE3 integration module will not function properly within the latest releases of TDE. We are prepared to maintain and enhance the TDE integration module for the foreseeable future. The patch can be found here: http://git.trinitydesktop.org/viewgit/index.php?a=viewblobp=Trinity%20Desktop%20Environmenth=33a55305c99e0dc808b25eaba3f7373521eec3e1hb=HEADf=main/thirdparty/libreoffice/3.3.2/patches/libreoffice-trinity.diff If you need the patch in e different format, or have concerns about it, please don't hesitate to contact me! Thanks, Timothy Pearson Trinity Desktop Project http://www.trinitydesktop.org/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
The attached patch is an attempt to bring some sanity to the situation: It seems that you have investigate this quite deeply and I would love to commit and push your patch. However, I am a bit scared. Could somebody else who actually understands the issues involved have a look? This only done for 'unx' similar work is needed for 'win' and 'aqua', but I'm not familiar with these platforms and can't test on it. I wonder if this patch will then introduce significant rendering differences between platforms? Or do we have such anyway already (even if the same fonts are present)? Lastly, can you confirm that your patch is licensed under LGPLv3+ and MPL1.1? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
