Re: [Libreoffice] consistent SCCOL use?

[Markus Mohrhard]

Hello Kevin,


> A quick question to any more-knowledgeable-than-me person on whether there's
> a reason these spots in the calc code base are hard-coded to sal_Int16,

It is sal_uInt16 which is not the same as SCCOL.

> rather than using SCCOL?
>

There are 3 different cases here:

- pivot.hxx may use SCCOL, but I think that the used short can only
have values between 0 and 7 there ( Kohei should know it much better )

- source/filter/excel should always use the type already used there
otherwise the binary import might make problems

- pfiltdlg.cxx uses sal_uInt16 because it is an unsigned datatype and
SCCOL is signed, we could use SCCOL there too


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

[Libreoffice] consistent SCCOL use?

[Kevin Hunter]

Hullo SC Devs,

A quick question to any more-knowledgeable-than-me person on whether 
there's a reason these spots in the calc code base are hard-coded to 
sal_Int16, rather than using SCCOL?


Thanks,

Kevin
diff --git a/sc/inc/pivot.hxx b/sc/inc/pivot.hxx
index 705f794..b6bded9 100644
--- a/sc/inc/pivot.hxx
+++ b/sc/inc/pivot.hxx
@@ -189,12 +189,12 @@ typedef ::std::vector< ScPivotField > ScPivotFieldVector;
 
 struct ScDPFuncData
 {
-short   mnCol;
+SCCOL   mnCol;
 sal_uInt16  mnFuncMask;
 ::com::sun::star::sheet::DataPilotFieldReference maFieldRef;
 
-explicitScDPFuncData( short nNewCol, sal_uInt16 nNewFuncMask );
-explicitScDPFuncData( short nNewCol, sal_uInt16 nNewFuncMask,
+explicitScDPFuncData( SCCOL nNewCol, sal_uInt16 nNewFuncMask );
+explicitScDPFuncData( SCCOL nNewCol, sal_uInt16 nNewFuncMask,
 const ::com::sun::star::sheet::DataPilotFieldReference& rFieldRef );
 };
 
diff --git a/sc/source/filter/excel/impop.cxx b/sc/source/filter/excel/impop.cxx
index 533bbb9..cffbaf0 100644
--- a/sc/source/filter/excel/impop.cxx
+++ b/sc/source/filter/excel/impop.cxx
@@ -465,7 +465,7 @@ void ImportExcel:: WinProtection( void )
 
 void ImportExcel::Columndefault( void )
 {// Default Cell Attributes
-sal_uInt16  nColMic, nColMac;
+SCCOL  nColMic, nColMac;
 sal_uInt8   nOpt0;
 
 aIn >> nColMic >> nColMac;
@@ -651,7 +651,7 @@ void ImportExcel::Builtinfmtcnt( void )
 
 void ImportExcel::Colinfo( void )
 {// Column Formatting Information
-sal_uInt16  nColFirst, nColLast, nColWidth, nXF;
+SCCOL  nColFirst, nColLast, nColWidth, nXF;
 sal_uInt16  nOpt;
 
 aIn >> nColFirst >> nColLast >> nColWidth >> nXF >> nOpt;
diff --git a/sc/source/ui/dbgui/pfiltdlg.cxx b/sc/source/ui/dbgui/pfiltdlg.cxx
index 1b65585..5437ef6 100644
--- a/sc/source/ui/dbgui/pfiltdlg.cxx
+++ b/sc/source/ui/dbgui/pfiltdlg.cxx
@@ -103,7 +103,7 @@ ScPivotFilterDlg::ScPivotFilterDlg( Window* pParent,
 nSrcTab ( nSourceTab ), // ist nicht im QueryParam
 nFieldCount ( 0 )
 {
-for (sal_uInt16 i=0; i<=MAXCOL; i++)
+for (SCCOL i=0; i<=MAXCOL; i++)
 pEntryLists[i] = NULL;
 
 Init( rArgSet );
@@ -114,7 +114,7 @@ ScPivotFilterDlg::ScPivotFilterDlg( Window* pParent,
 
 ScPivotFilterDlg::~ScPivotFilterDlg()
 {
-for (sal_uInt16 i=0; i<=MAXCOL; i++)
+for (SCCOL i=0; i<=MAXCOL; i++)
 delete pEntryLists[i];
 
 if ( pOutItem )
@@ -567,7 +567,7 @@ IMPL_LINK( ScPivotFilterDlg, CheckBoxHdl, CheckBox*, pBox )
 
 if ( pBox == &aBtnCase )// Wertlisten
 {
-for (sal_uInt16 i=0; i<=MAXCOL; i++)
+for (SCCOL i=0; i<=MAXCOL; i++)
 DELETEZ( pEntryLists[i] );
 
 String aCurVal1 = aEdVal1.GetText();
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] binfilter dependencies

[Peter Foley]

Matus,

I noticed that you added basic to tail_build in feature/gbuild_extensions.
Be warned that when feature/gbuild_extensions gets merged to master 
binfilter/prj/build.lst will have to get changed from depending on basic 
to depending on tail_build simultaneously.

Thanks,

Peter


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

Re: [Libreoffice] [PATCH] Fix fdo#42783 get rid of CPU define/build system variable

[Norbert Thiebaud]

On Tue, Dec 20, 2011 at 10:45 AM, Bjoern Michaelsen
 wrote:
>
> IMHO (other might disagree), we should get rid of these opaque names in the
> long run anyway. INPATH and OUTPATH should only be "build" or "host".
>

Sure, but then stuff like rm -fr */$INPATH may end-up having
unexpected consequences...

once everything is on workdir (and even in solver) then sure no
problem to use build/host... but as long as INPATH is in individual
module that maybe a bit dangerous to change with such common terms.

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

Re: [Libreoffice] calc: Re: com.sun.star.container.XNameContainer.removeByName() fails v3.5b0+ (linux)

[Markus Mohrhard]

Hello Tomas,

2011/12/20 Michael Stahl :


>
> On 20/12/11 14:52, Tomas Hlavaty wrote:
>> could you please advise me how to build and run the test case?
>>
>> I did:
>>
>> $ cd sc/
>> $ make
>>
>> and it built the tests.
>>
>> It seems to have run something called CHK from the console log, but
>> where can I find the test results?
>
> the CUT (or JUT) lines announce that a single unit test is being run.
> the output is redirected to a log file, and if the test is successful no
> output is displayed on the terminal.
> if the test fails, then the log file is output to the terminal.
>
>> How do I run this single test case?
>
> it seems you can't run this one yet because it isn't actually built with
> a makefile :)

Yes and that was my intention. I made a assumption in the test that
might not be true for every build. I need someone with an non en-US
build and non en-US locale to check that forcing en-US in the test
setup works for sheet names too.

You can use the attached patch and run a normal make in sc. The test
should then be executed as sc_spreadsheetobj. You can find the logfile
for the test at
workdir/platform/CppunitTest/sc_spreadsheetobj.test.log

Regards,
Markus
___
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]

Petr Mladek píše v Čt 15. 12. 2011 v 11:09 +0100:
> 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.

I have finally got time to look at it. There were two problems:

1. core/bin/distro-install-sdk move many files to /usr/share to make it
LSB-compliant. It creates compat symlinks in /usr/lib; The symlinks are
absolute and invalid if you use $DESTDIR.

2. As Tomas found, "make distro-pack-install" did the installation twice
from some reasons. The second installation failed because it tried to
access files via the invalid symlinks.


I am not able to find why the installation is called twice. The gbuild
stuff is still a bit cryptic to me :-)

Though, I have updated ooinstall to cleanup $DESTDIR before installation
starts. It works fine now. I am not 100% sure that we want this
solutions. Well, it makes some sense even after we fix the installation
dependencies.

Unfortunately, it was too late to get this into beta2. You might find
the change at 
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=1048d8fa4abd3e55a45dfb6884db808da1d72c9e


Best Regards,
Petr

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

[Libreoffice] [PATCH] fix EasyHack FDO42454, remove code associated with unused icons

[Gustavo Pacheco]

Hi!

Fix for EasyHack FDO42454 (
https://bugs.freedesktop.org/show_bug.cgi?id=42454) in attachment for
review.

I have found 8 high-contrast cross icons in images.zip:
res/sx03241.png
res/lx03241.png
res/commandimagelist/lc_splitparentvertical.png
sw/res/anchor.png
sw/res/danchor.png
fpicker/res/list.png
svx/res/galimpl.png
svx/res/galimps.png

But only list.png, galimpl.png, galimps.png were referenced in the code:

fpicker/res/list.png: list.bmp (removed from
/fpicker/source/office/iodlg.src in the patch)
svx/res/galimps.png: galimps.bmp (removed from
svx/source/gallery2/gallery.src in the patch)
svx/res/galimpl.png: galimpl.bmp (removed from
cui/source/dialogs/gallery.src in the patch)

Thanks,
Gustavo Pacheco.
From 32233a6f91c92cb29f7508bc6a67ee364da2446d Mon Sep 17 00:00:00 2001
From: Gustavo Buzzatti Pacheco 
Date: Fri, 16 Dec 2011 17:55:26 -0200
Subject: [PATCH] Fix for EasyHack FDO42454, remove code associated with unused icons

fpicker/res/list.png: list.bmp removed from /fpicker/source/office/iodlg.src
svx/res/galimps.png: galimps.bmp removed from svx/source/gallery2/gallery.src
svx/res/galimpl.png: galimpl.bmp removed from cui/source/dialogs/gallery.src
---
 cui/source/dialogs/gallery.src  |5 -
 fpicker/source/office/iodlg.src |8 
 svx/source/gallery2/gallery.src |5 -
 3 files changed, 0 insertions(+), 18 deletions(-)

diff --git a/cui/source/dialogs/gallery.src b/cui/source/dialogs/gallery.src
index 0108027..3607d18 100644
--- a/cui/source/dialogs/gallery.src
+++ b/cui/source/dialogs/gallery.src
@@ -468,11 +468,6 @@ Bitmap RID_SVXBMP_THEME_NORMAL_BIG
 File = "galnorl.bmp" ;
 };
 
-Bitmap RID_SVXBMP_THEME_IMPORTED_BIG
-{
-File = "galimpl.bmp" ;
-};
-
 Bitmap RID_SVXBMP_THEME_READONLY_BIG
 {
 File = "galrdol.bmp" ;
diff --git a/fpicker/source/office/iodlg.src b/fpicker/source/office/iodlg.src
index 4a3c2f6..2015a5c 100644
--- a/fpicker/source/office/iodlg.src
+++ b/fpicker/source/office/iodlg.src
@@ -82,14 +82,6 @@ ModalDialog DLG_SVT_EXPLORERFILE
 HelpID = "fpicker:ImageButton:DLG_SVT_EXPLORERFILE:BTN_EXPLORERFILE_LISTVIEW";
 TabStop = FALSE ;
 Pos = MAP_APPFONT ( 109 , 6 ) ;
-ButtonImage = Image
-{
-ImageBitmap = Bitmap
-{
-File = "list.bmp" ;
-};
-MASKCOLOR
-};
 QuickHelpText [ en-US ] = "List";
 };
 HelpID = "fpicker:ImageButton:DLG_SVT_EXPLORERFILE:BTN_EXPLORERFILE_DETAILSVIEW";
diff --git a/svx/source/gallery2/gallery.src b/svx/source/gallery2/gallery.src
index b801b1d..6bb583a 100644
--- a/svx/source/gallery2/gallery.src
+++ b/svx/source/gallery2/gallery.src
@@ -190,11 +190,6 @@ Bitmap RID_SVXBMP_THEME_NORMAL
 File = "galnors.bmp" ;
 };
 
-Bitmap RID_SVXBMP_THEME_IMPORTED
-{
-File = "galimps.bmp" ;
-};
-
 Bitmap RID_SVXBMP_THEME_READONLY
 {
 File = "galrdos.bmp" ;
-- 
1.7.0.4


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

Re: [Libreoffice] [Libreoffice-qa] Bugs in Portable LibO Versions

[Pedro Lino]

> I do not know at all how bug fixes for Portable LibO Builds will be
> proceeded. I believe hints in
>  are not
> useful.
>
> What do you think?

Are there any specific Portable LO errors?

I assume that the Portable version works 100% like the installed.
If there are any errors they should be detected in the installed version...

In any case there is specific support at portableapps.com
http://portableapps.com/support/libreoffice_portable
http://portableapps.com/forums/support/libreoffice_portable

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

[Libreoffice] [PUSHED] Re: [patch] translate some german comments in /svx

[Michael Stahl]

On 19/12/11 12:56, Noel Grandin wrote:
> Hi
> 
> More translations, work by Mike Whiteley and Noel Grandin, patch is
> under MPL/LGPL+
> 
> Regards, Noel

thanks for your patch, pushed to master:

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

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

[Libreoffice] Hi ! We are new on libo! 2/2

[Julien Levesy]

Hi, to follow my friend Martius, i'm introducing myself.

I'm Julien Levesy, french student in CS.
As a school project, I'll will help Martin in reworking file picker, and
implementing new features he has presented in his previous mail.
All this work is mentored by Cedric Bosdonnat.

My nickname in IRC is Jlevesy.

All the best !

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

[Libreoffice] [ANNOUNCE] libreoffice-3.4.99.2 tag created (3.5.0-beta2)

[Petr Mladek]

Hi,

there have been created the libreoffice-3.4.99.2 tag for 3.5.0-beta2 release.
The corresponding official builds will be available within 3 days or so.

See the attached list of changes against 3.5.0-beta1.

See also the schedule at 
http://wiki.documentfoundation.org/ReleasePlan#3.5_release
and release criteria at http://wiki.documentfoundation.org/Release_Criteria


Now, if you want to switch your clone to the tag, please do:

./g fetch --tags
./g checkout -b tag-libreoffice-3.4.99.2 libreoffice-3.4.99.2


Thanks again everyone who helped to make this happen.

Best Regards,
Petr

+ core
+ 'Back' is misleading, use 'Revert' instead (fdo#39452) [Lior Kaplan]
+ always load res of LibO UI locale, not system deflocale (fdo#43475) [Andras Timar]
+ always sort category axis when it's a date type. (fdo#43681) [Kohei Yoshida]
+ avoid SIGBUS writing to overcommitted mmaped diskspace (rhbz#767708) [Stephan Bergmann]
+ better fix for over-zealous Zip package consistency. (bnc#653688) [Thorsten Behrens]
+ can't claim its not a DXF just because didn't see SECTION (fdo#43082) [Caolán McNamara]
+ component_getFactory is missing (fdo#43422) [Caolán McNamara]
+ correct default horizontal alignment for complex script. (fdo#32530) [Kohei Yoshida]
+ crash inserting table control (fdo#42694) [Caolán McNamara]
+ do not lose height of tree list box in Navigator (fdo#39528) [Ivan Timofeev]
+ don't evaluate error cells as values during filtering. (fdo#35539) [Kohei Yoshida]
+ don't try to use Inf for axes calculation (fdo#43703) [Markus Mohrhard]
+ fail fast if cups is non-operational. (bnc#722902) [Thorsten Behrens]
+ fix (bnc#653688) [Thorsten Behrens]
+ fix RTF import crasher with \keep in table properties (bnc#228839) [Cédric Bosdonnat]
+ fix RTF import of fields inside tables (fdo#42109) [Miklos Vajna]
+ fix docx hyperlink writing (fdo#35826, bnc#706138) [Luboš Luňák]
+ fix inconsistent compression method for encrypted ZIP packages. (bnc#653688) [Thorsten Behrens]
+ fix selection of background pictures vs text (bnc#676858) [Cédric Bosdonnat]
+ fixed ROWS(), COLUMNS() and SHEETS() don't work with external references (fdo#43700) [Eike Rathke]
+ fixed an RTF import crash when handling formdata in non-FORM fields (bnc#703032) [Cédric Bosdonnat]
+ fixed chart listener registration during ODS import. (fdo#39118) [Kohei Yoshida]
+ fixed present Catalan (Valencian) as selectable UI language (fdo#37349) [Eike Rathke]
+ handle empty members correctly during field popup. (fdo#35981) [Kohei Yoshida]
+ header/Footer: RTL display fixes (fdo#43793) [Cédric Bosdonnat]
+ iFSD_Equal is asymmetrical (rhbz#761009) [Caolán McNamara]
+ if a bracket pair has no left/right bracket, it needs to explicit (fdo#32636) [Luboš Luňák]
+ import m:eqArr (part of (fdo#32636) [Luboš Luňák]
+ impress210: added CTRL-ALT-C as shortcut for inserting comments in calc (i#116847) [Christian Lippka ORACLE]
+ infer number format from formula result if appropriate. (fdo#43467) [Kohei Yoshida]
+ label PRINTING misplaced on paper sheet (fdo#36874) [Winfried Donkers]
+ move SID_INSERT_CURRENT_DATE/TIME to GID_INSERT (fdo#30714) [Miklos Vajna]
+ pass the correct ScTabViewShell instance to the input box. (fdo#43614) [Kohei Yoshida]
+ preserving dbf import/export charset. (fdo#33602) [Muthu Subramanian]
+ rTF export: handle url fields without a field result (fdo#37498) [Miklos Vajna]
+ rTF import: default scale for images is 100% not 0% (bnc#228839, bnc#77738) [Cédric Bosdonnat]
+ rTL PopupMenu position fixes (fdo#43790) [Cédric Bosdonnat]
+ resolved Advanced FILTER incompatible with 3.4.4 documents (fdo#43831) [Eike Rathke]
+ resolves crash on saving a file (fdo#43725) [Eike Rathke]
+ revert "Fix " (bnc#653688) [Thorsten Behrens]
+ row Height is unnecessarily large. (fdo#33747) [Muthu Subramanian]
+ set correct auto scaling for stacked data series. (fdo#43681) [Kohei Yoshida]
+ set initial focus to "Number of copies" (fdo#34641) [Ivan Timofeev]
+ show/hide anchor when the anchoring status changes. (fdo#38545) [Kohei Yoshida]
+ sw: Fix cursor accessibility API (fdo#43390) [Vincent Povirk]
+ sw: avoid creating cursor with non-text node text range (fdo#40195) [Noel Power]
+ teach old-style method about the new form of screen numbering (fdo#43458) [Michael Meeks]
+ tweak workarounds for (fdo#43707, fdo#42865) [Michael Stahl]
+ use correct address convention during search and replace. (fdo#39917) [Kohei Yoshida]
+ use different default key bindings for Hungarian locale (fdo#30714) [Miklos Vajna]
+ common
+ version 3.4.99.2, tag libreoffice-3.4.99.2 (3.5.0-beta2) [Petr Mladek]
+ core
+ 'Back' is misleading, use 'Revert' instead (fdo#39452) [Lior Kaplan]
+ -Wl,-dead_strip_dylibs is not supported with XCode 2.5, align with master [Christian Lohmaier]
+ -lz was sucke

Re: [Libreoffice] [PATCH] Update French dictionaries

[Olivier R.]

Sorry.
Here is the patch:
http://nabble.documentfoundation.org/file/n3601795/0001-Update-French-dictionaries.patch
0001-Update-French-dictionaries.patch 

--
View this message in context: 
http://nabble.documentfoundation.org/PATCH-Update-French-dictionaries-tp3601788p3601795.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] Update French dictionaries

[Olivier R.]

Hello,

Here the attached patch to update the French dictionaries:

1. Spelling dictionary
4.3 to 4.4: approx. 1500 new entries
http://nabble.documentfoundation.org/file/n3601788/0001-Update-French-dictionaries.patch
0001-Update-French-dictionaries.patch 
cleaning and few fixes


3. Hyphenation rules
2.0 to 3.0 New revised and expanded version:
  +  Conversion to UTF-8 Unicode encoding
  +  Processing of hyphenated compounds
  +  Correction of altered patterns
Thanks to Marc Lodewijck


3. Thesaurus
Mostly cleaning


Best regards,
Olivier R.

--
View this message in context: 
http://nabble.documentfoundation.org/PATCH-Update-French-dictionaries-tp3601788p3601788.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Bugs in Portable LibO Versions

[Rainer Bielefeld]

Hi,

I do not know at all how bug fixes for Portable LibO Builds will be 
proceeded. I believe hints in 
 are not 
useful.


What do you think?

Discussion please in "libreOffice-QA"

Kind regards

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

Re: [Libreoffice] [PATCH] Fix fdo#42783 get rid of CPU define/build system variable

[Bjoern Michaelsen]

On Tue, Dec 20, 2011 at 04:43:41AM -0600, Norbert Thiebaud wrote:
> a/
>  if ( "@WITH_MOZILLA@" eq "YES" and "@BUILD_MOZAB@" ne "TRUE" and
> "@SYSTEM_MOZILLA@" ne "YES" )
>  {
> print("Checking for prebuilt Mozilla libraries ...");
> my $mozbinfile = $SRC_ROOT."/moz/zipped/";
> -   $mozbinfile .= $OS.$COM.$CPU;
> +   $mozbinfile .= $OS.$COM.$CPUNAME;
> if ( -e $mozbinfile."inc.zip"
> 
> These filename have not actually changed. they are hosted in our web
> site and we can't ust 'rename' them or we would break 3.4/3.5 and any
> version prior to the patch

Ok, so we have to keep CPU for now. Id suggest to maybe rename CPU to
CPU_DEPRECATED, if we are down to the stuff that cant be easily removed, so
that it doesnt creep back in.

> 
> b/ INPATH adn OUPATH have a name that is today constructed based on
> CPU... removing that 1 letter shortcut from the rest of the product
> will render these naming convention even more opaque.

IMHO (other might disagree), we should get rid of these opaque names in the
long run anyway. INPATH and OUTPATH should only be "build" or "host".

> e/ there are missed occurrences, like in hyphen, lpsolve, redland...
> for instance. you can't remove the setup in set_soenv.in until _all_
> use case have been removed.
> so maybe first patching out the use cases -- starting with the one
> that are straight forward and fo not have side effect --  and then...
> a final patch that clean-up set_soenv.in once we are sure there is
> nothing left.

Yes, for now lets just EasyHack the ones that are easy to remove incrementally
and keep CPU in set_soenv.in for now.

Best,

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

Re: [Libreoffice] [PATCH] Fix fdo#39639 [EasyHack] Fix duplicate longname IDs

[Jan Holesovsky]

Hi Victor,

On 2011-12-20 at 17:34 +0900, Victor Lee wrote:

> the attached patch simply removes duplicated and unused IDs in
> BackgroundsDialog.

Thank you for the patch, and welcome to LibreOffice! :-)

Just wanted to ask you how did you find these?  I mean, it seems to me
that "HID:WIZARDS_HID_BG_BTN_IMG12" is not used either [or is it?], so
why exactly do you remove only IMG13 and above, and not all the
HID:WIZARDS_HID_BG_BTN_IMG*?

Regarding the patch itself, it would be great if you can use the output
of git format-patch as described here:

http://wiki.documentfoundation.org/Development#Preparing_patches

Thank you a lot,
Kendy

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

Re: [Libreoffice] [PUSHED][PATCH] Fix for fdo43460 Part XI getLength() to isEmpty()

[Ivan Timofeev]

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

Re: [Libreoffice] [PATCH] Fix for fdo43460 Part XI getLength() to isEmpty()

[Ivan Timofeev]

Hi Olivier,

16.12.2011 23:33, Olivier Hallot пишет:

Please find attached a partial fix for Easy Hack FDO43460

Part XI
Module
cui


sorry for the delay, (he-he, now I know how to resolve conflicts :) pushed:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=1375183d465fb17db513dfe16ac522e48573a4c0

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

Re: [Libreoffice] calc: Re: com.sun.star.container.XNameContainer.removeByName() fails v3.5b0+ (linux)

[Jan Holesovsky]

Hi Tomas,

On 2011-12-20 at 13:23 +0100, Tomas Hlavaty wrote:

> > i guess 3.4.4 is this: libreoffice-3.4.4.2
> > beta0:  libreoffice-3.5.0.0
> > beta1:  libreoffice-3.4.99.1
> >
> > yes, really :)
> 
> Is that somewhere documented?  Or wouldn't it be better if it was
> obvious from the tag names?

Bugs happen - sorry for that :-(  We should probably re-tag the beta0 as
libreoffice-3.4.99.0, and dump libreoffice-3.5.0.0 from the
repositories.

Regards,
Kendy

___
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

Bug 35673 depends on bug 36991, which changed state.

Bug 36991 Summary: crash when duplicating draw page with linked wmf pictures
https://bugs.freedesktop.org/show_bug.cgi?id=36991

   What|Old Value   |New Value

 Resolution||FIXED
 Status|REOPENED|RESOLVED

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

Re: [Libreoffice] calc: Re: com.sun.star.container.XNameContainer.removeByName() fails v3.5b0+ (linux)

[Michael Stahl]

On 20/12/11 15:51, Tomas Hlavaty wrote:
> Hi Michael,
> 
> Michael Stahl  writes:
>> i guess 3.4.4 is this: libreoffice-3.4.4.2
> 
> libreoffice-3.4.4.2 tag doesn't exist:-(  Any other ideas?  Are there
> any rules how tags are created and named?  And branches?

the 3.4 stuff does not exist in the core repo but in the old bootstrap
based zoo of repos.

http://wiki.documentfoundation.org/Development/Native_Build_From_Bootstrap

On 20/12/11 14:52, Tomas Hlavaty wrote:
> could you please advise me how to build and run the test case?
> 
> I did:
> 
> $ cd sc/
> $ make
> 
> and it built the tests.
> 
> It seems to have run something called CHK from the console log, but
> where can I find the test results?

the CUT (or JUT) lines announce that a single unit test is being run.
the output is redirected to a log file, and if the test is successful no
output is displayed on the terminal.
if the test fails, then the log file is output to the terminal.

> How do I run this single test case?

it seems you can't run this one yet because it isn't actually built with
a makefile :)

if it were it would be something like this:

make -r /data/lo/core/workdir/unxlngx6/CppunitTest/sc_cellrangesbase.test

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

Re: [Libreoffice] calc: Re: com.sun.star.container.XNameContainer.removeByName() fails v3.5b0+ (linux)

[Tomas Hlavaty]

Hi Michael,

Michael Stahl  writes:
> i guess 3.4.4 is this: libreoffice-3.4.4.2

libreoffice-3.4.4.2 tag doesn't exist:-(  Any other ideas?  Are there
any rules how tags are created and named?  And branches?

Thank you,

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

Re: [Libreoffice] calc: Re: com.sun.star.container.XNameContainer.removeByName() fails v3.5b0+ (linux)

[Tomas Hlavaty]

Hi Bjoern,

Bjoern Michaelsen  writes:
> Any you could try bibisect: http://sweetshark.livejournal.com/7683.html
> to close in on the bug even more (and thus make it get fixed faster).

bibisect is brilliant but unfortunatelly dosn't cover the range I would
need for this (v3.4.4+).

Regards,

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

Re: [Libreoffice] [Libreoffice-qa] calc: Re: com.sun.star.container.XNameContainer.removeByName() fails v3.5b0+ (linux)

[Tomas Hlavaty]

Hi Markus,

> Ok, I wrote a simple c++ based test for that and can't reproduce your
> problem.

could you please advise me how to build and run the test case?

I did:

$ cd sc/
$ make

and it built the tests.

It seems to have run something called CHK from the console log, but
where can I find the test results?

How do I run this single test case?

Thank you,

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

Re: [Libreoffice] LoadComponentFromUrl misuse lead to crash

[Laurent Godard]

Hi Caolan

> This still a problem for you? if so can you run it under gdb and get a
> backtrace.

cedric & noel submited a patch yesterday
i did not have the time to check, but will do

Thanks a lot, i let you know

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

Re: [Libreoffice] Build problems (and some solutions) in Mac OSX

[Christian Lohmaier]

Hi Michael, *,

On Tue, Dec 20, 2011 at 12:32 PM, Michael Meeks  wrote:
> On Tue, 2011-12-20 at 19:04 +1300, James C wrote:
>> I have burned about 1.5 GB of metered network bandwidth, so far,
>> following these instructions:
>> There is also a human-sized problem, with some instructions on the
>> web-site being wrong:
>> https://bugs.freedesktop.org/show_bug.cgi?id=43920
>
>        Wrt. the wiki - it is quite possibly out of date :-)

Nah, the Mac OSX dependencies/build instructions are up-to-date.
http://wiki.documentfoundation.org/Development/Install_Mac_OS_X_Dependencies

> but the good thing
> is that the wiki is human editable - having said that (and I'm not a Mac
> hacker), I was lead to believe that the build is reasonably self
> contained.

And it still is.

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

Re: [Libreoffice] Build problems (and some solutions) in Mac OSX

[Christian Lohmaier]

Hi James, *,

On Tue, Dec 20, 2011 at 7:04 AM, James C
 wrote:
> [building on Mac]
> There is also a human-sized problem, with some instructions on the
> web-site being wrong:
> https://bugs.freedesktop.org/show_bug.cgi?id=43920

Your issues show that you got a polluted environment, you have
macports/fink/whatever installed that interferes with the build.

Building against non-Apple-provided libraries and stuff is not
supported. Patches to shield the build-environment against
accidentally building against those are welcome.

To build LO on Mac: Get rid of the macports/fink/... stuff. Create an
environment where only XCode is used. (with the exception of the mac
dependencies when you don't use --disable-mozilla)

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

Re: [Libreoffice] [Libreoffice-qa] calc: Re: com.sun.star.container.XNameContainer.removeByName() fails v3.5b0+ (linux)

[Tomas Hlavaty]

Hi Markus,

Markus Mohrhard  writes:
> Ok, I wrote a simple c++ based test for that

wow, thank you very much!

> and can't reproduce your problem.

Hmm, I'll dig into it.  I noticed there were some changes in the code
regarding string handling, so maybe it might be related.

> The test (
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=b77902d38d06df87694564ded859733bdb1d4fb2
> ) creates an empty document, checks that it has a second sheet( bad
> assumption there from me) and removes the sheet. Eventually I even
> check that removing with the same name will throw an
> NoSuchElementException. I also had some quick looks at the
> implementation and I don't see any place that would throw an out of
> bounds exception.
>
> All of these parts pass without any problem, not even a suspicious
> line in a dbgutil build.
>
> Can you open a bug report for this with some more details and assign
> it to me?

I'll try to reproduce it here with your test case and see if the problem
is on my side or LO side (in which case I file a bug).

Thank you very much,

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

Re: [Libreoffice] calc: Re: com.sun.star.container.XNameContainer.removeByName() fails v3.5b0+ (linux)

[Tomas Hlavaty]

Hi Michael,

Michael Stahl  writes:
> you are much more likely to get a reply for this kind of bug on the
> dev list.

sorry I haven't got the feel for the right places yet;-)

> sounds like a bug to me. guess you should file it in bugzilla and set
> the "regression" keyword.

ok, I'll do that when I'm confident it's a regression.

> in sc you should find some new C++ unit tests and old Java unit tests
> (in qa/complex).

Thank you for the pointer.

> i guess 3.4.4 is this: libreoffice-3.4.4.2
> beta0:  libreoffice-3.5.0.0
> beta1:  libreoffice-3.4.99.1
>
> yes, really :)

Is that somewhere documented?  Or wouldn't it be better if it was
obvious from the tag names?

Thank you,

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

Re: [Libreoffice] LoadComponentFromUrl misuse lead to crash

[Caolán McNamara]

On Tue, 2011-11-29 at 13:58 +0100, Laurent Godard wrote:
> Hi caolan
> 
> > Can you attach a demo ?
> > 
> 
> here is a macro showing the problem
> just change the myFile.ods so that it points to a file of your filestem

Checked this locally (finally), and I get no crash. I get a "unsupported
url" dialog from starbasic.

This still a problem for you? if so can you run it under gdb and get a
backtrace.

C.

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

Re: [Libreoffice] Build problems (and some solutions) in Mac OSX

[Michael Meeks]

Hi James,

On Tue, 2011-12-20 at 19:04 +1300, James C wrote:
> I have burned about 1.5 GB of metered network bandwidth, so far,
> following these instructions:

Grief; hopefully the meter doesn't roll too quickly. Of course, once
you have the git repository - you should fetch only deltas from then on
- which should be quick and easy: you have both the 3.5 and master
branches locally etc. So hopefully bandwidth wise things should go
better.

> There is also a human-sized problem, with some instructions on the
> web-site being wrong:
> https://bugs.freedesktop.org/show_bug.cgi?id=43920

Wrt. the wiki - it is quite possibly out of date :-) but the good thing
is that the wiki is human editable - having said that (and I'm not a Mac
hacker), I was lead to believe that the build is reasonably self
contained. Perhaps some Mac-ite can take this bug on.

>   - I do not understand which pieces of the source I would need, in
> order to play with Writer, and how big they would be

So - as Norbert says in sw/ lives much of the code; but 'git grep' can
be a good tool to find UI strings which are typically defined in .src
files next to the .cxx file that implements the behaviour you're
interested in.

After processing this thread of replies ;-) it'd be great to know what
your next sticking point is ... getting the first build is quite an
achievement on Mac (it's rather simple on Linux these days ;-)

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

Re: [Libreoffice] [PATCH] Fix fdo#42783 get rid of CPU define/build system variable

[Norbert Thiebaud]

On Tue, Dec 20, 2011 at 2:52 AM, Victor Lee  wrote:

First welcome to LibreOffice...

> This patch substituts $CPU to $CPUNAME in makfiles and has been
> successfully built on my Linux/x86 machine.
>  However, there are two
> questions remain:
> 1) Statements setting $CPU="U" (looks like it should be "SPARC64")
> could not be found in set_soenv.in or related files, but $(CPU)=="U"
> is checked in some makefiles.  I left those lines untouched in this
> patch.
> 2) Fixing patch files directly (e.g., jpeg/jpeg-6b.patch) seems not a
> good idea, though I have done it.
> Please give me your advice.


thee are more little problems...

a/
 if ( "@WITH_MOZILLA@" eq "YES" and "@BUILD_MOZAB@" ne "TRUE" and
"@SYSTEM_MOZILLA@" ne "YES" )
 {
print("Checking for prebuilt Mozilla libraries ...");
my $mozbinfile = $SRC_ROOT."/moz/zipped/";
-   $mozbinfile .= $OS.$COM.$CPU;
+   $mozbinfile .= $OS.$COM.$CPUNAME;
if ( -e $mozbinfile."inc.zip"

These filename have not actually changed. they are hosted in our web
site and we can't ust 'rename' them or we would break 3.4/3.5 and any
version prior to the patch

b/ INPATH adn OUPATH have a name that is today constructed based on
CPU... removing that 1 letter shortcut from the rest of the product
will render these naming convention even more opaque.

c/ most if not all these use of CPU are in dmake module, which are
destined to be converted to gbuild... so I suspect a lot of these
'uses' will disappear during the conversion.

d/
--- a/libpng/libpng-1.5.1.patch
+++ b/libpng/libpng-1.5.1.patch
@@ -21,7 +21,7 @@
 +.INCLUDE :  settings.mk
 +
 +
-+.IF "$(GUI)$(CPU)"=="WNTP"
++.IF "$(GUI)$(CPUNAME)"=="WNTPOWERPC" || "$(GUI)$(CPUNAME)"=="WNTPOWERPC64"
 +CFLAGS=$(CFLAGS) -Od
 +.ENDIF
 +

illustrate that things do not necessarily get 'simplified'.

e/ there are missed occurrences, like in hyphen, lpsolve, redland...
for instance. you can't remove the setup in set_soenv.in until _all_
use case have been removed.
so maybe first patching out the use cases -- starting with the one
that are straight forward and fo not have side effect --  and then...
a final patch that clean-up set_soenv.in once we are sure there is
nothing left.

I'm really sorry I did not see that fdo#42783 earlier, I would have
added these remarks earlier... _before_ you did the work :-/

But the bug was filled by Bjorn, so I'll let him weight in...

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

Re: [Libreoffice] [REVIEW] [Fwd: Fwd: gcc 4.6.2]

[Caolán McNamara]

On Tue, 2011-12-20 at 10:13 +0100, Petr Mladek wrote:
> Hi Rafael,
> 
> fixes for 3.4.5-rc2 need triple review, so I forward this mail to the
> mailing list.

We've seen this problem recently with our rawhide gcc as well and 3.4.X,
though 3.5.X doesn't seem to have the problem (though whether that
because 3.5.X has the problem fixed, or a new update to gcc materialized
coincidentally) To me it looks as if the compiler generates
operator=(foo&) instead of operator=(const foo&) and I'd lazily
dismissed it as a bug in a development gcc which would be fixed soon :-)

It'd be great if someone who has the problem in 3.4.X can see if 3.5.X
compiles without error with the same compiler, like now appears to be
the case in the fedora rawhide build system.

Un-enthused by casting const away willy-nilly and/or writing error-prone
manual operator= to get it to compile if we've already got the fix for
it in 3.5.X, but just don't know what that fix was :-)

C.

___
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

Petr Mladek  changed:

   What|Removed |Added

 Depends on||43752

--- Comment #59 from Petr Mladek  2011-12-20 01:25:40 PST ---
(In reply to comment #44)
> Nominate "Bug 43752 - VIEWING: Rotated flipped shapes in 3.4 drawings loose
> rotation opened in 3.5".

Yup, we should fix this.

-- 
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] [REVIEW] [Fwd: Fwd: gcc 4.6.2]

[Petr Mladek]

Hi Rafael,

fixes for 3.4.5-rc2 need triple review, so I forward this mail to the
mailing list.

I am not sure why your mails are moderated. Are you subscribed to the
mailing list? If not, please try to do so at
http://lists.freedesktop.org/mailman/listinfo/libreoffice

If you are subscribed and still see the problem, please forward Thorsten
the mail about that the mail is moderated? I guess that it mentions a
reason why it is moderated.

Best Regards,
Petr


 Přeposlaná zpráva 
Od: Rafael Cabral 
Reply-to: cab...@mandriva.com.br
Komu: pmla...@suse.cz
Předmět: Fwd: gcc 4.6.2
Datum: Mon, 19 Dec 2011 16:34:43 -0200

Hi Petr,

Just to let you know and complementing, it seems all my e-mails fall in
the moderator approval, is the filtering ok, is every kind of email
moderator-checked ?

Thanks
Rafael Cabral


 Original Message  
   Subject: 
gcc 4.6.2
  Date: 
Mon, 19 Dec 2011 10:26:15 -0200
  From: 
Rafael Cabral

  Reply-To: 
cab...@mandriva.com.br
  Organization: 
Mandriva
To: 
michael.me...@suse.com,
libreoffice@lists.freedesktop.org


Hi,

Attached is a patch for reviewing that I've prepared to solved some LO 
3.4 build issues related to GCC 4.6.2. It was also tested and compiles 
fine with GCC 4.6.1. Mostly issues are stated on 
(https://bugs.freedesktop.org/show_bug.cgi?id=43139)

Btw, I sent it last week to the LibreOffice mail list but the e-mail 
falls in the moderator approval. Anyway consider the patch in this e-mail
as the most updated one.


kind of regards
Rafael Cabral
--- ./framework/source/accelerators/acceleratorcache.cxx.orig	2011-12-15 15:08:41.329168423 -0200
+++ ./framework/source/accelerators/acceleratorcache.cxx	2011-12-15 15:17:59.473190664 -0200
@@ -61,7 +61,7 @@ AcceleratorCache::AcceleratorCache()
 AcceleratorCache::AcceleratorCache(const AcceleratorCache& rCopy)
 : ThreadHelpBase(&Application::GetSolarMutex())
 {
-m_lCommand2Keys = rCopy.m_lCommand2Keys;
+m_lCommand2Keys = const_cast< framework::BaseHash >& > (rCopy.m_lCommand2Keys);
 m_lKey2Commands = rCopy.m_lKey2Commands;
 }
 
@@ -78,7 +78,7 @@ void AcceleratorCache::takeOver(const Ac
 // SAFE -> --
 WriteGuard aWriteLock(m_aLock);
 
-m_lCommand2Keys = rCopy.m_lCommand2Keys;
+m_lCommand2Keys = const_cast< framework::BaseHash >& > (rCopy.m_lCommand2Keys);
 m_lKey2Commands = rCopy.m_lKey2Commands;
 
 aWriteLock.unlock();
--- ./framework/source/loadenv/loadenv.cxx.orig	2011-12-15 15:08:15.771487938 -0200
+++ ./framework/source/loadenv/loadenv.cxx	2011-12-15 15:19:06.038358483 -0200
@@ -255,7 +255,8 @@ void LoadEnv::initializeLoading(const ::
 // take over all new parameters.
 m_xTargetFrame.clear();
 m_xBaseFrame= xBaseFrame;
-m_lMediaDescriptor  = impl_mergeMediaDescriptorWithMightExistingModelArgs(lMediaDescriptor);
+::comphelper::MediaDescriptor tmp = impl_mergeMediaDescriptorWithMightExistingModelArgs(lMediaDescriptor);
+m_lMediaDescriptor  =  tmp;
 m_sTarget   = sTarget   ;
 m_nSearchFlags  = nSearchFlags  ;
 m_eFeature  = eFeature  ;
--- ./framework/source/uiconfiguration/uiconfigurationmanagerimpl.hxx.orig	2011-12-15 15:08:49.033072112 -0200
+++ ./framework/source/uiconfiguration/uiconfigurationmanagerimpl.hxx	2011-12-15 15:11:07.209344668 -0200
@@ -175,6 +175,15 @@ namespace framework
 sal_Int16 nElementType;
 UIElementDataHashMap  aElementsHashMap;
 com::sun::star::uno::Reference< com::sun::star::embed::XStorage > xStorage;
+UIElementType& operator=(const UIElementType& rRight) {
+bModified = rRight.bModified;
+bLoaded = rRight.bLoaded;
+bDefaultLayer = rRight.bDefaultLayer;
+nElementType = rRight.nElementType;
+aElementsHashMap = rRight.aElementsHashMap;
+xStorage = rRight.xStorage;
+return *this;
+};
 };
 
 typedef ::std::vector< UIElementType > UIElementTypesVector;
--- ./framework/inc/uiconfiguration/moduleuiconfigurationmanager.hxx.orig	2011-12-19 11:10:56.0 +
+++ ./framework/inc/uiconfiguration/moduleuiconfigurationmanager.hxx	2011-12-19 11:12:06.0 +
@@ -185,6 +185,15 @@ namespace framework
 sal_Int16 nElementType;
 UIElementDataHashMap  aElementsHashMap;
 com

Re: [Libreoffice] Build problems (and some solutions) in Mac OSX

[Tor Lillqvist]

Anyway, I forgot to say: Welcome to hacking on LibreOffice!

We will try to help you in all ways we can. Especially for Mac OS X,
many of the system APIs used by the code are slightly obsolete, to put
it mildly. It would be very much welcome, if you are a Mac expert, if
you could help in modernising that code. I mean mainly the stuff in
vcl/aqua, which uses APIs that were marked as obsolete already in the
10.4 SDK. (The code won't even compile against the 10.7 SDK because of
that; those APIs are now gone completely from headers. Even if
apparently still present in the 10.7 run-time libraries, as code using
those APIs still works...)

As you probably will find out about it yourself anyway, I will tell
you right away: There is another descendant of the OpenOffice.org
codebase called NeoOffice which is developed only for the Mac, and
they do have (at least based on what they say on their website)
modernised the code a lot. But, they license their changes under the
GPL, which means stuff from their code can't be simply picked to
LibreOffice. So please don't look too closely at their code, if at
all. Reading their textual descriptions of their improvements is fine,
though.

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

Re: [Libreoffice] [PATCH][PUSHED] Build problems (and some solutions) in Mac OSX

[Norbert Thiebaud]

On Tue, Dec 20, 2011 at 12:04 AM, James C
 wrote:
> Hello All,
>
> I have burned about 1.5 GB of metered network bandwidth, so far,
> following these instructions:
>
> http://wiki.documentfoundation.org/Development/How_to_build#Getting_the_sources
>
> I have found and, I think fixed, problems which occur on both
> origin/master and origin/libreoffice-3-5, where the test for a
> parallel build bug presumes that mktmp and the thing to do sha1 hash
> sums look like they do on linux.  A patch is attached, which I *think*
> will not break the linux builds.  I release this change under GPLv3
> and MPL, as requested.  I hope that nobody has a software patent on
> the idea of correctness in code :-)

Looks nice, Thanks, pushed.

>
> There is also a human-sized problem, with some instructions on the
> web-site being wrong:
> https://bugs.freedesktop.org/show_bug.cgi?id=43920
>
> I am now stuck, and have not yet built libre-office.  There are two
> ways forward; one technical and one human.
>
> The technical one is:
>  - my builds of origin/master and origin/libreoffice-3-5 fail in
> pango, because it depends on where cairo gets its fonts from, and on
> Apple Aqua, cairo gets its fonts from quartz, for which the
> corresponding parts of pango seem not to have been written
>
>  - this bug records my journey:
>    https://bugs.freedesktop.org/show_bug.cgi?id=43917
>
>  - I expect that I will not complete it without help
>
>  - how, if at all, is this software buildable under MacOS?
>
> The human one is:
>  - prebuilt LibreOffice 3.4.4 OOO340m1 (Build:402) from here:
>    http://www.libreoffice.org/download/
>    runs on my Mac, so it must be buildable
>
>  - I cannot find the OOO340m1 tag in the git repository that I have
> already invested resources in downloading

1/ no OOO340m1 is _not_ a tag, just a reference to the lasted OOo
version that was 'merged' into lo.

2/ the 3.4 branch was build using a 'split repo' scheme. back then we
had 19 git repos... in august we merged most of them into what is
known as 'core'. see:
http://wiki.documentfoundation.org/Development/One_Git_Conversion for
the gory details...

since then the two repos have diverged... the old set is only used for
maintainling the 3-4 branch... and 3.4.4 occurred after the switch, so
it is not in core.
so, since you already invested in the core repo, you may want to stick
to the 3-5 beta



>
>  - I do not understand which pieces of the source I would need, in
> order to play with Writer, and how big they would be

The writer code is in sw.
but you still to build thw 'whole' there is no method to build 'just writer'

>
>  - please can there be a link on the download page, to an explanation
> of how the various torrents relate to the various repositories?

torrent? you mean for binary download ? if so, I don't think that idea
will be popular. the binary download page is targeted to the public at
large, not develppers.. trying to explain the layout of our source
repo there is going to create more confusion than anything else.

>
>  - better yet, please can the source for this version be put into the
> repository, and I be told how to change to it?

there is a source download
see
http://www.libreoffice.org/download
and click on 'downalod the source and build your own installer'

the problem is that it is a tar.gz snapshot... making patch will be
problematic 9more exactly up-streaming them. and that method of
building is not very often practiced... so help is scarce.

Now regarding your freetype problem:

1/ you want to send your autogen.lastrun (that will tell us which
options/configuration you used to build... even better the output of
your autogen.sh
2/ some info about extra stuff you have, I presume you have the
pre-req XCode3 with 10.4 SDK, but also pay attention about the
possible nefaste interaction with macports and the like...

The good news is that both 3-5 and master build on MacOSX quite
regularly see: http://tinderbox.libreoffice.org/libreoffice-3-5/status.html,
so it is most likely some local configuration quick that surely can be
fixed :-)

Cheers,

Norbert

PS: thanks again for the patch. Few pointers for the next time: 1/
prefix the subject of the email with [PATCH]. that help us spot them
:-)  2/ if you can, try to learn how to do a commit (locally on your
own copy of git repo). that way you can create a nice patch using git
foramt-patch that is easier for us to apply, and already contain you
name and email (as the author) and preferably a nice comment for the
git log.
see : http://wiki.documentfoundation.org/Development/Patch_Handling_Guideline
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Build problems (and some solutions) in Mac OSX

[Tor Lillqvist]

You fail to give useful information to help you with your problems...

- What version of MacOSX are you running? What Xcode?
- What branch of the source code are you building?
- What exact error messages do you see, at what point in the build?
- How exactly did you configure your build? What does your
autogen.lastrun look like?

Anyway, some general answers to your question:
- Yes. LibreOffice can be built on MacOSX. As far as I know, on
versions from 10.4 to 10.7. (Myself I build on 10.7.) From the normal
sources.
- Yes, nothing extra is supposed to be needed, as long as you
--disable-mozilla. At least on 10.7 that's true, but then the Perl
there seems to come with the modules you mention. Maybe on earlier
versions it didn't.
- The master branch, and 3.5, use a different git repository structure
than earlier versions. In master and 3.5, there is one repository for
code, "core", and then optional repositories for localisation and
help. In 3.4 there was a whole bunch of repositories for code.

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

[Libreoffice] [PATCH] Fix fdo#39639 [EasyHack] Fix duplicate longname IDs

[Victor Lee]

Hello,
the attached patch simply removes duplicated and unused IDs in
BackgroundsDialog.

Victor Lee
diff --git a/wizards/com/sun/star/wizards/common/HelpIds.java b/wizards/com/sun/star/wizards/common/HelpIds.java
index 12af48a..4c9971b 100644
--- a/wizards/com/sun/star/wizards/common/HelpIds.java
+++ b/wizards/com/sun/star/wizards/common/HelpIds.java
@@ -139,10 +139,10 @@ public class HelpIds
 "HID:WIZARDS_HID_BG_BTN_IMG10",// HID:34306
 "HID:WIZARDS_HID_BG_BTN_IMG11",// HID:34307
 "HID:WIZARDS_HID_BG_BTN_IMG12",// HID:34308
-"HID:WIZARDS_HID_BG_BTN_IMG13",// HID:34309
-"HID:WIZARDS_HID_BG_BTN_IMG14",// HID:34300
-"HID:WIZARDS_HID_BG_BTN_IMG15",// HID:34311
-"HID:WIZARDS_HID_BG_BTN_IMG16",// HID:34312
+PropertyNames.EMPTY_STRING,
+PropertyNames.EMPTY_STRING,
+PropertyNames.EMPTY_STRING,
+PropertyNames.EMPTY_STRING,
 PropertyNames.EMPTY_STRING,
 PropertyNames.EMPTY_STRING,
 PropertyNames.EMPTY_STRING,
diff --git a/wizards/com/sun/star/wizards/common/HelpIds.py b/wizards/com/sun/star/wizards/common/HelpIds.py
index c6bd1b7..38a8bf7 100644
--- a/wizards/com/sun/star/wizards/common/HelpIds.py
+++ b/wizards/com/sun/star/wizards/common/HelpIds.py
@@ -109,10 +109,10 @@ class HelpIds:
 "HID:WIZARDS_HID_BG_BTN_IMG10", # HID:34306
 "HID:WIZARDS_HID_BG_BTN_IMG11", # HID:34307
 "HID:WIZARDS_HID_BG_BTN_IMG12", # HID:34308
-"HID:WIZARDS_HID_BG_BTN_IMG13", # HID:34309
-"HID:WIZARDS_HID_BG_BTN_IMG14", # HID:34300
-"HID:WIZARDS_HID_BG_BTN_IMG15", # HID:34311
-"HID:WIZARDS_HID_BG_BTN_IMG16", # HID:34312
+"",
+"",
+"",
+"",
 "",
 "",
 "",
diff --git a/wizards/com/sun/star/wizards/web/WWHID.java b/wizards/com/sun/star/wizards/web/WWHID.java
index 8baa372..9cc7670 100644
--- a/wizards/com/sun/star/wizards/web/WWHID.java
+++ b/wizards/com/sun/star/wizards/web/WWHID.java
@@ -132,11 +132,7 @@ public interface WWHID
 public static final int HID_BG_BTN_IMG9 = 34200 + 105;
 public static final int HID_BG_BTN_IMG10 = 34200 + 106;
 public static final int HID_BG_BTN_IMG11 = 34200 + 107;
-public static final int HID_BG_BTN_IMG12 = 34200 + 108;
-public static final int HID_BG_BTN_IMG13 = 34200 + 109;
-public static final int HID_BG_BTN_IMG14 = 34200 + 100;
-public static final int HID_BG_BTN_IMG15 = 34200 + 111;
-public static final int HID_BG_BTN_IMG16 = 34200 + 112;//   web wizard icons sets dialog
+public static final int HID_BG_BTN_IMG12 = 34200 + 108;//   web wizard icons sets dialog
 public static final int HID_IS = 41000 + 0;
 public static final int HID_IS_ICONSETS = 41000 + 1;
 public static final int HID_IS_BTN_NONE = 41000 + 2;
diff --git a/wizards/com/sun/star/wizards/web/WWHID.py b/wizards/com/sun/star/wizards/web/WWHID.py
index 28b3aaa..c71fda8 100644
--- a/wizards/com/sun/star/wizards/web/WWHID.py
+++ b/wizards/com/sun/star/wizards/web/WWHID.py
@@ -86,11 +86,7 @@ HID_BG_BTN_IMG8 = 34200 + 104
 HID_BG_BTN_IMG9 = 34200 + 105
 HID_BG_BTN_IMG10 = 34200 + 106
 HID_BG_BTN_IMG11 = 34200 + 107
-HID_BG_BTN_IMG12 = 34200 + 108
-HID_BG_BTN_IMG13 = 34200 + 109
-HID_BG_BTN_IMG14 = 34200 + 100
-HID_BG_BTN_IMG15 = 34200 + 111
-HID_BG_BTN_IMG16 = 34200 + 112  #web wizard icons sets dialog
+HID_BG_BTN_IMG12 = 34200 + 108  #web wizard icons sets dialog
 HID_IS = 41000 + 0
 HID_IS_ICONSETS = 41000 + 1
 HID_IS_BTN_NONE = 41000 + 2
diff --git a/wizards/util/hidother.src b/wizards/util/hidother.src
index bf1953e..004b0ff 100644
--- a/wizards/util/hidother.src
+++ b/wizards/util/hidother.src
@@ -238,14 +238,6 @@ hidspecial HID { HelpID = HID_BG_BTN_IMG10; } ;
 hidspecial HID { HelpID = HID_BG_BTN_IMG11; } ;
 // #define	HID_BG_BTN_IMG12	34308
 hidspecial HID { HelpID = HID_BG_BTN_IMG12; } ;
-// #define	HID_BG_BTN_IMG13	34309
-hidspecial HID { HelpID = HID_BG_BTN_IMG13; } ;
-// #define	HID_BG_BTN_IMG14	34300
-hidspecial HID { HelpID = HID_BG_BTN_IMG14; } ;
-// #define	HID_BG_BTN_IMG15	34311
-hidspecial HID { HelpID = HID_BG_BTN_IMG15; } ;
-// #define	HID_BG_BTN_IMG16	34312
-hidspecial HID { HelpID = HID_BG_BTN_IMG16; } ;
 
 // ++
 // Note: Web Wizard continues on 41000 later in this file.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice