Re: [Libreoffice] [PATCH] Automatically select an option page if a user clicks on a category

[Cor Nouws]

Hi August,

August Sodora wrote (16-12-11 06:27)


Stefan Knorr notified me of the following whiteboard item from the
design team [1], and I have created the following patch that should
implement the desired behavior.
[...]
[1] http://wiki.documentfoundation.org/Whiteboards/KillOptions#Filler_Pages


Has this been mentioned on the UX-list?
IMO it's a good habit to involve that list in UX-changes - even if they 
seem not controversial :-)


Thanks,

--
 - Cor
 - http://nl.libreoffice.org

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Arno Teigseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/12/11 08:26, Khaled Hosny wrote:
> certain culture is superior to others, and if we can remove a
> possibly offending item to certain people, what harm can be caused
> by that?

This is the only time I'll comment on this thread, don't worry.

Is this "possibly" offending, or _is it_ offending? Maybe there should
be some kind of official reference to whom it would offend? One person
only?

I mean, if there's an official reference to some group actually being
offended, I think it would add weight to the request.

A mail from one single person saying it's "possibly" offending isn't
very heavyweight, is it?

best
Arno
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7q3l0ACgkQEMIGVCc8BjB4XQCgy0pzA/Oy7nP0gcTUfWR5cR+4
iQYAoJbOwOkW3oBiWXjsqfxTJ9cI03rJ
=93mr
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] Automatically select an option page if a user clicks on a category

[August Sodora]

Hey all,

Stefan Knorr notified me of the following whiteboard item from the
design team [1], and I have created the following patch that should
implement the desired behavior. I haven't done any of the cleanup for
this because I'd like to dig a little deeper but there are definitely
src and hrc entries that can be removed, as well as simplying the
logic a little bit in the select handler in
cui/source/options/treeopt.cxx. Ideally I'd like to clean things up to
the point where I can remove the switch statement and glean the
default page to display from information in treeopt.[src|hrc].

[1] http://wiki.documentfoundation.org/Whiteboards/KillOptions#Filler_Pages



August Sodora
aug...@gmail.com
(201) 280-8138
From d00daca6dec8f9cbef08bc095e8d92394816caaa Mon Sep 17 00:00:00 2001
From: August Sodora 
Date: Fri, 16 Dec 2011 00:14:03 -0500
Subject: [PATCH 2/2] Automatically select an option page if a user clicks on
 a category

---
 cui/source/options/treeopt.cxx |   56 
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/cui/source/options/treeopt.cxx b/cui/source/options/treeopt.cxx
index 66210b7..5fdb53a 100644
--- a/cui/source/options/treeopt.cxx
+++ b/cui/source/options/treeopt.cxx
@@ -1028,6 +1028,62 @@ IMPL_LINK( OfaTreeOptionsDialog, SelectHdl_Impl, Timer*, EMPTYARG )
 return 0;
 //#111938# lock the SelectHdl_Impl to prevent multiple executes
 FlagSet_Impl aFlag(bInSelectHdl_Impl);
+
+// If the user has selected a category, automatically switch to a suitable
+// default sub-page instead.
+if (!pParent)
+{
+OptionsGroupInfo* pGroupInfo = static_cast(pEntry->GetUserData());
+
+if(!pGroupInfo)
+return 0;
+
+switch(pGroupInfo->m_nDialogId)
+{
+case SID_GENERAL_OPTIONS:
+ActivatePage(RID_SFXPAGE_GENERAL);
+break;
+case SID_LANGUAGE_OPTIONS:
+ActivatePage(OFA_TP_LANGUAGES);
+break;
+case SID_INET_DLG:
+ActivatePage(RID_SVXPAGE_INET_PROXY);
+break;
+case SID_SW_EDITOPTIONS:
+ActivatePage(RID_SW_TP_OPTLOAD_PAGE);
+break;
+case SID_SW_ONLINEOPTIONS:
+ActivatePage(RID_SW_TP_HTML_CONTENT_OPT);
+break;
+case SID_SC_EDITOPTIONS:
+ActivatePage(SID_SC_TP_LAYOUT);
+break;
+case SID_SD_EDITOPTIONS:
+ActivatePage(SID_SI_TP_MISC);
+break;
+case SID_SD_GRAPHIC_OPTIONS:
+ActivatePage(SID_SD_TP_MISC);
+break;
+case SID_SM_EDITOPTIONS:
+ActivatePage(SID_SM_TP_PRINTOPTIONS);
+break;
+case SID_SCH_EDITOPTIONS:
+ActivatePage(RID_OPTPAGE_CHART_DEFCOLORS);
+break;
+case SID_SB_STARBASEOPTIONS:
+ActivatePage(SID_SB_CONNECTIONPOOLING);
+break;
+case SID_FILTER_DLG:
+ActivatePage(RID_SFXPAGE_SAVE);
+break;
+default:
+SAL_WARN("cui", "Unrecognized options category " << pGroupInfo->m_nDialogId);
+break;
+}
+
+return 0;
+}
+
 TabPage* pOldPage = NULL;
 TabPage* pNewPage = NULL;
 OptionsPageInfo* pOptPageInfo = ( pCurrentPageEntry && aTreeLB.GetParent( pCurrentPageEntry ) )
-- 
1.7.5.4

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Patch] Remove OOoImprovement

[August Sodora]

Hello,

I realized there were still a few things left over from the testtool
removal so I created the attached patch. There seem to be some
logging-related things left in comphelper and officecfg that are used
all over the place but I'm not 100% sure about them yet. Would
somebody mind reviewing/pushing this? I was forced to upgrade and am
still waiting for my gpg key to be changed.

August Sodora
aug...@gmail.com
(201) 280-8138
From 9a660bb921402e6ef1f70101af7024f2b08529dc Mon Sep 17 00:00:00 2001
From: August Sodora 
Date: Thu, 15 Dec 2011 00:00:07 -0500
Subject: [PATCH 1/2] Remove OOoImprovement

---
 officecfg/Configuration_officecfg.mk   |1 -
 officecfg/qa/cppheader.cxx |1 -
 officecfg/registry/Makefile|1 -
 officecfg/registry/files.mk|1 -
 .../schema/org/openoffice/Office/Logging.xcs   |   27 --
 .../openoffice/Office/OOoImprovement/Settings.xcs  |   98 
 postprocess/packregistry/makefile.mk   |1 -
 scp2/source/ooo/common_brand.scp   |5 -
 8 files changed, 0 insertions(+), 135 deletions(-)
 delete mode 100644 officecfg/registry/schema/org/openoffice/Office/OOoImprovement/Settings.xcs

diff --git a/officecfg/Configuration_officecfg.mk b/officecfg/Configuration_officecfg.mk
index 0b0a8b0..3d7f8d2 100644
--- a/officecfg/Configuration_officecfg.mk
+++ b/officecfg/Configuration_officecfg.mk
@@ -108,7 +108,6 @@ $(eval $(call gb_Configuration_add_schemas,registry,officecfg/registry/schema,\
 	org/openoffice/Office/UI/GlobalSettings.xcs \
 	org/openoffice/Office/UI/WindowContentFactories.xcs \
 	org/openoffice/Office/DataAccess/Drivers.xcs \
-	org/openoffice/Office/OOoImprovement/Settings.xcs \
 	org/openoffice/TypeDetection/Types.xcs \
 	org/openoffice/TypeDetection/Filter.xcs \
 	org/openoffice/TypeDetection/GraphicFilter.xcs \
diff --git a/officecfg/qa/cppheader.cxx b/officecfg/qa/cppheader.cxx
index 12042ca..2dac76d 100644
--- a/officecfg/qa/cppheader.cxx
+++ b/officecfg/qa/cppheader.cxx
@@ -66,7 +66,6 @@
 #include "officecfg/Office/Linguistic.hxx"
 #include "officecfg/Office/Logging.hxx"
 #include "officecfg/Office/Math.hxx"
-#include "officecfg/Office/OOoImprovement/Settings.hxx"
 #include "officecfg/Office/OptionsDialog.hxx"
 #include "officecfg/Office/Paths.hxx"
 #include "officecfg/Office/ProtocolHandler.hxx"
diff --git a/officecfg/registry/Makefile b/officecfg/registry/Makefile
index edb80b0..0810755 100644
--- a/officecfg/registry/Makefile
+++ b/officecfg/registry/Makefile
@@ -52,7 +52,6 @@ endef
 # appears to let % span sub-directories, so that the above rule would produce
 # unexpected results; sorting this way seems to avoid the problem:
 $(eval $(call my_target,Office,DataAccess))
-$(eval $(call my_target,Office,OOoImprovement))
 $(eval $(call my_target,Office,UI))
 $(eval $(call my_target,Office))
 $(eval $(call my_target,TypeDetection))
diff --git a/officecfg/registry/files.mk b/officecfg/registry/files.mk
index f4c72d7..c6cebcf 100644
--- a/officecfg/registry/files.mk
+++ b/officecfg/registry/files.mk
@@ -28,7 +28,6 @@ FILES = \
 Office/Linguistic \
 Office/Logging \
 Office/Math \
-Office/OOoImprovement/Settings \
 Office/OptionsDialog \
 Office/Paths \
 Office/ProtocolHandler \
diff --git a/officecfg/registry/schema/org/openoffice/Office/Logging.xcs b/officecfg/registry/schema/org/openoffice/Office/Logging.xcs
index 2fda9ea..4e8426e 100644
--- a/officecfg/registry/schema/org/openoffice/Office/Logging.xcs
+++ b/officecfg/registry/schema/org/openoffice/Office/Logging.xcs
@@ -79,33 +79,6 @@
 
   
   
-
-  
-		b_michaelsen
-specifies settings for the logging of userinterface events.
-  
-  
-
-  only if this is true, usage tracking is allowed and its options will be shown
-  
-
-false
-  
-  
-
-  directory where the logs will get saved
-  
-
-$(user)/temp/Feedback
-  
-  
-
-  idle time in minutes. If two log event are separated by a longer
-  time, the log will be rotated.
-
-180
-  
-
 
   
 contains the settings for all known loggers in OpenOffice.org.
diff --git a/officecfg/registry/schema/org/openoffice/Office/OOoImprovement/Settings.xcs b/officecfg/registry/schema/org/openoffice/Office/OOoImprovement/Settings.xcs
deleted file mode 100644
index a4339cc..000
--- a/officecfg/registry/schema/org/openoffice/Office/OOoImprovement/Settings.xcs
+++ /dev/null
@@ -1,98 +0,0 @@
-
-http://openoffice.org/2001/registry"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; oor:name="Settings" oor:package="org.openoffice.Office.OOoImprovement" xml:lang="en-US">
-  
-Contains preferences for the OpenOffice.org Improvement Program components.
-  
-  
-  
-
-  
-  

Re: [Libreoffice] [RFC] COMPRESSMODE_FULL

[Thorsten Behrens]

Matteo Casalin wrote:
> set:
>  /binfilter/binfilter/bf_svtools/source/filter.vcl/filter/svt_filter.cxx
>  /core/svtools/source/filter/filter.cxx
>
Both can go.

> check:
>  /core/tools/source/generic/gen.cxx
>  /core/tools/source/generic/color.cxx
>  /core/tools/source/generic/poly.cxx
>
Heh. Hard to tell - that is used for reading our pesky
StarViewMetafiles, I have *no* idea whether we ever wrote those out
with that compression mode. If we take that out, we'd need to catch
the case somewhere in vcl/source/gdi/gdimtf.cxx and generate a very
noisy warning.

>  /binfilter/binfilter/bf_svx/source/xoutdev/svx__xpoly.cxx
> 
Wouldn't touch that - binfilter is destined to die for 4.0

Cheers,

-- Thorsten


pgpWiULhGSsZA.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech. steering call ...

[Thorsten Behrens]

Christian Lohmaier wrote:
> A proposal for such common URL has been
> hub.libreoffice.org/?optional=parameters&like=version&and=distribution
> 
Yep, recall that - wanna work on this, you seem to have spent quite
some thought on it already?

Cheers,

-- Thorsten


pgpWkkRW3kXQG.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech. steering call ...

[Christian Lohmaier]

Hi Thorsten, *,

On Thu, Dec 15, 2011 at 9:30 PM, Thorsten Behrens
 wrote:
> Michael Meeks wrote:
>>
>>       + bugzilla submission assistant - lots of work currently
>>               + pending integration of link in the help menu for 3.5
>> AA:           + get a permanant re-direction link for bug assistent 
>> (Thorsten)
>> AA:           + hack up the Help->File bug menu item
>>
> https://www.libreoffice.org/get-help/bug/ is not what we want?

No - as that is tied to the current site layout/structure.
For links added to LO itself, never-ever-changing (or better: always
working) ones should be used.

A proposal for such common URL has been
hub.libreoffice.org/?optional=parameters&like=version&and=distribution

so hub.libreoffice.org/file-a-bug or something like that is what is wanted here.
That will then redirect to the get-help/bug page, or when the version
is ancient suggests "this version is stone-age, we suggest to try a
newer version instead of wasting time filing a bug when no new
releases are going to be made on that codeline"
or "ah, you're using , have a look at those known bugs/file
bugs regarding  in -bugtracker, all other bugs go
here → get-help/bugs"

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [RFC] COMPRESSMODE_FULL

[Matteo Casalin]

Hi everybody,
   some days ago I stumbled upon vcl Rectangle SvStream >> and << 
operators (gen.cxx). Their implementation handles the case that the 
stream is compressed as COMPRESSMODE_FULL (and can surely be improved). 
For better understanding I opengrok'ed this COMPRESSMODE_FULL and it 
turns out to be used in just 7 [1] files (1 for definition, 2 just set 
it and the remaining 4 use it for selecting I/O implementation).
Regarding I/O implementations, all of them can be improved but I think 
that that of Polygon is also broken. I was planning to clean/fix these, 
but the main question, due to this limited use, is if this feature is 
really used/needed or can be completely removed. Any idea?


Thanks for any hint

Ciao
Matteo

[1]
definition:
 /core/tools/inc/tools/stream.hxx
set:
 /binfilter/binfilter/bf_svtools/source/filter.vcl/filter/svt_filter.cxx
 /core/svtools/source/filter/filter.cxx
check:
 /core/tools/source/generic/gen.cxx
 /core/tools/source/generic/color.cxx
 /core/tools/source/generic/poly.cxx
 /binfilter/binfilter/bf_svx/source/xoutdev/svx__xpoly.cxx

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] libicudata ICU data info

[Eike Rathke]

Hi Mike,

On Wednesday, 2011-12-14 07:48:49 -0800, Mike Whiteley wrote:

> The current libicudata is about 15MB, but it doesn't need
> to be that large.  We can probably get it down to 5MB
> or less. I took a bit of time on this.
> 
> 1) The configuration files needed to modify what is actually
> in icudata are NOT included in the package in libreoffice's repository.
> A real "source" package can be downloaded, which is what we'll
> need to do if we want to customize this library.

