Re: [Libreoffice] Strange filesystems-related enum in libs-gui/tools
And this would also be stupid: only the WIN32 subsystem Which is the subsystem LibreOffice runs in, so what is your point? is case-insensitive by default on Windows NT systems. And it can be set to be case-sensitive by toggling a single registry value. Surely you are not suggesting we should potentially break existing functionality for the majority of Windows users, just to cater for a handful of people who intentionally break their systems just because they can? I mean, if we have code in there that assumes NTFS (and SMB) volumes are case insensitive (at least when accessed from Windows), we should definitely keep it that way, even if somebody might have toggled a registry value to change it. If somebody does that, they deserve what they get. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Strange filesystems-related enum in libs-gui/tools
On Tue, May 03, 2011 at 02:06:24AM -0600, Tor Lillqvist wrote: And this would also be stupid: only the WIN32 subsystem Which is the subsystem LibreOffice runs in, so what is your point? NTFS itself is case sensitive. There may be files files differing only by case even on Microsoft Windows systems. Surely you are not suggesting we should potentially break existing functionality for the majority of Windows users, just to cater for a handful of people who intentionally break their systems just because they can? I'm not suggesting anything, just thinking out loud for now. I mean, if we have code in there that assumes NTFS (and SMB) volumes are case insensitive (at least when accessed from Windows), we should definitely keep it that way, even if somebody might have toggled a registry value to change it. If somebody does that, they deserve what they get. The code is overly complex and wrong in some cases. I was thinking of simplifying it by doing a simple compile-time check for WNT but this may not be the best way. And the function we're talking about is only used once in all the code base. I'm not even sure it's doing anything useful. -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 vitriol vitriol_vitr...@katamail.com changed: What|Removed |Added Depends on||36667 --- Comment #48 from vitriol vitriol_vitr...@katamail.com 2011-05-03 02:11:40 PDT --- Nominating Bug 36667. Function result update in Writer is broken. Regression form 3.3.2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 vitriol vitriol_vitr...@katamail.com changed: What|Removed |Added Depends on|36667 | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 vitriol vitriol_vitr...@katamail.com changed: What|Removed |Added Depends on||36667 -- 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] Strange filesystems-related enum in libs-gui/tools
On Tue, May 03, 2011 at 10:21:18AM +0200, Francois Tigeot wrote:
On Tue, May 03, 2011 at 02:06:24AM -0600, Tor Lillqvist wrote:
I mean, if we have code in there that assumes NTFS (and SMB) volumes are
case insensitive (at least when accessed from Windows), we should
definitely keep it that way, even if somebody might have toggled a registry
value to change it. If somebody does that, they deserve what they get.
The code is overly complex and wrong in some cases. I was thinking of
simplifying it by doing a simple compile-time check for WNT but this may not
be
the best way.
Following a short discussion on IRC, I've decided to remove the bulk of the
code and use a single #if defined(WNT) check instead.
The attached patch is relative to libs-gui.
--
Francois Tigeot
diff --git a/tools/inc/tools/fsys.hxx b/tools/inc/tools/fsys.hxx
index 47ce264..e4ab76b 100644
--- a/tools/inc/tools/fsys.hxx
+++ b/tools/inc/tools/fsys.hxx
@@ -296,8 +296,6 @@ public:
FSysPathStyle eParser = FSYS_STYLE_HOST );
~DirEntry();
-sal_Bool IsCaseSensitive (FSysPathStyle
eFormatter = FSYS_STYLE_HOST) const;
-
sal_uIntPtrGetError() const { return
nError; }
sal_Bool IsValid() const;
DirEntryFlag GetFlag() const { return eFlag; };
diff --git a/tools/source/fsys/dirent.cxx b/tools/source/fsys/dirent.cxx
index a557edb..625fc48 100644
--- a/tools/source/fsys/dirent.cxx
+++ b/tools/source/fsys/dirent.cxx
@@ -1662,13 +1662,12 @@ sal_Bool DirEntry::ImpToRel( String aCurStr )
aThis.ToAbs();
String aThisStr( aThis.GetFull( FSYS_STYLE_HPFS ) );
-// #109512 preserve case of path even if caseinsensitive
+// preserve case of path even if caseinsensitive
String aThisCompareStr( aThisStr ), aCurCompareStr( aCurStr );
-if ( ! IsCaseSensitive() )
-{
+#if defined(WNT)
aThisCompareStr.ToLowerAscii();
aCurCompareStr.ToLowerAscii();
-}
+#endif
// Ubereinstimmung prufen
sal_uInt16 nPos = aThisCompareStr.Match( aCurCompareStr );
diff --git a/tools/source/fsys/unx.cxx b/tools/source/fsys/unx.cxx
index a2eba54..90c7a94 100644
--- a/tools/source/fsys/unx.cxx
+++ b/tools/source/fsys/unx.cxx
@@ -191,81 +191,6 @@ static sal_Bool GetMountEntry(dev_t dev, struct mymnttab
*mytab)
#endif
-/
-|*
-|*DirEntry::IsCaseSensitive()
-|*
-*/
-
-sal_Bool DirEntry::IsCaseSensitive( FSysPathStyle eFormatter ) const
-{
-
-if (eFormatter==FSYS_STYLE_HOST)
-{
-#if defined(NETBSD) || defined(DRAGONFLY)
-return sal_True;
-#else
-struct stat buf;
-DirEntry aPath(*this);
-aPath.ToAbs();
-
-while (stat (ByteString(aPath.GetFull(),
osl_getThreadTextEncoding()).GetBuffer(), buf))
-{
-if (aPath.Level() == 1)
-{
-return sal_True; // ich bin unter UNIX, also ist der
default im Zweifelsfall case sensitiv
-}
-aPath = aPath [1];
-}
-
-struct mymnttab fsmnt;
-GetMountEntry(buf.st_dev, fsmnt);
-if ((fsmnt.mymnttab_filesystem.CompareTo(msdos)==COMPARE_EQUAL) ||
-(fsmnt.mymnttab_filesystem.CompareTo(umsdos)==COMPARE_EQUAL) ||
-(fsmnt.mymnttab_filesystem.CompareTo(vfat)==COMPARE_EQUAL) ||
-(fsmnt.mymnttab_filesystem.CompareTo(hpfs)==COMPARE_EQUAL) ||
-(fsmnt.mymnttab_filesystem.CompareTo(smb)
==COMPARE_EQUAL) ||
-(fsmnt.mymnttab_filesystem.CompareTo(ncpfs)==COMPARE_EQUAL))
-{
-return sal_False;
-}
-else
-{
-return sal_True;
-}
-#endif
-}
-else
-{
-sal_Bool isCaseSensitive = sal_True; // ich bin unter UNIX, also ist
der default im Zweifelsfall case sensitiv
-switch ( eFormatter )
-{
-case FSYS_STYLE_MAC:
-case FSYS_STYLE_FAT:
-case FSYS_STYLE_VFAT:
-case FSYS_STYLE_NTFS:
-case FSYS_STYLE_NWFS:
-case FSYS_STYLE_HPFS:
-{
-isCaseSensitive = sal_False;
-break;
-}
-case FSYS_STYLE_SYSV:
-case FSYS_STYLE_BSD:
-case FSYS_STYLE_DETECT:
-{
-isCaseSensitive = sal_True;
-break;
-}
-default:
-{
-isCaseSensitive = sal_True;// ich bin unter UNIX,
also ist der default im Zweifelsfall case sensitiv
-break;
-}
-}
-return isCaseSensitive;
-}
-}
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #49 from Michael Meeks michael.me...@novell.com 2011-05-03 02:30:05 PDT --- There are a number of bugs here that are long standing, and not regressions, so - annoying as they are I don't believe we should really focus on fixing them for 3.4: bug #32672, bug #32862, bug #34814, bug #36547 So - I nominate them for removal :-) -- 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] Reducing the number of localized help packs
On Sat, 2011-04-30 at 12:30 +0200, Andras Timar wrote: OK, sorry, this happened fast. There is one more change that was not noticed by the website team (or was not communicated to them). There is no _all installer any more for Windows. _multi contains all languages. Lovely - hopefully that will reduce the complexity a little. Nice, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#31251 Writer Impress shadow consistency
Hi Sebastien, On 2011-04-30 at 18:58 +0200, Sébastien Le Ray wrote: Since OOo UX team implemented a new shadow on impress which seem to please more people than the writer shadow I provided before, here is a patchset that add the same shadow to writer. So - I like it, and would love to include for 3.4; one more review needed :-) - David? Cedric? I have noticed one thing that I think is still worth fixing before the release - unlike in Impress, there is no black line around the page, see: http://artax.karlin.mff.cuni.cz/~kendy/libreoffice/missing-black-line.png [Writer on the left, Impress on the right] This causes the mode when you have 2 pages next to each other look a bit strange: http://artax.karlin.mff.cuni.cz/~kendy/libreoffice/no-division-between-pages.png This is not a regression against what we have in the libreoffice-3-4 branch though, so I think we should apply your patches still for the 3.4 anyway. Thank you very much for them! Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: REMINDER: Release 3.4.0-rc1 from ooo-build-3-2-1 branch == string and UI freeze
On Mon, 2011-05-02 at 21:28 +0300, Sophie Gautier wrote: Yes I do too, but the issue is that we didn't test the betas at all yet due to this bug Which sucks; hopefully the Windows Mac builds have been use-able for testing - and of course, the snapshots of them. and it covers a quiet large range of distributions. So, may be we should really take time to test the RC fully before really calling it an RC and spread the word around it. The danger of this - is that by introducing further delay into the release pipeline - we slow down our ability to respond to bugs that are found, and since we are releasing a build per week anyway - we can only really choose to miss out a week: which isn't that wonderful :-) Already we only have a few days to fix a bug in RCn and get the fix out in RCn+1. -Far- better for people to be running and using the daily snapshot releases and reporting bugs against them - instead of waiting for RCs (per-se). Having said that - warning that RC1 may be a bit rough in the release notes is a good idea :-) - although, given that this is caused by some obscure compiler problem - apparently only present on the gross / old system we compile the binaries on for Linux, I'm optimistic that once it is fixed we'll not be in such terrible shape. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] What is the exact system switches used for the x86 linux build?
On Mon, 2011-05-02 at 18:12 +0200, Thorsten Behrens wrote: to work fine I wonder whether it is a problem with the build-environment of with the code. Excellent insight Christian :-) an annoying place to find that. Unfortunately, the RHEL4 build-environment is mostly a nightmare to setup and maintain. We need to arrive at a new (much more modern) baseline operating system to build from - Caolan was doing some work on that (cf. ESC minutes) before his paternity leave. Independently, Fridrich, could you add your release build's configure lines to the wiki? Well - this should certainly be in the distro-config directory. I would hope it is the LibreOfficeLinux variant - is that so Fridrich ? ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] update - Courgette ...
Hi guys, So - there are lots of ways to do this. Chrome seems to have some quite funky very-small-diff creator for binary files, that should let us do security updates, and the kinds of small changes we tend to see in minor point-releases into very small patches: http://www.chromium.org/developers/design-documents/software-updates-courgette At least for Windows (only) - [ this is Chrome right ;-] But then Windows is the problem platform for updates I guess. Personally - I would love to get a review of how Firefox and Chrome do their on-line updating for Windows, and what code from each project we can / should borrow re-use. It would be great to have a wiki page with lots of code pointers for the integration points into each project listed etc. Re-using something already used in a large, successful Free Software project that ships cross-platform is (AFAICS) mandatory. There are dozens of projects out there that might/could do this - but we want to free-ride on these other large projects' hard work, and share the burden with them IMHO. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: REMINDER: Release 3.4.0-rc1 from ooo-build-3-2-1 branch == string and UI freeze
Hi Michael, On 03/05/2011 13:30, Michael Meeks wrote: On Mon, 2011-05-02 at 21:28 +0300, Sophie Gautier wrote: Yes I do too, but the issue is that we didn't test the betas at all yet due to this bug Which sucks; hopefully the Windows Mac builds have been use-able for testing - and of course, the snapshots of them. Not sure about Mac, but I think we have a lot of testers under Linux. and it covers a quiet large range of distributions. So, may be we should really take time to test the RC fully before really calling it an RC and spread the word around it. The danger of this - is that by introducing further delay into the release pipeline - we slow down our ability to respond to bugs that are found, and since we are releasing a build per week anyway - we can only really choose to miss out a week: which isn't that wonderful :-) Already we only have a few days to fix a bug in RCn and get the fix out in RCn+1. -Far- better for people to be running and using the daily snapshot releases and reporting bugs against them - instead of waiting for RCs (per-se). Yes agreed, there is a lot of room for improvement on the testing side. But betas are supposed to be tested too :) Having said that - warning that RC1 may be a bit rough in the release notes is a good idea :-) But a RC1 is supposed to be a release candidate, so how could it be rough? I mean I understand all the reasons you have given above about correction of bugs, etc. And I know we have a good part of responsibility for not pointing the stopper at the good time. What I'm trying to highlight also here is the communication. It's quiet frustrating to not be able to install a version when you want to contribute to tests, and having a RC that is rough sound strange for me. - although, given that this is caused by some obscure compiler problem - apparently only present on the gross / old system we compile the binaries on for Linux, I'm optimistic that once it is fixed we'll not be in such terrible shape. Ok, let see. Kind regards Sophie -- Founding member of The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] reviewboard: a solution or just creating new problems?
Hi Jani, Hi Michael, On Thu, 21 Apr 2011 23:04:38 +0300 Jani Monoses j...@ubuntu.com wrote: I think using code review helper apps is a great idea, and the lack of their use in any non-trivial FOSS project with many contributors will be in 5 years as perplexing as seeing one now going without the use version control software :) given this and other responses, Id like to propose this topic for the next TSC-call. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] source Java
how to insert an encoded source libreoffice in JAVA? -- Att. Luiz Henrique Natalino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] error building translations
Le 02/05/2011 22:12, Jean-Baptiste Faure a écrit :
Le 02/05/2011 13:58, Jean-Baptiste Faure a écrit :
Le 01/05/2011 20:27, Júlio Hoffimann a écrit :
Hi Jean,
This problem was solved by KAMI as you can see here:
http://nabble.documentfoundation.org/po2oo-skipsource-support-td2802247.html
http://nabble.documentfoundation.org/po2oo-skipsource-support-td2802247.html#a2802983Try
to update your repo and build again. :-)
I am afraid it does not work for me.
I configured libreoffice-3-4 branch for multiple workdirs as explained
on the wiki :
http://wiki.documentfoundation.org/Development/Native_Build#Multiple_Work_Dirs
Is it possible that po2oo is searched in directory for master branch and
not in the tree for libreoffice-3-4 branch ?
It seems that for my master branch translate-toolkit has not been build.
Ok, I have build the master and then rebuild libreoffice-3-4. Same problem.
Error message is :
LD_LIBRARY_PATH=/home/jbf/LibO/libreoffice-3-4/solver/300/unxlngx6.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
/home/jbf/LibO/libreoffice-3-4/solver/300/unxlngx6.pro/bin/po2oo
--skipsource -i ./source/fr -t ./unxlngx6.pro/misc/sdf-template/en-US.sdf -o
./unxlngx6.pro/misc/sdf-l10n/fr.sdf -l fr
Usage: po2oo [--version] [-h|--help] [--manpage] [--progress PROGRESS]
[--errorlevel ERRORLEVEL] [-i|--input] INPUT [-x|--exclude EXCLUDE]
[-o|--output] OUTPUT [-t|--template TEMPLATE]
po2oo: error: no such option: --skipsource
So I have the path of the po2oo used : ./solver/300/unxlngx6.pro/bin/po2oo
So I tried : ./solver/300/unxlngx6.pro/bin/po2oo --version
Answer: 1.5.3 that is the version already on the system
If I do the same on master branch, answer 1.8.1
I conclude that there is a problem with some link when working with
Multiple Work Dirs as recommended on the wiki.
Regards
JBF
Ok, it works if I copy ./solver/300/unxlngx6.pro/bin/translate from my
master branch to ./solver/300/unxlngx6.pro/bin/ in my libreoffice-3-4
branch.
Regards.
JBF
--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: REMINDER: Release 3.4.0-rc1 from ooo-build-3-2-1 branch == string and UI freeze
Hi Kendy, Jan Holesovsky wrote (03-05-11 11:17) Please - what went wrong that this serious bug has not appeared among the 3.4 Most Annoying Bugs? Without that, it was impossible to focus on this - it just stayed hidden among the flow of the other 'normal' bugs. I guess it's partly my fault, cause I expected the problem to be picked up, cause it was mentioned on some lists long ago. A bit naive, but attracting in times of large work loads :-) And please, do you have suggestions what can we do to stress / get to the public knowledge that: - to get the proper attention to the real blockers, they _must_ appear in the Most Annoying Bugs [https://bugs.freedesktop.org/show_bug.cgi?id=35673] - the Most Annoying Bugs are meant for really serious bugs only, and not for my favorite red button should be blue, and that such bugs will be removed from there - daily builds [http://dev-builds.libreoffice.org/] are important, and can be used for testing even between betas, ie. the next day after the bug is fixed, and pushed to the repository AFAIAC, I mention those regularly on the Dutch lists. We need time to get this in the minds (and hearts) of the people. Kind regards, Cor -- - http://nl.libreoffice.org - giving openoffice.org its foundation :: The Document Foundation - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: REMINDER: Release 3.4.0-rc1 from ooo-build-3-2-1 branch == string and UI freeze
Hi Michael, Michael Meeks wrote (03-05-11 12:30) On Mon, 2011-05-02 at 21:28 +0300, Sophie Gautier wrote: Yes I do too, but the issue is that we didn't test the betas at all yet due to this bug Which sucks; hopefully the Windows Mac builds have been use-able for testing - and of course, the snapshots of them. But are we relative sure that this does that give enough feedback from people we can expect to help testing? and it covers a quiet large range of distributions. So, may be we should really take time to test the RC fully before really calling it an RC and spread the word around it. The danger of this - is that by introducing further delay into the release pipeline - we slow down our ability to respond to bugs that are I don't see this problem. The current build scheme can be kept, just in the naming there will be a shift. found, and since we are releasing a build per week anyway - we can only really choose to miss out a week: which isn't that wonderful :-) Already we only have a few days to fix a bug in RCn and get the fix out in RCn+1. -Far- better for people to be running and using the daily snapshot releases and reporting bugs against them - instead of waiting for RCs (per-se). Yes, but as mentioned before: people have to get used to this way of working. Plus that still the snapshots (and betas) will replace the stable version, which does not help testing too. So that are all pointers that we are risking quality. Having said that - warning that RC1 may be a bit rough in the release notes is a good idea :-) - although, given that this is caused by some I will have to advice people to be very careful with installing a RC1 that has been probably tested rather little and is to replace the stable version and also introduces a lot of changes in our code base. obscure compiler problem - apparently only present on the gross / old system we compile the binaries on for Linux, I'm optimistic that once it is fixed we'll not be in such terrible shape. I try to share your optimism, but would feel far more comfortable with an intermediate step looking at the very special situation. Would it bring someone in big trouble? Kind regards, Cor -- - http://nl.libreoffice.org - giving openoffice.org its foundation :: The Document Foundation - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] What is the exact system switches used for the x86 linux build?
Hi Christian, On 2011-04-30 at 23:58 +0200, Christian Lohmaier wrote: https://bugs.freedesktop.org/show_bug.cgi?id=36275 affected Distros (at least) * Mandriva 2010.2 * Debian Lenny * Ubuntu 10.4 * Ubuntu 10.10 * Fedora 14 * Fedora 15 * Puppy (not sure what version, wasn't mentioned) There is no point in releaseing beta after beta when you cannot run it. For beta1 - OK; shit happens. But beta1 should have taught the lesson to do minimal sanity checks before releasing the builds/putting them on the mirror/announcing them. beta2: OK, might have been special distros only. beta3: Sorry, no mercy, no understanding why this happens yet again. The problem here is that the bug did not have the proper visibility for quite a long time - this is one of those that should have been added to the Most Annoying Bugs as soon as it showed up it is a broader problem. Without that, we did not have the opportunity to spot it / give it the right priority. I am afraid that the use rules for the Most Annoying Bugs is not enough widespread yet, so please let me summarize it: - To get the proper attention to the real blockers, they _must_ appear in the Most Annoying Bugs [https://bugs.freedesktop.org/show_bug.cgi?id=35673] - The Most Annoying Bugs are meant for really serious bugs only, and not for my favorite red button should be blue; such bugs will be removed from there If they do not appear there, there is a big probability they'll be overlooked, even if mentioned on all the mailing lists many times. BTW, the nightly build from yesterday evening has the issue fixed: http://dev-builds.libreoffice.org/daily/Linux_x86_Release_Configuration/libreoffice-3-4/2011-05-02_18:50:09/ Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#31251 Writer Impress shadow consistency
On Sat, Apr 30, 2011 at 06:58:29PM +0200, Sébastien Le Ray wrote:
if(aShadowColor != SwViewOption::GetShadowColor() ) {
aShadowColor = SwViewOption::GetShadowColor();
-AlphaMask aMask( SW_RES( BMP_PAGE_BOTTOM_RIGHT_SHADOW_MASK ) );
-Bitmap aFilledSquare( Size( mnShadowPxWidth, mnShadowPxWidth ), 24 );
-aFilledSquare.Erase( aShadowColor );
+AlphaMask aMask( shadowMask.getBottomRight().GetBitmap() );
+Bitmap aFilledSquare( aMask.GetSizePixel(), 24 );
+aFilledSquare.Erase( aShadowColor );
...
This looks like a good candidate for a function... Like
void lcl_createShadow(Color const rColor, BitmapEx const rMask,
BitmapEx rShadow)
{
AlphaMask aMask( rMask.GetBitmap() );
Bitmap aFilledSquare( aMask.GetSizePixel(), 24 );
aFilledSquare.Erase( rColor );
rShadow = aFilledSquare;
}
But this is really just nice to have, not a blocker :)
if ( bPaintRightShadow )
{
-SwPageFrm::GetRightShadowRect( _rPageRect, _pViewShell, aPaintRect,
bRightSidebar );
+pOut-DrawBitmapEx( pOut-PixelToLogic( Point( aPaintRect.Right() +
1, aPagePxRect.Bottom() + 1 - (aPageBottomRightShadow.GetSizePixel().Height()
- mnShadowPxWidth) ) ),
+aPageBottomRightShadow );
+pOut-DrawBitmapEx( pOut-PixelToLogic( Point( aPaintRect.Right() +
1, aPagePxRect.Top() - mnShadowPxWidth ) ),
+aPageTopRightShadow );
BitmapEx aPageRightShadow = aPageRightShadowBase;
-aPageRightShadow.Scale( 1, aPaintRect.Height() );
-pOut-DrawBitmapEx( pOut-PixelToLogic( aPaintRect.Pos() ),
aPageRightShadow );
-pOut-DrawBitmapEx( pOut-PixelToLogic( Point( aPaintRect.Left(),
aPaintRect.Top() - mnShadowPxWidth ) ), aPageTopRightShadow );
-pOut-DrawBitmapEx( pOut-PixelToLogic( aPaintRect.BottomLeft() ),
aPageBottomRightShadow );
+aPageRightShadow.Scale( 1, aPagePxRect.Height() - 2 *
(mnShadowPxWidth - 1) );
+pOut-DrawBitmapEx( pOut-PixelToLogic( Point( aPagePxRect.Right() +
1, aPagePxRect.Top() + mnShadowPxWidth - 1) ), aPageRightShadow );
Do I count wrong or is the right shadow painted over the bottom right
corner shadow? And the same for left shadow lower.
@@ -5326,20 +5326,19 @@ const sal_Int8 SwPageFrm::mnShadowPxWidth = 9;
aPageTopRightShadow );
BitmapEx aPageRightShadow = aPageRightShadowBase;
aPageRightShadow.Scale( 1, aPagePxRect.Height() - 2 *
(mnShadowPxWidth - 1) );
-pOut-DrawBitmapEx( pOut-PixelToLogic( Point( aPagePxRect.Right() +
1, aPagePxRect.Top() + mnShadowPxWidth - 1) ), aPageRightShadow );
+pOut-DrawBitmapEx( pOut-PixelToLogic( Point( aPaintRect.Right() +
mnShadowPxWidth, aPagePxRect.Top() + mnShadowPxWidth - 1) ), aPageRightShadow
);
Is this really correct? AFAICS it moves the shadow too much to the
right... And if it is correct, why the corner shadows do not need to be
adjusted too?
D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Fixed bug regarding zero values not appearing (Bug 36748).
Hi Cassio, On 2011-05-01 at 18:27 +0100, Cassio Neri wrote: It's probably unnecessary to say this but, for the avoidance of doubt, my contribution is released under LGPLv3+ / MPL. Please find attached a patch to fix bug 36748. Very nice, thank you for that! :-) Kohei has already pushed this, so just marking this thread accordingly. Thanks a lot, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] ooinstall: respect DESTDIR
On Sun, Apr 24, 2011 at 01:51:47PM +0200, Andreas Radke a.ra...@arcor.de
wrote:
DESTDIR seem to be not properly applied to ooinstall. Has anybody
tested this? It doens't work for me.
I had the same problem, the attached patch seems to fix it here.
Petr, could you please review and in case it looks ok, then sign off /
push it to -3-4?
Thanks.
From 0cabc8890365201cd8ad5764473c5fe50e0f06f5 Mon Sep 17 00:00:00 2001
From: Miklos Vajna vmik...@frugalware.org
Date: Tue, 3 May 2011 14:27:06 +0200
Subject: [PATCH] ooinstall: respect DESTDIR
The problem was that ooinstall just passed -destdir to
make_installer.pl, but before that, it tried to create the root
directory, where it did not respect DESTDIR.
---
solenv/bin/ooinstall |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/solenv/bin/ooinstall b/solenv/bin/ooinstall
index 7ab12b9..b3f4c5f 100755
--- a/solenv/bin/ooinstall
+++ b/solenv/bin/ooinstall
@@ -29,7 +29,7 @@ for $arg (@ARGV) {
$help = 1;
} else {
# Cwd::realpath does not work if the path does not exist
- mkpath($arg) unless -d $arg;
+ mkpath($ENV{DESTDIR} . $arg) unless -d $ENV{DESTDIR} . $arg;
$path = Cwd::realpath( $arg );
}
}
--
1.7.4.4
pgp9PEAmD6DJp.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: Strange filesystems-related enum in libs-gui/tools
Hi Francois, On 2011-05-03 at 11:22 +0200, Francois Tigeot wrote: Following a short discussion on IRC, I've decided to remove the bulk of the code and use a single #if defined(WNT) check instead. The attached patch is relative to libs-gui. Nice cleanup - pushed. Thank you! :-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Remove tools/table.hxx include
Thanks Rafael :-) -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Re: Strange filesystems-related enum in libs-gui/tools
Hi Jan, On Tue, May 03, 2011 at 02:35:27PM +0200, Jan Holesovsky wrote: On 2011-05-03 at 11:22 +0200, Francois Tigeot wrote: Following a short discussion on IRC, I've decided to remove the bulk of the code and use a single #if defined(WNT) check instead. The attached patch is relative to libs-gui. Nice cleanup - pushed. Thank you! :-) Thanks for beeing so enthusiastic, but I didn't think this patch would be pushed so soon. It was merely intended for discussion atm. Maybe I should have added a warning... At least the code still compiles this time, I've just finished building -head ;) -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] fdo#31251 Writer Impress shadow consistency
Hi David, Sebastien, On 2011-05-03 at 14:37 +0200, David Tardon wrote: So - I like it, and would love to include for 3.4; one more review needed :-) - David? Cedric? +1 from me, even with the small glitches Great, thanks a lot! Pushed :-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: REMINDER: Release 3.4.0-rc1 from ooo-build-3-2-1 branch == string and UI freeze
Le 03/05/11 12:30, Michael Meeks a écrit : Hi Michael, Which sucks; hopefully the Windows Mac builds have been use-able for testing - and of course, the snapshots of them. Unfortunately, both beta1 and beta2 refused to start on my Mac, that kind of leaves potential volunteer testers with a bitter taste in their mouth that their time could be better spent elsewhere despite their willingness to help out grin. As to using the nightly builds, well, I would say fine, if, and only if: (a) they are actually available - speaking for Mac, this has not been a regular occurrence for a while ; (b) you can easily install it next to your production version of LO, without it destroying your stable environment. Of course, on Mac, the solution is relatively simple, but it still involves : (a) renaming your stable app bundle name to something other than the string LibreOffice ; (b) renaming your /Library/Applications Support/LibreOffice folder to the same string as your newly renamed stable app ; (c) installing the test version (be it beta, rc, or nightly). That is a lot of effort for people who are keen to help out by just testing to see if the app actually works !! Then they have to run the battery of tests (still to be defined), and/or pick their favourite module to test on, etc. Knowing that any extensions they might want to test (other than bundled) also have to be reinstalled each time they install a new test version, it makes for a rather painstaking testbed setup. Hence, all the hooha about re-activating the dev switch so that at least the testers can install a version of LibO which, in theory, will be an independent, self-contained launchable version. Personally, I get by with a mix of nightly build (when available) and the betas, rcs, etc as and when they are released. However, I would like to point out that currently, testing of nightly builds and reporting of incidents related thereto seems to bear less weight with the devs than the betas or rcs, probably because if it is reported on the dev mailing list, then it can go unnoticed in the flow of patches flying back and forwards (which would seem fairly logical). My current understanding is that the QA Litmus framework is not yet quite ready for prime time, so in the meantime we still need a mechanism whereby anything we discover in the nightly builds does not remain under the radar. Bugzilla obviously doesn't appear to cater for such an eventuality as yet. The question will also arise when testing nightly/daily builds as to which branch of the repo actually represents the build - my understanding is that the nightly/daily is from master - this is not the same as the feature/string frozen branch of a future release, even if the changes/bug fixes are pushed back to master afterwards. Master potentially contains all sorts of stuff that will not be in the future final release branch, or have I misunderstood something ? Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Remove usage of List in SbiDdeControl
Hi Rafael, On 2011-04-27 at 11:36 -0430, Rafael Dominguez wrote: Well this patch is for windows only, but i develop only in linux, so if anyone can please review it and test it for me. Thanks I am terribly sorry this takes so long :-( - the Windows guys are busy with the 3.4 release. I am just trying the patches on my box, but that is going to take about a day to compile, really sorry for that. All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] ooinstall: respect DESTDIR
Miklos Vajna píše v Út 03. 05. 2011 v 14:33 +0200: On Sun, Apr 24, 2011 at 01:51:47PM +0200, Andreas Radke a.ra...@arcor.de wrote: DESTDIR seem to be not properly applied to ooinstall. Has anybody tested this? It doens't work for me. I had the same problem, the attached patch seems to fix it here. Petr, could you please review and in case it looks ok, then sign off / push it to -3-4? Looks fine. I have pushed it. Thanks a lot for looking at it. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] source Java
Hello Luiz, On Tue, May 3, 2011 at 1:40 PM, Luiz Henrique Natalino luizhenriquenatal...@gmail.com wrote: how to insert an encoded source libreoffice in JAVA? Can you give us a more detailed example of what you want to do? Thanks, -- Jesús Corrius je...@softcatala.org Document Foundation founding member Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] When downloading extensions to src, cut is provided with wrong option switches
Hi all, After an ./autogen including all the extension switches, I downloaded the newly available extensions using ./download, and this error/warning occurs : Copy extensions to their location ... Looking for /Users/alex/DevHack/git/libo/src/7e7efc5d4a03126bb9ae3ae9aa2c4e87-Barcode_1.3.1.0.oxt ... ok cut: illegal option -- - usage: cut -b list [-n] [file ...] cut -c list [file ...] cut -f list [-s] [-d delim] [file ...] Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Petr Mladek pmla...@suse.cz changed: What|Removed |Added Depends on||35554 --- Comment #50 from Petr Mladek pmla...@suse.cz 2011-05-03 07:19:33 PDT --- Add bug #35554: GNOME integration still does not work with 3.4.0-beta3. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Petr Mladek pmla...@suse.cz changed: What|Removed |Added Depends on|35554 | -- 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] [libreoffice-l10n] Re: REMINDER: Release 3.4.0-rc1 from ooo-build-3-2-1 branch == string and UI freeze
On Tue, May 3, 2011 at 13:02, Sophie Gautier gautier.sop...@gmail.com wrote: On 03/05/2011 13:30, Michael Meeks wrote: Having said that - warning that RC1 may be a bit rough in the release notes is a good idea :-) But a RC1 is supposed to be a release candidate, so how could it be rough? I agree. If it's still a bit rough, it should be called a beta version instead of a RC. Regards, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] testDataPilot unit test breaks in sc
On Mon, 2011-05-02 at 16:08 +0200, Andras Timar wrote: This unit test expects that the UI is in English. Two English strings are hard coded into this test: Sum and Total. So, I looked into this this morning in hopes of finding a way to set UI locale to en-US explicitly. http://cgit.freedesktop.org/libreoffice/calc/commit/?h=libreoffice-3-4id=5051d6a1f1e239fb38c60a227046111ec438a518 But at the moment this causes run-time exception. I haven't investigated deeper into this to find out why. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] ooinstall: respect DESTDIR
Am Tue, 03 May 2011 15:02:07 +0200 schrieb Petr Mladek pmla...@suse.cz: Looks fine. I have pushed it. Thanks a lot for looking at it. Best Regards, Petr $DESTDIR is now recognised. Thanks. Please close https://bugs.freedesktop.org/show_bug.cgi?id=3 But all files are now put under /usr/lib/libeoffice. In 3.3.x some files were put to /etc, /usr/bin and to /usr/share. Can you also fix this for better desktop integration? -Andy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] ooinstall: respect DESTDIR
Hi Andreas, On Tue, 2011-05-03 at 18:18 +0200, Andreas Radke wrote: $DESTDIR is now recognised. Thanks. Please close https://bugs.freedesktop.org/show_bug.cgi?id=3 I closed it; however - you are likely to provoke a negative reaction by appearing to tell people what to do :-) This is not a list to report or manage bugs on (unless there are patches as well). But all files are now put under /usr/lib/libeoffice. In 3.3.x some files were put to /etc, /usr/bin and to /usr/share. Can you also fix this for better desktop integration ? I would suggest that this is something you could look into yourself; digging in 'scp2' might be a good place. Of course - it means that the goal of parallel-installability (something other people are clamouring for), is much harder to achieve. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] corrupted tables in docx import
Hello,
I originally posted this bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=33462
In versions later than OO v3.2.1, importing a docx file that contained a
table with a fixed-height row somewhere caused all other rows in any tables
to adopt this height making the document hard to use.
I found a fix. I'd like to point that this tiny fix makes docx documents
much more usable in LO. According to Noel Power it should be put into
release v3.4.
As I'm not really used to send patches over mailing lists so far, I hope you
can use this kind of format. Feel free to use it under the LGPL v3+ and to
check it in. :)
---
diff --git a/writerfilter/inc/resourcemodel/TableManager.hxx
b/writerfilter/inc/resourcemodel/TableManager.hxx
index 7579ff6..6ea3da5 100644
--- a/writerfilter/inc/resourcemodel/TableManager.hxx
+++ b/writerfilter/inc/resourcemodel/TableManager.hxx
@@ -221,7 +221,7 @@ class TableManager
void resetRowProps()
{
- mpCellProps.reset();
+ mpRowProps.reset();
}
void setRowProps(PropertiesPointer pProps)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSoC 2011] Some technical question
Hi all, I'm happy to be on board and spending the GSoC time-frame working with you. As I said I'll start hacking on May, 23, however in the bound period I want to get more in confidence with the tools required for LibreOffice development, so some questions follow. Where should I put the source code I'll write down ? Should I create a development branch as described on the Easy Hack page ? Shall I choose the branch name by myself (e.g. gsoc2011/svgfilter) or there is already an ad-hoc branch ? To submit the code, should I send a mail with an attached patch ? (saying weekly), or you'll provide me an account to push my branch on the remote repository directly. When I add new header/source files, do I have to modify any build configuration file ? Btw how does the LibreOffice build system work ? How can I find out the header file targeted by an include directive ? I can see that sometime the same header file is in more than one place. For instance given the include directive: #include xmloff/xmlexp.hxx I can find: /libo/xmloff/inc/xmloff/xmlexp.hxx /libo/clone/filters/binfilter/inc/bf_xmloff/xmlexp.hxx /libo/solver/300/unxlngx6.pro/inc/xmloff/xmlexp.hxx Is there a configuration file per module/sub-project where are listed the include directories passed to the compiler ? Kind Regards, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [ANNOUNCE] libreoffice-3.3.99.4 tag created (3.4.0-beta4)
Hi, there have been created the libreoffice-3.3.99.4 tag for 3.4.0-beta4 release. The corresponding official builds will be available by the end of the week. See the attached list of changes against 3.4.0-beta3. You might switch your current 3-4 source tree to it using: ./g fetch --tags ./g checkout -b tag-libreoffice-3.3.99.4 libreoffice-3.3.99.4 Note that the build repo is not tagged. We would like to get rid of it. See also the schedule at http://wiki.documentfoundation.org/ReleasePlan#3.4.0_release Best Regards, Petr + bootstrap + enable extern scripting for offical LO builds (fdo#33355) [Petr Mladek] + calc + don't forget to create undo object for normal merging. (bnc#689442) [Kohei Yoshida] + treat filter by filter and filter by page separate. (fdo#36771) [Kohei Yoshida] + try a bit harder to determine the number format of a dimension. (bnc#677917) [Kohei Yoshida] + components + automation-testtool-oobuildfix.diff: testtool and basic compatability defaults (bnc#145906) [Petr Mladek] + dictionaries belong to main install not to langpacks (fdo#34910) [Andras Timar] + revert native334 # no more change of DS_Store file (#163388) [Thorsten Behrens] + wizards-source-importwizard-filesmodul-xba.diff: document converter fix (bnc#113235, i#56633) [Petr Mladek] + filters + fix-ppt-linespacing-import-export.diff: fix ppt import (bnc#355302) [Radek Doulik] + goodies-eps-filter-unix.diff: generate correct EPS on UNIX (bnc#200053) [Radek Doulik] + svx-ppt-bullet-offset-fix.diff: bullet list paragraph indentation (bnc#593609) [Radek Doulik] + svx-ppt-import-fix-bullet-size.diff: bullet size import (bnc#515972) [Radek Doulik] + impress + fix-ppt-linespacing-import-export.diff: fix ppt import (bnc#355302) [Radek Doulik] + pdf-link-export-fix.diff: (bnc#639278, bnc#598816) [Cédric Bosdonnat] + sd-ppt-fix-document-summary-reading.diff: crasher fix (bnc#546758) [Radek Doulik] + libs-core + copy localized globlmn.hrc to $(OUTDIR)/inc/svx (fdo#36727) [Andras Timar] + fix-ppt-linespacing-import-export.diff: fix ppt import (bnc#355302) [Radek Doulik] + fixed components names reintroduced with .component files (fdo#32872) [Cédric Bosdonnat] + normalize-template-paths-fix.diff: allow to install templates from extensions (bnc#512146) [Thorsten Behrens] + remove status listener upon exit (lp#754562) [Bjoern Michaelsen] + svx-fix-fit-to-frame-crash.diff: fix for crash on Windows (bnc#508621) [Radek Doulik] + svx-sdrobjeditview-update-edit-area.diff: edit area calcualtion (bnc#305205, bnc#347355) [Radek Doulik] + update product code of vcredist_x86.exe (9.0.30729.4148) (fdo#32650) [Andras Timar] + libs-extern-sys + updated oc_FR dictionary to version 0.6.1 (fdo#36718) [Andras Timar] + libs-gui + fix for Spinboxes missing up/down arrows on Windows (fdo#36481) [Tor Lillqvist] + fix for corrupted IDE tabs when adding/deleting modules (fdo#36629) [Noel Power] + fix off-by-one when exporting postscript fonts to pdf (bnc#690005) [Luboš Luňák] + more than one text cursor at the same time in textfields (fdo#36404) [Robert Dargaud] + normalize-template-paths-fix.diff: allow to install templates from extensions (bnc#512146) [Thorsten Behrens] + once more, or, bitten by git .-) (fdo#36404) [David Tardon] + real fix this time (fdo#36404) [David Tardon] + svtools-unsort-template-dialogentries.diff: grouping items in templates dialog (bnc#106603) [Radek Doulik] + wmf-mm-text-1.diff: fix regression caused by wmf-mm-text.diff (bnc#417818) [Radek Doulik] + wmf-mm-text.diff: M_TEXT map mode support in wmf (bnc#417818) [Petr Mladek] + translations + change German string to Turkish (fdo#32987) [Andras Timar] + writer + writer-default-as-optimal-page-wrap.diff: Optimal Page Wrap by default (X#59831) [Jody Goldberg] + common + version 3.3.99.4, tag libreoffice-3.3.99.4 (3.4.0-beta4) [Petr Mladek] + artwork + updated page shadow masks. [Sébastien Le Ray] + bootstrap + Lightweight removal of BrOffice branding here in this branch [Tor Lillqvist] + 3.3 - 3.4 [Andras Timar] + add --enable-lomenubar switch to configure [Bjoern Michaelsen] + add -DBOOST_NO_EXCEPTIONS to gb_LinkTarget_NOEXCEPTIONFLAGS [Robert Nagy] + bump product version to 3.4.0-beta4, release number to 4 [Petr Mladek] + configure: fix help text of --with-install-dirname [Miklos Vajna] + do not pack empty help packs [Andras Timar] + do not ship non-localized helppacks [Andras Timar] + enable extern scripting for offical LO builds (fdo#33355) [Petr Mladek] + lo-commit-stat: detect mismatch of branches between repos [Petr Mladek] + lo-commit-stat: new --bug-numbers option to print just bug numbers [Petr Mladek] + ooinstall: respect DESTDIR [Miklos Vajna] + ooinstall: use DESTDIR also for the Cwd::realpath call [Petr Mladek] + oxygenOffice distro conf update [libo64] + put
Re: [Libreoffice] Moving duplicate code into methods
Hi, +sal_Int32 GetNumberOfProperties ( const SvxMSDffHandle* pData ) and +void SetProperties (const SvxMSDffHandle* pData, com::sun::star::beans::PropertyValues rPropValues) looks ok to me - or maybe ShapePropertiesFromDFF or somesuch, as set/getProps sounds somehow generic (and is quite heavily overloaded as a name). Additionally, please make those methods static (they're only used inside that file) - and another loosely followed convention is to prefix those local methods with either lcl_ or Impl/impl. So we have: static sal_Int32 prefixGetNumberOfProperties ( const SvxMSDffHandle* pData ) and static void prefixShapePropertiesFromDFF (const SvxMSDffHandle* pData, com::sun::star::beans::PropertyValues rPropValues) with prefix = lcl_ or [Ii]mpl - is one of these prefices more modern than the others? What about indentation and formatting of if/then/else or switch statements? Any rules? Though that's a matter of taste ... ;) That's why I've asked for review :-) Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] [PATCH] corrupted tables in docx import
Hi Marcel On 03/05/11 18:46, Marcel HB wrote: Hello, I originally posted this bug here: https://bugs.freedesktop.org/show_bug.cgi?id=33462 [...] As I'm not really used to send patches over mailing lists so far, I hope you can use this kind of format. Feel free to use it under the LGPL v3+ and to check it in. :) Thanks again for the patch ( and the efforts you made to fight with the docx filter to identify the problem ) It is pushed now to the 3.4 branch, the commit is here http://cgit.freedesktop.org/libreoffice/filters/commit/?h=libreoffice-3-4id=489fdfcdf2a84fe4d87b6f3d1c1a8cffa0f6c4f5 regards Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] [REVIEW] html-select import
On 03/05/11 15:38, Noel Power wrote: Hi, Be great if someone could review cherrypick this patch ( ported from build repo ) that solves bnc#523191 ) appears that for this week it's ok still to do a bugfix and just post to the list ( so I pushed it ) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #52 from clio fyv...@ya.ru 2011-05-03 12:54:25 PDT --- Consider Bug 35706 – Ctrl F, Ctrl Alt F doesn't work in Basic IDE Also, in Draw and Writer components, when the Draw panel is active, the Find toolbar doesn't have enough space whith Default icons and 1280*800 screen resolution. IMHO, this patch is not stable for release yet. Also note these Basic IDE bugs: https://bugs.freedesktop.org/show_bug.cgi?id=30545#c7 And this bug: Bug 35480 – Curves have round control points with black background (the solution is to use the picture markers2.png from hg.services.openoffice.org or to save it with options given in the bug) The fix for the filter would be better, but as far as it is not fixed, IMHO, the picture should be fixed, because it is publicly visible contrary to the hidden bug with PNG exporting that appears in very rare cases. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 35554, which changed state. Bug 35554 Summary: LO-3.4: missing GNOME integration https://bugs.freedesktop.org/show_bug.cgi?id=35554 What|Old Value |New Value Resolution||INVALID Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC 2011] Some technical question
Marco wrote: Where should I put the source code I'll write down ? Should I create a development branch as described on the Easy Hack page ? Shall I choose the branch name by myself (e.g. gsoc2011/svgfilter) or there is already an ad-hoc branch ? Recommended branch naming convention is feature/name, so feature/svgexport or somesuch would be good. To submit the code, should I send a mail with an attached patch ? (saying weekly), or you'll provide me an account to push my branch on the remote repository directly. Commit access is usually offered when project members agree on that the person is doing a good job; meanwhile, git format-patch - generated mails of your branch is appreciated - or you push to one of the many free git hosting sites (you'll likely only need the filters repo for the while). When I add new header/source files, do I have to modify any build configuration file ? Btw how does the LibreOffice build system work ? Currently changing - but for the filter module, just edit the makefile.mk next to your source files - it should be reasonably self-explanatory. How can I find out the header file targeted by an include directive ? I can see that sometime the same header file is in more than one place. For instance given the include directive: #include xmloff/xmlexp.hxx I can find: /libo/xmloff/inc/xmloff/xmlexp.hxx /libo/clone/filters/binfilter/inc/bf_xmloff/xmlexp.hxx /libo/solver/300/unxlngx6.pro/inc/xmloff/xmlexp.hxx libo/xmloff/inc/xmloff/xmlexp.hxx is the master version, libo/solver/300/unxlngx6.pro/inc/xmloff/xmlexp.hxx is just a copy/symlink - not under revision control, but the file actually included by the compiler. The solver subdir is used as a kind of blackboard - modules export things into that, everything not copied there is not accessible from outside a module's subdir. You can safely ignore everything below /libo/clone/filters/binfilter. Is there a configuration file per module/sub-project where are listed the include directories passed to the compiler ? Just stick with the existing include directories for the while. Put private headers next to your cxx, and stuff you need to export (because it's part of your module's API) into module/inc/module. (I don't think the latter is necessary for your project, though). HTH, -- Thorsten pgpHwqACrK3AW.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #53 from Jean-Baptiste Faure jbf.fa...@orange.fr 2011-05-03 14:12:20 PDT --- I would like nominate bug 36519 : it is may be received as a very bad signal by ODF adepts. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Jean-Baptiste Faure jbf.fa...@orange.fr changed: What|Removed |Added Depends on||36519 -- 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] [ANNOUNCE] libreoffice-3.3.99.4 tag created (3.4.0-beta4)
Hi Petr, *, Petr Mladek schrieb: Hi, there have been created the libreoffice-3.3.99.4 tag for 3.4.0-beta4 release. The corresponding official builds will be available by the end of the week. See the attached list of changes against 3.4.0-beta3. So if I see it right https://bugs.freedesktop.org/show_bug.cgi?id=36437 didn't go in?? That's very sad, as it is already fixed. [..] Gruß/regards -- Friedrich Libreoffice-Box http://libreofficebox.org/ LibreOffice and more on CD/DVD images ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [ANNOUNCE] libreoffice-3.3.99.4 tag created (3.4.0-beta4)
Friedrich Strohmaier wrote: https://bugs.freedesktop.org/show_bug.cgi?id=36437 didn't go in?? That's very sad, as it is already fixed. Version was planned as rc initially, where the fix would not be useful. Sometimes not all constraints can be satisfied - and the bug you quote is there since last September, and only recently reported. Cheers, -- Thorsten pgpPw6GGeKm6p.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [ANNOUNCE] libreoffice-3.3.99.4 tag created (3.4.0-beta4)
I'm not sure I understand this: does this mean that RC releases are not considered temporary builds and will be allowed to replace the previous stable build? Will Beta4 overwrite my stable 3.3.2? -- View this message in context: http://nabble.documentfoundation.org/ANNOUNCE-libreoffice-3-3-99-4-tag-created-3-4-0-beta4-tp2895369p2896582.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] First build has stalled...
Having got ./autogen to work I decided to try a Buid. And it has stalled for over an hour at this point. Last login: Tue May 3 16:44:24 on ttys000 Gandalf:~ pteeson$ cd git/libo Gandalf:libo pteeson$ make checking build system type... i686-apple-darwin10.6.0 ... = libs-core = Cloning into libs-core... remote: Counting objects: 2955 So I did Ctl-C = libs-core = Cloning into libs-core... ^Cmake: *** Deleting file `dmake/dmake' error: index-pack died of signal 2 fatal: index-pack failed make: *** [dmake/dmake] Interrupt Comments? Suggestions? respect... Peter ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] First build has stalled...
On 05/04/2011 04:00 AM, Peter Teeson wrote: Having got ./autogen to work I decided to try a Buid. And it has stalled for over an hour at this point. Last login: Tue May 3 16:44:24 on ttys000 Gandalf:~ pteeson$ cd git/libo Gandalf:libo pteeson$ make checking build system type... i686-apple-darwin10.6.0 ... = libs-core = Cloning into libs-core... remote: Counting objects: 2955 So I did Ctl-C = libs-core = Cloning into libs-core... ^Cmake: *** Deleting file `dmake/dmake' error: index-pack died of signal 2 fatal: index-pack failed make: *** [dmake/dmake] Interrupt Comments? Suggestions? respect... Peter ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Same issue had happened to me. I would like an explanation as to why cloning is so slow. Just to clone all the repos it took me about 18 hrs at about 20 to 25 kbps ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Rainer Bielefeld libreoff...@bielefeldundbuss.de changed: What|Removed |Added Depends on||34184 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Rainer Bielefeld libreoff...@bielefeldundbuss.de changed: What|Removed |Added Depends on||34093 -- 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] [ANNOUNCE] libreoffice-3.3.99.4 tag created (3.4.0-beta4)
2011/5/4 plino pedl...@gmail.com: I'm not sure I understand this: does this mean that RC releases are not considered temporary builds and will be allowed to replace the previous stable build? Yes. Will Beta4 overwrite my stable 3.3.2? Yes. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
