Re: [Libreoffice] [REVIEW] fdo#40701 Base crashes when Find Record button is clicked
On Mon, Sep 12, 2011 at 01:50:29AM +0200, Lionel Elie Mamane wrote:
On Mon, Sep 12, 2011 at 01:07:53AM +0200, Eike Rathke wrote:
On Monday, 2011-09-12 00:25:51 +0200, Lionel Elie Mamane wrote:
0001-fdo-40701-DbGridControl-RemoveColumn-even-if-no-corr.patch
fixes the root cause of the bug, which caused
void DbGridControl::EnableHandle(sal_Bool bEnable)
{
RemoveColumn(0);
m_bHandle = bEnable;
InsertHandleColumn();
}
to misfunction: RemoveColumn(0) silently did not remove the column, so
the call to InsertHandleColumn() added a second Handle Column, which
confused the code in other places.
Hmm.. this
@@ -1723,11 +1723,12 @@ sal_uInt16 DbGridControl::AppendColumn(const
XubString rName, sal_uInt16 nWidth
void DbGridControl::RemoveColumn(sal_uInt16 nId)
{
sal_uInt16 nIndex = GetModelColumnPos(nId);
-if (nIndex == GRID_COLUMN_NOT_FOUND)
-return;
DbGridControl_Base::RemoveColumn(nId);
+if (nIndex == GRID_COLUMN_NOT_FOUND)
+return;
+
delete m_aColumns[ nIndex ];
DbGridColumns::iterator it = m_aColumns.begin();
::std::advance( it, nIndex );
now attempts to unconditionally remove any column nId. I don't know if
and how the underlying code handles such cases,
Good point; it handles it well
but a safer approach would be to still check for a valid index and
additionally the handle column case, so
if (nIndex != GRID_COLUMN_NOT_FOUND || nId == 0)
DbGridControl_Base::RemoveColumn(nId);
might be better suited.
I don't think it makes a real difference either way.
After having slept on it, no. The situation is that there are *two*
column sequences:
1) BrowseBox::pCols
2) DbGridControl::m_aColumns
The call to DbGridControl_Base::RemoveColumn(nId) does remove
column from BrowseBox::pCols, if it is present there;
DbGridControl_base is a class derived from BrowseBox.
The rest of the code of the function does remove column from
DbGridControl::m_aColumns, if it is present there.
Tour version implements the logic is if the column is not in
DbGridControl::m_aColumns, then do not remove it from
BrowseBox::pCols, except for the known case if nId==0.
From a general robustness principle, my version seems preferable. For
example, it makes this code work as intended:
uInt16 nId = ...;
try
{
addColumTo_pCols(nId, ...);
// some code that may throw
(...)
addColumnTo_m_aColumns(nId, ...);
}
catch (...)
{
removeColumn(nId);
throw;
}
And actually, now that this is clear in my mind, I think the patch
should be, for more clarity:
void DbGridControl::RemoveColumn(sal_uInt16 nId)
{
+DbGridControl_Base::RemoveColumn(nId);
+
sal_uInt16 nIndex = GetModelColumnPos(nId);
if (nIndex == GRID_COLUMN_NOT_FOUND)
return;
-DbGridControl_Base::RemoveColumn(nId);
-
delete m_aColumns[ nIndex ];
DbGridColumns::iterator it = m_aColumns.begin();
::std::advance( it, nIndex );
This makes it more clear that the call to
DbGridControl_Base::RemoveColumn and the result of
GetModelColumnPos(nId) are meant to be completely independent.
--
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Experimental features
Hi all, I can't find a list of all experimental features that are enabled by the option in Tools Options LibreOffice General Does such a list exist ? Experimental features I know : - macros recorder - in-line formula editor Is there something else ? In http://wiki.documentfoundation.org/Development/GSoc it is said that the features developed during the GSoc would be integrated as soon as possible and unfinished feature works will be activated only when enabling experimental features. For me, this means that we should have a list of experimental features for the current release and another or a complement for the master. Best regards. JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Cppcheck defect when @ is present
On 09/11/2011 01:27 PM, Pierre-André Jacquod wrote: What's the best thing to do : - to keep objective C++ parts ? - to replace objective C++ by plain (with or without boost) C++ ? for me there are already too many languages and flavour of languages. I would stay with plain C++, not adding objective C++ on top In the Mac OS X specific code parts, we do need Objective C code, to interface the relevant Mac APIs. -Stephan ___ 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 37390, which changed state. Bug 37390 Summary: LibreOffice does not create valid ODF. https://bugs.freedesktop.org/show_bug.cgi?id=37390 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] Mi first very little patch
On 09/12/2011 01:03 AM, Lionel Elie Mamane wrote: On Sun, Sep 11, 2011 at 10:04:52PM +0200, CaStarCo wrote: I've created a second (very little too) patch to reduce the scope of a variable. --- a/sal/osl/w32/file_dirvol.cxx +++ b/sal/osl/w32/file_dirvol.cxx @@ -60,7 +60,6 @@ extern C BOOL TimeValueToFileTime(const TimeValue *cpTimeVal, FILETIME *pFTime Thank you for your contribution to LibreOffice, it is most welcome. Looking at that function in that file, it needs a more thorough cleanup, and maybe other functions in that file and/or in other files in the same directory; see http://msdn.microsoft.com/en-us/library/ms724284%28v=VS.85%29.aspx, in particular: [...] Also, the scope of localTime can be reduced even further, changing the line that assigns it into also declaring it, as in __int64 localTime = cpTimeVal-...; -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Experimental features
On Mon, Sep 12, 2011 at 09:02:07AM +0200, Jean-Baptiste Faure jbf.fa...@orange.fr wrote: Does such a list exist ? Experimental features I know : - macros recorder - in-line formula editor Is there something else ? You can seach the code: http://opengrok.libreoffice.org/search?q=IsExperimentalModeproject=core Regarding my code, the RTF export exports tables in experimental mode in a different way (similar to how Word does and the spec suggests, but libreoffice-3.4 and earlier does not understand that). pgpNeBZ0VKgHJ.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] git account request
+1. I would really like that too!!! -- Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On Mon 12 Sep 2011 02:37:20 AM IST, Olivier Hallot wrote: Hi Marco Do you mind to write some lines on how you succeded to have the big source code set under Eclipse CDT? Thanks in advance Olivier Em 11-09-2011 17:14, Marco escreveu: Hi Thorsten, I completed the switch to the new unified repository, everything built smoothly and I also succeeded in configuring eclipse cdt with the new big source code set. Now before bringing my project forward I'm going to request a git repo account through Freedesktop bugzilla site. I created a new feature branch named feature/svg-anims that I'll push as soon as I commit something new. Cheers, Marco ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] some cleaning for Windows part - need a review
based on some remarks, here exactly the same patches, but with improved commit comments. Will be probably better to integrate these. Thanks, looked fine to me, committed and pushed. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] SAL_DEPRECATED (was: [Libreoffice-commits] .: sal/inc)
On Sun, 11 Sep 2011 20:55:21 +0200 Stephan Bergmann sberg...@redhat.com wrote: On 09/09/2011 09:45 PM, Stephan Bergmann wrote: Is it true that __declspec must go before the return type for MSC (i.e., that the return type must go within the SAL_DEPRECATED argument)? No. It turns out SAL_DEPRECATED can be simplified after all, see http://cgit.freedesktop.org/libreoffice/core/commit/?id=d88bceafa0227e0e7bfe6bad1221eb93d3a9619a. Yes. looking way better. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to get LVS spellchk dict into distribution
Hi, 2011/9/10 Jānis ja...@dv.lv: the latest version, also found on openoffice extension site: http://dict.dv.lv/download/lv_LV-0.9.4.oxt Licence - LGPL Integrated, thanks. Please notify us about future updates. Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix compilation in gtk3salnativewidgets-gtk.cxx
On Sun, 2011-09-11 at 10:13 +0200, Lucas Baudin wrote: Hi, The small attached patch fixes the compilation in gtk3salnativewidgets-gtk.cxx, it's just a cast from long int to int. What's this patch against, that code doesn't exist in master. Is it against a gtk3 feature branch ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Fix configure to not require java packages when passed --without-java
On Thu, 2011-09-08 at 14:58 +0200, Tomáš Chvátal wrote: As requested in the fdo#40687 attaching the from the bug. Pushed now, thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED][REVIEW] take two on the where did my dictionaries go
On Fri, 2011-09-02 at 15:47 +0100, Caolán McNamara wrote: On Thu, 2011-09-01 at 13:52 +0100, Caolán McNamara wrote: Attached is the backport for 3-4 as this code changed a little between 3-4 and master. caolanm-Andras: could you arrange to have the attached tested ? https://bugs.freedesktop.org/show_bug.cgi?id=37195 testing seems to show success here. marking this thread as PUSHED. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] cppcheck duplicateExpression
On Thu, 2011-09-08 at 13:38 -0700, julien2412 wrote: Hello, Cppcheck has detected a duplicateExpression in vcl/ios/source/window/salframe.cxx, line 470 I checked on salframe.cxx of aqua, there's the same duplicate (line 631) Here is the line : if( pState-mnMask (SAL_FRAMESTATE_MASK_X | SAL_FRAMESTATE_MASK_X) ) Looks wrong alright, jpowers fixed this since with 64c15de6489b5a72f8530b66968d3d1660d39d55, and I merged it into ios equivalent with 7b2e14a0812ce3fbb450873e86243520f992d710 C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Пожелания по программе.
Здравствуйте. Добавьте, пожалуйста, возможность вырезания строки (с удалением пустой строчки) и последующей вставки вырезанной строки в заданное место так, чтобы не надо было делать лишних действий по удалению очищенной строки и добавлению строк перед вставкой вырезанной информации. Спасибо, Андрей.___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Пожелания по программе.
Hello! Should this letter be translated? 12.09.2011 13:49, meb...@ya.ru пишет: Здравствуйте. Добавьте, пожалуйста, возможность вырезания строки (с удалением пустой строчки) и последующей вставки вырезанной строки в заданное место так, чтобы не надо было делать лишних действий по удалению очищенной строки и добавлению строк перед вставкой вырезанной информации. Спасибо, Андрей. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Small refactoring
Hello! I found many classes which have functions like «queryInterface», «acquire» and etc. implemented in a same way. Maybe is it better to introduce a new helper class? I can do it. -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Delivery reports about your e-mail
6Ì1ÚzwÂw©nò;
'OôcvVܬK2¼¶!A|ÜcS¿¥s*qºØZÚ5¦[Ù-þb
ÁBÃo)N¯CÓ£¸¶sÃãx·¿ÊSgyN;ÃcKí2Y¹je¦rµ_¦U®,µÊ¬câ(«KãuæWs2åÃü,ó144ÑwÈÌ©èðųæ80õ
ÞÝK»g\Óáó9Í,«H^¿¶»÷ï!¬óa[iÛèþ£Â\ÐÌaÃ
øü0æu¸o¦/ó»d ¥Ò©òZÜGØgjÁ^
ØÜõ/½#º
Îì^AxÓe}ááÚ¦¸#x¶ÍÐ1ÙiòhîVÎÕçÎÛÚþçÀ§ñZDÝ`ø2ÎC¦
úÙC}ÿ!]®àAØGÃÆn^ëh±½Ý·ªPo
|³[!Ä1ÎåjÞ^!ó
kîÅÂWM'iYpÒß3½eîG1ßo4â?a´b×nÒÃÚµ¤bs#¤-a
l¦¶N lÏÈö;½!ÒLÌ£Ñ``¾´ë»zÐôÏY÷øH¼èÞâÛR¸?ð
vìH#ÙË¥ÍpÆuQÀÙÈ¢µ~Ãc9t%XÜÜO Q!
ÜBµä_À
Ï¿âÐ'4'Ð,øßHñ3ÖÉÞâ,u§
qäÁ/´¶#s.{?(RÐÈ)äðÄî?ÜÉÀ ®ðXÑß
ÔT£v¾éjÌcW§)ý
xå¼Æþ0ÁmÚÚL¾Ó 3ó.[ RçÞÀ/(ê¢Ö£ÜÛæ_ëÔeMzHµ¾IóC¼:}Õ?âP«Ô
Ä¡âY÷³¾ë¸j³ïþͯxîGÏ;ö`/»µ¿PUSë53%4ÞsÁ
ßtå!±i¢ì%HLÔ9l»©ÃiVÕ|ñÛ±åLa¢ZoKÀõ-Áú¯Î¶æ°úäZG$âBô$»vfNùZKÄÑÌ©N»n-xÎ¥
qк¡
2Ûpùñ~kç]Þë°éi4K
Tì:ìX*,
]¿{T
}KbEvÔ§*[¼
³¬tx»ÄàZoz(Y\trpÒäCï#Õ¡÷î¡)oßS®/Ê0¯¾¼ï©*Á76T³L}BÔNc¦9ã×´Ôð9èä¥ÀÉßGÞ
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Пожелания по программе.
Hello, 2011.09.12. 12:53 keltezéssel, Dmitry. A. Ashkadov írta: Hello! Should this letter be translated? No, it looks like a feature request. Please, either use bug tracker or tdf-discuss list for that. Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Пожелания по программе.
I'm not an author of feature request. Should I add feature request to bug tracker? It seems, this request requires more details from author. 12.09.2011 15:02, Andras Timar пишет: Hello, 2011.09.12. 12:53 keltezéssel, Dmitry. A. Ashkadov írta: Hello! Should this letter be translated? No, it looks like a feature request. Please, either use bug tracker or tdf-discuss list for that. Thanks, Andras -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] licensing statement
hi all, licensing statement, valid until further notice: Any patches of which i'm the author that i send to the LibreOffice lists or commit to the LibreOffice repos are available under LGPLv3+/MPLv1.1 license unless explicitly noted otherwise, or, in case of newly added files, the license header says otherwise. regards, michael ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ccache support
On Saturday 10 of September 2011, Norbert Thiebaud wrote: On Fri, Sep 9, 2011 at 1:22 PM, Lubos Lunak l.lu...@suse.cz wrote: Since there (AFAIR) haven't been any actual data presented in the discussion here are some number for my linux buildbot. Ccache hit statistics from a buildbot is probably the least realistic example possible. Of course the hit ratio is almost 100% when it repeatedly rebuilds almost the same source. For normal development builds the hit ratio should be much much lower, for many reasons (building noticeably less often and building when something does change being the primary two). I consider even my 40% hit ratio to be unusually high. The only useful numbers I can see is the ~5% ccache overhead, which should mean here the break even ratio is 10%, which I guess should be doable for LO, but without any real numbers this is still just guesswork. Note: when icecream is enable configure.in does _not_ auto-enable ccache (iow if you want ccache _with_ icecream you need to actively say --enable-ccahe or set up up transparently on your environment I have manual setup for either/both icecream and cccache, if this was directed at me. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Try to improve LibreOffice
Hello!
I attached two patches (= 2 commits).
Improvement: #39430 (http://bugs.freedesktop.org/show_bug.cgi?id=39430)
Author: Dmitry Ashkadov
License: LGPLv3/MPL
Should I close bug #39430 ?
07.09.2011 18:10, Dmitry. A. Ashkadov пишет:
Hello!
Can I try to improve LibreOffice? I had found task «Improving Saving
Information Icon in the Status Bar»
(http://bugs.freedesktop.org/show_bug.cgi?id=39430). But I don't know
who can help me, who can give me icons.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Best Regards,
Dmitry
From 3bd23342be1f14b428a96cfb2cdb81bc746c1e32 Mon Sep 17 00:00:00 2001
From: Dmitry Ashkadov dmitry.ashka...@gmail.com
Date: Mon, 12 Sep 2011 18:57:42 +0400
Subject: [PATCH 1/2] #39430: Saving Information Icon in the Status Bar was
improved.
---
default_images/svx/res/doc_modified_feedback.png | Bin 0 - 462 bytes
default_images/svx/res/doc_modified_no_14.png| Bin 429 - 369 bytes
default_images/svx/res/doc_modified_yes_14.png | Bin 506 - 462 bytes
svx/inc/svx/dialogs.hrc |9 +-
svx/inc/svx/modctrl.hxx |9 ++
svx/source/stbctrls/modctrl.cxx | 88 --
svx/source/stbctrls/stbctrls.src | 10 ++-
7 files changed, 89 insertions(+), 27 deletions(-)
create mode 100644 default_images/svx/res/doc_modified_feedback.png
diff --git a/default_images/svx/res/doc_modified_feedback.png b/default_images/svx/res/doc_modified_feedback.png
new file mode 100644
index ..1fa1f7421d48a207aa2a90957b8b8a49ed87296d
GIT binary patch
literal 462
zcmV;0WtoGP)h;3K|Lk000e1NJLTq000gE000XJ1^@s6Pldc4b3#c}2nYxW
zdbNS9a7bBm000fw000fw0YWI7cmMzZ8FWQhbW?9;ba!ELWdL_~cP?peYja~^
zaAhuUa%Y?FJQ@H10ZU0lK~yM_jgm1-LQxdQe_g#8`T~aroeZK71BaHTrXUnTFz_4H
zqgr0Lj*7ClKz|2WShV;60H1O|mo1rAb6b|3Y6=C#Q(Eb2F%!}R!#QL9ejfm
zbpXWp;?7#TbmZw*7^p0hyGae(MhFs79HY})PiRJ~q5)mkrEYuAJjbzovJ7yLph
zm7-WICZ{~5aLw`u?#f-6bEvtR7y%IJ!@^Kl*;}~e13l-NW4%kmy=RTPis9tB8FiI
zfbI9VHVps{?rZEfcX1qtLZOiCcDsioqVM|v?A`8Cy;|e!@tBi`BQ~bD2x}z(`k$`
zQzN1=27t}!9cE%Vwl3CjGgW4t9IaOCTLy;CVT_^Ik$c~?9bIWpYKrEYfH+2!h~u
z(f55KkqGg49DwD_3IO?hp5e?-8{aCG%JApL@+2m0ACS-(yir=wEzGB07*qoM6N$
EfTVS^xk5
literal 0
HcmV?d1
diff --git a/default_images/svx/res/doc_modified_no_14.png b/default_images/svx/res/doc_modified_no_14.png
index cc9d6f58155cb66b140aa41415a0f04d16795e11..2fbd22e956f94a45157d8b6cb9e3c32ec1178d8f 100644
GIT binary patch
delta 335
zcmV-V0kHn91Mvco7a9u)1^@s6Pldc4b3#c}2nYxWdbNSkw6%K8FWQhbW?9;
zba!ELWdL_~cP?peYja~^aAhuUa%Y?FJQ@H10PaadK~yM_jnOe~gD@Bc;Af0b1`i%G
zxHs|z=oGb^k;oM~_6S|@*iKzLaU=$cDzK1cjNK(vGz7J8`Ypdt)-RJ7BLJYPswYAS
z#U+H0uW6dz%d%{=)@J~J#~9;W6vZDq^lxTN-ak;O~dQDe$-mOdhb6dr6)p2w%jM!
zi4X!(%0rfA4{4fuO6ePbp+Wc4k64+sh5AjYpk`t+d${sF6Nv=N_lY3-EW{VW*4??
z3n2uIF?7uVc3OT*KImK-_iFyLI@bg5!PB*Yk$p4X9JBfNRk99j4?3AZoa%;XAS2(
h*@EZNsQ4i^EaJmaj6owVRQfh002ovPDHLkV1hIFh{ON@
delta 395
zcmV;60d)TH08m(7by-11^@s6A4o0H1b5ch_0Itp)=Px#24YJ`L;(K){{a7
zy{D6rFKXbbV*G`2ipVz6aoiMYpw?0013nR9JLFZ*6U5Zgcu(a%Ew3Wn_C
zX@2HM@dakWG-a~00035NklZD9^ppy-tQO6b9h8rGcoit_-~$5(qPKPzMmJ2z}
z0q(%~#lcJ9ei$4GL-`FMJx+YVAZlV_r0ubNl$-fd5`E%H2nA|k%^|o!F;y8ZK
zvg{GS4P(qCN%9N;VoebdPm)Us;asw%Q7yC;0BTbAXXh%VPYKN|Tg)j^qA;cZ$
z+!$kCiAetl0l;-#_`ZKZM6nQprD^)|E4bny2pr3@9*Uw+J2=ntA(m3Y^E_u9$J-s$
zS|3-!x~`#=Lff|2JJ|RAA#9pvmpMO2*L7Hy1;a34nkG!s^rDmJE*mW5CT$4NGZSE
pd3zkO8P!Bl^zAJ(#}7pIWPwbD3qp!GSS002ovPDHLkV1jr$p~(OM
diff --git a/default_images/svx/res/doc_modified_yes_14.png b/default_images/svx/res/doc_modified_yes_14.png
index e78de2384c0201224f9223bf753baadd1524f567..8a111d6532d08d489b3f3ff33be7b259a16a1f77 100644
GIT binary patch
delta 429
zcmV;e0aE_@1I`1G7a9u)1^@s6Pldc4b3#c}2nYxWdbNSkw6%K8FWQhbW?9;
zba!ELWdL_~cP?peYja~^aAhuUa%Y?FJQ@H10ZU0lK~yM_ebT*313?sq;n$LO2n*%
zKiMv6L=jOW7a$0dNGc(B5Qc!gMeOVZ+cbk0U}GTsg(5obxIl|HbzT#z|F)wFrrU
z7{BTq~*F@%tRc=04Sw@LST~LyjW}ZDwWEEQtAm20Bv8DS*V#;G~pt(6rm_Oube
zR!VJKYs*52Ixy3J7mP_dou*JI%(||7C4~4ALhJy||DpNr;rY1%w$?^c%H{F!^8-^|
zgYO7aT_c?o1FV$V9Dz|3^@`L2Vxx#XJ3wp{A+#dF1o?*1Ogdp-iS*2GT@%E*A
zz252O5D1|@O1BT;lsaK@em{U=RdMtZd=b-XWVqY?UFK!PUV}D3o`bi8!V+`TP
zEAHI|9Nl9M*LlwD5{l$_sI|s%9H#v96y4SfRiSxhM$U)_-p7luD)HpYvD3e(?hy
X%Y*}$*7flK8NkvXXu0mjfZfL|U
delta 473
zcmV;~0Ve*=1NsAy7by-11^@s6A4o0H1b5ch_0Itp)=Px#24YJ`L;(K){{a7
zy{D6rFKXbbV*G`2ipVz6ay|uO`L-0013nR9JLFZ*6U5Zgcu(a%Ew3Wn_C
zX@2HM@dakWG-a~0003|NklZD9^o;yGjF55Qe`!*IA)fbkNM1hMl0gouKTMAu}
zc-ZKZzFb|m#`E}Cz!^{Cs5QhUXtdlaXr~RYh!+7%zq3R5Q%~%?vXG|836DQA!N}
z_e1X9ah#nn3@?;YH$Vl*q9}6tBy__t90i?DXTH^Hohqfag%Ge+7n=Am1uTQZARN
z*Xzv{o_2(Giz-fkDF6$lS%M%adY*SGgm9uLs(cGt^FX(~Mz6h2_pHj?bb%lU
zr0;+GEu~a-3^c|7(7!r+#!9w1w=Z+($}DtyYu9n4{4`hK|-6(`(beKE!b)*aZ7
zNB4)Sf#wOi`IH^tYaL_{9w-D|-lk2E+uyDAjzS|(uX~saUHEEiXmzrc*M()ls
zNK-DKwnmr1^4G*L9J_W#s1hTTRP?^L{1jFTpsDvqqy)_~p~mKmY10LfD1_=6;g~
P0NkvXXu0mjfE?3WO
diff --git
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 37390, which changed state. Bug 37390 Summary: LibreOffice does not create valid ODF. https://bugs.freedesktop.org/show_bug.cgi?id=37390 What|Old Value |New Value Resolution|FIXED | Status|RESOLVED|REOPENED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix compilation in gtk3salnativewidgets-gtk.cxx
Yes, it is for the gtk3 feature branch, sorry, I forgot to mention it :/ On 09/12/2011 11:36 AM, Caolán McNamara wrote: On Sun, 2011-09-11 at 10:13 +0200, Lucas Baudin wrote: Hi, The small attached patch fixes the compilation in gtk3salnativewidgets-gtk.cxx, it's just a cast from long int to int. What's this patch against, that code doesn't exist in master. Is it against a gtk3 feature branch ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ccache support
On Mon, Sep 12, 2011 at 10:08 AM, Lubos Lunak l.lu...@suse.cz wrote: On Saturday 10 of September 2011, Norbert Thiebaud wrote: On Fri, Sep 9, 2011 at 1:22 PM, Lubos Lunak l.lu...@suse.cz wrote: Since there (AFAIR) haven't been any actual data presented in the discussion here are some number for my linux buildbot. Ccache hit statistics from a buildbot is probably the least realistic example possible. Of course the hit ratio is almost 100% when it repeatedly rebuilds almost the same source. For normal development builds the hit ratio should be much much lower, for many reasons (building noticeably less often and building when something does change being the primary two). I consider even my 40% hit ratio to be unusually high. The only useful numbers I can see is the ~5% ccache overhead, which should Agreed. that was indeed the most interesing part. the fact that ccache give good benefit for a completely hot cache is indeed quite expected. mean here the break even ratio is 10%, which I guess should be doable for LO, but without any real numbers this is still just guesswork. Well that is real number for overhead... since the difference between the no ccache run and the empty cache ccache run is purely the ccache overhead. so it is a very good indicator of the ccache overhead. Note: when icecream is enable configure.in does _not_ auto-enable ccache (iow if you want ccache _with_ icecream you need to actively say --enable-ccahe or set up up transparently on your environment I have manual setup for either/both icecream and cccache, if this was directed at me. I was wondering if the difference of overhead observed between your numbers and mine may have been related to ice-cream... All that being said. I am not overly attached to the default. I mean I can just as easily add --enable-ccache to my autogen.lastrun as you can add --disable-ccache to yours. and as I said earlier, as partial rebuild becomes more reliable it may very well make sens to have it 'disabled' by default. The problem is that today, when someone hit a build issue, the first advice we give is make clean make... which is typically 4 to 5 time more painful if you did not use ccache That is why I think that --enable-ccache is a much more causal/new-dev friendly. and more experience dev can pretty easily chose the setting that fit best their build pattern Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild: filter module
On Mon, Sep 12, 2011 at 12:19 PM, Michael Stahl m...@openoffice.org wrote: hi all, i'm sitting on patches to convert the filter module to gbuild. these could land in a git repo near you soon if somebody gave me an fdo account :) Michael, see: http://www.freedesktop.org/wiki/AccountRequests Fill a bug and thy wish shall be granted :-) because this is based on patches for ApacheOOo most of the new files have the standard ASF/AL2 license boilerplate. i'd like to leave that as is, because i'm lazy and it doesn't make that much sense to me to replace it with MPL/whatever when the same code is available elsewhere as AL2. except of course if there is some requirement or policy here that i'm currently not aware of :) Personal feeling aside, I don't think that would be a show-stopper, provided it is understood that the fact that the original submission is under AL2 does _not_ mean that subsequent patch to it shall also be under AL2. also, tested only on Linux because that's all i can build at home. That is why we have tinderboxes :-) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild: filter module
On Mon, Sep 12, 2011 at 2:06 PM, Norbert Thiebaud nthieb...@gmail.com wrote: see: http://www.freedesktop.org/wiki/AccountRequests Fill a bug and thy wish shall be granted :-) oh, I see that you already did https://bugs.freedesktop.org/show_bug.cgi?id=40758 well, these are typically handled by mmeeks, and he is on the road I believe... so it may take a few days... I you want i can push these for you in the mean time... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Mi first very little patch
Thanks you very much :) , I'll take a look and try to make better patches. And, of course, all my patches will be licensed under MPL1.1/LGPLv3+ . ^_^ . ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Mi first very little patch
@Lionel , What is the QuadPart member of the structure? The high part? the low part? or another thing? Thanks in advance :) . 2011/9/12 Lionel Elie Mamane lio...@mamane.lu On Sun, Sep 11, 2011 at 10:04:52PM +0200, CaStarCo wrote: I've created a second (very little too) patch to reduce the scope of a variable. --- a/sal/osl/w32/file_dirvol.cxx +++ b/sal/osl/w32/file_dirvol.cxx @@ -60,7 +60,6 @@ extern C BOOL TimeValueToFileTime(const TimeValue *cpTimeVal, FILETIME *pFTime Thank you for your contribution to LibreOffice, it is most welcome. Looking at that function in that file, it needs a more thorough cleanup, and maybe other functions in that file and/or in other files in the same directory; see http://msdn.microsoft.com/en-us/library/ms724284%28v=VS.85%29.aspx, in particular: It is not recommended that you add and subtract values from the FILETIME structure to obtain relative times. Instead, you should copy the low- and high-order parts of the file time to a ULARGE_INTEGER structure, perform 64-bit arithmetic on the QuadPart member, and copy the LowPart and HighPart members into the FILETIME structure. Do not cast a pointer to a FILETIME structure to either a ULARGE_INTEGER* or __int64* value because it can cause alignment faults on 64-bit Windows. It would be best to look at every place that FILETIME is used in that directory. Just in case you want to volunteer for that cleanup :) When you send a patch, could you please confirm the patch is licensed under MPL1.1/LGPLv3+? To make things easier, you can do a one-time blanket all my patches thing if you wish, sort of common to do that. Best Regards, -- Lionel -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] From sal/cppunit.h to sal/precppunit.hxx
Hi all, With http://cgit.freedesktop.org/libreoffice/core/commit/?id=d996328cd5f46eeed2df0cbd510eda28e2f7cef9 come three changes for CppUnit based tests in the LibO code base: - The header sal/cppunit.h has been removed (and it was not used much). - There is a new header sal/precppunit.hxx that should be included in every file (.hxx or .cxx) that includes any cppunit/... headers. What it does at the moment is override CPPUNIT_PLUGIN_EXPORT (see next), but it might get extended in the future. This means that the first headers included into any file (.hxx or .cxx) should now follow the pattern [#include precompiled_XXX.hxx] #include sal/config.h [#include sal/precppunit.hxx] - The overridden CPPUNIT_PLUGIN_EXPORT exports the cppunitTestPlugIn function via symbol visibility, so there is no longer a need to export it via a map file. (For dmake-based code, that means use VISIBILITY_HIDDEN=TRUE and SHLnUSE_EXPORTS=name instead of SHLnVERSIONMAP=... This feature was also already available with the old sal/cppunit.h, but lots of places in the code still used map files. I changed this to exclusively use symbol visibility now.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] convert xml2cmp to gbuild
Another gbuild conversion. Peter From 468dc3d5ce676ccd2aabf85540735086dccde7de Mon Sep 17 00:00:00 2001 From: Peter Foley pefol...@verizon.net Date: Mon, 12 Sep 2011 16:58:14 -0400 Subject: [PATCH] convert xml2cmp to gbuild --- Repository.mk|4 ++ RepositoryModule_ooo.mk |1 + xml2cmp/Executable_srvdepy.mk| 40 +++ xml2cmp/Executable_xml2cmp.mk| 39 ++ xml2cmp/Makefile | 38 ++ xml2cmp/Module_xml2cmp.mk| 40 +++ xml2cmp/StaticLibrary_x2c_support.mk | 38 ++ xml2cmp/StaticLibrary_x2c_xcd.mk | 40 +++ xml2cmp/prj/build.lst|9 +--- xml2cmp/prj/d.lst|4 -- xml2cmp/prj/makefile.mk | 40 +++ xml2cmp/source/finder/makefile.mk| 65 -- xml2cmp/source/support/makefile.mk | 57 --- xml2cmp/source/xcd/makefile.mk | 72 -- xml2cmp/util/makefile.mk | 58 --- 15 files changed, 282 insertions(+), 263 deletions(-) create mode 100644 xml2cmp/Executable_srvdepy.mk create mode 100644 xml2cmp/Executable_xml2cmp.mk create mode 100644 xml2cmp/Makefile create mode 100644 xml2cmp/Module_xml2cmp.mk create mode 100644 xml2cmp/StaticLibrary_x2c_support.mk create mode 100644 xml2cmp/StaticLibrary_x2c_xcd.mk create mode 100644 xml2cmp/prj/makefile.mk delete mode 100644 xml2cmp/source/finder/makefile.mk delete mode 100644 xml2cmp/source/support/makefile.mk delete mode 100644 xml2cmp/source/xcd/makefile.mk delete mode 100644 xml2cmp/util/makefile.mk diff --git a/Repository.mk b/Repository.mk index eebefe7..962356c 100644 --- a/Repository.mk +++ b/Repository.mk @@ -36,6 +36,8 @@ $(eval $(call gb_Helper_register_executables,NONE, \ mkunroll \ rscdep \ so_checksum \ +srvdepy \ +xml2cmp \ )) $(eval $(call gb_Helper_register_executables,OOO, \ @@ -255,6 +257,8 @@ $(eval $(call gb_Helper_register_static_libraries,PLAINLIBS, \ salcpprt \ vclmain \ writerperfect \ +x2c_support \ +x2c_xcd \ )) ifeq ($(OS),WNT) diff --git a/RepositoryModule_ooo.mk b/RepositoryModule_ooo.mk index 2d53175..3f09ba7 100644 --- a/RepositoryModule_ooo.mk +++ b/RepositoryModule_ooo.mk @@ -86,6 +86,7 @@ $(eval $(call gb_Module_add_moduledirs,ooo,\ wizards \ writerfilter \ writerperfect \ +xml2cmp \ xmloff \ xmlreader \ xmlscript \ diff --git a/xml2cmp/Executable_srvdepy.mk b/xml2cmp/Executable_srvdepy.mk new file mode 100644 index 000..3bcaa84 --- /dev/null +++ b/xml2cmp/Executable_srvdepy.mk @@ -0,0 +1,40 @@ +# +# Version: MPL 1.1 / GPLv3+ / LGPLv3+ +# +# The contents of this file are subject to the Mozilla Public License Version +# 1.1 (the License); you may not use this file except in compliance with +# the License or as specified alternatively below. You may obtain a copy of +# the License at http://www.mozilla.org/MPL/ +# +# Software distributed under the License is distributed on an AS IS basis, +# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License +# for the specific language governing rights and limitations under the +# License. +# +# The Initial Developer of the Original Code is +# Peter Foley pefol...@verizon.net +# Portions created by the Initial Developer are Copyright (C) 2011 the +# Initial Developer. All Rights Reserved. +# +# Major Contributor(s): +# +# For minor contributions see the git repository. +# +# Alternatively, the contents of this file may be used under the terms of +# either the GNU General Public License Version 3 or later (the GPLv3+), or +# the GNU Lesser General Public License Version 3 or later (the LGPLv3+), +# in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable +# instead of those above. +# + +$(eval $(call gb_Executable_Executable,srvdepy)) + +$(eval $(call gb_Executable_add_exception_objects,srvdepy,\ + xml2cmp/source/finder/dependy \ + xml2cmp/source/finder/dep_main \ +)) + +$(eval $(call gb_Executable_add_linked_static_libs,srvdepy,\ + x2c_support \ + x2c_xcd \ +)) diff --git a/xml2cmp/Executable_xml2cmp.mk b/xml2cmp/Executable_xml2cmp.mk new file mode 100644 index 000..692a043 --- /dev/null +++ b/xml2cmp/Executable_xml2cmp.mk @@ -0,0 +1,39 @@ +# +# Version: MPL 1.1 / GPLv3+ / LGPLv3+ +# +# The contents of this file are subject to the Mozilla Public License Version +# 1.1 (the License); you may not use this file except in compliance with +# the License or as specified alternatively below. You may obtain a copy of +# the License at http://www.mozilla.org/MPL/ +# +# Software distributed under the License is distributed on an AS IS basis, +# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License +# for the specific
Re: [Libreoffice] [PUSHED][PATCH] convert xml2cmp to gbuild
On Mon, Sep 12, 2011 at 4:04 PM, Peter Foley pefol...@verizon.net wrote: Another gbuild conversion. Nice. Pushed, Thanks. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build
gbuild conversion. PeterFrom 6bc7b647d1f116df04fcf43ce42db1d25ff0 Mon Sep 17 00:00:00 2001 From: Peter Foley pefol...@verizon.net Date: Mon, 12 Sep 2011 17:19:42 -0400 Subject: [PATCH] convert MathMLDTD to gbuild and add to tail_build --- MathMLDTD/Makefile| 38 ++ MathMLDTD/Module_MathMLDTD.mk | 32 MathMLDTD/Package_bin.mk | 34 ++ MathMLDTD/prj/build.lst |5 ++--- MathMLDTD/prj/d.lst |2 -- MathMLDTD/prj/makefile.mk | 40 Module_tail_build.mk |1 + RepositoryModule_ooo.mk |1 + postprocess/prj/build.lst |2 +- 9 files changed, 149 insertions(+), 6 deletions(-) create mode 100644 MathMLDTD/Makefile create mode 100644 MathMLDTD/Module_MathMLDTD.mk create mode 100644 MathMLDTD/Package_bin.mk create mode 100644 MathMLDTD/prj/makefile.mk diff --git a/MathMLDTD/Makefile b/MathMLDTD/Makefile new file mode 100644 index 000..90947b2 --- /dev/null +++ b/MathMLDTD/Makefile @@ -0,0 +1,38 @@ +#* +# +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# Copyright 2000, 2011 Oracle and/or its affiliates. +# +# OpenOffice.org - a multi-platform office productivity suite +# +# This file is part of OpenOffice.org. +# +# OpenOffice.org is free software: you can redistribute it and/or modify +# it under the terms of the GNU Lesser General Public License version 3 +# only, as published by the Free Software Foundation. +# +# OpenOffice.org is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Lesser General Public License version 3 for more details +# (a copy is included in the LICENSE file that accompanied this code). +# +# You should have received a copy of the GNU Lesser General Public License +# version 3 along with OpenOffice.org. If not, see +# http://www.openoffice.org/license.html +# for a copy of the LGPLv3 License. +# +#* + +ifeq ($(strip $(SOLARENV)),) +$(error No environment set!) +endif + +gb_PARTIALBUILD := T +GBUILDDIR := $(SOLARENV)/gbuild +include $(GBUILDDIR)/gbuild.mk + +$(eval $(call gb_Module_make_global_targets,$(shell ls $(dir $(realpath $(firstword $(MAKEFILE_LIST/Module*.mk))) + +# vim: set noet sw=4 ts=4: diff --git a/MathMLDTD/Module_MathMLDTD.mk b/MathMLDTD/Module_MathMLDTD.mk new file mode 100644 index 000..f60b555 --- /dev/null +++ b/MathMLDTD/Module_MathMLDTD.mk @@ -0,0 +1,32 @@ +# +# Version: MPL 1.1 / GPLv3+ / LGPLv3+ +# +# The contents of this file are subject to the Mozilla Public License Version +# 1.1 (the License); you may not use this file except in compliance with +# the License or as specified alternatively below. You may obtain a copy of +# the License at http://www.mozilla.org/MPL/ +# +# Software distributed under the License is distributed on an AS IS basis, +# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License +# for the specific language governing rights and limitations under the +# License. +# +# The Initial Developer of the Original Code is +# Peter Foley pefol...@verizon.net +# Portions created by the Initial Developer are Copyright (C) 2011 the +# Initial Developer. All Rights Reserved. +# +# Major Contributor(s): +# +# For minor contributions see the git repository. +# +# Alternatively, the contents of this file may be used under the terms of +# either the GNU General Public License Version 3 or later (the GPLv3+), or +# the GNU Lesser General Public License Version 3 or later (the LGPLv3+), +# in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable +# instead of those above. +# + +$(eval $(call gb_Module_Module,MathMLDTD)) + +$(eval $(call gb_Module_add_targets,MathMLDTD,Package_bin)) diff --git a/MathMLDTD/Package_bin.mk b/MathMLDTD/Package_bin.mk new file mode 100644 index 000..a1730cd --- /dev/null +++ b/MathMLDTD/Package_bin.mk @@ -0,0 +1,34 @@ +# +# Version: MPL 1.1 / GPLv3+ / LGPLv3+ +# +# The contents of this file are subject to the Mozilla Public License Version +# 1.1 (the License); you may not use this file except in compliance with +# the License or as specified alternatively below. You may obtain a copy of +# the License at http://www.mozilla.org/MPL/ +# +# Software distributed under the License is distributed on an AS IS basis, +# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License +# for the specific language governing rights and limitations under the +# License. +# +# The Initial Developer of the Original Code is +# Peter Foley pefol...@verizon.net +# Portions created by the Initial Developer are Copyright (C) 2011 the +# Initial Developer. All
Re: [Libreoffice] [PUSHED][PATCH] convert MathMLDTD to gbuild and add to tail_build
On Mon, Sep 12, 2011 at 4:26 PM, Peter Foley pefol...@verizon.net wrote: gbuild conversion. Pushed with a little fix: a missing '\' in Module_tail_build.mk Thanks Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build
On 12.09.2011 23:26, Peter Foley wrote: gbuild conversion. Peter hi Peter, mostly looking good except: --- a/Module_tail_build.mk +++ b/Module_tail_build.mk @@ -35,6 +35,7 @@ $(eval $(call gb_Module_add_moduledirs,tail_end,\ formula \ hwpfilter \ lotuswordpro \ +MathMLDTD missing backslash at EOL Mesa \ oox \ padmin \ diff --git a/RepositoryModule_ooo.mk b/RepositoryModule_ooo.mk index 3f09ba7..64093db 100644 --- a/RepositoryModule_ooo.mk +++ b/RepositoryModule_ooo.mk @@ -53,6 +53,7 @@ $(eval $(call gb_Module_add_moduledirs,ooo,\ idl \ linguistic \ lotuswordpro \ +MathMLDTD same problem Mesa \ o3tl \ offapi \ --- a/MathMLDTD/prj/build.lst +++ b/MathMLDTD/prj/build.lst @@ -1,3 +1,2 @@ -md MathMLDTD : solenv NULL -md MathMLDTD usr1 - all md_mkout NULL -md MathMLDTD\prj get - all md_prj NULL +md MathMLDTD : NULL you remove the dependency on solenv; it seems that currently we don't have any module (except solenv of course, and testautomation which doesn't do anything) that does not directly or indirectly depend on solenv; i wonder why that is? is there perhaps some reason that modules must depend on solenv? regards, michael -- Do you not know, my son, with how little wisdom the world is governed? -- Axel Oxenstierna ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] additional symbols or alternatively stencils in Draw templates
Although I always try to convince people to use LibreOffice or OpenOffice before LB started there is one complaint coming back regularly. That is the missing capabilities of Draw compared to Visio. A first step in that direction would be offering more drawing symbols like a symbol set for BPMN. If someone could give some assistance on how such an additional symbol set could be integrated I would be willing to provide it. The further step would be implementing stencils in Draw templates. I created some stencil sets for Visio in the past therefore I have some experience in doing so but I have know idea who they could be integrated. They are somehow like template internal galleries but every shape can have attributes like for network mapping a field IP address for every shape representing an active component together with a name, a type and so on. Therefore a dynamic dialog would be necessary to show these attributes and let the user enter the values. Finally a shape editor would be nice to allow the user for creating his own stencils. Is there anybody else interested in such an extension and able to aid with the programming part? Kind regards Ulrich -- ~ ZPK Moser UG (haftungsbeschränkt) i.G. Ulrich Moser - Geschäftsführer Schlossstraße 7 - 78244 Gottmadingen +49 (0)7734 395 494 - +49 (0)179 915 54 18 www.zpk-moser.de - ulrich.mo...@zpk-moser.de ~ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi, [Please *first read my next mail* on this list !] Let me also reply on the minutes of tech. steering call: from Re: [Libreoffice] minutes of tech. steering call ... Michael Meeks wrote (08-09-11 17:28) + Cor's considerations on release timing Better: time available between Beta1 / RC1 and release. + existing schedule is here: http://wiki.documentfoundation.org/ReleasePlan#3.5_release + very vague, lots of factors and no data / heuristics (Thorsten) That is by intention. As written: Goal: take a clear look at what influences the development and QA of 3.5.0, in order So I wanted to gather the areas of interest first, rather then examples for every item. Sorry if that was not clear, or not inspiring ;-) + could try a slushy feature-freeze on master around an earlier release with new features (Norbert) Sounds interesting. + some new features have good QA coupling with their own builds eg. Jean Baptiste (Cedric) Some ... I think it would be good to know on which features that is and on which not. (BTW, I do like that co-operation ! ) + lots of reasons already provided why next time would be better quality-wise than last time (Michael) Looks rather unspecified and does not wipe away remaining/new reasons. + not too late to discuss at the conference and move freeze dates by a week or two (Norbert) Do all working on features agree? + always a trade-off between quality, community fun, pace of development (Michael) No real argument. I am more interested in the question: do we want avoid another 3.4-style release? + Release mgmt (Petr) + concern wrt. bugs in master - need some focus there + no more releases until after the conference + QA update (Rainer) + master in v. good shape currently modulo a few annoying bugs + eg. PDF export from writer completely broken Only few annoying bugs might as well mean that too few people work with master.. I file some, post some on IRC/dev@. (But also come across problems that are so time-consuming to try to make understandable / reproducible, that until now I did not.) Rainers does master-bugs. Mow many others do? We have to be careful for a 'I see no problems so there are no problems' trap. + monthly bug hunting session last week: + not so successful Alas. And not a signal that adds trust. Cor Nouws wrote (06-09-11 22:41) [resend of my post from 2011-09-04, 20:38 UTC with one little change] Obviously, my more conceptual approach did not work. So this time, I will try to add some more content. So, items that come to my mind: - number and severity of changes on code how many difficult/basic stuff are touched in these months? We know that when so much is changed, for sure many nasty hidden older bugs will surface.. I have deep respect for the work of Kohei, Eike and Marcus. But they do change a whole lot of stuff these days, weeks, months. Is it strange that we have to expect quite some unexpected side effects? We cannot on the one side complain that the old code is quite filled with oddities, mistakes, redundancies etc etc, and on the other hand do light on the risk of side effect with large code changes Same for other devs / area of development. - How much time can one annoying bug ask? Two day, two weeks? (many bugs show that is can be very time consuming) - what is the progress in the weak spots in our attention? Base e.g. Base, Windows, Mac - what can we expect for new large code chunks in the coming months or integration of some older CWS'es there will be, isn't it? - the increase in the number of people available for testing - how many people start working/testing with master/nightly builds? - how many issues see we from there? - and how fast are those solved? - development in the quality and the use of tools for testing - is attention in testing well spread over Windows / Linux / MacOS ? Do we see more or about the same activity by testers? Growth or decline in bugs? I read (about) bugs in BugZilla sometimes, that are annoying and regressions, yet did not make it to one of the most annoying gathering issues, and without doubt partly because of lack of attention of QA, either hard to simply reproduce. Compatibility with older versions, older document, ... - are there other releases/tasks that need attention during that time ? - how many people are available for beta-RC testing and fixing bugs ? e.g. the time of the year (Christmas, Western New year) Does it really make sense to have one release on Dec. 23 and the next one on Jan 6th? - can we attract
Re: [Libreoffice] 3.5 release from QA to point-zero
Hi, from Re: [Libreoffice] minutes of tech. steering call ... Michael Meeks wrote (08-09-11 17:28) + not too late to discuss at the conference and move freeze dates by a week or two (Norbert) If it is true that ... none of the devs have working of features has problems with : - a possible decision on/around October 14; - for a change of the feature freeze date (from say December 5th to 2 or 3 weeks earlier) (so that means from appr. 7 weeks back to appr 4 weeks) .. then please read my previous mail as some context for the discussion at the conference. If not, please consider the content of that mail now. Thanks -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech. steering call ...
Michael Meeks wrote (08-09-11 17:28) + Release mgmt (Petr) + concern wrt. bugs in master - need some focus there + no more releases until after the conference A pity since 3.4.3 has at least one nasty regression. -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert MathMLDTD to gbuild and add to tail_build
On Mon, Sep 12, 2011 at 4:53 PM, Michael Stahl m...@openoffice.org wrote: On 12.09.2011 23:26, Peter Foley wrote: gbuild conversion. Peter hi Peter, mostly looking good except: --- a/Module_tail_build.mk +++ b/Module_tail_build.mk @@ -35,6 +35,7 @@ $(eval $(call gb_Module_add_moduledirs,tail_end,\ formula \ hwpfilter \ lotuswordpro \ + MathMLDTD missing backslash at EOL I got that one... Mesa \ oox \ padmin \ diff --git a/RepositoryModule_ooo.mk b/RepositoryModule_ooo.mk index 3f09ba7..64093db 100644 --- a/RepositoryModule_ooo.mk +++ b/RepositoryModule_ooo.mk @@ -53,6 +53,7 @@ $(eval $(call gb_Module_add_moduledirs,ooo,\ idl \ linguistic \ lotuswordpro \ + MathMLDTD same problem but I missed that one... fixed now Mesa \ o3tl \ offapi \ --- a/MathMLDTD/prj/build.lst +++ b/MathMLDTD/prj/build.lst @@ -1,3 +1,2 @@ -md MathMLDTD : solenv NULL -md MathMLDTD usr1 - all md_mkout NULL -md MathMLDTD\prj get - all md_prj NULL +md MathMLDTD : NULL you remove the dependency on solenv; it seems that currently we don't have any module (except solenv of course, and testautomation which doesn't do anything) that does not directly or indirectly depend on solenv; i wonder why that is? is there perhaps some reason that modules must depend on solenv? isn't that for the basic setup of solver ? (mkdir od bin inc etc..) but I believe Deliver.mk do the mkdir by precaution anyways.. so that should no have any impact here.. Norber ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] 3.5 release from QA to point-zero
On Tue, 2011-09-13 at 00:23 +0200, Cor Nouws wrote: + always a trade-off between quality, community fun, pace of development (Michael) No real argument. I am more interested in the question: do we want avoid another 3.4-style release? So, our memory is getting rustier about how the 3.4.0 release went. Could you refresh our memory as to what exactly were the issues concerning the 3.4.0 release? I assume here that by 3.4-style release you mean the actual 3.4.0 release. It's much easier to discuss specific issues than vague let's avoid the 3.4-style release style of argument. - number and severity of changes on code how many difficult/basic stuff are touched in these months? We know that when so much is changed, for sure many nasty hidden older bugs will surface.. I have deep respect for the work of Kohei, Eike and Marcus. But they do change a whole lot of stuff these days, weeks, months. Is it strange that we have to expect quite some unexpected side effects? So, you want us to stop writing code? On a serious note, any developers worth his/her money are aware that making changes may introduce side effects. There is no way to avoid it. What we do is that, given that possibility, balance out the necessary code change *and* avoiding regressions, and do our due diligence to test our code. Even with that, some things break in some unknown corner case scenarios. So we rely on testers to weed out those weird corner cases that we had not anticipated. To me that's just the normal course of business. We also help each other out by code review, and also fix each other's bugs. Plus, we are not even hitting the code freeze (Dec 5), so I don't think it's fair to start blaming us for the necessary code changes, unless you want this project to stagnate to a stand-still way before hitting the code freeze. We cannot on the one side complain that the old code is quite filled with oddities, mistakes, redundancies etc etc, and on the other hand do light on the risk of side effect with large code changes Oh come on. Save us the lecture there. We are all aware of the risks of large code changes. So we are limiting that until we hit a code freeze. Isn't that reasonable? I'm very very confused. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] (no subject)
The original message was received at Tue, 13 Sep 2011 12:32:29 +0700 from 35.150.96.253 - The following addresses had permanent fatal errors - libreoffice@lists.freedesktop.org - Transcript of session follows - ... while talking to 139.165.184.241: 554 libreoffice@lists.freedesktop.org... Message is too large 554 libreoffice@lists.freedesktop.org... Service unavailable ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