There's an easier way by using the ICU data library customizer available
at http://apps.icu-project.org/datacustom/


> 2) The bulk of the data in (our non-source package) icudata
> comes from an input file ./source/data/in/icudt44l.dat.  This
> file can be removed which causes the resulting icudata library to
> go from 15MB to 4.4MB.

The configurable data lib is 13945 KB in size. We can't remove that in
its entirety. We need at least, numbers taken from ICU 4.4
http://apps.icu-project.org/datacustom/ICUData44.html
* Break Iterator (534 KB)
* Collators (4830 KB)
* Transliterators (308 KB)

From "Miscellaneous Data (4282 KB)" we'd only need parts of.

Quite safe to remove are currently
* Charset Mapping Tables (3469 KB)
* Rule Based Number Format (275 KB)
* Formatting, Display Names and Other Localized Data (572 KB)

The resulting lib would be 10197 KB (including miscellaneous)
respectively 5916 KB (miscellaneous removed). So we could gain between
~4MB and ~8MB. Given that only systems where ICU doesn't already exist
(Windows and?) would benefit from this it's surely a benevolent task for
some merciful soul ;-)


> HELP:  We should try this solution first.  Will someone please
> who knows more about icudata see if a library build this way
> is enough for what libreoffice needs?

The only way to be sure is to exchange the library in the build
environment, build, run and test.


> 3) There are two icudata packages in my repository.  Probably
> one of them can be deleted (also, these are not pure source
> packages anyways).

Which repository? If the external sources tarballs downloaded during
build, then one probably can be removed, at least LibO 3.4 and later use
ICU 4.4.2, if built internally at all.


> 5) Keep in mind my knowledge of icudata is still very limited,
> and this information is only from me reading their web pages for
> 20 min, and me messing with code for another 20 minutes.

With good results :-)

> Anyways, I just thought this would be helpful.

Sure, thanks. Would be nice if you could try out stripped-down versions
of the library and report back the results.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpg1mv5lzS2K.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Cor Nouws  changed:

   What|Removed |Added

 Depends on||43869

--- Comment #55 from Cor Nouws  2011-12-15 14:36:34 PST ---
propose Bug 43869 - Paste special from Calc to Writer, causes last paragraph to
be removed

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Cor Nouws  changed:

   What|Removed |Added

 Depends on||43480

--- Comment #54 from Cor Nouws  2011-12-15 14:34:25 PST ---
proposing Bug 43480 - EDITING: cell text *contents* from Calc pasted to Writer
is pasted at bottom of document, unless paste special is used

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Cor Nouws  changed:

   What|Removed |Added

 Depends on||43532

--- Comment #53 from Cor Nouws  2011-12-15 14:15:07 PST ---
propose Bug 43532 - Renaming and deleting of inserted template categories
broken, inserted templates land in wrong category (indexing issue in code)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Cor Nouws  changed:

   What|Removed |Added

 Depends on||43824

--- Comment #52 from Cor Nouws  2011-12-15 14:13:14 UTC ---
propose Bug 43824 - Crash when starting to enter cell contents with a single
quote for the second time

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Cor Nouws  changed:

   What|Removed |Added

 Depends on||43458

--- Comment #51 from Cor Nouws  2011-12-15 14:12:27 UTC ---
propose Bug 43458 - LibreOffice does not start with a second monitor connected

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=35673

Cor Nouws  changed:

   What|Removed |Added

 Depends on||43867

--- Comment #238 from Cor Nouws  2011-12-15 14:09:11 UTC ---
Propose Bug 43867 - MAILMERGE: Mail Merge with image in header of document,
causes crash

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Cor Nouws  changed:

   What|Removed |Added

 Depends on||43867

--- Comment #50 from Cor Nouws  2011-12-15 14:08:46 PST ---
Propose Bug 43867 - MAILMERGE: Mail Merge with image in header of document,
causes crash

-- 
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] gbuild'ified salhelper

[Michael Stahl]

On 15/12/11 12:24, Stephan Bergmann wrote:
> 
>  
> converts salhelper to gbuild directly on master (rather than on 
> feature/gbuild branch, should help us find out faster if it breaks on 
> some platform).  Technically its the earliest feature/gbuild-changeset 
> cherry-picked, plus additional modifications to keep salhelper backwards 
> compatible.  See the commit message for details.
> 
> I tried this on Linux and Mac OS X, and I *think* it should not break 
> anything on Windows (fingers crossed).  At least on Mac, the resulting 
> salhelper library is substantially larger than the old dmake-based one, 
> I'm investigating that.
> 
> Björn, Michael, some of those changes are rather bad hacks, maybe one of 
> you can add some gbuild magic to improve them to something acceptable.

done, see newly added gb_Library_set_soversion_script

http://cgit.freedesktop.org/libreoffice/core/commit/?id=039cdb19e69b59b95609025c2d23cdb84f5c73c0

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f3b7bfcef472ed31b341c008793d96ed2bafae4b

i'm currently wondering why the mac os tinderbox does not like the gcc3
version script...

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] What do we want from extensions module?

[Matúš Kukan]

Hi Peter,

I think your e-mail did not make it to the list, so re-sending without patch.

> On Wed, 14 Dec 2011, Michael Stahl wrote:
>
>> On 14/12/11 12:34, Mat?? Kukan wrote:
>> > Hi,
>> >
>> > I'm going to have a look at converting extensions to gbuild.
>>
>> i have dug out my incomplete patches this afternoon and made them
>> actually build, which took longer than expected :)
>>
>> result of that is in feature/gbuild_extensions branch; ~6 libraries
>> already converted.
>>
>> (i think doing this on a branch is a good idea because there is a lot of
>> platform specific stuff in there and i remember how the desktop
>> conversion went...)
>>
>
> I've actually already converted extensions to gbuild. I'm attaching my
> current patch which should be essentially complete, however it probably
> won't build on mac.
>
> Thanks,
>
> Peter
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

--- Comment #49 from Regina Henschel  2011-12-15 
13:15:22 PST ---
Nominate Bug 43837 - Impress crashes on custom animation of presentation
objects

Please try it out, it is not confirmed yet.

-- 
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] minutes of tech. steering call ...

[Thorsten Behrens]

Michael Meeks wrote:
>   + cleanup old test build server directories (Thorsten)
>
This is done - there were beta0 builds from the Linux/Windows
Release config still around, but since beta0 was not so nice anyway
... ;)

>   + 3.4.5 - tag delayed by two days
>   + builds already on pre-release ftp site,
> synching to mirrors for announce soon,
> delay not that large in the end.
>
Might take a day longer, system is still syncing 3.5

>   + bugzilla submission assistant - lots of work currently
>   + pending integration of link in the help menu for 3.5
> AA:   + get a permanant re-direction link for bug assistent (Thorsten)
> AA:   + hack up the Help->File bug menu item
> 
https://www.libreoffice.org/get-help/bug/ is not what we want?

Cheers,

-- Thorsten


pgpuoUs8DiFCZ.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Bug 37361 depends on bug 43831, which changed state.

Bug 43831 Summary: Advanced FILTER incompatible with 3.4.4 documents
https://bugs.freedesktop.org/show_bug.cgi?id=43831

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|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] minutes of tech. steering call ...

[Norbert Thiebaud]

On Thu, Dec 15, 2011 at 1:46 PM, Christian Lohmaier
 wrote:
> Hi *,
>
> On Thu, Dec 15, 2011 at 6:40 PM, Michael Meeks  wrote:
>> QA awesome git bibi fun (Bjoern)
>> [...]
>>        + Norbert to investigate it working on Mac, will it bloat up
>>                + have to copy images, not DMGs
>
> DMGs are the images (disk images, similar to a iso, i.e. an
> in-file filesystem) - so one has to use the extracted version / the
> version before it gets packed. 
> Smoketests already creates such a flat tree, but it is also easy to
> mount the image and copy the files from the mounted image.
> (Installation on Mac works by simply copying the files from the dmg to
> any folder on your harddisk)

yes that is what I meant during the call... we may get better git
compression by using the content of the mounted dmg rather than
committing the dmg itself (*)...
but then... number will talk ultimately... I'll experiment with both
and compare :-)

Norbert

(*) git should have a easier time to find redundancies across build that way.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech. steering call ...

[Christian Lohmaier]

Hi *,

On Thu, Dec 15, 2011 at 6:40 PM, Michael Meeks  wrote:
> QA awesome git bibi fun (Bjoern)
> [...]
>        + Norbert to investigate it working on Mac, will it bloat up
>                + have to copy images, not DMGs

DMGs are the images (disk images, similar to a iso, i.e. an
in-file filesystem) - so one has to use the extracted version / the
version before it gets packed. 
Smoketests already creates such a flat tree, but it is also easy to
mount the image and copy the files from the mounted image.
(Installation on Mac works by simply copying the files from the dmg to
any folder on your harddisk)

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] Fix for fdo43460 Part X getLength() to isEmpty()

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please find attached a partial fix for Easy Hack FDO43460

Part X
Module
cppu
cppuhelper
cpputools
- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO6kwGAAoJEJp3R7nH3vLx3iEH/RbmYWDFir8eFwucl/tAoMFE
dy00/adJQeE6Fhn4JfUtYiG4VTl4uLwBHN0MhoAcaxIXQ/Zr4vwMqWGCVYbxqLS4
0xlApf+yWZqx87NKAkpKvELkP4v37jJFtX0i81xFQCUtyaHM2tA7pWJjnHIW1kVK
sL+UxoOFNFdxfn5g6fJkd89cPKMUGRwPfPGEe0IzGyqmiQr8eF8q6u/6aBr0z25L
BMVcESBOI31HXI6mLWKNylvB4y5nAkZjpapWuQdMyo57+wgfrjj7QNEIdNGuDcXQ
eJjrWq6+WhXGTsbuvXHyx9ffXuSK7Ml9hS4a7YW2nhm60sZ+TQRtp+PmBLaFHWE=
=vOfW
-END PGP SIGNATURE-
>From 336a40c2fa4dbac7160722e82f97ed481f42a67b Mon Sep 17 00:00:00 2001
From: Olivier Hallot 
Date: Thu, 15 Dec 2011 17:29:53 -0200
Subject: [PATCH] Fix for fdo43460 Part X getLength() to isEmpty()

Part X
Module
cppu
cppuhelper
cpputools
---
 cppu/source/uno/EnvStack.cxx   |2 +-
 cppu/source/uno/lbenv.cxx  |4 ++--
 cppu/source/uno/lbmap.cxx  |6 +++---
 cppuhelper/source/bootstrap.cxx|8 
 cppuhelper/source/component_context.cxx|2 +-
 cppuhelper/source/factory.cxx  |2 +-
 cppuhelper/source/propertysetmixin.cxx |2 +-
 cppuhelper/source/propshlp.cxx |8 
 cppuhelper/source/servicefactory.cxx   |   14 +++---
 cppuhelper/source/shlib.cxx|4 ++--
 .../source/registercomponent/registercomponent.cxx |   16 
 cpputools/source/regsingleton/regsingleton.cxx |2 +-
 cpputools/source/unoexe/unoexe.cxx |   18 +-
 13 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/cppu/source/uno/EnvStack.cxx b/cppu/source/uno/EnvStack.cxx
index d1ff292..9542440 100644
--- a/cppu/source/uno/EnvStack.cxx
+++ b/cppu/source/uno/EnvStack.cxx
@@ -203,7 +203,7 @@ static int s_getNextEnv(uno_Environment ** ppEnv, uno_Environment * pCurrEnv, un
 res = 1;
 }
 
