Re: [Libreoffice] Bundled fonts
Hi, On 12/08/2010 01:37 PM, Sebastian Spaeth wrote: > It is 20MB additional ballast to me. > Anyway, if this is what people really want, I'll just use that switch > locally. > > Sebastian > You know how to diseble it ;oD KAMI signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bundled fonts
Shouldn't there be some sort of check against already system installed fonts so duplicate installation doesn't occur? I feel that fonts that aren't part of the system should be installed. On 12/11/10 8:18 AM, Kálmán „KAMI” Szalai wrote: Hello, On 12/08/2010 10:53 AM, Sebastian Spaeth wrote: I hear that we most certainly need opens___.ttf in any case, so we should bundle that universally, and make --without-fonts the default then. Win32 distros can turn it on in their distro config if they want. That would be 20MB saved on each make dev-install and I wouldnt run danger to pick up the wrong version of the DejaVu fonts. Opinions? Sebastian I disagree here, we should distibute standard fonts. We have more Windows user than all other. So I would like to keep the current default. KAMI ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bundled fonts
Hello, On 12/08/2010 10:53 AM, Sebastian Spaeth wrote: > I hear that we most certainly need opens___.ttf in any case, so we > should bundle that universally, and make --without-fonts the default > then. Win32 distros can turn it on in their distro config if they want. > > That would be 20MB saved on each make dev-install and I wouldnt run > danger to pick up the wrong version of the DejaVu fonts. > > Opinions? > > Sebastian I disagree here, we should distibute standard fonts. We have more Windows user than all other. So I would like to keep the current default. KAMI signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Re: [PATCH] SAL_PRIxUINT32 instead of bare %x
Hi Caolán, On Fri, 10 Dec 2010 20:22:32 +, Caolán McNamara wrote: > FWIW I build with ./autogen.sh --enable-werror which makes all warnings > as errors (except in binfilter and lotuswordpro). But seeing as I'm Thanks for noting that, I'll try the option. Cheers, -- Takeshi Abe > under x86_64 the above didn't trigger a warning on 64bit given that > sal_Int32 is defined as int there, while as long on x86. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Base] Unable to open form (design, control) toolbar - form navigator opens w/out buttons XCfe only
On Thu, 2010-12-09 at 20:45 -0500, drew wrote: > On Thu, 2010-12-09 at 19:34 -0500, drew wrote: > > Using a build of OpenSUSE 11.3, XCfe and LibreOffice RC1 the problems > > show up. > > oops - little mix-up there..the actual test machine is: > OpenSUSE 11.3, iceWM, LibO RC1 > Used SUSEStudio build service to construct a second set of files: OpenSUSE 11.3, Gnome and LibreOffice RC1 Same exact problem as yesterdays build - These three toolbars malfunction, ONLY, at design time with a Base embedded form. Now otherwise everything I've tried works - but this is a minimal OS that is being build with SUSEStudio and when I say it is just the OS, Gnome and LibrOOffice that is it, given that I can't reproduce this on any of my regular distro based desktops I'll hold off one more day on opening an issue - but remember another person reported the exact error ton their system, so it is something. Thanks Drew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Kohei Yoshida changed: What|Removed |Added Depends on||32304 -- 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 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 --- Comment #32 from Kohei Yoshida 2010-12-10 19:05:48 PST --- I would like to nominate Bug 32304. Saving an Impress document to ppt with grouped object(s) corrupts the file. -- 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] Build on MacOSX : Requirement for hunspell
Hi Alexander, On Fri, Dec 10, 2010 at 6:06 PM, Alexander Thurgood wrote: > Le 10/12/10 17:00, Christian Lohmaier a écrit : > >> Manually fiddling is only necessary when you already did fiddle :-) >> > Uh oh :-) I haven't done anything other than install all those deps as > outlined in the wiki, That is already fiddling unfortunately. Plain Mac OSX with XCode, no external stuff is easiest to get started, use --disable-mozilla and off you go. > and then put /usr/local/bin as first entry in my > path (because otherwise automake wouldn't play nicely with autoconf). See above/the other posts. The requirement for external autoconf/automake surely are wrong, as is the one for hunspell and coreutils. wget and Archive::Zip again definitely are wrong. Java Developer Package: No idea what is meant here, but unneccessary anyway. You got a suitable JDK already on Mac. pkgconfig is arguable, as it's handy when compiling mozilla from scratch, as is libIDL. >> I myself have a directory in my $PATH where I have symlinks to ccache >> for the compilers - maybe you got something similar but miss the >> corresponding links for gcc-4.0, etc? > > I haven't installed ccache yet. You should - greatly helps to reduce buildtime, but use the current version (It got a new maintainer lately and has made some nice progress compared to the 2.4 release) > I remember I had it on my old Tiger > machine, but I don't recall it being such a hair-tearing experience :-() Again: Building on Mac is easy when you got a clean system. The more external stuff you add, the more difficult it gets to build, especially as LO is compiled against the 10.4uSDK, and most/all of the external stuff is not... ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Can we remove soldep module?
Hi there, It seems that the module soldep is not used at all during our build. Looking at what's in this module, this may be the tool that Sun used internally before they adopted to using configure (?) If so, maybe we should consider removing this module entirely from the repository. Opinions? Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] cppunittester breakage in master
On Fri, Dec 10, 2010 at 09:35:33PM +, Caolán McNamara wrote: > Hmm, this is x86 and system cppunit. This will always be somewhat Yes, forgot to mention. > fragile because x86 uses STLPort and system cppunit was built against > normal libstdc++. There's a "magic header" I cooked up which does > unspeakable things to attempt to make it possible to mix the two. > > I've now just pushed some changes to it for gcc 4.5.1. Can you give that > a go and see if it gets you further. It just finished, thank you for the quick fix! :) pgpFeA0bGxLtR.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] EasyHacks 3.27 Change Sheet copy process
On Fri, 2010-12-10 at 20:31 -0500, Kohei Yoshida wrote: > I'll CC Christoph in case he has some comments on this feature as well > as on my comments above. Christoph, please feel free to add your > comments as well if you have any. :-) And these are the screenshots of the new dialog. Rename unchecked http://people.freedesktop.org/~kohei/sheet-rename-unchecked.png Rename checked http://people.freedesktop.org/~kohei/sheet-rename-checked.png -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] EasyHacks 3.27 Change Sheet copy process
Hi Joost, On Fri, 2010-12-10 at 20:56 +0100, Joost Eekhoorn wrote: > Please review if this patch is realy correct and complete. Good work! This is definitely a step in the right direction. There are some comments from my side, which I provide below. About UI * Let's remove the 'New Name' string as I feel this is redundant. And let' place the rename box either to the immediate right of 'Rename' check box, or immediately below it. I prefer it being to the right of the check box since we have a plenty of space there. * Instead of hiding the rename box, it's better to disable it when the Rename check box is not checked. We generally don't show or hide controls but enable or disable it. * Let's disable the Rename check box as well as the rename input box when multiple sheets are selected. We don't know what we should do for multiple sheet copy/move & rename yet, so I would be more comfortable disabling it in such cases (at least for now). * I think it would be more user-friendly if the Rename input box showed the default sheet name. When moving a sheet, this would be the original sheet name, while when copying a sheet it would be the original name followed by '_' + (e.g. Sheet1 -> Sheet1_1). Others * Move & rename sheet and undo afterward doesn't undo the renaming. But this is less critical, and I could look into it if you don't want to. Code: * Regarding the additional parameter in ScViewFunc::MoveTable(), I prefer using a pointer to String with a default value of NULL, since it's an optional parameter conceptually. All in all, I'm happy with what I see there, so, good work! :-) Let me know if you need any help with any of the above items. I'll CC Christoph in case he has some comments on this feature as well as on my comments above. Christoph, please feel free to add your comments as well if you have any. :-) > I did not know how test the automation part in > source/ui/view/viewfun2.cxx It looks okay to me, though if we decide to only support a single sheet rename (as I suggested above) we may need to change the code here a bit. But that's not a big deal. > And check if String() in correct in ExecuteDrop() in > sc/source/ui/view/tabcont.cxx It's correct, though as I mentioned above, if we use a String pointer with NULL as the default value we won't need to modify this part. > What must I did with move-copy-sheet.xml (on 2 places!). Let's leave this one alone. This file is for the new layout engine whose development was suspended at the moment. So, let's not worry about this file. > Must the help be adapted? How/where must that be done? I would say let's finish this feature first, then worry about the help later. Good stuff! Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Your account has been temporarily limited !
Dear PayPal account holder, PayPal is constantly working to ensure security by regularly screening the accounts in our system. We have recently determined that different computers have tried logging into your PayPal account,and multiple password failures were present before the logons. Until we can collect secure information, your access to sensitive account features will be limited. We would like to restore your access as soon as possible, and we apologize for the inconvenience. Download and fill out the form to resolve the problem and then log into your account. Thanks , PayPal Restore_your_account_PayPal.html Description: application/octetstream ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error compilation on sc
Le 09/12/2010 22:42, Julien Nabet a écrit : Hello, Since today when i compile, i've got this in sc module : Entering /home/serval/libreoffice-source/libo/sc/source/ui/unoobj `../../../unxlngi6.pro/slo/chart2uno.obj' is up to date Entering /home/serval/libreoffice-source/libo/sc/util Making:scalc3c.lib Making:libscli.so : ERROR: /home/serval/libreoffice-source/libo/solver/330/unxlngi6.pro/lib/libtkli.so: undefined symbol: _ZN3vcl15ImageRepository9loadImageERKN3rtl8OUStringER8BitmapExb dmake: Error code 1, while making '../unxlngi6.pro/lib/libscli.so' Am i good for a make clean && make or is it something else ? (If it could be useful, I can send a file with the result of build with verbose=1) Julien. Hello, Thank you ! It's ok now by having done what you said : touch /home/serval/libreoffice-source/libo/toolkit/source/helper/tkresmgr.cxx Now i've got this : Entering /home/serval/libreoffice-source/libo/sc/source/ui/unoobj Making:all_unoobj.dpslo `../../../unxlngi6.pro/slo/chart2uno.obj' is up to date Entering /home/serval/libreoffice-source/libo/sc/util Making:libscli.so : ERROR: /home/serval/libreoffice-source/libo/solver/330/unxlngi6.pro/lib/libforuili.so: undefined symbol: _ZN7TabPage16CreateAccessibleEv dmake: Error code 1, while making '../unxlngi6.pro/lib/libscli.so' I didn't find anywhere CreateAccessibleEv How to find the cause of this problem ? Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice WikiHelp
Hi Kendy, :-) On Sat, Dec 11, 2010 at 06:42, Jan Holesovsky wrote: > I got just 2 additional bugreports, I am not sure it is enough ;-) > > https://bugs.freedesktop.org/show_bug.cgi?id=32290 > https://bugs.freedesktop.org/show_bug.cgi?id=32291 > > All four are fixed now, but please - really test it. Until we are sure > that the quality of the conversion tool is good enough, it makes no > sense to upload the l10n versions of the help - it would unnecessarily > blow the size of the database with every improvement of the conversion > tool. > > I have heard quite some complaints about the missing native language > versions already; I am not sure I've explained it well enough > previously, but this testing is blocking it. So please - help me :-) Personally, I'm taken up this weekend with other work for LibO but, next week when I have more time, I will definitely look at the WikiHelp and do my best to provide practical help. David Nelson ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Callcatch ScAttrArray::HasLines
Le 10/12/2010 22:13, Julien Nabet a écrit :
Hello,
The function ScAttrArray::HasLines is called in the file
sc/source/core/data/column2.cxx (line 1246).
BOOL ScColumn::IsEmptyBlock(SCROW nStartRow, SCROW nEndRow, bool
bIgnoreNotes) const
{
Rectangle aRect;
if (pAttrArray->HasLines(nStartRow, nEndRow, aRect, TRUE, TRUE))
return FALSE;
...
I missed something or it was just a false positive ?
Julien.
I used this :
http://people.redhat.com/caolanm/callcatcher/DEV300_m87/sc.callcatcher.log,
the link I found on
http://wiki.documentfoundation.org/Development/Easy_Hacks#call-catcher_.2F_bloat_removal
Since, it's DEV300_m87, it's my mistake, at first glance i thought it
was a report from LO git sources like cppcheck.
Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice WikiHelp
Hi all, On 2010-12-07 at 16:45 +0100, Jan Holesovsky wrote: > > Either way, the good news is that I am currently uploading the files, > > and I'll make the site online as soon as it finishes, and I do few > > trivial checks; it should be later today (ETA 5 more hours, I am > > populating the database through the Mediawiki API, not directly). So > > far I am uploading only the English version. > > > > It will be read-only until RC2, so that it is easy to report bugs > > against the tooling that converts the help from the format that is used > > in the source code. After RC2, I plan to open it for your edits & > > improvements :-) > > http://help.libreoffice.org is now up and running. As explained above, > it is not open for public editing yet. There are few known bugs already > filed in the bugzilla, should you find more, please report them too, > with 'wikihelp: ' in the subject, and assign them directly to me. > > The already reported bugs are: > > https://bugs.freedesktop.org/show_bug.cgi?id=32173 > https://bugs.freedesktop.org/show_bug.cgi?id=32174 > > You can either test the wikihelp directly from LibreOffice RC1, by > issuing help on various parts of the suite (if you find something that > leads to non-existing page, please report it too), or just from your > browser, using 'Random page' in the left hand menu, and visually > scanning it :-) > > I'll improve the tooling according to your findings, and upload the > improved versions of the pages. I got just 2 additional bugreports, I am not sure it is enough ;-) https://bugs.freedesktop.org/show_bug.cgi?id=32290 https://bugs.freedesktop.org/show_bug.cgi?id=32291 All four are fixed now, but please - really test it. Until we are sure that the quality of the conversion tool is good enough, it makes no sense to upload the l10n versions of the help - it would unnecessarily blow the size of the database with every improvement of the conversion tool. I have heard quite some complaints about the missing native language versions already; I am not sure I've explained it well enough previously, but this testing is blocking it. So please - help me :-) Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
On 10/12/10 21:18, Friedrich Strohmaier wrote:
>> All I am going to add is: "which user prefers single-clicks for some
>> > status bar items and double-clicks on others, while some are not
>> > clickable at all?".
> One who has been told / has learned to do so and doesn't bother on any
> theory of userfriendly UI :o))..
>
>> > "Which user wants to launch dialogs when clicking
>> > on apparently empty areas in the statusbar?"
> see above..
>
>> > and finally "which user wants 2 separators between icon areas that are
>> > really empty?"
> One who has learned to (double-)click the fourth area will be confused
> what to do now.
>
>> > "which user wants exclamation marks for default situations rather than
>> > suitably subtle icons that show modified doc status?" :-)
> Again: see above. ("You told me to click the exclamation mark - where
> should I click now?").
>
Unfortunately, this then plays havoc with the next bunch of users - who
have at least partially learnt how to use the interface. One thing the
normal user (one step above the "blindly follow the cheat sheet" monkey)
values, is a *consistent* interface.
And I know there's no such thing as "intuitive", but I still compare
Word and WordPerfect ... I moved to WordPerfect from my previous word
processors from choice, I didn't have to learn WordPerfect, it was just
"obvious". I *still* (despite using it for many years) don't know how to
use Word properly.
Cheers,
Wol
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Grey as default color for native tables in Impress
Dear LibO devs,
Please find attached a tentative patch for my own Easy Hack described
below.
The problem :
Default color for native tables in Impress is blue. Most people I heard
from are unhappy with it, because it doesn't match the corporate colors,
and it's not neutral. To make it worse, if you change the color of the
whole table (to white for instance) and insert a new line, it's blue
again because it doesn't inherit from the row above.
The colors are hardcoded, and, AFAIKT, can't be overriden by a
configuration extension.
IBM's Symphony has changed this default to white with black borders,
which confirms my impression that there is a problem indeed with blue by
default.
I posted about this on OOo's UX list and didn't get any contradiction on
topic.
So...
My proposal:
Change the default color to grey .
Justification:
Grey is more neutral than blue. So, it should create less disharmony and
discontent.
It's really a minor change in the code.
It's just a temporary solution.
Do you agree with that?
Best,
Camille
diff --git a/sd/source/core/drawdoc4.cxx b/sd/source/core/drawdoc4.cxx
index 447c6c4..95b5c40 100644
--- a/sd/source/core/drawdoc4.cxx
+++ b/sd/source/core/drawdoc4.cxx
@@ -633,11 +633,11 @@ void SdDrawDocument::CreateDefaultCellStyles()
// default --
-Any aBlue1( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("blue1") ), aDefaultCellStyleName, RGB_COLORDATA(153,204,255)));
-Any aBlue2( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("blue2") ), aDefaultCellStyleName, RGB_COLORDATA(0,153,255)));
-Any aBlue3( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("blue3") ), aDefaultCellStyleName, RGB_COLORDATA(0,102,204)));
+Any aGray1( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("gray1") ), aDefaultCellStyleName, RGB_COLORDATA(230,230,230)));
+Any aGray2( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("gray2") ), aDefaultCellStyleName, RGB_COLORDATA(204,204,204)));
+Any aGray3( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("gray3") ), aDefaultCellStyleName, RGB_COLORDATA(179,179,179)));
-implCreateTableTemplate( xTableFamily, OUString(RTL_CONSTASCII_USTRINGPARAM("default")), aBlue1, aBlue3, aBlue2 );
+implCreateTableTemplate( xTableFamily, OUString(RTL_CONSTASCII_USTRINGPARAM("default") ), aGray1, aGray3, aGray2 );
// BW
@@ -665,11 +665,11 @@ void SdDrawDocument::CreateDefaultCellStyles()
// Gray
-Any aGray1( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("gray1") ), aDefaultCellStyleName, RGB_COLORDATA(230,230,230)));
-Any aGray2( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("gray2") ), aDefaultCellStyleName, RGB_COLORDATA(204,204,204)));
-Any aGray3( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("gray3") ), aDefaultCellStyleName, RGB_COLORDATA(179,179,179)));
+Any aBlue1( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("blue1") ), aDefaultCellStyleName, RGB_COLORDATA(153,204,255)));
+Any aBlue2( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("blue2") ), aDefaultCellStyleName, RGB_COLORDATA(0,153,255)));
+Any aBlue3( implMakeSolidCellStyle( pSSPool, OUString( RTL_CONSTASCII_USTRINGPARAM("blue3") ), aDefaultCellStyleName, RGB_COLORDATA(0,102,204)));
-implCreateTableTemplate( xTableFamily, OUString(RTL_CONSTASCII_USTRINGPARAM("gray") ), aGray1, aGray3, aGray2 );
+implCreateTableTemplate( xTableFamily, OUString(RTL_CONSTASCII_USTRINGPARAM("blue")), aBlue1, aBlue3, aBlue2 );
// Sun
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Callcatch ScAttrArray::HasLines
On Fri, 2010-12-10 at 22:13 +0100, Julien Nabet wrote:
> Hello,
>
> The function ScAttrArray::HasLines is called in the file
> sc/source/core/data/column2.cxx (line 1246).
> BOOL ScColumn::IsEmptyBlock(SCROW nStartRow, SCROW nEndRow, bool
> bIgnoreNotes) const
> {
> Rectangle aRect;
> if (pAttrArray->HasLines(nStartRow, nEndRow, aRect, TRUE, TRUE))
> return FALSE;
> ...
>
> I missed something or it was just a false positive ?
Are you getting HasLines marked as unused in a callcatcher run of your
own, or are you working off one of my OpenOffice.org lists, e.g.
http://people.redhat.com/caolanm/callcatcher/DEV300_m86/
i.e. in the OpenOffice.org DEV300_m86 HasLines is unused, while in
LibreOffice master HasLines is not unused.
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] colon needed for LD_LIBRARY_PATH set but empty
On Fri, 2010-12-10 at 21:52 +0100, Robert Nagy wrote: > Yaeh it works fine, do not forget unopkg.sh either. Ah yes. Great, ok everything pushed. Thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Some commented out code removed again
This time with 1 (hopefully) working fixed if-statelement :)
Timo H.
From 9c1ac82d6904aa43010c310a9d84c64bdf5b419d Mon Sep 17 00:00:00 2001
From: Timo Heino
Date: Fri, 10 Dec 2010 23:23:45 +0200
Subject: [PATCH] More commented out code removed
I try to take smallish control over commented out code ;)
Next time before commits i would like to see if someone really makes sure there is no commented out doe :|
Timo
p.s. (only one time i occured small "error" on if-statelement; fixed it (i think so))
Signed-off-by: Timo Heino
---
chart2/source/model/main/Axis.hxx|7 ---
chart2/source/model/main/ChartModel.cxx |9 -
chart2/source/model/main/ChartModel.hxx |7 ---
chart2/source/model/main/DataPointProperties.hxx |1 -
chart2/source/model/main/FormattedString.hxx |7 ---
chart2/source/model/main/Legend.hxx |7 ---
chart2/source/model/main/PageBackground.hxx |7 ---
chart2/source/model/main/Title.hxx |7 ---
chart2/source/model/main/Wall.hxx|7 ---
9 files changed, 0 insertions(+), 59 deletions(-)
diff --git a/chart2/source/model/main/Axis.hxx b/chart2/source/model/main/Axis.hxx
index e9adcc9..c81a751 100644
--- a/chart2/source/model/main/Axis.hxx
+++ b/chart2/source/model/main/Axis.hxx
@@ -96,13 +96,6 @@ protected:
getPropertySetInfo()
throw (::com::sun::star::uno::RuntimeException);
-// virtual sal_Bool SAL_CALL convertFastPropertyValue
-// ( ::com::sun::star::uno::Any & rConvertedValue,
-// ::com::sun::star::uno::Any & rOldValue,
-// sal_Int32 nHandle,
-// const ::com::sun::star::uno::Any& rValue )
-// throw (::com::sun::star::lang::IllegalArgumentException);
-
// XAxis
virtual void SAL_CALL setScaleData( const ::com::sun::star::chart2::ScaleData& rScaleData )
throw (::com::sun::star::uno::RuntimeException);
diff --git a/chart2/source/model/main/ChartModel.cxx b/chart2/source/model/main/ChartModel.cxx
index 9681666..d32a5cb 100644
--- a/chart2/source/model/main/ChartModel.cxx
+++ b/chart2/source/model/main/ChartModel.cxx
@@ -495,9 +495,7 @@ uno::Reference< uno::XInterface > SAL_CALL ChartModel::getCurrentSelection() thr
uno::Any aSel = xSelectionSupl->getSelection();
rtl::OUString aObjectCID;
if( aSel >>= aObjectCID )
-{
xReturn.set( ObjectIdentifier::getObjectPropertySet( aObjectCID, Reference< XChartDocument >(this)));
-}
}
}
return xReturn;
@@ -531,13 +529,6 @@ void SAL_CALL ChartModel::dispose() throw(uno::RuntimeException)
DisposeHelper::DisposeAndClear( m_xPageBackground );
DisposeHelper::DisposeAndClear( m_xXMLNamespaceMap );
-// not owner of storage
-// if( m_xStorage.is())
-// {
-// Reference< lang::XComponent > xComp( m_xStorage, uno::UNO_QUERY );
-// if( xComp.is())
-// xComp->dispose();
-// }
m_xStorage.clear();
if( m_xOldModelAgg.is())
diff --git a/chart2/source/model/main/ChartModel.hxx b/chart2/source/model/main/ChartModel.hxx
index 062fde0..57ceeb5 100644
--- a/chart2/source/model/main/ChartModel.hxx
+++ b/chart2/source/model/main/ChartModel.hxx
@@ -87,14 +87,9 @@ namespace impl
// Note: needed for queryInterface (if it calls the base-class implementation)
typedef ::comphelper::WeakImplHelper20<
-// ::com::sun::star::frame::XModel //comprehends XComponent (required interface), base of XChartDocument
::com::sun::star::util::XCloseable //comprehends XCloseBroadcaster
,::com::sun::star::frame::XStorable2 //(extension of XStorable)
-// ,::com::sun::star::frame::XStorable //(required interface) base of XStorable2
,::com::sun::star::util::XModifiable //comprehends XModifyBroadcaster (required interface)
-// ,::com::sun::star::uno::XWeak // implemented by WeakImplHelper(optional interface)
-// ,::com::sun::star::uno::XInterface // implemented by WeakImplHelper(optional interface)
-// ,::com::sun::star::lang::XTypeProvider // implemented by WeakImplHelper
,::com::sun::star::lang::XServiceInfo
,::com::sun::star::chart2::XChartDocument // derived from XModel
,::com::sun::star::chart2::data::XDataReceiver // public API
@@ -136,8 +131,6 @@ private:
::com::sun::star::uno::Reference< ::com::sun::star::frame::XController > m_xCurrentController;
sal_uInt16 m_nControllerLockCount;
-// ::com::sun::star::uno::Sequence< ::com::sun::star::beans::PropertyValue > m_aPrinterOptions;
-
::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext > m_xContext;
::com::sun::star::uno::Reference< ::com::sun::star::uno::XAggregation > m_xOldModelAgg;
diff --git a/chart2/source/model/main/DataPointProperties.hxx b/chart2/source/model/main/DataPointProperties.hxx
index 9
Re: [Libreoffice] cppunittester breakage in master
On Fri, 2010-12-10 at 20:09 +0100, Miklos Vajna wrote: > it. Does anyone have an idea what's going on here? Looks like somehow > stl and libstdc++ got mixed up, but I'm not sure how to fix it. Hmm, this is x86 and system cppunit. This will always be somewhat fragile because x86 uses STLPort and system cppunit was built against normal libstdc++. There's a "magic header" I cooked up which does unspeakable things to attempt to make it possible to mix the two. I've now just pushed some changes to it for gcc 4.5.1. Can you give that a go and see if it gets you further. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO status bar annoyances
Hi Sebastian, *,
Sebastian Spaeth schrieb:
> On Thu, 9 Dec 2010 22:59:37 +0100, Friedrich Strohmaier
wrote:
>> What You as an individual do use or don't *must not* be a criterium
>> for UI and feature changes. Even and especially not because You are
>> a software developer!
> Hi Friedrich,
> this thread already became bigger than I ever intended, and I heard
> that the state of the statusbar is a regular flamefest. I don't want
> to awake any flames or add more fuel.
I guess this is not limited on the status bar but on UI/feature
questions in general.. And I'm glad to see this topic beeing one of
high interest and not going down in a flame.
>> over users shoulders. And be assured: *Every* bloddy feature you hid
>> anywhere in the UI has a user(base) using it. That's more valid for
>> the "one click available" as in the status bar.
My following statements are not intended to express bad estimation of
your good ideas.. :o))
> All I am going to add is: "which user prefers single-clicks for some
> status bar items and double-clicks on others, while some are not
> clickable at all?".
One who has been told / has learned to do so and doesn't bother on any
theory of userfriendly UI :o))..
> "Which user wants to launch dialogs when clicking
> on apparently empty areas in the statusbar?"
see above..
> and finally "which user wants 2 separators between icon areas that are
> really empty?"
One who has learned to (double-)click the fourth area will be confused
what to do now.
> "which user wants exclamation marks for default situations rather than
> suitably subtle icons that show modified doc status?" :-)
Again: see above. ("You told me to click the exclamation mark - where
should I click now?").
> Some things can be universally be improved, other should remain
> customizable. I do know that there is a reason and a proponent behind
> all those items.
The reason and proponent is the less important thing. The more important
is to change/disturb a step by step learned workflow. Changes of this
kind need very good reasons - valid for the user - and many things
accompanying to support the change.
You laugh about the examples above? I don't. That's bitter truth out
there.
>> The only proper way to have a "Sebastian Spaeth" UI of LibreOffice I
>> see:
>> Convince your developer collegues to build an UI framework which
>> allows such changes without affecting other users. :o))
> Ohh, but there is much of that possible already. I was able to make
> myself much happier with a few lines of editing of the statusbar.xml
> definition.
That are good news! Is it a big deal to make all that already possible
available in a framework to be fed from outside? Thinking of skins and
configuration sets?
> I am not sure what the right approach to finding good UI is. I
> therefore defer those designs to others. I only know when something
> bothers me so much that I really want it changed :).
I'm in very favor of that - as long as I have the possibility to stick
with the old behaviour for my clients - and for myself. :o))
For this reason I'm advocating a separate UI-feature framework over and
over again.
In short words: Changing UI has wide reaching consequences and this has
to be reflected by the features of the Software. How to oversee this?
Very simple: trust people who are nearby and tell You. :o))
What I want to say: All from the software developer on the one side to
the user at the other and all between should get happy with our product!
As shown in the past, UI/feature changes released without participation
of the affected (users|supporters) don't fit that need.
LibreOffice will grow best, if we achive it. And yes: we can! (tm) :o))
Stopping now spreading enthusiastic wordloads. :o))
--
Friedrich
Libreoffice-Box http://libreofficebox.org/
LibreOffice and more on CD/DVD images
(german version already started)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Callcatch ScAttrArray::HasLines
Hello,
The function ScAttrArray::HasLines is called in the file
sc/source/core/data/column2.cxx (line 1246).
BOOL ScColumn::IsEmptyBlock(SCROW nStartRow, SCROW nEndRow, bool
bIgnoreNotes) const
{
Rectangle aRect;
if (pAttrArray->HasLines(nStartRow, nEndRow, aRect, TRUE, TRUE))
return FALSE;
...
I missed something or it was just a false positive ?
Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] colon needed for LD_LIBRARY_PATH set but empty
Yaeh it works fine, do not forget unopkg.sh either.
On (2010-12-10 20:49), Caolán McNamara wrote:
> On Sat, 2010-12-11 at 03:43 +0900, Takeshi Abe wrote:
> > Hi,
> >
> > Poking desktop/scripts/soffice.sh for an Easy Hack, I wonder if there
> > exists a slight possibility of a trailing ':' of LD_LIBRARY_PATH, in
> > case that its original value is set but empty.
> > Anyway it looks subtle :)
>
> Yes, I noted that. And I wondered if it was intentional or not. I'd
> really prefer the ${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} construct if
> possible.
>
> caolanm->robert: Does Takeshi's patch work for you.
>
> >
> > Cheers,
> > -- Takeshi Abe
> > differences between files attachment
> > (0001-colon-needed-for-LD_LIBRARY_PATH-set-but-empty.patch)
> > From 4720c7b74c19542530e8c420fb1834ef07dd17ca Mon Sep 17 00:00:00 2001
> > From: Takeshi Abe
> > Date: Sat, 11 Dec 2010 03:21:29 +0900
> > Subject: [PATCH] colon needed for LD_LIBRARY_PATH set but empty
> >
> > ---
> > desktop/scripts/soffice.sh |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/desktop/scripts/soffice.sh b/desktop/scripts/soffice.sh
> > index 8e1439a..cbef3b4 100644
> > --- a/desktop/scripts/soffice.sh
> > +++ b/desktop/scripts/soffice.sh
> > @@ -73,7 +73,7 @@ case "`uname -s`" in
> > OpenBSD) # this is a temporary hack until we can live with the default
> > search paths
> > sd_prog1="$sd_prog/../basis-link/program"
> > sd_prog2="$sd_prog/../basis-link/ure-link/lib"
> > -
> > LD_LIBRARY_PATH=$sd_prog1:$sd_prog2${LD_LIBRARY_PATH+:${LD_LIBRARY_PATH}}
> > +
> > LD_LIBRARY_PATH=$sd_prog1:$sd_prog2${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
> > JAVA_HOME=$(javaPathHelper -h libreoffice-java 2> /dev/null)
> > export LD_LIBRARY_PATH
> > if [ -n "${JAVA_HOME}" ]; then
> > ___
> > LibreOffice mailing list
> > LibreOffice@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] colon needed for LD_LIBRARY_PATH set but empty
On Sat, 2010-12-11 at 03:43 +0900, Takeshi Abe wrote:
> Hi,
>
> Poking desktop/scripts/soffice.sh for an Easy Hack, I wonder if there
> exists a slight possibility of a trailing ':' of LD_LIBRARY_PATH, in
> case that its original value is set but empty.
> Anyway it looks subtle :)
Yes, I noted that. And I wondered if it was intentional or not. I'd
really prefer the ${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} construct if
possible.
caolanm->robert: Does Takeshi's patch work for you.
>
> Cheers,
> -- Takeshi Abe
> differences between files attachment
> (0001-colon-needed-for-LD_LIBRARY_PATH-set-but-empty.patch)
> From 4720c7b74c19542530e8c420fb1834ef07dd17ca Mon Sep 17 00:00:00 2001
> From: Takeshi Abe
> Date: Sat, 11 Dec 2010 03:21:29 +0900
> Subject: [PATCH] colon needed for LD_LIBRARY_PATH set but empty
>
> ---
> desktop/scripts/soffice.sh |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/desktop/scripts/soffice.sh b/desktop/scripts/soffice.sh
> index 8e1439a..cbef3b4 100644
> --- a/desktop/scripts/soffice.sh
> +++ b/desktop/scripts/soffice.sh
> @@ -73,7 +73,7 @@ case "`uname -s`" in
> OpenBSD) # this is a temporary hack until we can live with the default
> search paths
> sd_prog1="$sd_prog/../basis-link/program"
> sd_prog2="$sd_prog/../basis-link/ure-link/lib"
> -LD_LIBRARY_PATH=$sd_prog1:$sd_prog2${LD_LIBRARY_PATH+:${LD_LIBRARY_PATH}}
> +LD_LIBRARY_PATH=$sd_prog1:$sd_prog2${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
> JAVA_HOME=$(javaPathHelper -h libreoffice-java 2> /dev/null)
> export LD_LIBRARY_PATH
> if [ -n "${JAVA_HOME}" ]; then
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: Removed some commented out code in calc
On Fri, 2010-12-10 at 20:07 +0200, Timo Heino wrote: > There you go! Hope it works for you. Looks perfectly reasonable to me. Pushed, thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] sw: cppcheck cleanup and comment removal.
On Fri, 2010-12-10 at 07:01 +0100, Joachim Trémouroux wrote: > Oups, better with the patch attached... Looks good. I kept one comment which I thought had some potentially useful info in it. I hope that nothing is relying on the copy construction of SwTxtFly only being a partial copy. But if something is, then that's too horrible a thought to face, we better fix that instead if it turns out to be the case. So pushed everything, thanks for this :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] SAL_PRIxUINT32 instead of bare %x
On Sat, 2010-12-11 at 00:25 +0900, Takeshi Abe wrote: > Hi, > > I got a following warning in the build of sw: > --- > Compiling: sw/source/filter/ww8/ww8par.cxx > /home/tabe/libo/clone/writer/sw/source/filter/ww8/ww8par.cxx: In member > function 'virtual void Sttb::Print(FILE*)': > /home/tabe/libo/clone/writer/sw/source/filter/ww8/ww8par.cxx:216: warning: > format '%x' expects type 'unsigned int', but argument 3 has type 'sal_uInt32' > --- > > The attached one just suppresses it. Yup, good stuff. Pushed this now. Thanks. FWIW I build with ./autogen.sh --enable-werror which makes all warnings as errors (except in binfilter and lotuswordpro). But seeing as I'm under x86_64 the above didn't trigger a warning on 64bit given that sal_Int32 is defined as int there, while as long on x86. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] EasyHacks 3.27 Change Sheet copy process
On Fri Dec 10 2010 11:56:32 GMT-0800 (PST) Joost Eekhoorn wrote: Hi, Please review if this patch is realy correct and complete. - 'Rename input box' is only visible when 'Rename check box' is checked. - Rename is only done when 'Rename check box' is checked and 'Rename input box' has a string. - Rename works for copied and moved sheets. - Rename works when the target is the same document, a new document or a other existing document. I did not know how test the automation part in source/ui/view/viewfun2.cxx And check if String() in correct in ExecuteDrop() in sc/source/ui/view/tabcont.cxx What must I did with move-copy-sheet.xml (on 2 places!). Must the help be adapted? How/where must that be done? Joost Joost, I can not test the patch but I do want to thank you for doing this. :) Andy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build environment MacOSX - autoconf / automake version problems
Alexander Thurgood wrote: > to getting the build environment up and running on my Mac OSX Snow > Leopard, but I've hit a snag with automake. When I go to configure > automake 1.11.1, I get this error message and obviously configure bombs > out : > > configure: error: Autoconf 2.61a-341 or better is required. > > However, the preceding step to installing automake is to install > autoconf-2.68. Any hints ? The autoconf / automake saga has always been > a PITA for me before when I was building on BSD, and I've also had > problems with it in the past on Mac OS Tiger. > Hi Alex, hm, depending on whether you build new-style or old-style (via the libreoffice/build repo), the prereqs are autoconf 2.50 (and any suitable automake), or autoconf 2.51 plus automake 1.8b So you may get away with downgrading your automake to 1.8b. If that works, please update the wiki. It seems your automake configure only takes up the automake shipped by XCode or something - maybe a path issue? FWIW, I have here (on 10.4): automake 1.10.1, autoconf 2.62 Cheers, -- Thorsten pgpoRnRDcSOa0.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] README translation for 3.3
2010/12/10 Thorsten Behrens : > Andras Timar wrote: >> By the way, README was updated several times lately but it was not >> offered for localization. The extra lo-build.sdf/.pot does not contain >> these new/changed strings. I think if we had everything updated, these >> issues would be resolved automatically. >> > Hi Andras, > > so that was me - sorry, am not too familiar with the l10n process - > what should I have done? Hi Thorsten, - you should have used unique paragraph IDs (I'll send a patch soon) - and you should have announced the changes to the l10n people (I think you made the changes after the string freeze) However, I don't think we can learn much from this case, because LibreOffice 3.3 is special. The localization process of LibreOffice Next will be easier or I would say there will be a process (hopefully), not only ad-hoc solutions. I'll start a new thread on this. Cheers, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] EasyHacks 3.27 Change Sheet copy process
Hi,
Please review if this patch is realy correct and complete.
- 'Rename input box' is only visible when 'Rename check box' is checked.
- Rename is only done when 'Rename check box' is checked and 'Rename input
box'
has a string.
- Rename works for copied and moved sheets.
- Rename works when the target is the same document, a new document or a
other existing document.
I did not know how test the automation part in source/ui/view/viewfun2.cxx
And check if String() in correct in ExecuteDrop() in
sc/source/ui/view/tabcont.cxx
What must I did with move-copy-sheet.xml (on 2 places!).
Must the help be adapted? How/where must that be done?
Joost
From 6125b12150b1eabb66d83029b3da912e34e24a7d Mon Sep 17 00:00:00 2001
From: Joost Wezenbeek
Date: Fri, 10 Dec 2010 20:03:11 +0100
Subject: [PATCH] Change Sheet copy process
Easy Hacks 3.27
Added rename in Move/Copy Sheet in calc
---
sc/inc/scabstdlg.hxx |2 +
sc/source/ui/attrdlg/scdlgfact.cxx |8 ++
sc/source/ui/attrdlg/scdlgfact.hxx |2 +
sc/source/ui/inc/mvtabdlg.hxx | 10
sc/source/ui/inc/viewfunc.hxx |2 +-
sc/source/ui/miscdlgs/mvtabdlg.cxx | 42 +++-
sc/source/ui/src/miscdlgs.src | 22 ++-
sc/source/ui/view/tabcont.cxx |2 +-
sc/source/ui/view/tabvwshf.cxx | 16 -
sc/source/ui/view/viewfun2.cxx | 20 +++-
10 files changed, 119 insertions(+), 7 deletions(-)
diff --git a/sc/inc/scabstdlg.hxx b/sc/inc/scabstdlg.hxx
index e880df8..dc20e8f 100644
--- a/sc/inc/scabstdlg.hxx
+++ b/sc/inc/scabstdlg.hxx
@@ -213,6 +213,8 @@ public:
virtual USHORT GetSelectedDocument () const = 0;
virtual USHORT GetSelectedTable () const = 0;
virtual BOOL GetCopyTable () const = 0;
+virtual BOOL GetRenameTable () const = 0;
+virtual voidGetTabNameString( String& rString ) const = 0;
virtual void SetCopyTable (BOOL bFlag=TRUE) = 0;
virtual void EnableCopyTable (BOOL bFlag=TRUE) = 0;
};
diff --git a/sc/source/ui/attrdlg/scdlgfact.cxx b/sc/source/ui/attrdlg/scdlgfact.cxx
index fa14720..5a78eae 100644
--- a/sc/source/ui/attrdlg/scdlgfact.cxx
+++ b/sc/source/ui/attrdlg/scdlgfact.cxx
@@ -502,6 +502,14 @@ BOOL AbstractScMoveTableDlg_Impl::GetCopyTable() const
{
return pDlg->GetCopyTable();
}
+BOOL AbstractScMoveTableDlg_Impl::GetRenameTable() const
+{
+return pDlg->GetRenameTable();
+}
+void AbstractScMoveTableDlg_Impl::GetTabNameString( String& rString ) const
+{
+pDlg->GetTabNameString( rString );
+}
void AbstractScMoveTableDlg_Impl::SetCopyTable(BOOL bFla)
{
return pDlg->SetCopyTable( bFla );
diff --git a/sc/source/ui/attrdlg/scdlgfact.hxx b/sc/source/ui/attrdlg/scdlgfact.hxx
index f1ec2a5..dc583a6 100644
--- a/sc/source/ui/attrdlg/scdlgfact.hxx
+++ b/sc/source/ui/attrdlg/scdlgfact.hxx
@@ -263,6 +263,8 @@ class AbstractScMoveTableDlg_Impl : public AbstractScMoveTableDlg //add for ScM
virtual USHORT GetSelectedDocument () const;
virtual USHORT GetSelectedTable () const;
virtual BOOL GetCopyTable () const;
+virtual BOOL GetRenameTable () const;
+virtual voidGetTabNameString( String& rString ) const;
virtual void SetCopyTable (BOOL bFlag=TRUE);
virtual void EnableCopyTable (BOOL bFlag=TRUE);
};
diff --git a/sc/source/ui/inc/mvtabdlg.hxx b/sc/source/ui/inc/mvtabdlg.hxx
index 1260737..543fa01 100644
--- a/sc/source/ui/inc/mvtabdlg.hxx
+++ b/sc/source/ui/inc/mvtabdlg.hxx
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -50,8 +51,12 @@ public:
USHORT GetSelectedDocument () const;
SCTAB GetSelectedTable () const;
BOOL GetCopyTable () const;
+BOOL GetRenameTable () const;
+voidGetTabNameString( String& rString ) const;
void SetCopyTable (BOOL bFlag=TRUE);
void EnableCopyTable (BOOL bFlag=TRUE);
+void SetRenameTable (BOOL bFlag=TRUE);
+void SetTabNameVisible (BOOL bFlag=TRUE);
private:
FixedText aFtDoc;
@@ -59,6 +64,9 @@ private:
FixedText aFtTable;
ListBox aLbTable;
CheckBox aBtnCopy;
+CheckBox aBtnRename;
+FixedText aFtTabName;
+Edit aEdTabName;
OKButton aBtnOk;
CancelButton aBtnCancel;
HelpButton aBtnHelp;
@@ -66,11 +74,13 @@ private:
USHORT nDocument;
SCTAB nTable;
BOOL bCopyTable;
+BOOL bRenameTable;
//--
void Init ();
void InitDocListBox ();
DECL_LINK( OkHdl, void * );
DECL_LINK( SelHdl, ListBox * );
+DECL_LINK( RenameHdl, void * );
};
#include
diff --git a/sc/source/ui/inc/viewfunc.hxx b/sc/source/ui/inc/viewfunc.hxx
index 0cacc54..e8ed808 100644
--- a/sc/source/ui/inc/viewfunc.hxx
+++ b/sc/source/ui/inc/viewfunc.hxx
@@ -272,7 +272,7 @@ public:
BOOL DeleteTables(const SvShorts &TheTabs, BOOL bRecord = TRUE );
BOOL RenameTable( const String& rN
[Libreoffice] cppunittester breakage in master
Hi, I recently wanted to update my master build (sorry, no exact version, but it was after doing a successful build from scratch without the build repo), and now I get this: http://frugalware.org/~vmiklos/logs/lo-master-log.txt I already tried a 'make clean && ./autogen.sh && make' but I still get it. Does anyone have an idea what's going on here? Looks like somehow stl and libstdc++ got mixed up, but I'm not sure how to fix it. Thanks. pgpJXXCktqxmV.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Number of days for testing RC
Hi Petr, all, Le 10/12/2010 15:24, Petr Mladek a écrit : > Hi, > > Jean has modified http://wiki.documentfoundation.org/Release_Criteria > and increased the number of days for reporting blocker bugs from 7 to > 10. My first name is Jean-Baptiste :-) > He says that they need to do the complete WE inside the period, > see http://wiki.documentfoundation.org/Talk:Release_Criteria > > Heh, what is "WE"? :-) Sorry, it is an acronym for a typical French expression : Week-End ;-) I think we need more time to allow volunteers to do manual tests. They do these tests during their spare time so often during the week-end. > OOo has only 5 days, see > http://wiki.services.openoffice.org/wiki/Release_criteria#Stopper_issues > How is it there with building and approving the national builds? Perhaps am I influenced by the big number of RC we have raised for OOo 3.3.0, but I think that if we take our time to deeply test our release candidates, we will have better stable version and enjoyed and not discouraged testers. > Michael thought that 7 days were too much, see > http://lists.freedesktop.org/archives/libreoffice/2010-November/003498.html > > Jean and Michael already discussed this matter, see > http://lists.freedesktop.org/archives/libreoffice/2010-November/003505.html > http://lists.freedesktop.org/archives/libreoffice/2010-November/003600.html > > > My opinion is that 10 days might make sense for the first release > candidate but it is too much for the next release candidates. Otherwise, > we would do only 2 release candidates during one month and the release > would be newerending story. > > Note that we have more strict rules for changes during the rc phase, see > http://wiki.documentfoundation.org/Development#Hack_and_commit_on_a_stable_branch > > Also I think that it does not make sense that every national team would > do the whole testing. IMHO, 95% of the functionality is language > independent, so most of the testing can be shared and distributed. Right. For OOo, NL QA-team do only Release Sanity Test. But the current test period on OOo 3.3.0 shows that the last blockers have been found by the Community and these blockers could not be found by automatic or TCM tests; they have been found by users who have done tests on their documents they use in the real life. To do that we need time. Kind regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] colon needed for LD_LIBRARY_PATH set but empty
Hi,
Poking desktop/scripts/soffice.sh for an Easy Hack, I wonder if there
exists a slight possibility of a trailing ':' of LD_LIBRARY_PATH, in
case that its original value is set but empty.
Anyway it looks subtle :)
Cheers,
-- Takeshi Abe
>From 4720c7b74c19542530e8c420fb1834ef07dd17ca Mon Sep 17 00:00:00 2001
From: Takeshi Abe
Date: Sat, 11 Dec 2010 03:21:29 +0900
Subject: [PATCH] colon needed for LD_LIBRARY_PATH set but empty
---
desktop/scripts/soffice.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/desktop/scripts/soffice.sh b/desktop/scripts/soffice.sh
index 8e1439a..cbef3b4 100644
--- a/desktop/scripts/soffice.sh
+++ b/desktop/scripts/soffice.sh
@@ -73,7 +73,7 @@ case "`uname -s`" in
OpenBSD) # this is a temporary hack until we can live with the default search paths
sd_prog1="$sd_prog/../basis-link/program"
sd_prog2="$sd_prog/../basis-link/ure-link/lib"
-LD_LIBRARY_PATH=$sd_prog1:$sd_prog2${LD_LIBRARY_PATH+:${LD_LIBRARY_PATH}}
+LD_LIBRARY_PATH=$sd_prog1:$sd_prog2${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
JAVA_HOME=$(javaPathHelper -h libreoffice-java 2> /dev/null)
export LD_LIBRARY_PATH
if [ -n "${JAVA_HOME}" ]; then
--
1.7.2.3
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Removed some commented out code in calc
There you go! Hope it works for you.
Timo H.
From 8da85e6725a0be25617fa326fed7c92723867fcf Mon Sep 17 00:00:00 2001
From: Timo Heino
Date: Fri, 10 Dec 2010 16:04:41 +0200
Subject: [PATCH] Removed commented code
Signed-off-by: Timo Heino
---
chart2/source/model/inc/BaseCoordinateSystem.hxx | 22 --
chart2/source/model/inc/ChartTypeManager.hxx |1 -
chart2/source/model/inc/Diagram.hxx |9 -
3 files changed, 0 insertions(+), 32 deletions(-)
diff --git a/chart2/source/model/inc/BaseCoordinateSystem.hxx b/chart2/source/model/inc/BaseCoordinateSystem.hxx
index 6b7584c..2cb9d9d 100644
--- a/chart2/source/model/inc/BaseCoordinateSystem.hxx
+++ b/chart2/source/model/inc/BaseCoordinateSystem.hxx
@@ -92,12 +92,6 @@ protected:
// XCoordinateSystem
virtual ::sal_Int32 SAL_CALL getDimension()
throw (::com::sun::star::uno::RuntimeException);
-// not implemented
-// virtual ::rtl::OUString SAL_CALL getCoordinateSystemType()
-// throw (::com::sun::star::uno::RuntimeException);
-// not implemented
-// virtual ::rtl::OUString SAL_CALL getViewServiceName()
-// throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL setAxisByDimension(
::sal_Int32 nDimension,
const ::com::sun::star::uno::Reference< ::com::sun::star::chart2::XAxis >& xAxis,
@@ -128,22 +122,6 @@ protected:
throw (::com::sun::star::lang::IllegalArgumentException,
::com::sun::star::uno::RuntimeException);
-// XCloneable
-// not implemented
-// virtual ::com::sun::star::uno::Reference<
-// ::com::sun::star::util::XCloneable > SAL_CALL createClone()
-// throw (::com::sun::star::uno::RuntimeException);
-
-// XServiceInfo
-// not implemented
-// virtual ::rtl::OUString SAL_CALL getImplementationName()
-// throw (::com::sun::star::uno::RuntimeException);
-// virtual ::sal_Bool SAL_CALL supportsService(
-// const ::rtl::OUString& ServiceName )
-// throw (::com::sun::star::uno::RuntimeException);
-// virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames()
-// throw (::com::sun::star::uno::RuntimeException);
-
// XModifyBroadcaster
virtual void SAL_CALL addModifyListener(
const ::com::sun::star::uno::Reference< ::com::sun::star::util::XModifyListener >& aListener )
diff --git a/chart2/source/model/inc/ChartTypeManager.hxx b/chart2/source/model/inc/ChartTypeManager.hxx
index 1cc8794..2a3a449 100644
--- a/chart2/source/model/inc/ChartTypeManager.hxx
+++ b/chart2/source/model/inc/ChartTypeManager.hxx
@@ -44,7 +44,6 @@ namespace chart
class ChartTypeManager :
public ::cppu::WeakImplHelper2<
::com::sun::star::lang::XMultiServiceFactory,
-// ::com::sun::star::lang::XMultiComponentFactory,
::com::sun::star::chart2::XChartTypeManager >
{
public:
diff --git a/chart2/source/model/inc/Diagram.hxx b/chart2/source/model/inc/Diagram.hxx
index 3b9a077..c243a97 100644
--- a/chart2/source/model/inc/Diagram.hxx
+++ b/chart2/source/model/inc/Diagram.hxx
@@ -110,16 +110,7 @@ protected:
virtual void SAL_CALL getFastPropertyValue(
::com::sun::star::uno::Any& rValue, sal_Int32 nHandle ) const;
-// virtual sal_Bool SAL_CALL convertFastPropertyValue
-// ( ::com::sun::star::uno::Any & rConvertedValue,
-// ::com::sun::star::uno::Any & rOldValue,
-// sal_Int32 nHandle,
-// const ::com::sun::star::uno::Any& rValue )
-// throw (::com::sun::star::lang::IllegalArgumentException);
-
// XDiagram
-// virtual ::rtl::OUString SAL_CALL getChartTypeTemplateServiceName()
-// throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Reference<
::com::sun::star::beans::XPropertySet > SAL_CALL getWall()
throw (::com::sun::star::uno::RuntimeException);
--
1.7.1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Pushed] Remove duplicate placeholder icons
Hi Andrew, Michael,
On 12/09/2010 09:05 PM, Joachim Trémouroux wrote:
Andrew,
Should I do the actual removal of the duplicate icons?
I guess these are the "green cross on blue background" images.
Regards,
Joachim.
Here is a patch that removes the placeholder icons in default_images/res.
I also modified the packaging script as it dies if an icon is missing.
There are still such icons in ooo_custom_images, I'll send a patch later.
Regards,
Joachim.
diff --git a/solenv/bin/packimages.pl b/solenv/bin/packimages.pl
index 90707f6..0c75993 100755
--- a/solenv/bin/packimages.pl
+++ b/solenv/bin/packimages.pl
@@ -356,9 +356,13 @@ sub create_zip_archive
foreach ( optimize_zip_layout($zip_hash_ref) ) {
my $path = $zip_hash_ref->{$_} . "/$_";
print_message("zipping '$path' ...") if $extra_verbose;
-my $member = $zip->addFile($path, $_, COMPRESSION_STORED);
-if ( !$member ) {
-print_error("can't add file '$path' to image zip archive: $!", 5);
+if ( -e $path) {
+my $member = $zip->addFile($path, $_, COMPRESSION_STORED);
+if ( !$member ) {
+print_error("can't add file '$path' to image zip archive: $!", 5);
+}
+} else {
+print_message("file '$path' not found");
}
}
my $status = $zip->writeToFileNamed($tmp_out_file);
diff --git a/default_images/res/basgocl.png b/default_images/res/basgocl.png
deleted file mode 100644
index 25d195a..000
Binary files a/default_images/res/basgocl.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_addbookmark.png b/default_images/res/commandimagelist/lc_addbookmark.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_addbookmark.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_beamer.png b/default_images/res/commandimagelist/lc_beamer.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_beamer.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_countall.png b/default_images/res/commandimagelist/lc_countall.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_countall.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_editframeset.png b/default_images/res/commandimagelist/lc_editframeset.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_editframeset.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_filedocument.png b/default_images/res/commandimagelist/lc_filedocument.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_filedocument.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_getactivetask.png b/default_images/res/commandimagelist/lc_getactivetask.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_getactivetask.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_helpdownload.png b/default_images/res/commandimagelist/lc_helpdownload.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_helpdownload.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_internetonline.png b/default_images/res/commandimagelist/lc_internetonline.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_internetonline.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_macrorecordingfloat.png b/default_images/res/commandimagelist/lc_macrorecordingfloat.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_macrorecordingfloat.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_mailwindow.png b/default_images/res/commandimagelist/lc_mailwindow.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_mailwindow.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_playmacro.png b/default_images/res/commandimagelist/lc_playmacro.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_playmacro.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_preview.png b/default_images/res/commandimagelist/lc_preview.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_preview.png and /dev/null differ
diff --git a/default_images/res/commandimagelist/lc_splithorizontal.png b/default_images/res/commandimagelist/lc_splithorizontal.png
deleted file mode 100644
index 40b59d5..000
Binary files a/default_images/res/commandimagelist/lc_splithorizonta
Re: [Libreoffice] README translation for 3.3
Andras Timar wrote: > By the way, README was updated several times lately but it was not > offered for localization. The extra lo-build.sdf/.pot does not contain > these new/changed strings. I think if we had everything updated, these > issues would be resolved automatically. > Hi Andras, so that was me - sorry, am not too familiar with the l10n process - what should I have done? Cheers, -- Thorsten pgpidOp7U3hyJ.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Bug 31865 depends on bug 32250, which changed state. Bug 32250 Summary: RC1 : Windows installer (multi) wants suffficiently free space https://bugs.freedesktop.org/show_bug.cgi?id=32250 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] Build on MacOSX : Requirement for hunspell
Le 10/12/10 17:00, Christian Lohmaier a écrit : Hi Christian, > Manually fiddling is only necessary when you already did fiddle :-) > Uh oh :-) I haven't done anything other than install all those deps as outlined in the wiki, and then put /usr/local/bin as first entry in my path (because otherwise automake wouldn't play nicely with autoconf). export PATH=/usr/local/bin:/usr/bin:/usr/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/mysql/bin$PATH This was of course before both you and Norbert chipped in :-) > I myself have a directory in my $PATH where I have symlinks to ccache > for the compilers - maybe you got something similar but miss the > corresponding links for gcc-4.0, etc? > I haven't installed ccache yet. I remember I had it on my old Tiger machine, but I don't recall it being such a hair-tearing experience :-() Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] compile time verification of SAL_N_ELEMENTS and STRING_CONST foo
On Tue, 2010-12-07 at 13:04 +, Caolán McNamara wrote: > On Tue, 2010-12-07 at 12:53 +, Noel Power wrote: > > presumeably RTL_CONSTASCII_USTRINGPARAM would try to take sizeof( > > ConstAsciiString ) in that case > > Soon enough I'll commit in a compile time test that will catch if that > happens by accident. Though it can only be enabled with gcc 4.5.0 and > above, but I compile with that so it'll get caught if it happens. This test has now been in for a few days. The test requires c++0x support with a particular language defect fix implemented. So configure checks for it and enables c++0x support if it works with gcc and in those cases SAL_N_ELEMENTS is checked to make sure its not applied to the wrong type of arguments, and as a side effect the STRING_CONST get checked as well. In practice this only happens for gcc 4.5.0 onwards, but that's the version I have, so I'm relatively confident that any potential future accidents will be caught. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Important changes in master for Windows
Hi all, Short version: If you are building master on a Windows platform, you should make a full rebuild or you are going to get lots of runtime errors. Long version: Until now most common Win32 API calls on Windows were executed through the uwinapi.dll layer. This lawyer was in charge of looking for ANSI versions of the Unicode functions (using unicows.dll) on the Win9x platforms to make the product compatible with those obsolete versions of Windows. Thanks to the latest changes in the branch this doesn't happen anymore and the code calls the Win32 API directly. This should slightly improve performance and the size of the build on the Windows platform. I still haven't removed the uwinapi library because sal still uses the C99 compliant implementation of snprintf there, but the library will be completely removed from the source code very soon. Goodbye Win95/98/ME. You'll be missed. -- Jesús Corrius Document Foundation founding member Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
Hi Alexander, On Fri, Dec 10, 2010 at 4:25 PM, Alexander Thurgood wrote: > Le 10/12/10 15:24, Norbert Thiebaud a écrit : >> >> it should work out-of-the-box (except for the requirement of having >> the 10.4 SDK) > > Unfortunately not, configure had a moan that GCC 4.2 can not be used > with 10.4u SDK, so will fiddle with ENV settings. Manually fiddling is only necessary when you already did fiddle :-) i.e. it should choose 4.0 compiler itself when not explicitly told otherwise (i.e. no environmentvariables set already) If version is greater, then it checks for 4.0 and tries to uses that http://cgit.freedesktop.org/libreoffice/bootstrap/tree/configure.in#n1902 So you apparently did set some paths or links, so that gcc-4.0 is not at the same place at the detected compiler. I myself have a directory in my $PATH where I have symlinks to ccache for the compilers - maybe you got something similar but miss the corresponding links for gcc-4.0, etc? ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] SAL_PRIxUINT32 instead of bare %x
Hi,
I got a following warning in the build of sw:
---
Compiling: sw/source/filter/ww8/ww8par.cxx
/home/tabe/libo/clone/writer/sw/source/filter/ww8/ww8par.cxx: In member
function 'virtual void Sttb::Print(FILE*)':
/home/tabe/libo/clone/writer/sw/source/filter/ww8/ww8par.cxx:216: warning:
format '%x' expects type 'unsigned int', but argument 3 has type 'sal_uInt32'
---
The attached one just suppresses it.
Cheers,
-- Takeshi Abe
>From 8262590d08eb767ada06ef3131fb57e18819b632 Mon Sep 17 00:00:00 2001
From: Takeshi Abe
Date: Sat, 11 Dec 2010 00:24:01 +0900
Subject: [PATCH] SAL_PRIxUINT32 instead of bare %x
---
sw/source/filter/ww8/ww8par.cxx |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sw/source/filter/ww8/ww8par.cxx b/sw/source/filter/ww8/ww8par.cxx
index 4a333f4..801cc2f 100644
--- a/sw/source/filter/ww8/ww8par.cxx
+++ b/sw/source/filter/ww8/ww8par.cxx
@@ -213,7 +213,7 @@ bool Sttb::Read( SvStream* pS )
void Sttb::Print( FILE* fp )
{
-fprintf( fp, "[ 0x%x ] Sttb - dump\n", nOffSet);
+fprintf( fp, "[ 0x%" SAL_PRIxUINT32 " ] Sttb - dump\n", nOffSet);
fprintf( fp, " fExtend 0x%x [expected 0x ]\n", fExtend );
fprintf( fp, " cData no. or string data items %d (0x%x)\n", cData, cData );
--
1.7.2.3
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
Le 10/12/10 15:24, Norbert Thiebaud a écrit : > you can start with: autgogen.sh --disable-moz --disable-mozilla ;-) > it should work out-of-the-box (except for the requirement of having > the 10.4 SDK) Unfortunately not, configure had a moan that GCC 4.2 can not be used with 10.4u SDK, so will fiddle with ENV settings. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Number of days for testing RC
On Fri, 2010-12-10 at 15:24 +0100, Petr Mladek wrote: > Hi, > > Jean has modified http://wiki.documentfoundation.org/Release_Criteria > and increased the number of days for reporting blocker bugs from 7 to > 10. > > He says that they need to do the complete WE inside the period, > see http://wiki.documentfoundation.org/Talk:Release_Criteria > > Heh, what is "WE"? :-) A WeekEnd I bet, i.e. Jean'd like the blocker-bug period to have a weekend in it. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
On Fri, Dec 10, 2010 at 8:21 AM, Alexander Thurgood wrote: > Le 10/12/10 14:35, Christian Lohmaier a écrit : > >> And when you don't install PKG_CONFIG for those, you have to provide >> the corresponding environment variables with the corresponding flags, >> thus pkg-config is just for convenience. >> > > And there was I thinking it was going to be simple, hehehe, silly me ;-) > I remember when I started building OOo on Mac, it was complicated, this > seems just a tad more so :-)) I'll persevere anyway. you can start with: autgogen.sh --disable-moz it should work out-of-the-box (except for the requirement of having the 10.4 SDK) Norbert > > Alex > > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Number of days for testing RC
Hi, Jean has modified http://wiki.documentfoundation.org/Release_Criteria and increased the number of days for reporting blocker bugs from 7 to 10. He says that they need to do the complete WE inside the period, see http://wiki.documentfoundation.org/Talk:Release_Criteria Heh, what is "WE"? :-) OOo has only 5 days, see http://wiki.services.openoffice.org/wiki/Release_criteria#Stopper_issues How is it there with building and approving the national builds? Michael thought that 7 days were too much, see http://lists.freedesktop.org/archives/libreoffice/2010-November/003498.html Jean and Michael already discussed this matter, see http://lists.freedesktop.org/archives/libreoffice/2010-November/003505.html http://lists.freedesktop.org/archives/libreoffice/2010-November/003600.html My opinion is that 10 days might make sense for the first release candidate but it is too much for the next release candidates. Otherwise, we would do only 2 release candidates during one month and the release would be newerending story. Note that we have more strict rules for changes during the rc phase, see http://wiki.documentfoundation.org/Development#Hack_and_commit_on_a_stable_branch Also I think that it does not make sense that every national team would do the whole testing. IMHO, 95% of the functionality is language independent, so most of the testing can be shared and distributed. I propose to go back and use 7 days for rc2. What do you think? Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
Le 10/12/10 14:35, Christian Lohmaier a écrit : > And when you don't install PKG_CONFIG for those, you have to provide > the corresponding environment variables with the corresponding flags, > thus pkg-config is just for convenience. > And there was I thinking it was going to be simple, hehehe, silly me ;-) I remember when I started building OOo on Mac, it was complicated, this seems just a tad more so :-)) I'll persevere anyway. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
Hi Norbert, *, On Fri, Dec 10, 2010 at 1:56 PM, Norbert Thiebaud wrote: > On Fri, Dec 10, 2010 at 5:24 AM, Christian Lohmaier > wrote: >> [...] >> Only if (and *only*) if you build mozilla from source, you need >> libIDL, glib2 and gettext in addition (and pkg-config for not having >> to specify lots of enviornment variables when building those extra >> deps). > > An to build these, you need a recent 'autoconf, automake or whatever' No. You don't. Release tarballs don't require you to run autoconf or automake to begin with. And even if it would be required, the autoconf/automake already provided by XCode would be enough. >> so ./configure --prefix=/my/seamonkeydepsdir/ && make && make install >> for those abovementioned requirements is enough. (and setting >> PKG_CONFIG=/my/seamonkeydepsdir/bin/pkg-config) > > Actually that should not be needed anymore. we deliver a m4 macros > for mac to circumvent the need for pkg-config I know, I wrote that patch :-)) But it is still necessary to compile the requirements to compile mozilla/seamonkey from scratch. That is not covered by LO autogen/configure (yet) And when you don't install PKG_CONFIG for those, you have to provide the corresponding environment variables with the corresponding flags, thus pkg-config is just for convenience. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] RC1 / size redux ...
Hi Michael, all, Michael Meeks wrote (07-12-10 18:55) So - as we all know, RC1 is too large; and there are a complicated set of reasons why that is so, [...] Great to see the work and progress on this subject. Of course it had to be done anyway, but making the effort now is, looking to all comments, very positive. On thing that I wondered this morning (when I saw a remark somewhere about extensions) is why we do not look at the integrated extensions. Compressed in a tar.gz they count for 25.8 MB! Also I remember some remarks on lists (including on from a very big community) that have a strong preference for installation sets without those extensions. And really, it does not make LibreOffice better software to include those, or to prevent people to download and install some Sun or Oracle stuff. Also you should be delighted to leave Java-stuff, that most users do not use anyway, out, isn't it :-p After all, it 25 MB... One side note about your little, understandable, grief that comments on the download size came in rather late. I think it has been a mistake of all in the initial discussion, that was rather fast (hectic times, back in those days), that we didn't realise that more time for discussion with more people would be better. Sorry that the burden of that mistake is now carried by you and other devs. Best, Cor -- - giving openoffice.org its foundation :: The Document Foundation - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
On Fri, Dec 10, 2010 at 5:24 AM, Christian Lohmaier wrote: > Hi Alexander, *, > > On Fri, Dec 10, 2010 at 11:18 AM, Alexander Thurgood > wrote: >> >> I just wanted to touch base with others here as to the requirement for >> hunspell in the build environment on MacoSX. Is it absolutely necessary > > No. It is even stupid/pointless to use system hunspell, as nobody will > have it installed on Mac. > >> ? I only ask this because OOo uses the MacOS spellchecker AFAIK and has >> done for some while. Any comments ? > > MacOSX spell checker and hunspell can both be used, so MacOS versions > should continue shipping hunspell. But not system one, but the one > included in the sources. > > Similar for the other requirmenets listed: They are just wrong. > You need XCode. You don't need extra autoconf, automake or whatever. > > Only if (and *only*) if you build mozilla from source, you need > libIDL, glib2 and gettext in addition (and pkg-config for not having > to specify lots of enviornment variables when building those extra > deps). An to build these, you need a recent 'autoconf, automake or whatever' > > so ./configure --prefix=/my/seamonkeydepsdir/ && make && make install > for those abovementioned requirements is enough. (and setting > PKG_CONFIG=/my/seamonkeydepsdir/bin/pkg-config) Actually that should not be needed anymore. we deliver a m4 macros for mac to circumvent the need for pkg-config Norbert > After building seamonkey, go to the moz dir, run dmake zip, save the > zips from unxmac*pro/zip to a safe place and the next time when > building put the zips into moz/zipped and specify > --disable-build-mozilla on configure. You can remove > /my/seamonkeydepsdir completely. > > ciao > Christian > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] making it easy to valgrind the smoketest etc.
So to make it easy to valgrind the smoketest and soffice, if you now export VALGRIND=memcheck make check the soffice instance will be run under valgrind and error out if valgrind detects any errors during the smoketest. I took VALGRIND=something because that's what we do in hunspell as well during its make check which is part of the standard libreoffice build so doing an export VALGRIND=memcheck before the build runs the hunspell regression test under valgrind as well as the smoketest/LibreOffice itself. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Base - sqlite - licence grief
Le 10/12/10 11:32, Wols Lists a écrit : > > Because he's not the copyright holder? Well that would actually depend on which version of the JCA / SISSL combo he signed when he contributed. When I first signed the JCA, I retained my rights as author. Even with the later versions of the SISSL, I seem to recall that the original author retained copyright in his/her work. See here : http://www.openoffice.org/licenses/jca.pdf "2. Contributor hereby assigns to Sun joint ownership in all worldwide common law and statutory rights associated with the copyrights, copyright application, copyright registration and moral rights in the Contribution to the extent allowable under applicable local laws and copyright conventions. Contributor agrees that this assignment may be submitted by Sun to register a copyright in the Contribution. Contributor retains the right to use the Contribution for Contributor's own purposes. This Joint Copyright Assignment supersedes and replaces all prior copyright assignments made by Contributor to Sun under the OpenOffice.org project." Note that what is important here is the fact that ownership is joint. The original author retained the right to use for his own purposes (e.g. relicensing). So you see, it might not be entirely hopeless after all. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
Hi Alexander, *, On Fri, Dec 10, 2010 at 11:18 AM, Alexander Thurgood wrote: > > I just wanted to touch base with others here as to the requirement for > hunspell in the build environment on MacoSX. Is it absolutely necessary No. It is even stupid/pointless to use system hunspell, as nobody will have it installed on Mac. > ? I only ask this because OOo uses the MacOS spellchecker AFAIK and has > done for some while. Any comments ? MacOSX spell checker and hunspell can both be used, so MacOS versions should continue shipping hunspell. But not system one, but the one included in the sources. Similar for the other requirmenets listed: They are just wrong. You need XCode. You don't need extra autoconf, automake or whatever. Only if (and *only*) if you build mozilla from source, you need libIDL, glib2 and gettext in addition (and pkg-config for not having to specify lots of enviornment variables when building those extra deps). so ./configure --prefix=/my/seamonkeydepsdir/ && make && make install for those abovementioned requirements is enough. (and setting PKG_CONFIG=/my/seamonkeydepsdir/bin/pkg-config) After building seamonkey, go to the moz dir, run dmake zip, save the zips from unxmac*pro/zip to a safe place and the next time when building put the zips into moz/zipped and specify --disable-build-mozilla on configure. You can remove /my/seamonkeydepsdir completely. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
Le 10/12/10 11:59, Caolán McNamara a écrit : > > e.g. if someone wants to install a spell-checker for languages which > LibreOffice supports but the OS might not. e.g. minority languages like > Gikuyu, Akan, Mossi, and so on. > Ah, Ok, I get it, hadn't thought about that seeing as Apple does seem to have quite a wide range of supported languages, but probably not as many as are currently available for OOo/LibO. Thanks, Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Localization issues, readme
Hi Andras, On 10/12/2010 13:05, Andras Timar wrote: Hi, I found a few issues and I need your advice. If I correct these issues, new strings for translation will appear, but I think we need to address these issues before the release (not necessaryly before RC2 because there is not enough time). Strings for our additional features (difference between OOo 3.3 and LibreOffice) are in build/po/lo-build.pot which is generated from lo-build.sdf. However, in lo-build.sdf there are duplicated source language entries, because bogus strings are coming from build/po/sdf-templates/OxygenOffice.sdf. Therefore translators may translate OxygenOffice strings instead of LibreOffice string in po files, it depend on which string comes first in the alphabetically sorted string list. My recommendation: clean duplicated/unused strings from OxygenOffice.sdf (will there be any left?). Other big issue is the readme. The source of the readme is in libs-core/readlicense_oo/docs/readme.xrm which contains many duplicated paragraph IDs, therefore messup is granted. First thing to do is change duplicated IDs to unique IDs. Then strings should be extracted and changed+new strings should be added to build/po/sdf-templates/SUSE.sdf and build/po/lo-build.sdf, then pot/po files should be generated, should be sent to Pootle etc. Readme contains many new strings to translate, so it will take time to have them translated in all languages. Also, old strings should be removed from l10n/source//localize.sdf files, because they will come back, and make the localized readmes confusing (half-LibreOffice, half-OpenOffice.org). Alternatively we can change the corresponding paragraph IDs in LibreOffice readme. Please let me know, if you wish me to work on these issue in the week-end. It is unfortunate to have these issues long after the string freeze, but it's better to correct them now. Corrections can be pushed after RC2 tagging. Please go on, several of us won't be able to distribute LibreOffice otherwise, so even if it's late, it's better anyway. Thanks a lot. Kind regards Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX : Requirement for hunspell
On Fri, 2010-12-10 at 11:18 +0100, Alexander Thurgood wrote: > Hi, > > I just wanted to touch base with others here as to the requirement for > hunspell in the build environment on MacoSX. Is it absolutely necessary > ? I only ask this because OOo uses the MacOS spellchecker AFAIK and has > done for some while. Any comments ? What I would expect to be the case, but as I'm not on Mac so someone will have to check this out, is that while MaxOSX provides system integration for spelling that LibreOffice can use, presumably LibreOffice on MacOSX should still be able to support the arch-independent LibreOffice dictionary extensions which require hunspell. e.g. if someone wants to install a spell-checker for languages which LibreOffice supports but the OS might not. e.g. minority languages like Gikuyu, Akan, Mossi, and so on. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Base - sqlite - licence grief
On 10/12/10 10:16, Alexander Thurgood wrote: > Hi, > > > Le 09/12/10 20:07, Wols Lists a écrit : >> I've downloaded the old sqlite driver, which is copyright Sun LGPL 2.1. >> >> I was going to try and get that working, and teach myself C++ in the >> process, but on trying to commit it to my local repo the first thing I >> get is "you are adding tabs to these files" (no I'm not but never mind :-) >> >> So I fix that, then I get "Your change introduces old licences". Where >> do I go from here? I could unilaterally change all the files to GPL3+ >> (as permitted by the LGPL) but I don't yet have the skill to rewrite the >> files. Or is there a contact at Oracle I can ask to upgrade the licence >> to LGPL3? >> > Why not ask Christian Werner, the guy who wrote it in the first place ? > mailto:c...@ch-werner.de Because he's not the copyright holder? > From what I can see of the licence terms for the ODBC SQLite driver, his > terms are actually quite liberal : > > http://www.ch-werner.de/sqliteodbc/html/index.html > > As far as I can tell, his intention was the same for the SDBC driver > too, but you would be better off asking him I guess. > > Unfortunately, the files all claim to be copyright Sun. So, unfortunately, if this is true then what the author wants is irrelevant :-( I'll investigate that route, thanks, but going by the evidence in front of me it's likely to be futile. Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Fwd: Inclusion of a distro in the code
Hi Anke, On Fri, 2010-12-10 at 08:14 +0300, sophie wrote: > I'm forwarding your mail to the developer's list, you should have more > answers there Thanks Sophie. > Compiling the latest RC1 for the Linux distribution "Chakra", I noticed > there is a list of distro's in the code, that are supported for branding > libreoffice. Riight - so this is something we are trying to cut out of the picture; we don't really want lots of branding images in the repositories; these really belong in vendor packages I think - with some nice configure option to use them. As regards the distro config/ files - there is some merit in centralising these I guess (as/when we change defaults it can help); but its not clear to me that there needs to be so much diversity among them [ usually people want different levels of 'use system libfoo' tweaking ]. So - I'd say - probably best to to put the artwork in; keep it in your .spec file / build wrappers; [ and help us make that easier with better configure options perhaps ? - patches most welcome ]; we are also working to deprecate the build/ top-level (with distro specific patches etc.) such that all of that is flattened into the main tree, with conditionals (as appropriate). Does that make sense ? Perhaps other devs have different views - this is mostly Rene's world :-) anyhow - do post patches to the freedesktop dev list :-) Glad you're packaging LibreOffice ! and great to have you on board. Thanks, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Build on MacOSX : Requirement for hunspell
Hi, I just wanted to touch base with others here as to the requirement for hunspell in the build environment on MacoSX. Is it absolutely necessary ? I only ask this because OOo uses the MacOS spellchecker AFAIK and has done for some while. Any comments ? TIA, Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Base - sqlite - licence grief
Hi, Le 09/12/10 20:07, Wols Lists a écrit : > I've downloaded the old sqlite driver, which is copyright Sun LGPL 2.1. > > I was going to try and get that working, and teach myself C++ in the > process, but on trying to commit it to my local repo the first thing I > get is "you are adding tabs to these files" (no I'm not but never mind :-) > > So I fix that, then I get "Your change introduces old licences". Where > do I go from here? I could unilaterally change all the files to GPL3+ > (as permitted by the LGPL) but I don't yet have the skill to rewrite the > files. Or is there a contact at Oracle I can ask to upgrade the licence > to LGPL3? > Why not ask Christian Werner, the guy who wrote it in the first place ? mailto:c...@ch-werner.de >From what I can see of the licence terms for the ODBC SQLite driver, his terms are actually quite liberal : http://www.ch-werner.de/sqliteodbc/html/index.html As far as I can tell, his intention was the same for the SDBC driver too, but you would be better off asking him I guess. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Localization issues, readme
Hi, I found a few issues and I need your advice. If I correct these issues, new strings for translation will appear, but I think we need to address these issues before the release (not necessaryly before RC2 because there is not enough time). Strings for our additional features (difference between OOo 3.3 and LibreOffice) are in build/po/lo-build.pot which is generated from lo-build.sdf. However, in lo-build.sdf there are duplicated source language entries, because bogus strings are coming from build/po/sdf-templates/OxygenOffice.sdf. Therefore translators may translate OxygenOffice strings instead of LibreOffice string in po files, it depend on which string comes first in the alphabetically sorted string list. My recommendation: clean duplicated/unused strings from OxygenOffice.sdf (will there be any left?). Other big issue is the readme. The source of the readme is in libs-core/readlicense_oo/docs/readme.xrm which contains many duplicated paragraph IDs, therefore messup is granted. First thing to do is change duplicated IDs to unique IDs. Then strings should be extracted and changed+new strings should be added to build/po/sdf-templates/SUSE.sdf and build/po/lo-build.sdf, then pot/po files should be generated, should be sent to Pootle etc. Readme contains many new strings to translate, so it will take time to have them translated in all languages. Also, old strings should be removed from l10n/source//localize.sdf files, because they will come back, and make the localized readmes confusing (half-LibreOffice, half-OpenOffice.org). Alternatively we can change the corresponding paragraph IDs in LibreOffice readme. Please let me know, if you wish me to work on these issue in the week-end. It is unfortunate to have these issues long after the string freeze, but it's better to correct them now. Corrections can be pushed after RC2 tagging. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [Patch] call-catcher / bloat removal
On Thu, 2010-12-09 at 23:39 +0100, Julien Nabet wrote:
> Hello,
>
> First try to remove call-catcher / bloat removal with
> sc/source/core/tool/chgtrack.cxx and sc/inc/chgtrack.hxx
Looks good to me. Pushed this now. Thanks for this. IMO this is the good
stuff, code that cannot be called under any circumstances but is always
built and included in the binaries :-)
> I made a ./g grep AppendContent * on the whole project, i found it only
> on sc module
> I made a build and this file compiled ok but i had an error after so...
I assume your error was the one mentioned in the other thread. That
error is unrelated to this. Your change is fine.
> I made a ./g grep dlsym * on sc
> How to be sure the function isn't called by dlsym ?
In general this is hard, because it could also be called indirectly by
one of the dlsym wrappers, e.g. osl_getFunctionSymbol and friends.
> For example, must we check if a dlsym on the function AppendContent of
> the class
The good news though is that noone, in practice, dlsyms any name mangled
symbols. So you don't need to check for the general case of class
methods or normal C++ functions, *except* for extern "C" methods which
are not name-mangled, which makes them practical to dlsym.
Let me demo this to make it clear.
class ScChangeTrack
{
public:
void AppendContent();
};
void ScChangeTrack::AppendContent()
{
}
void mangled_impractical_to_dlsym()
{
}
extern "C" void notmangled_practical_to_dlsym()
{
}
gcc -c foo.cxx
nm foo.o
0005 T _Z29mangled_impractical_to_dlsymv
T _ZN13ScChangeTrack13AppendContentEv
000a T notmangled_practical_to_dlsym
See, the extern "C" function isn't mangled so someone could plausibly
dlsym it. e.g. a common one in LibreOffice which does get dlsymed is
extern "C" component_writeInfo. But everything else gets mangled
according to each compilers different name mangling rules. So noone
dlsyms on those, so you don't have to care about them if they are C++
symbols.
Obvious rule of thumb then is that if they are members of a class they
won't be dlsymed. If there are normal functions then they definitely
won't be dlsymed unless they are in a .c file or unless they are extern
"C", in which case they might be.
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error compilation on sc
On Thu, 2010-12-09 at 22:42 +0100, Julien Nabet wrote: > Hello, > > Since today when i compile, i've got this in sc module : > Entering /home/serval/libreoffice-source/libo/sc/source/ui/unoobj > > `../../../unxlngi6.pro/slo/chart2uno.obj' is up to date > Entering /home/serval/libreoffice-source/libo/sc/util > > Making:scalc3c.lib > Making:libscli.so > : ERROR: > /home/serval/libreoffice-source/libo/solver/330/unxlngi6.pro/lib/libtkli.so: > undefined symbol: > _ZN3vcl15ImageRepository9loadImageERKN3rtl8OUStringER8BitmapExb > dmake: Error code 1, while making '../unxlngi6.pro/lib/libscli.so' c++filt _ZN3vcl15ImageRepository9loadImageERKN3rtl8OUStringER8BitmapExb vcl::ImageRepository::loadImage(rtl::OUString const&, BitmapEx&, bool) loadImage had two extra args added to it yesterday, so I suspect that some dependency quick didn't kick in. (assuming that you're building an up-to-date g pulled master). And that the call of loadImage in toolkit's libtk didn't get rebuilt. Personally I'd touch /home/serval/libreoffice-source/libo/toolkit/source/helper/tkresmgr.cxx and run make again on the basis that tkresmgr is the only .cxx in toolkit that calls loadImage so touching it will force a rebuild of that. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