-if (nextPurpose.getLength())
+if (!nextPurpose.isEmpty())
 {
 rtl::OUString next_envDcp(s_uno_envDcp);
 next_envDcp += nextPurpose;
diff --git a/cppu/source/uno/lbenv.cxx b/cppu/source/uno/lbenv.cxx
index 08e7035..ba3465c 100644
--- a/cppu/source/uno/lbenv.cxx
+++ b/cppu/source/uno/lbenv.cxx
@@ -1031,7 +1031,7 @@ inline void EnvironmentsData::getRegisteredEnvironments(
   iPos != aName2EnvMap.end(); ++iPos )
 {
 uno_Environment * pWeak = iPos->second;
-if (!rEnvDcp.getLength() ||
+if (rEnvDcp.isEmpty() ||
 rEnvDcp.equals( pWeak->pTypeName ))
 {
 ppFound[nSize] = 0;
@@ -1116,7 +1116,7 @@ static uno_Environment * initDefaultEnvironment(
 that->releaseInterface = unoenv_releaseInterface;
 
 OUString envPurpose = cppu::EnvDcp::getPurpose(rEnvDcp);
-if (envPurpose.getLength())
+if (!envPurpose.isEmpty())
 {
 rtl::OUString libStem = envPurpose.copy(envPurpose.lastIndexOf(':') + 1);
 libStem += rtl::OUString( RTL_CONSTASCII_USTRINGPARAM("_uno_uno") );
diff --git a/cppu/source/uno/lbmap.cxx b/cppu/source/uno/lbmap.cxx
index ec56c05..84e2cc7 100644
--- a/cppu/source/uno/lbmap.cxx
+++ b/cppu/source/uno/lbmap.cxx
@@ -312,7 +312,7 @@ static inline OUString getBridgeName(
 SAL_THROW( () )
 {
 OUStringBuffer aBridgeName( 16 );
-if (rAddPurpose.getLength())
+if (!rAddPurpose.isEmpty())
 {
 aBridgeName.append( rAddPurpose );
 aBridgeName.append( (sal_Unicode)'_' );
@@ -469,7 +469,7 @@ static Mapping getMediateMapping(
 }
 
 // connect to uno
-if (rAddPurpose.getLength()) // insert purpose mapping between new ano_uno <-> uno
+if (!rAddPurpose.isEmpty()) // insert purpose mapping between new ano_uno <-> uno
 {
 // create anonymous uno env
 Environment aAnUno;
@@ -540,7 +540,7 @@ void SAL_CALL uno_getMapping(
 }
 
 // See if an identity mapping does fit.
-if (!aRet.is() && pFrom == pTo && !aAddPurpose.getLength())
+if (!aRet.is() && pFrom == pTo && aAddPurpose.isEmpty())
 aRet = createIdentityMapping(pFrom);
 
 if (!aRet.is())
diff --git a/cppuhelper/source/bootstrap.cxx b/cppuhelper/source/bootstrap.cxx
index 399af07..2fb8ccd 100644
--- a/cppuhelper/source/bootstrap.cxx
+++ b/cppuhelper/source/bootstrap.cxx
@@ -81,13 +81,13 @@ namespace cppu
 OUString const & get_this_libpath()
 {
 static OUString s_path;
-if (0 == s_path.getLength())
+if (s_path.isEmpty())
 {
 OUString path;
 Module::getUrlFromAddress( reinterpret_cast(get_this_libpath), path );
 path 

[Libreoffice] License statement: Gustavo Buzzatti Pacheco

[Gustavo Pacheco]

All my contributions to LibreOffice are licensed under the MPL/LGPLv3+
dual license.

Gustavo Buzzatti Pacheco.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Candidate patch for integration?

[Michael Meeks]

Hi Muthu,

On Thu, 2011-12-15 at 17:03 +0530, Muthu Subramanian K wrote:
> I had written this patch quite some time back:
> https://issues.apache.org/ooo/attachment.cgi?id=68593&action=diff
> Related to
> https://bugs.freedesktop.org/show_bug.cgi?id=33602
> I assumed this was in go-oo.org and also made it to libreoffice, but I
> guess I was wrong.

Looks rather non-controversial to me; IIRC we're storing similar stuff
for the CSV import in the settings. I'd be happy to have it in
libreoffice-3-5 if you can get another couple of 'acks' but the sooner
the better if it goes in there :-)

HTH,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] postgresql bits in minutes of tech. steering call

[Michael Meeks]

On Thu, 2011-12-15 at 19:11 +0100, Lionel Elie Mamane wrote:
> On this, someone said on the talk "we use only libc" (and I implicitly
> understood: in the binaries we distribute).

You have to be quite careful with claims from Fridrich, they are often
exaggerated for comic effect :-)

Sorry for fluffing the system up though,

ATB,

Michael.


-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] unit-test dependencies (Re: Tests on release build)

[Michael Meeks]

Hi there,

On Thu, 2011-12-15 at 18:01 +0100, Michael Stahl wrote:
> well that of course would be the case if the dependencies in the test
> makefile were complete.  which they apparently are not.  which is in no
> way obvious.  which is my point.

Hah :-) so - one thing that I wondered about ... is - is it possible
that our gnumake dependencies on .component files do not include
dependencies to the libraries they are for ? such that we can build and
install the .component file - without having the library already
installed alongside it ? that would seem to be suggested by the need to
add this explicit dep on the hwp library in the .mk file - which can't
scale across modules. Do we need to have that added to
gb_Library_set_componentfile ? [1]

Another thing that interests me is whether there could be a race
between the workdir and solver instances of various things; presumably
we depend on the solver versions though.

Wrt. the non-uno pieces I took a look at the ucb/ucp d.lst and it
certainly installs the dll/.so stuff before the .component files in the
list - which look hopeful on that account (same for configmgr).

> > Seemingly tail_build depends on fpicker which depends on ucb - so the
> > ucb1, ucbfile1 components should be in-place.
> 
> and i have already wasted half an hour looking at the libraries the darn
> thing loads and couldn't find anything obvious that was missing...

Right :-) I had a go too - nothing too obvious for the specific hwp
case; annoying really.

HTH,

Michael.

[1] - I'm just a gnumake newbie of course :-)
-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||43862

--- Comment #48 from Rainer Bielefeld  
2011-12-15 10:12:31 PST ---
Nominate "Bug 43862 - Page FORMATTING: Margin settings information not
compatible with 3.4.4", breaking version interoperability is a potential
blocker.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] postgresql bits in minutes of tech. steering call

[Lionel Elie Mamane]

On Thu, Dec 15, 2011 at 05:40:27PM +, Michael Meeks wrote:

> * postgresql bits
> AA:   + checking pg baseline on windows (Fridrich)

I had understood this as: "Check Kerberos/GSSAPI on our GNU/Linux
baseline, to see if we can use it as a system library". So nothing on
Windows.

On this, someone said on the talk "we use only libc" (and I implicitly
understood: in the binaries we distribute). This made me feel rather
bad for proposing adding MIT Kerberos to that list, but I found that a
rather suspicious claim, since to my knowledge we do not internalise
any of GDK, GTK, QT,/std gstreamer, gconf, fontconfig or freetype, so
I checked, from our .deb packages for 3.4.4 for 64 bits (amd64
architecture).

soffice.bin uses also X11 stuff (OK, I'll let that one slide as "as
low-level as libc as far as an X11 program is concerned...") and
libfreetype. The various .so files use a non-trivial list, among which
for example libgpg-error, libgtk-x11-2.0, libjpeg, libqt-mt, libpcre,
libgnomevfs-2, ...

So maybe I misunderstood what was being said?

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] minutes of tech. steering call ...

[Michael Meeks]

* Present:
+ Rainer, Michael Stahl, Christian, Norbert, Cor Nouws,
  Bjoern, Lionel, Stephan, Eike, Kendy, Caolan, Cedric,
  Petr, Lubos

* Completed Action Items
+ create 'lightproof' git repo on freedesktop for Laszlo (Michael)
+ review pending labels patch if possible (Bjoern)
+ cherry-pick lightproof to Beta2 (post Beta1) (Andras)
+ disable gtk3 except in experimental mode (Michael)
+ add this layout feature into a product build (Cedric)
+ make it dependent on a getenv() to avoid callcatcher
+ need to download & install libpostgresql for Mac/Windows (Fridrich)
+ enable Java 7 in 3.4.5, suck and see in RC1 (Stephan)
+ add fixing bugassistant to top #10 easy tasks page (Petr)

* Pending Action Items
+ [slow progress] extract 64bit build hardware from firewall (Kendy / 
Admins)
+ [in progress] come up with a list of QA heros (Rainer)
+ add tinderbox name to build-id (Norbert)
+ cleanup old test build server directories (Thorsten)
+ setup linux build system to build gtk3 support by default for this 
(Michael)
+ rename VCL API to make it GetBeamerFoo & fix (Michael)
+ get Rainer setup with git commit access (Michael)
+ forward access details to Thorsten (Rainer)

* Action Items

* Sexy new type-safe & small printf / format logic (Lubos)
AA: + make it clear the SAL_INFO etc. macros are internal only for 3.5 
(Stephan)
+ delay changes strings until LibO 4 ? (Stephan)
+ not necessarily the printf format; faster without it (Lubos)
+ just fixing the '+' operator can help too (Lubos)
+ consensus for inclusion of printf style in master if Lubos wants to 
do it

* Release Engineering update (Petr)
+ 3.5.0 B1 is out
+ first feedback from pre-release: good.
+ much better than Beta 0 / a promising start
+ thanks to all that helped
+ 3.5.0 B2
+ tag / deadline on Monday
+ 3.4.5 - tag delayed by two days
+ builds already on pre-release ftp site,
  synching to mirrors for announce soon,
  delay not that large in the end.
+ branch libreoffice-3-4-5 for this release
+ most-annoying bugs important for release

* QA - bug hunting sessions (Cor)
+ not easy to get lots of people involved
+ bug hunting planned for Wed 28 / Thur 29th of December
+ another one planned for RC1 Jan Fri 20th / Sat 21th of Jan
+ promotion on TDF blog / twitter etc.
+ litmus and random testing

* QA update (Rainer)
+ spreadsheet advanced filters problems, cf. mail on list
+ regressions discussions
+ component_getFactory issue is dominant (Caolan)
+ presenter console, language crash on popups, etc.
+ re-asses with fixes in master
+ planning to publish document
+ please track that query ...
+ http://tinyurl.com/7z9ozoc
+ bug hunting sessions on IRC - joining in with Cor
+ bugzilla submission assistant - lots of work currently
+ pending integration of link in the help menu for 3.5
AA: + get a permanant re-direction link for bug assistent (Thorsten)
AA: + hack up the Help->File bug menu item

QA awesome git bibi fun (Bjoern)
+ lots of binaries compressed into one git repo
+ allows bisection to find when it first appeared
+ 50+ installs into ~750Mb
+ built every 64th commit on master - 50% succeeded
+ having bisected - only a ~200 commit range
+ maybe visible from the git log
+ is it a universal install (Kendy)
+ built on a recent Ubuntu, but with internal libs (Bjoern)
+ tinderbox integration might be good
+ is there a script to add a package to git ? (Norbert)
+ script is in dev-tools (Bjoern)
+ could automate a once-per-day git repo creation
+ some of the magic is in the re-pack 4Gb -> 750Mb.
+ Norbert to investigate it working on Mac, will it bloat up
+ have to copy images, not DMGs

* Mitch / MSI building update (sends his regrets)

* cairo / Fedora 16 etc. version nasty (Michael)
+ prolly specific to some (non-default) theme
AA: + upgrade the internal cairo to latest stable to fix (Fridrich)
+ could we break things vs. an old system cairo (Petr)

* postgresql bits
AA: + add postgresql to 3.5 feature page (Lionel)
AA: + checking pg baseline on windows (Fridrich)

* Robust subsequenttests to a third category: tail_build tests (Michael/Stephan)
+ discuss next time:

* Next time:
+ skip 22nd and 29th TSC calls unless an emergency strikes
 

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

Em 15-12-2011 13:22, Pedro escreveu:

(snip useless references)

> 
> In any case the picture is not particularly helpful or useful.  The problem
> is: what do you replace it with?
> 

A big question mark ?, a traffic danger sign (yellow triangle with an
exclamation mark)?, a ripped sheet of paper? a broken glass of water?

> You can't use what would be more helpful (a plain image with text saying
> "Image not found") because that would require to have an image in every
> language supported by LO, which IMO is a waste of time and resources.
> 
> Can't this image be replaced by a Text message in the GUI language?

good as well.

Fact is: the icon is used and should not be removed, but can be enhanced.

Kind Regards and seasons greetings.
- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO6ijKAAoJEJp3R7nH3vLxQZMH/iPPWz355mrYw7z7ArTZM30r
tYxOSzaVbLCYrB6TYcrble7cE1Sysd+g8P1lGRGU++bbRXtxzZkU3oZIHERwicqh
KumBOoDJrdpzx4Gpd8tEXv14rv6/cNQeZ7yh5nR9LvANYU2JyODjdVVKLd9Pu2CY
fbMqqr+yrOX2zmr/8FLZIL7q0CPsoDj4IoroCDE5zMOoKhNrVCWjKAfDFHft6iE6
14Nc+rC2ClXFpoqyqWOqBYA2V1FtvKzwPZd2wmpKhImcogczdBpgLzT1Mtz1F0aH
5vpY9CCqy6LpxzUbOV6X/UYdRzIHBisht7Q4VT+CJpvemQgryyYsXoD9u2ueaP0=
=hzRk
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] unit-test dependencies (Re: Tests on release build)

[Michael Stahl]

On 15/12/11 17:37, Michael Meeks wrote:
> On Thu, 2011-12-15 at 13:18 +, Caolán McNamara wrote:
>> On Thu, 2011-12-15 at 13:56 +0100, Michael Stahl wrote:
>>> we wouldn't have this problem if these were subsequenttests
>>
>> but then no one would run them :-), I still feel its far better to try
>> and track down and fix the dependency or parallel test problem, whatever
>> it is, then move things into a subsequenttest because if the immediacy
>> of "make" to "pass/failure" isn't there I just have no faith that people
>> as lazy as me will run them :-(
> 
>   I tend to agree. If we have obscure crashers for our unit tests during
> make - then we should fix them :-)
> 
>   Oddly hwpfilter (two of the three reports) is included into tail_build,
> and thus it's prj/build.lst dependencies are irrelevant, it should be in
> the new, pristine world of gnumake-ness. Which makes this distinctly
> odd. Those files should not be moving around after creation - surely ?
> and make is all a single process, so it'll wait until the file creation
> rule is complete before relying on it rather than statting and finding a
> 1/2 done file.

well that of course would be the case if the dependencies in the test
makefile were complete.  which they apparently are not.  which is in no
way obvious.  which is my point.

>   Seemingly tail_build depends on fpicker which depends on ucb - so the
> ucb1, ucbfile1 components should be in-place.

and i have already wasted half an hour looking at the libraries the darn
thing loads and couldn't find anything obvious that was missing...

>   Like Michael S, I too have seen this intermittently fail too - which is
> deadly annoying.
> 
>   I guess we could add a '--disable-unit-tests' configure option for
> Gentoo-ers.


hmm, presumably Gentooers don't care that much whether the stuff they
build actually works as long as it's fast :-P


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Mozldap switch

[Lionel Elie Mamane]

On Thu, Dec 15, 2011 at 02:19:50PM +0100, Tomáš Chvátal wrote:
> Dne 15. prosince 2011 14:13 Lionel Elie Mamane  napsal(a):
>> On Tue, Dec 13, 2011 at 10:40:25AM +0100, Tomáš Chvátal wrog    te:

>>> I tried to implement simple mozldap system switch to update from the
>>> older-than-sun bundled firefox [1].

>> You seem to remove support for OpenLDAP; any reason for that?

> Yep, because even if that thing did build with openldap backend I was
> unable to make it work. It is also not working in SUSE so I just
> expected it to be uttery broken and rather drop it completely.

The Debian packages are built against OpenLDAP. I guess that if it
were utterly broken (in 3.4), some Debian user would have noticed? I'd
be glad to explicitly check it out if you give me a LibO/LDAP-noob
proof test script.

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Bug 37361 depends on bug 43707, which changed state.

Bug 43707 Summary: FILEOPEN PDF brings up (ASCII) filter selector instead of 
opening document
https://bugs.freedesktop.org/show_bug.cgi?id=43707

   What|Old Value   |New Value

 Resolution||FIXED
 Status|NEW |RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] unit-test dependencies (Re: Tests on release build)

[Michael Meeks]

On Thu, 2011-12-15 at 13:18 +, Caolán McNamara wrote:
> On Thu, 2011-12-15 at 13:56 +0100, Michael Stahl wrote:
> > we wouldn't have this problem if these were subsequenttests
> 
> but then no one would run them :-), I still feel its far better to try
> and track down and fix the dependency or parallel test problem, whatever
> it is, then move things into a subsequenttest because if the immediacy
> of "make" to "pass/failure" isn't there I just have no faith that people
> as lazy as me will run them :-(

I tend to agree. If we have obscure crashers for our unit tests during
make - then we should fix them :-)

Oddly hwpfilter (two of the three reports) is included into tail_build,
and thus it's prj/build.lst dependencies are irrelevant, it should be in
the new, pristine world of gnumake-ness. Which makes this distinctly
odd. Those files should not be moving around after creation - surely ?
and make is all a single process, so it'll wait until the file creation
rule is complete before relying on it rather than statting and finding a
1/2 done file.

Seemingly tail_build depends on fpicker which depends on ucb - so the
ucb1, ucbfile1 components should be in-place.

Like Michael S, I too have seen this intermittently fail too - which is
deadly annoying.

I guess we could add a '--disable-unit-tests' configure option for
Gentoo-ers.

Odd,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Make gbuild output [build CXX] filename also with the .cxx extension

[Lubos Lunak]

On Wednesday 14 of December 2011, Bjoern Michaelsen wrote:
> Hi Lubos,
>
> On Wed, Dec 14, 2011 at 04:45:29PM +0100, Lubos Lunak wrote:
> >  I find it mildly annoying that gbuild outputs "[ build CXX ]
> > starmath/source/types", without the .cxx extension, i.e. a non-existent
> > file. Especially since other target types like LNK do output "[ build LNK
> > ] Library/libsmlo.so". Any objections to the attached patch?
>
> Just some pedantic academics: If anything, the target you are building (and
> announcing) is foo.o, not foo.cxx. But I wont waste more keypresses on
> this, if you insist to make that on .cxx.

 It appears to be the common practice with other build systems (dmake, cmake) 
in non-verbose mode to print the .cxx source file name when compiling and .so 
file name when linking, as those are the ones that matter in that process.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] Use -gdwarf-4 by default if possible (was Re: Even more debugging info)

[Lubos Lunak]

On Thursday 08 of December 2011, Lubos Lunak wrote:
> On Wednesday 07 of December 2011, Michael Meeks wrote:
> > On Thu, 2011-12-01 at 17:35 +0100, Lubos Lunak wrote:
> > > >  So -gdwarf-4 looks like a sensible default to me. Even if not, I'm
> > > > going to use it (quick hack: modify your LO make script to add it to
> > > > $CXXFLAGS).
> > >
> > >  So, how about the attached patch? If it's ok, I will still wait until
> > > 3.5 has been branched off, just in case. I also have no idea if this
> > > should be enabled for the WNT_INTEL_GCC target too, but it and unxgcc
> > > were the only two to use -ggdbX flags.
> >
> > Sounds lovely to me :-) if it makes building with symbols smaller and
> > faster it sounds ideal.
>
>  Pushed, now that 3.5 has been branched. If there are any problems with
> this, yell.

 Just for the record, I've reverted this.

 Reportedly even gdb 7.1 is not new enough for this, and moreover while this 
in theory is supposed to make gdb faster and use less memory, in practice the 
handling in gdb seems to have problems that actually make gdb slower and use 
more memory.

 The flag may be still useful for people who want smaller binaries and don't 
use gdb for much more than backtraces, but it's apparently not a good default 
for the time being.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[julien2412]

In the same way, we should remove all the drawing tools too because someone
could use a personal photo and change it to make the person ridiculous...
We should also add some autocorrect to prevent the writing of rude words...

The pb is not the tool, it's what you do with it (think about all these
things you use in everyday life : knives, hammers, a stick of wood, almost
everything could be a weapon...)

Salam/Shalom/peace/pax/paix/... ;-)

--
View this message in context: 
http://nabble.documentfoundation.org/Tell-me-Easy-Hack-42782-remove-a-dog-is-a-joke-tp3587827p3589062.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] Hi ! We are new on libo!

[Martin Richard]

Hi Michael & Fernand !

The preview feature isn't in the scope of what we would like to do for the
moment, but if we've got the occasion, we'll have a look at it. Thank you
for the hint about FTP connections, we'll see what we can do to deal with
this issue.

We looked at this project on Elveos, but Julien and I believe we aren't yet
experienced enough with the codebase to fulfill the mission.

Cheers,
Martin

2011/12/14 Fernand Vanrie 

>  Martin,
>
> I am a "Belgium" user of OO en LO, and have sometimes contact with your
> mentor Cédric.
> As you will working at the "filepicker", please  have also a look at the
> "preview" when choosing pictures it simply never has worked.
> When working at the FTP site, there is also a problem, on some servers it
> works to have a ftp-url to store ad some servers the connection is refused,
> i think we need some extra parameters for FTP connections (as
> passive-active)
>
> I hopes this comments can inspire your project
>
>
> Greetz
>
> Fernand
>
> ps. please have also a look at our Elveos 
> projectit
>  is Funded but no candidates to do the work, maybe you  or one of your
> friends is interested ?
>
> Hi all,
>
> I am Martin Richard, a French student in CS.
>
> As a school project, a friend and I have the luck to be able to work on
> Libre Office Writer, mentored by Cédric Bosdonnat.
>
> We will work on the libre-office file picker in order to add some new
> interesting features, such as a list of highlighted places, allowing direct
> access to recently used files, favorites directories and FTP servers. At
> last, we would like to contribute to Cedric's library libcmis and continue
> his work of integration of repositories implementing CMIS (sharepoint,
> alfresco, etc).
>
> I'll probably be active on IRC under the nickname martius during the next
> weeks.
>
> My friend Julien will probably come forward soon.
>
> Cheers,
> Martin
>
>
> ___
> LibreOffice mailing 
> listLibreOffice@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
>


-- 
Martin  Richard
www.martiusweb.net 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] assertion in SwIndexReg::~SwIndexReg

[Terrence Enger]

On Thu, 2011-12-15 at 08:56 +0100, Stephan Bergmann wrote:
> On 12/15/2011 12:59 AM, Terrence Enger wrote:
> > [snip]
> >
> > How on earh can soffice.bin know that I did anything in
> > gnome-terminal?
> 
> Due to the clipboard being a resource shared across all applications.



  Calm down, Terry.  Stop sputtering.

  This *is* a GUI environment, so you have to expect
  notifications of things to be flying around everywhere,
  even between applications, and even if you do not
  understand why LibreOffice should care about the clipboard
  when it is doing neither a copy nor a paste.  Just accept
  it.

  Nowhere is it written that you will understand everything.




Stephan,

So, I take it, the helpful question to investigate is the
reason why the state of the object violates the
expectation--the expectation that the container is empty--
that the destructor asserts.  Or, coming from the opposite
side of the question, why should the destructor expect the
container to be empty by that time?

With luck, I shall be able to progress a little bit in that
direction before I have to ask for help again.

Thank you for your help.
Terry.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Pedro]

It is quite easy to get the dog image displayed and it shows up in the
Picture dialog replacing the missing image... 

That can be offending in any culture, especially if the image replaced is of
a person and the image replacing it is an offense for your culture (imagine
your picture replaced by a pig or an ass (the animal, obviously :) )

In any case the picture is not particularly helpful or useful.  The problem
is: what do you replace it with?

You can't use what would be more helpful (a plain image with text saying
"Image not found") because that would require to have an image in every
language supported by LO, which IMO is a waste of time and resources.

Can't this image be replaced by a Text message in the GUI language?

Peace! ;)

--
View this message in context: 
http://nabble.documentfoundation.org/Tell-me-Easy-Hack-42782-remove-a-dog-is-a-joke-tp3587827p3588920.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] Simpler logging using a string format function

[Lubos Lunak]

On Thursday 15 of December 2011, Stephan Bergmann wrote:
> On 12/15/2011 02:57 PM, Lubos Lunak wrote:
> >   The "bar"<<  "baz", which, at first glance, is nonsense. Code is not
> > only written, it is also read, and many more times.
>
> Still don't get what you mean.  You mean, "bar" << "baz" should be
> forbidden by the compiler, making sure one writes "barbaz" instead?

 No. I mean that 'foo( "bar" << "baz" )' is incorrect C++, unless foo is a 
macro that does some hidden magic behind the scenes that changes the meaning. 
And not only it's incorrect, it's also not obvious.

 Of course, one can learn this case, and add it to the hundreds of other cases 
that we already have where one either knows it or bumps into it and has to 
start digging around. When was the last time somebody has run e.g. into UNO's 
>>= operator (and that one actually is somewhat more obvious that this)?

> >>>Well, that's another advantage of the format approach then. It's an
> >>> inconvenience to have to explicitly say the format string is utf-8 (and
> >>> arguments probably as well), but then this conversion can be again
> >>> limited just to logging and not to every std::ostream operation.
> >>
> >> Yes, having the message in UTF-16 is an advantage here.  For the
> >> ostream-based approach, we need to wait for general availability of
> >> C++11's char16_t.
> >
> >   They are log messages. They are written in English.
>
> Erm, are we talking past each other here?  The fully composed log
> message, with string arguments placed into it, somehow needs to handle
> the UTF-16 string arguments placed into it.  All I wanted to say is that
> your approach, building up the fully composed message as
> rtl::OUStringBuffer, shields client code from having to specify how to
> translate any rtl::OUString arguments into the proper format.

 I was talking about the strings on the input of the log call. If the syntax 
is SAL_INFO( "area", "File ", file, " not found." ), then "File " and " not 
found." can be converted automatically using utf-8, because it's just a log 
message, so it's very likely only English anyway, and it's a perfectly fine 
way of avoiding the truly horrible SAL_INFO( "area", 
RTL_CONSTASCII_USTRINGPARAM( "File " ), file, RTL_CONSTASCII_USTRINGPARAM( " 
not found." )). At the same time, it does not introduce this automatic 
conversion anywhere else, as the ostream-based operator<< can.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] please pick those two build-related commits for libreoffice-3.5 (XCode 2.5 build breaker & download → use same branch for the clones)

[Christian Lohmaier]

Hi *,

was told that there is no sign-off needed yet for the branch, so
pushed myself :-)

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Simpler logging using a string format function

[Stephan Bergmann]

On 12/15/2011 02:57 PM, Lubos Lunak wrote:

On Thursday 15 of December 2011, Stephan Bergmann wrote:

On 12/13/2011 07:56 PM, Lubos Lunak wrote:

   But it might the moment you realize you're trading away things like

   SAL_INFO( "foo", 1<<   2 ) or SAL_INFO( "foo", "bar"<<   "baz" ).


Trading away the former, having to parenthesize (1<<  2) instead, is a
std C++ trade-off.  Granted, omission of the leading "ostream<<" in the
macro call makes this somewhat non-obvious.  What is traded away in the
latter case?


  The "bar"<<  "baz", which, at first glance, is nonsense. Code is not only
written, it is also read, and many more times.


Still don't get what you mean.  You mean, "bar" << "baz" should be 
forbidden by the compiler, making sure one writes "barbaz" instead?



Anyway, bikeshedding about surface syntax is rather pointless.


  Well, I did say that longer exposure to this codebase makes people oblivious
to bad API, didn't I? This is not bikesheding. This is adding yet one more
case of ugly API to the codebase, and while it's not tragically fugly and
neither are most of the other, it simply all adds up and the result is a
fugly codebase where even adding two strings together is an exercise. And it
will not get better if such stuff will keep getting added because surface
syntax, the thing developers deal with most of the time, is supposedly rather
pointless.


I still think neither approach is more beautiful than the other.  But 
that's subjective, of course.



   Well, that's another advantage of the format approach then. It's an
inconvenience to have to explicitly say the format string is utf-8 (and
arguments probably as well), but then this conversion can be again
limited just to logging and not to every std::ostream operation.


Yes, having the message in UTF-16 is an advantage here.  For the
ostream-based approach, we need to wait for general availability of
C++11's char16_t.


  They are log messages. They are written in English.


Erm, are we talking past each other here?  The fully composed log 
message, with string arguments placed into it, somehow needs to handle 
the UTF-16 string arguments placed into it.  All I wanted to say is that 
your approach, building up the fully composed message as 
rtl::OUStringBuffer, shields client code from having to specify how to 
translate any rtl::OUString arguments into the proper format.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] please pick those two build-related commits for libreoffice-3.5 (XCode 2.5 build breaker & download → use same branch for the clones)

[Christian Lohmaier]

Hi *,

please pick 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a845f988e6b5ec50ddda123cf761d8541c005fa
(change to download, so that when using linked git repos,
git-new-workdir will checkout the same branch as the core repo)
and
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f56780576fa8c28cd212ddfffc554cee40698009
(build fix for Mac OSX 10.4 / XCode 2.5 where -dead_strip_dylibs is
not supported - the makefile in libreoffice-3.5 uses .IF .ELSE
construct instead of $(eq,...), but the idea is the same, just remove
the flag - on Mac there is not much cruft linked to begin with)

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Simpler logging using a string format function

[Lubos Lunak]

On Thursday 15 of December 2011, Stephan Bergmann wrote:
> On 12/13/2011 07:56 PM, Lubos Lunak wrote:
> >   But it might the moment you realize you're trading away things like
> >
> >   SAL_INFO( "foo", 1<<  2 ) or SAL_INFO( "foo", "bar"<<  "baz" ).
>
> Trading away the former, having to parenthesize (1 << 2) instead, is a
> std C++ trade-off.  Granted, omission of the leading "ostream <<" in the
> macro call makes this somewhat non-obvious.  What is traded away in the
> latter case?

 The "bar" << "baz", which, at first glance, is nonsense. Code is not only 
written, it is also read, and many more times.

> Anyway, bikeshedding about surface syntax is rather pointless.

 Well, I did say that longer exposure to this codebase makes people oblivious 
to bad API, didn't I? This is not bikesheding. This is adding yet one more 
case of ugly API to the codebase, and while it's not tragically fugly and 
neither are most of the other, it simply all adds up and the result is a 
fugly codebase where even adding two strings together is an exercise. And it 
will not get better if such stuff will keep getting added because surface 
syntax, the thing developers deal with most of the time, is supposedly rather 
pointless.

> >> - Artificially limited to 9 arguments.  You can sure always extend that,
> >> but it's more work than not having to worry about it.
> >
> >   Hmm. How often is that going to be needed?
>
> With creative uses of SAL_WARN/INFO, I wouldn't be too sure.  ;)  (And
> as I already said, "none of those are critical shortcomings," only
> indicators to me that swapping implementations were not worth it if the
> only benefit were a different syntax.)

 It's not a big deal to add letters too for creative uses and 37 arguments to 
a log call is as implausible to be next to unrealistic.

> >> - No check that there are neither more nor fewer arguments than %Ns (or
> >> that the set of %Ns spans a range 1--M without holes).
> >
> >   There's a todo note, not that I think it matters that much if whoever
> > does that runs the code at least once.
>
> Note that at least SAL_WARNs will typically *not* be run by the code
> authors.  (Who goes to the pains of crafting a scenario to make each new
> SAL_WARN actually trigger, by temporarily modifying the code around it
> or creating an appropriate runtime environment?)

 Hmm, right. Ok, forget the format. I can make it

 SAL_INFO( "foo", "string ", s, " of length ", n )

 and that solves most of your objections I believe, while still keeping most 
of the advantages compared to the ostream approach.

> >   Well, that's another advantage of the format approach then. It's an
> > inconvenience to have to explicitly say the format string is utf-8 (and
> > arguments probably as well), but then this conversion can be again
> > limited just to logging and not to every std::ostream operation.
>
> Yes, having the message in UTF-16 is an advantage here.  For the
> ostream-based approach, we need to wait for general availability of
> C++11's char16_t.

 They are log messages. They are written in English.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Laurent Godard]

Hi all

> I don't know if it's a French ideal, it's just the fact that an image of dog
> should'nt possibly offend anyone.

as a newbye, with ideals too, and most important I'm french, i would
highly prefer that we speak about cats ! a highly cultural matter
concerning Lovecraft lovers

please guys, stop this ...

Laurent
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] postresql-sdbc bits out of minutes of tech. steering call

[Lionel Elie Mamane]

On Mon, Dec 12, 2011 at 10:32:26AM +0100, Lionel Elie Mamane wrote:
> On Mon, Dec 12, 2011 at 09:46:37AM +0100, Fridrich Strba wrote:
>> On 12/12/11 08:14, Lionel Elie Mamane wrote:

>>> This also means that by our "we have to build everything we ship"
>>> rule, we have to internalise, according to my first quick survey:

>>>  - MIT Kerberos:

>>>  - Kerberos for Windows: that's not part of the OS -> internalise
>>>(http://web.mit.edu/kerberos/dist/index.html#kfw-3.2)

>> Do we really really need this on Windows?

> It depends what value we give to "really".

So, I asked on the PostgreSQL devs mailing list. Briefly the answer is
that MIT Kerberos on Windows is bitrotten, unmaintained and a pain in
the backside: open security bugs will likely not be fixed soon,
etc. Other software in the PostgreSQL ecosystem have stopped linking
against it.

As to what feature is lost:

 - On Windows XP, any kind of decent crypto in the context of Kerberos
   authentication.

 - On Windows 7, the system Kerberos is actually quite OK.

So, all in all, we better *not* link against MIT Kerberos on Microsoft
Windows. That is our current situation, no change needed, just for
your information (& vindication).

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Khaled Hosny]

On Thu, Dec 15, 2011 at 05:05:34AM -0800, julien2412 wrote:
> I don't know if it's a French ideal, it's just the fact that an image of dog
> should'nt possibly offend anyone.

True, if you consider only one culture, the fact is that the world is
vastly different and what can't "possibly offend anyone" in one culture
can be highly offensive in another. LO should not dictate that that a
certain culture is superior to others, and if we can remove a possibly
offending item to certain people, what harm can be caused by that?

Regards,
 Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Mozldap switch

[Tomáš Chvátal]

Dne 15. prosince 2011 14:13 Lionel Elie Mamane  napsal(a):
> On Tue, Dec 13, 2011 at 10:40:25AM +0100, Tomáš Chvátal wrog    te:
>
>> I tried to implement simple mozldap system switch to update from the
>> older-than-sun bundled firefox [1].
>
> You seem to remove support for OpenLDAP; any reason for that?
>

Yep, because even if that thing did build with openldap backend I was
unable to make it work. It is also not working in SUSE so I just
expected it to be uttery broken and rather drop it completely.

Tom
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] unit-test dependencies (Re: Tests on release build)

[Caolán McNamara]

On Thu, 2011-12-15 at 13:56 +0100, Michael Stahl wrote:
> we wouldn't have this problem if these were subsequenttests

but then no one would run them :-), I still feel its far better to try
and track down and fix the dependency or parallel test problem, whatever
it is, then move things into a subsequenttest because if the immediacy
of "make" to "pass/failure" isn't there I just have no faith that people
as lazy as me will run them :-(

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [ANN] LibreOffice 3.4.5 RC1 test builds available

[Thorsten Behrens]

Hi *,

for 3.4.5 RC1, we're now uploading builds to a public (but
non-mirrored - so don't spread news too widely!) place, as soon as
they're available. Grab them here:

http://dev-builds.libreoffice.org/pre-releases-3-4/

If you've a bit of time, please give them a try & report *critical*
bugs not yet in bugzilla here, so we can incorporate them into the
release notes. Please note that it takes approximately 24 hours to
populate the mirrors, so that's about the time we have to collect
feedback.

The list of fixed bugs vs. 3.4.4 is available here

 
http://dev-builds.libreoffice.org/pre-releases-3-4/src/bugfixes-libreoffice-3-4-release-3.4.5.1.log

, it would be nice to verify they're really fixed in the build.

Thanks so much for your help,

-- Thorsten


pgp00USbQEg15.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Mozldap switch

[Lionel Elie Mamane]

On Tue, Dec 13, 2011 at 10:40:25AM +0100, Tomáš Chvátal wrogte:

> I tried to implement simple mozldap system switch to update from the
> older-than-sun bundled firefox [1].

You seem to remove support for OpenLDAP; any reason for that?

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[julien2412]

Hi again,

I answered to Mike and Khaled personally, i should have cc the forum too.
Just to sum up what I told them :
first : it's not a personal attack against anyone, all of you guys do a
great job and brought me friendly help when i needed. 
Then : of course the vast majority of muslims, like christians, jews, ...
are moderate. But I would'nt like LO to lose its independance because of a
simple image of dog. (ok the image should be changed to a better one :-) ).
If some want a Hallah/Casher/"Christian OK" LO, I don't care, they can use
automatic scripts to remove what they consider to be offending for them. But
LO original should stay independant.

I know that some of you have struggled really hard to be independant from
Oracle with this fork and it's great, but everyone must struggle harder to
stay independant.

I don't know if it's a French ideal, it's just the fact that an image of dog
should'nt possibly offend anyone.

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/Tell-me-Easy-Hack-42782-remove-a-dog-is-a-joke-tp3587827p3588492.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] unit-test dependencies (Re: Tests on release build)

[Stephan Bergmann]

On 12/15/2011 01:56 PM, Michael Stahl wrote:

we wouldn't have this problem if these were subsequenttests; it would
even be possible to run them when rebuilding a single module with
something like "make build&&  make subsequenttests" (perhaps "make
check" in a module should do that?), just not on the build from scratch.


If the build from scratch were done as "make check" (and who doesn't do 
that, anyway?), they would be included even then.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] unit-test dependencies (Re: Tests on release build)

[Michael Stahl]

On 15/12/11 11:34, Stephan Bergmann wrote:
> On 12/15/2011 10:58 AM, Tomáš Chvátal wrote:
>> So unless you can look at one of those traces and tell me that the
>> build should be stopped because "it is obvious error in the code (not
>> in the test, the app code) that needs to be fixed" I would want you
> 
> Hard to tell without a backtrace.

our new so-called unit tests are not as reliable as i would like:
i have seen this in build from scratch myself, sometimes the hwpfilter
test crashes, and it never happens when building only that module.

i guess the reason is probably that it needs some library loaded via
UNO, and concurrently with the test another process overwrites that
library (have seen exactly that with a test in sw and fixed it), making
the test very unhappy.

the problem i see is that most of our CppUnit test are not really unit
tests but system level tests, and really need most of a full office with
UNO stuff and configuration to run.
figuring out which UNO components are needed to run the test is a real
pain and so of course lots of dependencies are missing.

we wouldn't have this problem if these were subsequenttests; it would
even be possible to run them when rebuilding a single module with
something like "make build && make subsequenttests" (perhaps "make
check" in a module should do that?), just not on the build from scratch.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] symbol visibility, windows, 3-5

[Caolán McNamara]

On Thu, 2011-12-15 at 12:43 +, Caolán McNamara wrote:
> Looking at fdo#43422 and now looking at fdo#43707 I see that for some
> reason we are not exporting component_getFactory symbols under windows
> from some dmake-built uno libs.
> 
> Anyone know when these last worked ?

Alright, tracked down the offending commits.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] gbuild conversion module status

[Matúš Kukan]

On 15 December 2011 13:11, Michael Stahl  wrote:
> http://wiki.documentfoundation.org/Development/Build_System/Module_status
>
> people who have already converted modules in feature branches, please
> add that info to the page!
>
done

thanks,

Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tests on release build

[Tomáš Chvátal]

2011/12/15 Bjoern Michaelsen :
>
> It is (unless I broke it with the last major gbuild -- it should be easy to 
> fix
> then). That said, I really have a bad feeling about letting end users compile
> distro builds without running these tests -- the last thing we need is
> additional bugzilla workload by builds that should never have
> finished/installed.
>
Looks like it is broken then :)

As the crashes are in tail-build so gbuildified and i run this in the package:

458 src_compile() {
459 # this is not a proper make script and the jobs are passed
during configure
460 make build || die
461 }
462 
463 src_test() {
464 make check || die
465 }
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Khaled Hosny]

On Thu, Dec 15, 2011 at 11:58:52AM +, Michael Meeks wrote:
> 
> On Thu, 2011-12-15 at 13:14 +0200, Khaled Hosny wrote:
> > I'm really offended by
> ...
> > This is a software project, if you have some political,
> > cultural or religious agenda, please take it somewhere else.
> 
>   I'm sorry you're offended Khaled; this is (I suspect) a consequence of
> our growth - that we have a diverse and healthy project: so we can now
> start the infighting ! :-)

May be offended was a strong word, it should read "concerned about the
attitude", it is a little hypocritical to ask "others" to respect your
culture while you are showing no respect to theirs, after all
LibreOffice users are not French immigrants who have to either accept
the French "ideals" or return back to their homes.

>   I'm well aware that many people will not like many of the things that I
> stand for, and be offended by some of my opinions :-) personally I'd
> like to hope that I can still air them from time to time, and people
> will put up with me: IMHO having some secularness and blandness
> censorship filter of discourse on IRC will only create other channels
> that people will migrate to.

It is not about personal opinion, everyone is free to say whatever he
likes, but suggesting that it should be a project policy to accept only
culture X values and implying it is inherently superior than culture Y
values is no longer a personal opinion.

Regards,
 Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] symbol visibility, windows, 3-5

[Caolán McNamara]

Looking at fdo#43422 and now looking at fdo#43707 I see that for some
reason we are not exporting component_getFactory symbols under windows
from some dmake-built uno libs.

Anyone know when these last worked ?

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Stefan Knorr (Astron)]

Hi Julien,

if you find the current explanation why the dog should go
unconvincing, let's look at it from a different angle: how does it
fare as a preview image?
I'd say: okay-ish, but it's not great, a more conventional image would
definitely work better. So, even if the bug was started for the wrong
reason (I don't really think it was), there are other justifications
for going through with it.

Also, please note that the vast, vast, vast majority of Muslims aren't
Taliban, I think it should be obvious why such a comment when said in
earnest would be offensive to any Muslim contributor. As Khaled said:
please keep your politics at home, especially if they're so uninformed
by facts.

Astron.

(Arügh... sent that to Khaled only, not to the list at first...)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Bjoern Michaelsen]

Hi,

On Thu, Dec 15, 2011 at 11:58:52AM +, Michael Meeks wrote:
>   I'm well aware that many people will not like many of the things that I
> stand for, and be offended by some of my opinions :-) personally I'd
> like to hope that I can still air them from time to time, and people
> will put up with me: IMHO having some secularness and blandness
> censorship filter of discourse on IRC will only create other channels
> that people will migrate to.

I am having a quite different mindset as Michael on the topic of religion, but
I fully agree here. As for the original topic: Have you actually seen that dog?
Its rather ugly and seems to be used as a placeholder where a dog is indeed
inappropriate regardless of religion.

As for the censorship: Lets keep some wellnatured teasing on IRC, it would not
be fun without it. But lets also try to not offend others intentionally.

Best,

Bjoern

--
"I disapprove of what you say, 
 but I will defend to the death your right to say it."
 -- Evelyn Beatrice Hall
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] gbuild conversion module status

[Michael Stahl]

hi all,

if you consider converting a module to gbuild, please first take a look
at this brand new Wiki page, and add your name to the "remarks" column,
so we don't end up with 3 people doing the same thing:

http://wiki.documentfoundation.org/Development/Build_System/Module_status

people who have already converted modules in feature branches, please
add that info to the page!

thanks,
 michael

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tests on release build

[Bjoern Michaelsen]

On Thu, Dec 15, 2011 at 12:49:41PM +0100, Tomáš Chvátal wrote:
> > IIUC, "make build" will omit the checks (and "make unitcheck" will execute
> > them).
(for gbuildified modules, build.pl modules will still run tests)

> >
> > Stephan
> 
> That would be awesome to see implemented.

It is (unless I broke it with the last major gbuild -- it should be easy to fix
then). That said, I really have a bad feeling about letting end users compile
distro builds without running these tests -- the last thing we need is
additional bugzilla workload by builds that should never have
finished/installed.

Best,

Bjoern
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Michael Meeks]

On Thu, 2011-12-15 at 13:14 +0200, Khaled Hosny wrote:
> I'm really offended by
...
> This is a software project, if you have some political,
> cultural or religious agenda, please take it somewhere else.

I'm sorry you're offended Khaled; this is (I suspect) a consequence of
our growth - that we have a diverse and healthy project: so we can now
start the infighting ! :-)

I'm well aware that many people will not like many of the things that I
stand for, and be offended by some of my opinions :-) personally I'd
like to hope that I can still air them from time to time, and people
will put up with me: IMHO having some secularness and blandness
censorship filter of discourse on IRC will only create other channels
that people will migrate to.

Endless discussion on these topics tends only to divert people from the
hard business of learning about others & trying to understand, love them
(not their opinions), and work together to do something good we all
agree on.

Anyhow - both you and Julien do fantastic work on LibreOffice which I
(for one) value immensely.

All the best,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Bug 37361 depends on bug 43422, which changed state.

Bug 43422 Summary: Spell check: Crash "Runtime Error" with AutoSpellcheck
https://bugs.freedesktop.org/show_bug.cgi?id=43422

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 Resolution||FIXED
 Status|ASSIGNED|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] Tests on release build

[Tomáš Chvátal]

2011/12/15 Stephan Bergmann :
> On 12/15/2011 10:58 AM, Tomáš Chvátal wrote:
>>
>> So unless you can look at one of those traces and tell me that the
>> build should be stopped because "it is obvious error in the code (not
>> in the test, the app code) that needs to be fixed" I would want you
>
>
> Hard to tell without a backtrace.
>
Thats the problem these things do not crash when run in the submodule
attached to gdb.

>
> IIUC, "make build" will omit the checks (and "make unitcheck" will execute
> them).
>
> Stephan

That would be awesome to see implemented.

Tom
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] gbuild'ified salhelper

[Stephan Bergmann]

 
converts salhelper to gbuild directly on master (rather than on 
feature/gbuild branch, should help us find out faster if it breaks on 
some platform).  Technically its the earliest feature/gbuild-changeset 
cherry-picked, plus additional modifications to keep salhelper backwards 
compatible.  See the commit message for details.


I tried this on Linux and Mac OS X, and I *think* it should not break 
anything on Windows (fingers crossed).  At least on Mac, the resulting 
salhelper library is substantially larger than the old dmake-based one, 
I'm investigating that.


Björn, Michael, some of those changes are rather bad hacks, maybe one of 
you can add some gbuild magic to improve them to something acceptable.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] dog jokes ...

[Michael Meeks]

Hi Julien,

On Wed, 2011-12-14 at 23:03 -0800, julien2412 wrote:
> This morning I'm still angry about this tracker.

It is an easy hack :-) it is a somewhat light-hearted one designed to
attract and amuse volunteers - so yes it is partly a joke - but it's not
designed to make you angry. Its also an easy-to-do one. Personally I
rather like dogs too, and find it hard to understand why others would
not - then again, I don't quite get why you're angry - it'd be good to
understand that in more detail.

>  I read it yesterday and spoke my mind on IRC dev channel. I was
> glad I wasn't alone to think this easyhack is nonsense.
...
> I put a quick comment on this tracker but guys, I'd like to know
> your opinion about this even it's not a "dev" subject.

You actively want to stop someone else from replacing an image that
people almost never see (that may cause offence to some of our users),
with another image that people almost never see (that is far less likely
to offend anyone) :-) ?

Other examples of this sort of gut-wrenching problem comes around flags
and/or maps. As soon as you put a map anywhere with borders on it - you
offend someone ;-) this is why airlines flying over Asia tend to have
"no borders" maps[2] on their flights. Does that mean by removing them
we are not backing A.B.C democracy's claim over D.E.F totalitarian
state's claim to G.H.I chunks of strategically important land ? you just
can't win here really. How about flags - do we, or do we not recognise
Taiwan as a nation worthy of a flag: whatever the choice is you get to
offend someone. In these cases, mostly people don't ship flags, or don't
put borders on etc. it's a bit of a lame-ass cop-out, for sure - but it
helps us work together.

Anyhow, the easy-hack is more trivial to fix than to discuss at
length :-) Hopefully this helps convince you that I'm not some sort of
illiberal ogre suggesting an easy easy hack like that ? :-)

ATB,

Michael.

[1] - http://en.wikipedia.org/wiki/Swastika is rather interesting.
[2] - not just sitting on the fence: there is no fence ! :-)
-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] split links, word import issue?

[Cor Nouws]

[ forwarded to qa-list ]

Tomas Hlavaty wrote (15-12-11 12:06)

Hi all,

I created a document xx.odt with a link.  Then I saved the link as
[...]
Anybody seen this issue?


--
 - Cor
 - http://nl.libreoffice.org

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tell me Easy Hack 42782 "remove a dog ! " is a joke !

[Khaled Hosny]

Hi Julien,

On Wed, Dec 14, 2011 at 11:03:15PM -0800, julien2412 wrote:
> Hello,
> 
> This morning I'm still angry about this tracker. I read it yesterday and
> spoke my mind on IRC dev channel. I was glad I wasn't alone to think this
> easyhack is nonsense.
> I put a quick comment on this tracker but guys, I'd like to know your
> opinion about this even it's not a "dev" subject.


Though I can't care less about LibreOffice having a picture of dog or
not, I'm really offended by your Islamophobic remarks, so please save us
this nonsense. This is a software project, if you have some political,
cultural or religious agenda, please take it somewhere else.

Regards,
 Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] split links, word import issue?

[Tomas Hlavaty]

Hi all,

I created a document xx.odt with a link.  Then I saved the link as
xx.doc.  Then opened xx.doc and found that the single original link was
split into several links, each link for one word or space from the
original link label (see xx3.odt).

It looks like the algorithm for word import should collapse text nodes
(ranges) that have the same link attribute.

This issue was already in OpenOffice 3.1.1, same behaviour in
LibreOffice 3.3.2 (split links only sometimes) but LibreOffice 3.4.4
makes this problem really apparent.

Anybody seen this issue?

Thank you,

Tomas



xx.odt
Description: application/vnd.oasis.opendocument.text


xx2.odt
Description: application/vnd.oasis.opendocument.text
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Candidate patch for integration?

[Muthu Subramanian K]

Hi,

I had written this patch quite some time back:
https://issues.apache.org/ooo/attachment.cgi?id=68593&action=diff
Related to
https://bugs.freedesktop.org/show_bug.cgi?id=33602
I assumed this was in go-oo.org and also made it to libreoffice, but I
guess I was wrong.

If the code is fine, shall I push it?

I vaguely remember, Eike had a better idea to manage all the dialog box
preferences - I don't exactly remember the details.

Thanks!
Muthu Subramanian

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Tests on release build

[Stephan Bergmann]

On 12/15/2011 10:58 AM, Tomáš Chvátal wrote:

So unless you can look at one of those traces and tell me that the
build should be stopped because "it is obvious error in the code (not
in the test, the app code) that needs to be fixed" I would want you


Hard to tell without a backtrace.


guys to rethink running the tests for release build during the make
phase and just allow me to run them in designated test phase where it
is allowed to fail and wont stop user from installing the office
suite. (Yes those errors are logged, yes I will provide them, and yes
user will be able to use his office suite and not wait on some test
fixes)


IIUC, "make build" will omit the checks (and "make unitcheck" will 
execute them).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] SDK installation problem was: libreoffice-3.4.99.1 tag created (3.5.0-beta1)

[Petr Mladek]

Andreas Radke píše v St 14. 12. 2011 v 22:48 +0100:
> build is done in a clean chroot each time. shouldn't be a problem. the
> beta0 built fine here.

> the only difference to beta0 is the changed internal libvisio src bump.
> tried autoconf/autoreconf and make -j1 install without luck :(

It is really strange. Tomas have problems to reproduce it as well. It
happened him when he did a clean build. It did not happen when he tried
to reproduce it as root.

Could you please try to run installation twice in the chroot as a normal
user?

Could you please try to do it as root?

Also you might try to pass -log and --debug options to the
make_installer.pl call. Just edit solenv/bin/ooinstall in the ODK/SDK
part. It will produce many logs in instsetoo_native/unxlng??.pro. You
might try to search them for anything interesting.

Best Regards,
Petr


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Tests on release build

[Tomáš Chvátal]

Hello guys,
as again there is new series of lo it means more tests were added to
the list of those that are run during the make phase (where normal
software do only build).

For developers it helps to identify issues quickly because your build
crashes if you try to compile your changes but for users that try to
build the lo just for themselves the crashes can get really annoying.

Even that is not much of a problem as distributions usually provide
binaries that were once build so they do not run the tests for each
various hw/cflags/march/etc etc, sadly I am working on Gentoo, which
means I do get bazilion of bugs for failing tests that are not
reproducable on most machines.

Small list of bugs from "experimental" branch after two days (meaning
not much people using it and those errors will just grow as it moves
to stable):
https://bugs.gentoo.org/show_bug.cgi?id=394659
https://bugs.gentoo.org/show_bug.cgi?id=394615
https://bugs.gentoo.org/show_bug.cgi?id=394767

So unless you can look at one of those traces and tell me that the
build should be stopped because "it is obvious error in the code (not
in the test, the app code) that needs to be fixed" I would want you
guys to rethink running the tests for release build during the make
phase and just allow me to run them in designated test phase where it
is allowed to fail and wont stop user from installing the office
suite. (Yes those errors are logged, yes I will provide them, and yes
user will be able to use his office suite and not wait on some test
fixes)

This is quite critical issue for packaging in Gentoo and I would love
to fix it some other way than implementing cppunit hack that would
return true on each test so users will be able to install their
package...

Cheers

Tom
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [ANNOUNCE] libreoffice-3.4.99.1 tag created (3.5.0-beta1)

[Tomáš Chvátal]

2011/12/14 Andreas Radke :
>
> any suggestions welcome.
>
> the only difference to beta0 is the changed internal libvisio src bump.
> tried autoconf/autoreconf and make -j1 install without luck :(
>
> -Andy

It is not failure during build, but during install, so configure and
make can have any parallelism.

Anyway gentoo bug for this issue is here [1].
The problem as I managed to hit it once is that NO subdirs are created
in sdk directory -> all copying fails because it does not have the
place where it wants to put the files.

Cheers

Tom

[1] https://bugs.gentoo.org/show_bug.cgi?id=394599
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Simpler logging using a string format function

[Stephan Bergmann]

On 12/13/2011 10:21 PM, Michael Meeks wrote:


On Mon, 2011-12-12 at 22:59 +0100, Stephan Bergmann wrote:

To be honest, I don't think the stated benefits (a different syntax) are
worth a switch.


Well; the syntax that makes translation possible is a nice thing; but


Again, translation is a non-issue with conceivable uses of this in LO, 
right?



to me - having something efficient - that does not turn into some huge
sequence of calls is what I'm interested in. We have quite enough bloat
size-wise as it is, and infrastructure that makes it easy to create
small, efficient code is much to be praised I feel.

rtl::OUString x = "a" + 4 + "c";
turns into:
 x = new OUStringBuffer().append("a").append(4).append("c")
   .makeStringAndClear()

Which looks (to me) like a lot of back-to-back calls (in place of one);
and presumably some chunk of exception unwind table too. [ speaking of


But that's not related to the code in question.  Rather, at the call 
site, the printf-style approach amounts to a call to logfunction, while 
the <<-style approach amounts to one call to ostringstream ctor and one 
or more calls to the appropriate << operators.  Granted, the greater 
flexibility of the latter results in larger call-site code.



Sure, none of those are critical shortcomings, though.  (And its late
already, and maybe I'm just missing an obvious benefit completely.)


Heh.

Wrt. the panicing about now-or-never-again changes to these SAL_INFO
style macros, that seems a bit over-done to me.


Late in the evening, not late for changes was what I meant.


If there is any uncertainty about what we want to do with SAL_INFO and
friends, I suggest we just add a -DSAL_INTERNAL parameter (or alike) to
our build environment, and have some pieces of sal which are only for
internal use. Then we can improve this at our leisure without panicing
about sal's precious ABI :-)


No need for -DSAL_INTERNAL, I think.  The relevant symbols in sal.map 
are already in a PRIVATE_1.2 section, so clients that don't use 
sal/log.hxx would not be affected by incompatible changes.  And if we 
think so, we can mark the client-facing functionality in sal/log.hxx as 
"for LO internal use only, for now" (we already do so in some other places).


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Simpler logging using a string format function

[Stephan Bergmann]

On 12/13/2011 07:56 PM, Lubos Lunak wrote:

On Monday 12 of December 2011, Stephan Bergmann wrote:

Shrug.  Neither<<  nor something printf-like is particularly sexy, IMO.
   And trading<<  for +, when it requires you to wrap non-string
arguments in rtl::OUString::valueOf, doesn't look too exciting to me,
either.


  But it might the moment you realize you're trading away things like

  SAL_INFO( "foo", 1<<  2 ) or SAL_INFO( "foo", "bar"<<  "baz" ).


Trading away the former, having to parenthesize (1 << 2) instead, is a 
std C++ trade-off.  Granted, omission of the leading "ostream <<" in the 
macro call makes this somewhat non-obvious.  What is traded away in the 
latter case?


Anyway, bikeshedding about surface syntax is rather pointless.  Some 
seem to prefer a printf-style syntax, while others are fine with a C++ 
<<-based one.



- Artificially limited to 9 arguments.  You can sure always extend that,
but it's more work than not having to worry about it.


  Hmm. How often is that going to be needed?


With creative uses of SAL_WARN/INFO, I wouldn't be too sure.  ;)  (And 
as I already said, "none of those are critical shortcomings," only 
indicators to me that swapping implementations were not worth it if the 
only benefit were a different syntax.)



- No check that there are neither more nor fewer arguments than %Ns (or
that the set of %Ns spans a range 1--M without holes).


  There's a todo note, not that I think it matters that much if whoever does
that runs the code at least once.


Note that at least SAL_WARNs will typically *not* be run by the code 
authors.  (Who goes to the pains of crafting a scenario to make each new 
SAL_WARN actually trigger, by temporarily modifying the code around it 
or creating an appropriate runtime environment?)



  Well, that's another advantage of the format approach then. It's an
inconvenience to have to explicitly say the format string is utf-8 (and
arguments probably as well), but then this conversion can be again limited
just to logging and not to every std::ostream operation.


Yes, having the message in UTF-16 is an advantage here.  For the 
ostream-based approach, we need to wait for general availability of 
C++11's char16_t.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice