Re: [Libreoffice] [PUSHED] Adding and Removing Color Charts
On 25-03-11 07:20, Michael Meeks wrote: Hi Rob, On Thu, 2011-03-24 at 21:37 +0100, Rob Snelders wrote: I have created a patch that enables users to add and remove Color Charts. Oooh, nice :-) I had a play with Tools->Options->Chart colors, and it seems to work very nicely - I tried the corner cases of no colors, and so on and they seem to work. Adding black colors is a bit nasty though :-) I wonder if we could clone the previously selected color instead (?) The only problem is that when you select a color it will set that color for the selected item. So you change the color-chart you already had. Also, I guess perhaps we should dynamically renumber / rename the existing colors if we remove colors in the middle (?) although its not perhaps very cricical (thoughts on that ?). I also think that is needed. Also it will be needed to select the added item when you add an item, and select the next item when you delete an item. I'll try to work on that next week. Anyhow - I've pushed it; can you confirm it is licensed LGPLv3+/MPL ? and was this a result of the Netherlands hack-fest ? :-) it should show up in 3.4. Yes, this is a result of that hack-fest. It was fun and enlightning to work there, I there will be another one, there where plans. ATB, Michael. Greetings, Rob Snelders ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#32413: Add an apply button to style edit dialog in Writer
On Fri, Mar 25, 2011 at 08:48:25PM +, Michael Meeks wrote: > Looks lovely to me - though I guess it might be nice to just pick a > large number for RET_APPLY and not put that in vcl; that seems to be > how others do it eg. > > sfx2/inc/docvor.hxx:#define RET_EDIT_STYLE 100 > sfx2/inc/sfx2/new.hxx:#define RET_TEMPLATE_LOAD 100 > > etc. if we want to clean this up - we should add a: > > #define RET_CUSTOM_START 100 > > or something, to the vcl header, and then use that (I think) Ah, I didn't see it. We talked about this with Cedric and he explained an idea which avoids any modification in vcl, so I'm not planning to push this version, a better one will come soon. The main problem is not with the modification, but if you move the dialog, click Apply, then its position will be reset, which is ugly. > > Also, I can change the indentation in sw/source/ui/app/docst.cxx, I > > didn't do it yet for easier review. > .. > > What's your opinion, OK to push? > > With the above tweak I'm enthusiastic - nice patch ! :-) but ... why > are you (Mr Awesome) doing 'easy' hacks ? :-) I guess for each one you > fix, you need to research & create one more ;-> Partly because of GSoC - it's listed on the wiki page that students should solve one before applying. Partly as this touches GUI code - which I never did before, so it amuses me. :) pgpEVajRcfwnv.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fix odfflatxml and xsltfilter component registration
Hi Peter, On Fri, 2011-03-25 at 22:59 +0100, Peter Jentsch wrote: > the component registration seems to have changed recently, which broke > the new odf flat xml export and the libxslt based xslt transformation > service. Right ! :-) nice catch, and well done unwinding the new scheme which is rather different. > I'm unsure how to reliably get the service.rdb rebuilt after changing > the component definitions, just rebuilding postprocess It is quite possible that we don't linkoo 'services.rdb' and we probably should - perhaps we didn't do this in the past since it was built at install time; hacks to solenv/bin/linkoo to improve that appreciated :-) I added the component name to postprocess/packcomponents/makefile.mk - perhaps that was the missing piece (unless you didn't deliver?). Thanks muchly ! 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] removing the executable mode from some source files
Hi Saito, On Fri, 2011-03-25 at 14:50 -0300, saito wrote: > I discovered what is wrong with the perl files that dows not uses > shebangs. The perl file postprocess/rebase.pl is a valid executable > script, but it does not uses shebang. Right - it uses this env trick to avoid hard-coding the path of perl which varies cross-platform. > So I changed my script to search for "\ script" using "grep" and > "file" commands and no more file type (extensions) exclusion patterns. It seems to mis-categorise a number of things: postprocess/postprocess/packconfig/packconfig.pl But - wow, there a ton of mis-categorised files :-) if you can instead get a list of known-good mis-categorised files as a text file that we can just pass to "xargs chmod a-x" that we are certain are wrong - then we can iterate towards fixing the others too. So - as a start, just listing all the simple file types eg. .oxt, .sxw, .xls, .bas files etc. that are mis-tagged would be really useful - and lets get that lot fixed & committed. Thanks ! 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] Remove unused file edittest.cxx in svx module
Hi Rafael, On Fri, 2011-03-25 at 16:36 -0430, Rafael Dominguez wrote: > Im doing some DECLARE_LIST cleaning, i noticed that this file is not > used anywhere, clean build, can anyone confirm this? Sure - the workben/ code is normally just some sort of test harness often suffering various stages of bit-rot. Ideally we would be able to convert these over time into functioning tests we can run during the build. So far, we have left this code around, it can be useful. But you're right, almost certainly it is not used. 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] -Woverloaded-virtual
Hello, On 03/25/2011 02:13 PM, Lubos Lunak wrote: On Friday 25 of March 2011, Caolán McNamara wrote: argh!, I meant to say "then things are *not* too bad", not "*too* bad". I mean that's far less that I would have feared, quite manageable. Ok. In that case, if there are no objections, I'll commit my patches. just a bet: binfilter was off in your try? So I have some warning more to handle, once I am finished with cleaning. And I am always +1 for all what shows potential problems. Else it bites you harder later... regards Pierre-André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving
Hi Pierre, On Wed, 2011-02-16 at 22:39 +0100, Pierre-André Jacquod wrote: > after quite a long time, I have done a push again concerning this topic. > Sorry, I was very busy at work and had barely the time to go ahead. Nice ! :-) if this is right: git diff --numstat LIBREOFFICE_3_3_FREEZE..master binfilter > /tmp/changes.csv it seems to suggest we lost a net 55k lines out of that code since the 3.3 branch, ~5% of the code size at least - it sounds small, but lots of our problems require this sort of rock chipping solution :-) > So I will start on the next StarOffice format. Neato :-) it also looks like a good place for easy hacks I guess - if we could remove the functions that start the call tree, I wonder if we can publish a list of un-used functions from callcatcher ? Anyhow - great work, and good to get in for 3.4 before we freeze ! 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] fix odfflatxml and xsltfilter component registration
Hi, the component registration seems to have changed recently, which broke the new odf flat xml export and the libxslt based xslt transformation service. Attached are two patches to fix those. I'm unsure how to reliably get the service.rdb rebuilt after changing the component definitions, just rebuilding postprocess didn't seem to suffice and I manually edited services.input in the output tree there, so there might be some bit missing. Cheers, Peter >From 4eb7bfef439865c44eeaa60e34ebc29b885ae55b Mon Sep 17 00:00:00 2001 From: Peter Jentsch Date: Fri, 25 Mar 2011 08:02:31 +0100 Subject: [PATCH 1/2] add missing component registration for libxslttransformer --- filter/source/xsltfilter/xsltfilter.component |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/filter/source/xsltfilter/xsltfilter.component b/filter/source/xsltfilter/xsltfilter.component index 25a4797..5fb985c 100644 --- a/filter/source/xsltfilter/xsltfilter.component +++ b/filter/source/xsltfilter/xsltfilter.component @@ -31,4 +31,7 @@ + + + -- 1.7.1 >From 43e3435f60e1d056cf47f7f7293f4092282bfcac Mon Sep 17 00:00:00 2001 From: Peter Jentsch Date: Fri, 25 Mar 2011 22:51:51 +0100 Subject: [PATCH 2/2] fix odfflatxml export broken after merge --- filter/prj/d.lst |1 + filter/source/odfflatxml/makefile.mk |8 + filter/source/odfflatxml/odfflatxml.component | 37 + 3 files changed, 46 insertions(+), 0 deletions(-) create mode 100644 filter/source/odfflatxml/odfflatxml.component diff --git a/filter/prj/d.lst b/filter/prj/d.lst index 8957db6..160c266 100644 --- a/filter/prj/d.lst +++ b/filter/prj/d.lst @@ -63,6 +63,7 @@ mkdir: %_DEST%\inc%_EXT%\filter\msfilter ..\%__SRC%\misc\filterconfig1.component %_DEST%\xml%_EXT%\filterconfig1.component ..\%__SRC%\misc\flash.component %_DEST%\xml%_EXT%\flash.component ..\%__SRC%\misc\msfilter.component %_DEST%\xml%_EXT%\msfilter.component +..\%__SRC%\misc\odfflatxml.component %_DEST%\xml%_EXT%\odfflatxml.component ..\%__SRC%\misc\pdffilter.component %_DEST%\xml%_EXT%\pdffilter.component ..\%__SRC%\misc\placeware.component %_DEST%\xml%_EXT%\placeware.component ..\%__SRC%\misc\svgfilter.component %_DEST%\xml%_EXT%\svgfilter.component diff --git a/filter/source/odfflatxml/makefile.mk b/filter/source/odfflatxml/makefile.mk index aaffb35..0783bd9 100644 --- a/filter/source/odfflatxml/makefile.mk +++ b/filter/source/odfflatxml/makefile.mk @@ -54,3 +54,11 @@ SHL1STDLIBS= \ # --- Targets -- .INCLUDE : target.mk + +ALLTAR : $(MISC)/odfflatxml.component + +$(MISC)/odfflatxml.component .ERRREMOVE : $(SOLARENV)/bin/createcomponent.xslt \ +odfflatxml.component +$(XSLTPROC) --nonet --stringparam uri \ +'$(COMPONENTPREFIX_BASIS_NATIVE)$(SHL1TARGETN:f)' -o $@ \ +$(SOLARENV)/bin/createcomponent.xslt odfflatxml.component diff --git a/filter/source/odfflatxml/odfflatxml.component b/filter/source/odfflatxml/odfflatxml.component new file mode 100644 index 000..35238af --- /dev/null +++ b/filter/source/odfflatxml/odfflatxml.component @@ -0,0 +1,37 @@ + + +http://openoffice.org/2010/uno-components";> + + + + + -- 1.7.1 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving
Hello, On 03/25/2011 10:12 PM, Caolán McNamara wrote: On Fri, 2011-03-25 at 22:09 +0100, Pierre-André Jacquod wrote: something... Hopefully my tests are good And make check was successful,.. at last :- ) in case you're relying on it as some oracle :-) No, the other way around: I run make check to be sure not to break it, as I did once:- ) More seriously: I have my set of files for testing, but will nerveless be happy and thankful if other are also sometimes trying to use binfilter. regards ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Remove DECLARE_LIST( SvSlotElementList, SvSlotElement* )
0001-Remove-DECLARE_LIST-SvSlotElementList-SvSlotElement.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving
On Fri, 2011-03-25 at 22:09 +0100, Pierre-André Jacquod wrote: > something... Hopefully my tests are good And make check was > successful,.. at last :- ) FWIW make check doesn't do a *huge* amount, its a smoketest to ensure that basic functionality isn't broken. So for the binfilter side of things it just opens one .sdw, one .sdd, etc. So its very minimal, just in case you're relying on it as some oracle :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving
Hello, after working, hibernating, rebasing after changes,... and changing my way of doing this, I push again some deletions. I have done some deletions of functions that are not used any more within the binfilter and replaced theyre return value. All the code is not yet cleaned. I have done testing as far as I can, and I did not find out that I broke something... Hopefully my tests are good And make check was successful,.. at last :- ) regards Pierre-André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Pushed] Review needed to try to resurrect "add slide thumbnails to HTML export" part
Le 25/03/2011 07:37, Michael Meeks a écrit : Hi Julien, On Fri, 2011-03-25 at 00:25 +0100, Julien Nabet wrote: .. I don't know if it's what was expected but i'm sure it needs some reviewing since I added, changed and removed 1 or 2 things from the original patch. Heh - so, the essence is that the front-page of the slideshow: - test.html should have a little mosaic of the slides that you can click on (prolly this needs some html div/whatever love - perhaps we can ask the UI/design guys about that as/when we create the new list for that). If this patch is ok, i can of course push it. Looks fine to me :-) please do push it if it works as I outline above ;-) I checked by creating 20 slides and I got the mosaic. Of course, it could be better but this page is ok for W3C validation. So i pushed. We should also consult the design team as to whether they want this to be optional; there is a big white-space for 'options' in the 2nd page of the HTML export wizard that we could whack that into. Then again, IMHO adding gratuitous options is mostly cowardly (as previously discussed), either way IMHO the option should be on by default if it is there I think. I thought about creating a option for thumbnail but i didn't know how to do it. Perhaps, it could also be interesting to have as another option only the thumbnails just to leaf through. No doubt, there is quite some scope for cleaning up the HTML the HTML export dialog generates too in the light of the modern web. For html, maybe let's begin simple but "W3C correct" for having no surprise in any browsers. Then just a little css for the magic perhaps :-) We should define which browser and which version we would support. For example, IE6 seems quite hated by webdesigners and I fully understand since I did a little css and had to fight against IE6. But we could easily support IE (> 6), Safari, Mozilla family, Opera browsers. ... Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error building smoketestoo_native
It also fails without valgrind. This time I get: Backtrace: [42] /home/xisco/libo/solver/300/ unxlngi6.pro/installation/opt/program/soffice.bin: ???+0xda1 Exited with code '-1' officeconnection.cxx:140:Assertion Test name: N12_GLOBAL__N_14TestE::test setUp() failed - equality assertion failed - Expected: 2 - Actual : 0 Failures !!! Run: 1 Failure total: 1 Failures: 1 Errors: 0 dmake: Error code 1, while making 'cpptest' I attach the output of ./g log --one-1 2011/3/25 Caolán McNamara > On Fri, 2011-03-25 at 19:06 +0100, Xisco Faulí wrote: > > Hello, > > I'm trying to build this module with valgrind ( export > > VALGRIND=memcheck ) and I get an error in cpptest. > > Without VALGRIND=memcheck do you get an error ? The crucial bit looks > right at the top with "Failed to connect to pipe: and exit -1" so lets > disentangle a possible "smoketest doesn't work for me" vs "smoketest in > a debugging build doesn't work for me" vs "smoketest doesn't work under > valgrind". > > There was a little bit of fiddling around with the launcher > script/program over the last few days, which I think should have settled > down now. Hard to tell what someone is talking about at any given time, > but the last time I checked under VALGRIND yesterday or so smoketest > worked fine under valgrind for me something like ./g log --oneline -1 > might help there. > > > C. > > > log Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#32413: Add an apply button to style edit dialog in Writer
Hi Miklos, On Thu, 2011-03-24 at 12:17 +0100, Miklos Vajna wrote: > I'm attaching two patches, one for vcl, one for sw. Of course I could > introduce the define in sw, but that would cause problems when someone > would introduce a new define in vcl, so I did it this way. Looks lovely to me - though I guess it might be nice to just pick a large number for RET_APPLY and not put that in vcl; that seems to be how others do it eg. sfx2/inc/docvor.hxx:#define RET_EDIT_STYLE 100 sfx2/inc/sfx2/new.hxx:#define RET_TEMPLATE_LOAD 100 etc. if we want to clean this up - we should add a: #define RET_CUSTOM_START 100 or something, to the vcl header, and then use that (I think) > Also, I can change the indentation in sw/source/ui/app/docst.cxx, I > didn't do it yet for easier review. .. > What's your opinion, OK to push? With the above tweak I'm enthusiastic - nice patch ! :-) but ... why are you (Mr Awesome) doing 'easy' hacks ? :-) I guess for each one you fix, you need to research & create one more ;-> 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] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #6 from Petr Mladek 2011-03-25 13:48:15 PDT --- (In reply to comment #5) > please see > http://lists.freedesktop.org/archives/libreoffice/2011-March/009626.html I see that Michael actually suggested to link the bugs here ;-) > 35668 is a well reproducible crasher and should be fixed in any case. > > The others are not that critical IMHO, but keeping the complex and unoapi > tests > clean is a very valid goal. Luckily, because there are tests for these, they > should be rather easy to fix. Well, I would prefer to link here only bugs that really annoys people and breaks their daily work. Otherwise, we would end up with all bugs linked here and the purpose of the meta bug would be gone ;-) If you are going to fix them any time soon or you think that they point to serious problems, feel free to keep them linked. -- 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] l10n based on PO files
Hi Petr, > Petr Mladek píše v Čt 24. 03. 2011 v 21:38 +0100: > Worked well, so I have just pushed it. Here is the patch of the build repository (master). It is enough not to call localize-ooo. I went through localize-ooo and I found that it was deprecated. * merge localizations - not needed any more, we will migrate all localizations to the translations module * fix broken image in help, i#99165 - I pushed it today * workaround for i#56622, n#210797 - solved long time ago * copy help auxiliary files if they are missing but the localized strings are available - I pushed it today * add all missing en-GB strings; it is a workaround for i#66919, n#231678 - these bugs were fixed long time ago Best regards, Andras From 71ef7aaf45731e2e6906e4bf245f2e4907ed930c Mon Sep 17 00:00:00 2001 From: Andras Timar Date: Fri, 25 Mar 2011 20:22:48 +0100 Subject: [PATCH] do not run deprecated localize-ooo --- bin/build-ooo |7 --- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/bin/build-ooo b/bin/build-ooo index c3b2248..9484645 100755 --- a/bin/build-ooo +++ b/bin/build-ooo @@ -149,13 +149,6 @@ if test "z$PIECE" != "z"; then . $TOOLSDIR/bin/piece/build-$PIECE else -# update localizations from external sources -# FIXME temporary hack to merge the GSI files -cd $TOOLSDIR/bin -export EXTRA_BUILD_FLAGS EXTRA_DMAKE_FLAGS -./localize-ooo || exit 1; -cd - - echo 'Commencing main build' cd $OOBUILDDIR/instsetoo_native || exit 1; -- 1.7.0.4 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Remove DECLARE_LIST( SvTokenList, SvToken * )
0001-Remove-DECLARE_LIST-SvTokenList-SvToken.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error building smoketestoo_native
On Fri, 2011-03-25 at 19:06 +0100, Xisco Faulí wrote: > Hello, > I'm trying to build this module with valgrind ( export > VALGRIND=memcheck ) and I get an error in cpptest. Without VALGRIND=memcheck do you get an error ? The crucial bit looks right at the top with "Failed to connect to pipe: and exit -1" so lets disentangle a possible "smoketest doesn't work for me" vs "smoketest in a debugging build doesn't work for me" vs "smoketest doesn't work under valgrind". There was a little bit of fiddling around with the launcher script/program over the last few days, which I think should have settled down now. Hard to tell what someone is talking about at any given time, but the last time I checked under VALGRIND yesterday or so smoketest worked fine under valgrind for me something like ./g log --oneline -1 might help there. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] GSOC 2011 - Android project - pointers ...
First of all thanks for your answer On Fri, Mar 25, 2011 at 2:42 AM, Michael Meeks wrote: > Hi Korrawit, > > On Fri, 2011-03-25 at 12:53 +0700, Korrawit Pruegsanusak wrote: > > >Personally (what with time-to-market etc.) I think we should > target the > > > latest android API version - ie. API level 9 - which gives us a lot of > > > nice (pre-wrapped) C APIs for talking to the system. > > > > Shouldn't we use the lastest API level 11, of Android 3.0 platform? > > Details at http://developer.android.com/sdk/android-3.0.html > > You're right - it's not the latest API level ;-) but it is the > latest > API level mentioned in the latest NDK you can download (my mistake). It > is also the case, that I only have a device running 2.3.3 > (personally) ;-) so I'm biased. > >Its not clear to me that 3.0 gives us a lot more in the area of > basic > event handling / rendering too; clearly if there is something that makes > our job far easier there then we should use it, otherwise I'd prefer to > see 2.3.0 used personally :-) > >ATB, > >Michael. > After some research it's true that the 3.0 API would be great as it provide interesting new features, like copy/paste and better keyboard support, but it's not really widely use (at least for now) and the same goes for 2.3.3 so wouldn't it be better to use 2.2.x instead so more people could use it ? Cheers Maxime ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Remove DBG_TRACE_BASIC
Hi,
This macro is never defined so I delete it.
Bye
From 6281ffb378d83ef0a44e17f7da3de88d8d284c8a Mon Sep 17 00:00:00 2001
From: Xisco Fauli
Date: Fri, 25 Mar 2011 20:44:20 +0100
Subject: [PATCH] Remove DBG_TRACE_BASIC
---
basic/source/classes/sbxmod.cxx |4 -
basic/source/comp/sbcomp.cxx | 198 -
basic/source/inc/sbtrace.hxx | 44
basic/source/runtime/methods1.cxx |7 --
basic/source/runtime/rtlproto.hxx |5 -
basic/source/runtime/stdobj.cxx |4 -
6 files changed, 0 insertions(+), 262 deletions(-)
delete mode 100755 basic/source/inc/sbtrace.hxx
diff --git a/basic/source/classes/sbxmod.cxx b/basic/source/classes/sbxmod.cxx
index 15c6989..c7c7135 100644
--- a/basic/source/classes/sbxmod.cxx
+++ b/basic/source/classes/sbxmod.cxx
@@ -1223,10 +1223,6 @@ sal_uInt16 SbModule::Run( SbMethod* pMeth )
// VBA always ensures screenupdating is enabled after completing
if ( mbVBACompat )
VBAUnlockDocuments( PTR_CAST( StarBASIC, GetParent() ) );
-
-#ifdef DBG_TRACE_BASIC
-dbg_DeInitTrace();
-#endif
}
}
else
diff --git a/basic/source/comp/sbcomp.cxx b/basic/source/comp/sbcomp.cxx
index 729ec83..b433acd 100755
--- a/basic/source/comp/sbcomp.cxx
+++ b/basic/source/comp/sbcomp.cxx
@@ -34,204 +34,6 @@
#include "image.hxx"
#include
-// To activate tracing enable in sbtrace.hxx
-#ifdef DBG_TRACE_BASIC
-
-// Trace Settings, used if no ini file / not found in ini file
-static char GpTraceFileNameDefault[] = "d:\\zBasic.Asm\\BasicTrace.txt";
-static char* GpTraceFileName = GpTraceFileNameDefault;
-
-// GbTraceOn:
-// true = tracing is active, false = tracing is disabled, default = true
-// Set to false initially if you want to activate tracing on demand with
-// TraceCommand( "TraceOn" ), see below
-static bool GbTraceOn = true;
-
-// GbIncludePCodes:
-// true = PCodes are written to trace, default = false, correspondents
-// with TraceCommand( "PCodeOn" / "PCodeOff" ), see below
-static bool GbIncludePCodes = false;
-
-static int GnIndentPerCallLevel = 4;
-static int GnIndentForPCode = 2;
-
-/*
-With trace enabled the runtime function TraceCommand
-can be used to influence the trace functionality
-from within the running Basic macro.
-
-Format: TraceCommand( command as String [, param as Variant] )
-
-Supported commands (command is NOT case sensitive):
-TraceCommand "TraceOn" sets GbTraceOn = true
-TraceCommand "TraceOff" sets GbTraceOn = false
-
-TraceCommand "PCodeOn" sets GbIncludePCodes = true
-TraceCommand "PCodeOff" sets GbIncludePCodes = false
-
-TraceCommand "Print", aVal writes aVal into the trace file as
-long as it can be converted to string
-*/
-
-static void lcl_skipWhites( char*& rpc )
-{
-while( *rpc == ' ' || *rpc == '\t' )
-++rpc;
-}
-
-inline void lcl_findNextLine( char*& rpc, char* pe )
-{
-// Find line end
-while( rpc < pe && *rpc != 13 && *rpc != 10 )
-++rpc;
-
-// Read all
-while( rpc < pe && (*rpc == 13 || *rpc == 10) )
-++rpc;
-}
-
-inline bool lcl_isAlpha( char c )
-{
-bool bRet = (c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z');
-return bRet;
-}
-
-static void lcl_ReadIniFile( const char* pIniFileName )
-{
-const int BUF_SIZE = 1000;
-static sal_Char TraceFileNameBuffer[BUF_SIZE];
-sal_Char Buffer[BUF_SIZE];
-sal_Char VarNameBuffer[BUF_SIZE];
-sal_Char ValBuffer[BUF_SIZE];
-
-FILE* pFile = fopen( pIniFileName ,"rb" );
-if( pFile == NULL )
-return;
-
-size_t nRead = fread( Buffer, 1, BUF_SIZE, pFile );
-
-// Scan
-char* pc = Buffer;
-char* pe = Buffer + nRead;
-while( pc < pe )
-{
-lcl_skipWhites( pc ); if( pc == pe ) break;
-
-// Read variable
-char* pVarStart = pc;
-while( pc < pe && lcl_isAlpha( *pc ) )
-++pc;
-int nVarLen = pc - pVarStart;
-if( nVarLen == 0 )
-{
-lcl_findNextLine( pc, pe );
-continue;
-}
-strncpy( VarNameBuffer, pVarStart, nVarLen );
-VarNameBuffer[nVarLen] = '\0';
-
-// Check =
-lcl_skipWhites( pc ); if( pc == pe ) break;
-if( *pc != '=' )
-continue;
-++pc;
-lcl_skipWhites( pc ); if( pc == pe ) break;
-
-// Read value
-char* pValStart = pc;
-while( pc < pe && *pc != 13 && *pc != 10 )
-++pc;
-int nValLen = pc - pValStart;
-if( nValLen == 0 )
-{
-lcl_findNextLine( pc, pe );
-continue;
-}
-strncpy( ValBuffer, pValStart, nValLen );
-ValBuffer[nValLen] = '\0';
-
-// Match variables
-if( strcmp( VarNameBuffer, "GpTraceFileName") == 0 )
-{
-strcpy( TraceFileNameBuffer, ValBuffer );
-GpTrac
[Libreoffice] [PATCH] cppcheck variableScope cleanliness
This patch removes some variableScope warnings from
http://libreoffice.boldandbusted.com, sending for review.
revol_
diff --git a/filter/source/svg/svgwriter.cxx b/filter/source/svg/svgwriter.cxx
index 052a930..c0cd48f 100644
--- a/filter/source/svg/svgwriter.cxx
+++ b/filter/source/svg/svgwriter.cxx
@@ -489,7 +489,7 @@ NMSP_RTL::OUString SVGActionWriter::GetPathString( const PolyPolygon& rPolyPoly,
for( long i = 0, nCount = rPolyPoly.Count(); i < nCount; i++ )
{
const Polygon& rPoly = rPolyPoly[ (sal_uInt16) i ];
-sal_uInt16 n = 1, nSize = rPoly.GetSize();
+sal_uInt16 nSize = rPoly.GetSize();
if( nSize > 1 )
{
@@ -498,6 +498,7 @@ NMSP_RTL::OUString SVGActionWriter::GetPathString( const PolyPolygon& rPolyPoly,
aPathData += aComma;
aPathData += GetValueString( aPolyPoint.Y() );
sal_Char nCurrentMode = 0;
+sal_uInt16 n = 1;
while( n < nSize )
{
@@ -1072,7 +1073,7 @@ void SVGActionWriter::ImplWriteText( const Point& rPos, const String& rText,
const NMSP_RTL::OUString* pStyle,
Color aTextColor )
{
-long nLen = rText.Len(), i;
+long nLen = rText.Len();
if( nLen )
{
@@ -1102,7 +1103,7 @@ void SVGActionWriter::ImplWriteText( const Point& rPos, const String& rText,
{
const double fFactor = (double) nWidth / aNormSize.Width();
-for( i = 0; i < ( nLen - 1 ); i++ )
+for(long i = 0; i < ( nLen - 1 ); i++ )
pDX[ i ] = FRound( pDX[ i ] * fFactor );
}
}
diff --git a/connectivity/workben/testmoz/mozthread.cxx b/connectivity/workben/testmoz/mozthread.cxx
index 4a76ce7..521ce5d 100755
--- a/connectivity/workben/testmoz/mozthread.cxx
+++ b/connectivity/workben/testmoz/mozthread.cxx
@@ -328,10 +328,10 @@ Reference< ::com::sun::star::sdbc::XConnection> TestConnected
int autoTest(Reference &xRes)
{
-sal_Int32 nRows = 0;
printColumns(xRes);
if(xRes.is())
{
+sal_Int32 nRows = 0;
while( xRes.is() && xRes->next())
{
nRows++;
diff --git a/xmloff/source/chart/SchXMLExport.cxx b/xmloff/source/chart/SchXMLExport.cxx
index 7d74350..d0fece3 100755
--- a/xmloff/source/chart/SchXMLExport.cxx
+++ b/xmloff/source/chart/SchXMLExport.cxx
@@ -2767,7 +2767,6 @@ void SchXMLExportHelper_Impl::exportSeries(
SvXMLElementExport* pSeries = NULL;
Sequence< Reference< chart2::data::XLabeledDataSequence > > aSeqCnt(
xSource->getDataSequences());
-sal_Int32 nMainSequenceIndex = -1;
sal_Int32 nSeriesLength = 0;
sal_Int32 nAttachedAxis = chart::ChartAxisAssign::PRIMARY_Y;
sal_Bool bHasMeanValueLine = false;
@@ -2782,6 +2781,7 @@ void SchXMLExportHelper_Impl::exportSeries(
Reference< chart2::data::XDataSequence > xValuesSeq;
Reference< chart2::data::XDataSequence > xLabelSeq;
sal_Int32 nSeqIdx=0;
+sal_Int32 nMainSequenceIndex = -1;
for( ; nSeqIdx aDataPointList;
-sal_Int32 nLastIndex = -1;
-sal_Int32 nCurrIndex = 0;
-
// collect elements
if( bVaryColorsByPoint && xColorScheme.is() )
{
@@ -3431,6 +3428,10 @@ void SchXMLExportHelper_Impl::exportDataPoints(
}
else
{
+
+ sal_Int32 nLastIndex = -1;
+ sal_Int32 nCurrIndex = 0;
+
for( nElement = 0; nElement < nSize; ++nElement )
{
aPropertyStates.clear();
diff --git a/vcl/source/control/spinfld.cxx b/vcl/source/control/spinfld.cxx
index 154196d..9939e91 100644
--- a/vcl/source/control/spinfld.cxx
+++ b/vcl/source/control/spinfld.cxx
@@ -696,7 +696,6 @@ void SpinField::ImplCalcButtonAreas( OutputDevice* pDev, const Size& rOutSz, Rec
long nBottom1 = aSize.Height()/2;
long nBottom2 = aSize.Height()-1;
long nTop2 = nBottom1;
-long nTop1 = 0;
if ( !(aSize.Height() & 0x01) )
nBottom1--;
@@ -741,6 +740,7 @@ void SpinField::ImplCalcButtonAreas( OutputDevice* pDev, const Size& rOutSz, Rec
}
else
{
+long nTop1 = 0;
aSize.Width() -= CalcZoom( GetDrawPixel( pDev, rStyleSettings.GetSpinSize() ) );
rSpinUpArea = Rectangle( aSize.Width(), nTop1, rOutSz.Width()-aDropDownSize.Width()-1, nBottom1 );
diff --git a/vcl/source/gdi/outdev3.cxx b/vcl/source/gdi/outdev3.cxx
index e39d0af..02febe3 100644
--- a/vcl/source/gdi/outdev3.cxx
+++ b/vcl/source/gdi/outdev3.cxx
@@ -3548,12 +3548,8 @@ void OutputDevice::ImplDrawWaveLine( long nBaseX, long nBaseY,
{
longnCurX = nStartX;
longnCurY =
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #5 from Björn Michaelsen 2011-03-25 12:23:56 PDT --- @Rainer: please see http://lists.freedesktop.org/archives/libreoffice/2011-March/009626.html 35668 is a well reproducible crasher and should be fixed in any case. The others are not that critical IMHO, but keeping the complex and unoapi tests clean is a very valid goal. Luckily, because there are tests for these, they should be rather easy to fix. -- 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 --- Comment #4 from Hillar 2011-03-25 12:12:16 PDT --- 35602: Reason is quite clear. I personaly know three people who have lost their hours of work. -- 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 Hillar changed: What|Removed |Added Depends on||35602 -- 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 --- Comment #3 from Rainer Bielefeld 2011-03-25 11:55:21 PDT --- @Björn: Can you please explain why you see bugs nominated by you as "most annoying ... that are important for users"? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#34908
On Friday 25 of March 2011, Noel Power wrote: > Hi All, > I have a patch ( well really this is a workaround ) for a strange issue > ( https://bugs.freedesktop.org/show_bug.cgi?id=34908 ) that I have been > looking at on and off for the last while. > Briefly what is happening is that a dynamic_cast is failing in the > distro build ( e.g. with patches ) but only on 32 bit, the corresponding > rawbuild build works as expected. On 64, both distro and non distro > builds behave as expected ( no problems in this area ) ... > Anyway the patch/workaround is here > https://bugs.freedesktop.org/attachment.cgi?id=44788 Ewww ... class SAL_DLLPUBLIC_EXPORT IFieldmark : virtual public IMark ... class SAL_DLLPUBLIC_EXPORT ICheckboxFieldmark : virtual public IFieldmark ... IFieldmark* pFieldmark = ... ... ICheckboxFieldmark* pCheckboxFm = reinterpret_cast(pFieldmark); You really don't want to reinterpret_cast up and down virtual inheritance. Does your changing from dynamic_cast to reinterpret_cast actually really fix it? Since both the classes are defined in the same place, the only reasonable explanation I see for this is that somebody got the casting similarly wrong in another place and doing it wrong here too "undoes" the first wrong. I don't have a very good explanation why this would be different for 32/64bit though. I don't have any 32bit build, could you try with yourself few more things? First, using Valgrind is always a good idea, and second, the output of something like this could be interesting too: printf( "%p %p %s %p %p %s %p %p %s\n", ptr, dynamic_cast< void* >( ptr ), typeid( *ptr ).name(), pFieldmark, dynamic_cast< void* >( pFieldmark ), typeid( *pFieldmark ).name(), pCheckboxFm, dynamic_cast< void* >( pCheckboxFm ), typeid( *pCheckboxFm ).name()); (where 'ptr' is what you get from the pMarksAccess->makeNoTextFieldBookmark() call before casting to anything). -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild subsequentcheck is clean
Hi Michael, On Fri, 25 Mar 2011 17:22:12 + Michael Meeks wrote: > Having said that - it is somewhat annoying all of the > graphical thrash that this introduces: I end up with lots of > flickering windows, and some seem to just hang there ;-) Did I really > break -headless somehow with the new oostart.bin ? [ it works when I > try it manually ], and/or do we need to tweak the tests so they pass > that ? Well, I would prefer to have the tests not run headless as there is quite a bit of vcl/X11 code coverage that might be cut off doing that. I usually run those tests with DISPLAY set to a local vnc session (which I lurk into from time to time in viewonly mode). > Ooh ! nice - can you add that to the easy hacks ? Done. > and we also have a 3.4 blocker bug here: > https://bugs.freedesktop.org/show_bug.cgi?id=35673 that might be nice > to have those tracked on. Done. Subsequenttests should soon work on the old build system too. However, I havent blacklisted/disabled the broken tests there yet. I will add another Easy Task for that. Best Regards, Bjoern -- https://launchpad.net/~bjoern-michaelsen signature.asc 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 Björn Michaelsen changed: What|Removed |Added Depends on||35668, 35657, 35660, 35661, ||35662, 35663, 35666, 35667 --- Comment #2 from Björn Michaelsen 2011-03-25 11:44:45 PDT --- Depending on failing complex and unoapi tests: 35660, 35661, 35662, 35663, 35666, 35667. -- 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] Error building smoketestoo_native
Hello, I'm trying to build this module with valgrind ( export VALGRIND=memcheck ) and I get an error in cpptest. You can find the debug's output here: http://dl.dropbox.com/u/1274885/debugoutput ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Remove unused DECLARE_LIST
0001-Remove-unused-DECLARE_LIST.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] configmgr unit test resurrection ...
On Fri, 2011-03-25 at 14:18 -0300, Guto Maia wrote: > I will take a look on them and return to you! Good 'oh; failing that Bjoern's nice mail / bugs wrt. the subsequentcheck paths that are failing would be great to follow up. > Looks interesting and a real challenger!! Yep; it'd be good to start or expand a suitable wiki page as you go along to help people debug unit tests that fail - it is slightly non-trivial and impacts lots of people. 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] [PATCH] removing the executable mode from some source files
I discovered what is wrong with the perl files that dows not uses shebangs. The perl file postprocess/rebase.pl is a valid executable script, but it does not uses shebang.I took /usr/share/file/magic and there it is a mention for that kind of "magic" sign:... # commands: file(1) magic for various shells and interpreters0 string : shell archive or script for antique kernel text...And tried to execute on command line this file. It is properly executed. So it is a valid script to run.I have managed to grep the /usr/share/file/magic and the string "\ script" (with space) will manage to sort out just the executable ones.So I changed my script to search for "\ script" using "grep" and "file" commands and no more file type (extensions) exclusion patterns.It was tested here and attached on this email. Francisco Kem Iti Saito
< #Use test as argument to find the files that are not executable for file command but have the execution bit set< #The use of "\ script" was based on /usr/share/file/magic which is used by "file" command.---> # Set the exclusion pattern (e.g. not all perl files - pl - are detected as executable by file command because they use evaland there is no shebang)>> EXCLUSIONS="*.pl$|*.excludeme$"12a14,15>> #Use test as argument to find the files that are not executable for file command but have the execution bit set16c19< find . -perm /u+x -type f -print0 |xargs -0 -n1 file|grep -v "\ script" |cut -d: -f1---> find . -perm /u+x -type f -print0 |xargs -0 -n1 file|grep -v executable|cut -d: -f1|grep -E -v ''$EXCLUSIONS''22c25< find . -perm /u+x -type f |xargs -n1 file |grep -v "\ script"|cut -d: -f1|xargs chmod -x---> find . -perm /u+x -type f |xargs -n1 file |grep -v executable|cut -d: -f1|grep -E -v ''$EXCLUSIONS''|xargs chmod -xand the output of grep "\ script" on my Debian machine: $ grep "\ script" /usr/share/file/magic0 string : shell archive or script for antique kernel text0 string/b #!\ /bin/sh Bourne shell script text executable0 string/b #!\ /bin/csh C shell script text executable0 string/b #!\ /bin/ksh Korn shell script text executable0 string/b #!\ /bin/tcsh Tenex C shell script text executable0 string/b #!\ /usr/local/tcsh Tenex C shell script text executable0 string/b #!\ /usr/local/bin/tcsh Tenex C shell script text executable0 string/b #!\ /bin/zsh Paul Falstad's zsh script text executable0 string/b #!\ /usr/bin/zsh Paul Falstad's zsh script text executable0 string/b #!\ /usr/local/bin/zsh Paul Falstad's zsh script text executable0 string/b #!\ /usr/local/bin/ash Neil Brown's ash script text executable0 string/b #!\ /usr/local/bin/ae Neil Brown's ae script text executable0 string/b #!\ /bin/nawk new awk script text executable0 string/b #!\ /usr/bin/nawk new awk script text executable0 string/b #!\ /usr/local/bin/nawk new awk script text executable0 string/b #!\ /bin/gawk GNU awk script text executable0 string/b #!\ /usr/bin/gawk GNU awk script text executable0 string/b #!\ /usr/local/bin/gawk GNU awk script text executable0 string/b #!\ /bin/awk awk script text executable0 string/b #!\ /usr/bin/awk awk script text executable#0 regex BEGIN[[:space:]]*[{] awk script text0 string/b #!\ /bin/rc Plan 9 rc shell script text executable0 string/b #!\ /bin/bash Bourne-Again shell script text executable0 string/b #!\ /usr/local/bin/bash Bourne-Again shell script text executable>15 string >\0 %s script text executable>16 string >\0 %s script text executable# PHP scripts0 string/c =0 string =0 string =0 string/b #!\ /usr/local/bin/php PHP script text executable0 string/b #!\ /usr/bin/php PHP script text executable0 string Zend\x00 PHP script Zend Optimizer data0 string WNGZWZSC Wingz compiled script0 string/b #!\ /bin/perl perl script text executable0 string eval\ "exec\ /bin/perl perl script text0 string/b #!\ /usr/bin/perl perl script text executable0 string eval\ "exec\ /usr/bin/perl perl script text0 string/b #!\ /usr/local/bin/perl perl script text0 string eval\ "exec\ /usr/local/bin/perl perl script text executable0 string eval\ '(exit\ $?0)'\ &&\ eval\ 'exec perl script text0 string """ a py
Re: [Libreoffice] gbuild subsequentcheck is clean
Hi Bjoern, On Fri, 2011-03-25 at 17:37 +0100, Bjoern Michaelsen wrote: > subsequentcheck for the gbuild modules is clean. Just type Ooh - fun :-) > make -f GNUmakefile.mk -srkj30 gb_COLOR=t subsequentcheck > > in the source root and be amazed by the blinkenlights(*). It should > complete without any errors or hickups. I guess we should add this to the end of the generic all: rule for compilation, as we should with the smoketest IMHO (at least for Linux where it runs headless). Having said that - it is somewhat annoying all of the graphical thrash that this introduces: I end up with lots of flickering windows, and some seem to just hang there ;-) Did I really break -headless somehow with the new oostart.bin ? [ it works when I try it manually ], and/or do we need to tweak the tests so they pass that ? > The dirty secret is of course that I had to disable a few tests for > that. You will find a list of them here: > > > https://bugs.freedesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=subsequenttests > > So, if you are looking for a place to hack, these might be good > starting points as they show clearly reproducible bugs (and one of > them leads right into a crash). Ooh ! nice - can you add that to the easy hacks ? and we also have a 3.4 blocker bug here: https://bugs.freedesktop.org/show_bug.cgi?id=35673 that might be nice to have those tracked on. > The good thing about this is, as soon as there are errors popping up > when running subsequentcheck now, we know them to be regressions and > should take care of them! Right. The only problem is the graphical thrash I guess. Anyhow - great to see this in-place. Thanks, 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] GSOC 2011 regarding - Project Idea.
On Fri, 2011-03-25 at 05:44 +0530, Anurag Jain wrote: > > So is there anyway this idea of increasing the column limit while > maintaining the memory optimizations and compatibility with larger > documents can be proposed as project idea for my GSOC application? So, as we discussed on IRC yesterday, I have my reservation toward making this a GSOC task. The reason is that it would be very hard to define what's considered "task complete", and we don't know how long this task would take. So it'd be a bit hard to come up with an implementation plan that fits into the 3-month window of GSOC. Increasing the column limit itself is super easy, and it takes just a single line of change. But after that change, we don't know for sure where this change affects, what sort of performance issues arise, and how much of it. So, depending on which direction it goes, the task may finish within a week, or more than a year. Anyway, I know that you've already shown interest in picking up another task. I'm just posting this just to have this on record. Regards, Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] configmgr unit test resurrection ...
Year. I will take a look on them and return to you! Looks interesting and a real challenger!! Thanks 2011/3/25 Michael Meeks > Hi Guto, > >I took the liberty of CC'ing the dev list in reply, hope that's ok - > best to interact there so other people can help you out ;-) > > On Fri, 2011-03-25 at 13:31 -0300, Guto Maia wrote: > > Now I'm most of my interest is in the better understand of the build > > cycle and also the improvement of tests. > >Wonderful :-) Hopefully master is now increasingly build-able too - > which is helpful, you joined at a low-point in build-ability I'm afraid. > > > My interest in improve both of this parts (build cycle and tests) at > > the end could help others like me. > >Great - that is -really- useful work. > > > As many agile authors said, tests routines are a live documentation of > > the project. > >Yep. > > > Unfortunelly, the recent tests that I was studing didn't help much. As > > they were indeed useless. > > Can you give-me any clue or direct-me to any point as a good start? > >Right :-) so you saw sc/qa/unit/ and how that works ? we're trying > to > expand the number of these; also using a similar template in other > places to do some useful testing. > >Oh ! which reminds me, I have some tests I wrote that need > resurrecting: > >configmgr/qa/unit > >contains some tests that I wrote way back, that need some love to > switch them to the new cppunit test framework (like the sc/ code above). > That shouldn't be too hard. > >You need to enable that directory to build in > configmgr/prj/build.lst > >And tweak the code. It will prolly need some debugging, and pain to > get > it working, in particular the regcomp for services.rdb there needs > switching to the XSLT thing we use now, and I guess it needs the sax > components to parse the config database, and I suspect it will crash - > due to missing components and fun. > >So - there is some debugging & fun to get that working; but it is at > least fairly nicely self-contained - ie. if you can grok the code in > configmgr and some of the UNO stuff under it it should be fine. > >Could you try to help out with that ? > >Thanks ! > >Michael. > > -- > michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot > > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- Guto Maia @gutomaia ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] configmgr unit test resurrection ...
Hi Guto, I took the liberty of CC'ing the dev list in reply, hope that's ok - best to interact there so other people can help you out ;-) On Fri, 2011-03-25 at 13:31 -0300, Guto Maia wrote: > Now I'm most of my interest is in the better understand of the build > cycle and also the improvement of tests. Wonderful :-) Hopefully master is now increasingly build-able too - which is helpful, you joined at a low-point in build-ability I'm afraid. > My interest in improve both of this parts (build cycle and tests) at > the end could help others like me. Great - that is -really- useful work. > As many agile authors said, tests routines are a live documentation of > the project. Yep. > Unfortunelly, the recent tests that I was studing didn't help much. As > they were indeed useless. > Can you give-me any clue or direct-me to any point as a good start? Right :-) so you saw sc/qa/unit/ and how that works ? we're trying to expand the number of these; also using a similar template in other places to do some useful testing. Oh ! which reminds me, I have some tests I wrote that need resurrecting: configmgr/qa/unit contains some tests that I wrote way back, that need some love to switch them to the new cppunit test framework (like the sc/ code above). That shouldn't be too hard. You need to enable that directory to build in configmgr/prj/build.lst And tweak the code. It will prolly need some debugging, and pain to get it working, in particular the regcomp for services.rdb there needs switching to the XSLT thing we use now, and I guess it needs the sax components to parse the config database, and I suspect it will crash - due to missing components and fun. So - there is some debugging & fun to get that working; but it is at least fairly nicely self-contained - ie. if you can grok the code in configmgr and some of the UNO stuff under it it should be fine. Could you try to help out with that ? 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] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Petr Mladek changed: What|Removed |Added CC||LibreOffice@bielefeldundbus ||s.de, ||libreoffice@lists.freedeskt ||op.org, ||michael.me...@novell.com Depends on||35671 --- Comment #1 from Petr Mladek 2011-03-25 10:07:47 PDT --- Add bug 35671. Wiki help does not show the right pages and thus is hard to use. -- 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] [PATCH] fdo#34908
Hi All, I have a patch ( well really this is a workaround ) for a strange issue ( https://bugs.freedesktop.org/show_bug.cgi?id=34908 ) that I have been looking at on and off for the last while. Briefly what is happening is that a dynamic_cast is failing in the distro build ( e.g. with patches ) but only on 32 bit, the corresponding rawbuild build works as expected. On 64, both distro and non distro builds behave as expected ( no problems in this area ) Note: nm -C | grep CheckboxMark on the various libraries yields afaics mostly identical results, another test I did was to build the sw module from the rawbuild tree in the distro tree, running with those libraries yields the same problem ( confirming what I already thought from lots of manual patch reverts ) but interestingly moving those same libraries into the the rawbuild install and they work again :-/ Anyway the patch/workaround is here https://bugs.freedesktop.org/attachment.cgi?id=44788 In addition to review it would be great to get some opinion on what is the best way to deliver this fix, myself and Petr couldn't quite decide which was the best option, the choices are a) leave this as a patch ( with some note in apply ) at least we wont forget about the problem b) commit directly into the branch, this sortof sweeps the problem under the carpet ( which make me a little uncomfortable ) Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --with-num-cpus/--with-max-jobs and gbuild
On Fri, 2011-03-25 at 12:49 +, Caolán McNamara wrote: > So, the gbuild stuff uses -j$(MAXPROCESS) and we have configure options > tuned for build/dmake where .. > nothing sets MAXPROCESS Um - ;-) any solution that builds faster sounds good to me, personally I configure with: '--with-num-cpus=20' '--with-max-jobs=6' since icecream does the queueing, but of course, perhaps I'm just confused ;-) Anything is better than no gnumake paraellism though (that would be just silly). HTH, 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] --with-num-cpus/--with-max-jobs and gbuild
On Fri, 2011-03-25 at 17:23 +0100, Bjoern Michaelsen wrote: > Caolán McNamara wrote: > > nothing sets MAXPROCESS > > dmake sets MAXPROCESS to the number of jobs it got as a parameter. Ah!, gotcha. I was unaware that dmake set this itself. That's the magic bit I was missing, and of course we're still lauching gmake via dmake in the build case so it find its way in there that way. That's good enough for me for the moment in that case. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] gbuild subsequentcheck is clean
Hi all, subsequentcheck for the gbuild modules is clean. Just type make -f GNUmakefile.mk -srkj30 gb_COLOR=t subsequentcheck in the source root and be amazed by the blinkenlights(*). It should complete without any errors or hickups. The dirty secret is of course that I had to disable a few tests for that. You will find a list of them here: https://bugs.freedesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=subsequenttests So, if you are looking for a place to hack, these might be good starting points as they show clearly reproducible bugs (and one of them leads right into a crash). The good thing about this is, as soon as there are errors popping up when running subsequentcheck now, we know them to be regressions and should take care of them! Best Regards, Bjoern (*) Well, as said: you need to build smoketest before. -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --with-num-cpus/--with-max-jobs and gbuild
Hi Caolán, On Fri, 25 Mar 2011 12:49:50 + Caolán McNamara wrote: > So, the gbuild stuff uses -j$(MAXPROCESS) and we have configure > options tuned for build/dmake where > --with-num-cpus is the number of -PX given to "build" and sets > BUILD_NCPUS > --with-max-jobs is the number of -PX given to "dmake" and sets > BUILD_MAX_JOBS > nothing sets MAXPROCESS dmake sets MAXPROCESS to the number of jobs it got as a parameter. So given a "build.pl --all -PNUM_CPUS -- -PMAX_JOBS", MAXPROCESS will be MAX_JOBS. > so, we could e.g. change MAXPROCESS to be BUILD_MAX_JOBS and -jX to > the same X as dmake -X was. Thats how it is currently as build.pl start GNU make via dmake. And if you start GNU make directly you have better choices anyway. > Or we could invert our current allocation > of cpus and set the ncpus as the value for dmake && gmake, which is > sort of the standard practice, i.e. make --with-num-cpus control > dmake/gmake and set max-jobs as the no of parallel builds. > > Thoughts ? Another possibility (on unix only) would be, given a "build.pl -PNUM_CPUS -- -PMAX_JOBS" to start the GNU makes with: make -srjNUM_CPUS*MAX_JOBS -lNUM_CPUS The NUM_CPUS*MAX_JOBS multiplication would allow GNU make to start as many jobs as the old build system was allowed to (in NUM_CPUS dirs), but the -l switch would prevent it to overcommit the CPU, thus: - if build.pl/dmake are running few jobs (because it is bottlenecked in one dir) GNU make would tune up. - if build.pl/dmake are running many jobs (because it is not bottlenecked) GNU make would hold back. It would thus try to "fill in" where ever possible. This works only on unix, as Windows has no sensible load measurement. Best Regards, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] removing the executable mode from some source files
Hi Francisco, On Wed, 2011-03-23 at 11:24 -0300, Francisco Kem Iti Saito wrote: > This will remove execution bit from some source files on the > project filters. patch sended under LPGLv3+/MPL ! Since it seems there is some dithering around your scripts, I've pushed at least this patch - so you have something included :-) JFWIW, I'm almost never in favour of stalling partial fixes, because we're waiting for a perfect & complete solution. In my experience requiring a perfect solution tends to turn into an endless set of round-trips with no action. Anyhow - great to have you contributing ! 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] build error with stlport
On Fri, Mar 25, 2011 at 03:31:00PM +0100, Andreas Radke wrote: > I only found some notes about ixion and fields-table-formula.diff > probably breaking this. > > Any idea about this? Yes, I think anyone using the build repo disables fields-table-formula.diff in the build. In the long term it'll be fixed up and move to the repos, I guess. pgpvzdMBL6PcL.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Embedding LibreOffice in SWT on Linux
Hi there, On Wed, 2011-03-23 at 05:43 -0700, bt1 wrote: > I am using the officebean approach to embed LibreOffice in an SWT > application on Linux. What fun :-) you are treading well away from the beaten path I think. > I am facing a problem where the embedded window cannot get focus and so you > cannot type into it. Sounds like a nightmare. Then again - if you're using XEmbed across processes, there will be all sorts of problems I'm afraid; keyboard navigation is just not going to work eg. global keybindings are just not there (cf. the problems you get with flash inside mozilla etc). > If you select window -> new window and type in the new window, the text > appears in the new window and the embedded window (not a very nice work > around). .. > Any pointers on how to debug or help fix this would be greatly appreciated. You'll prolly need a build of libreoffice, and a build debug=true of vcl/ - that might spew some helpful looking warning. Also I'd try to isolate it to the widget plugin; do: export SAL_USE_VCLPLUGIN=gen vs. gtk to check that it is not some widget integration / backend problem. Here be dragons though :-) HTH, 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] Impress opening with font size too tiny
kranthi.t2000 wrote: > I opened a ppt format file in impress. The font size in most of the slides > was too tiny. What should I Do? > > http://nabble.documentfoundation.org/file/n2730355/impress_error.jpeg > First, we need a proper document to test this with - * take the problematic file, strip it down to the minimal content still showing the bug * while doing so, try to find out what aspect causes this bug - PowerPoint version, using particular features (master pages etc.) * ideally, create a from-scratch document showing the problem, and only the problem - that makes it even easier to track it down. Please file a bug with that document attached against LibreOffice at bugs.freedesktop.org. Cheers, -- Thorsten pgpQMoHGEHqFr.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] -Woverloaded-virtual
Lubos Lunak wrote: > BTW the warnings in canvas are pretty ugly - it's a template class that > inherits from some of its template arguments and sometimes one of those is a > UNO interface that implements disposing(const > com::sun::star::lang::EventObject&), whereas the class itself implements > disposing(). Solving it by "using Base::disposing" doesn't work, since the > template doesn't always inherit from that UNO class. > Hm, don't see an immediate fix, too - problem is, WeakComponentImplHelperBase's disposing *needs* to be overridden, as per the implementation of that cppu helper, that's the way to catch the message and forward it to the aggregated class. In this case, though, the warning is not critical (although of course the naming sucks). Cheers, -- Thorsten pgpWBY2BW6tWK.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] build error with stlport
I'trying to build --with-stlport on i686 for ArchLinux. The build fails here in "sw" using system boost 1.46.0: Compiling: sw/unxlngi6.pro/misc/vbaswobj_dflt.uno_version.c Making:swall.lib Making:swui.lib Making:swen-US.res Compiling: rsc_sw Making:libswdli.so Making:libswli.so ../unxlngi6.pro/slo/cellfml.o: In function `lcl_ConvertWWFormula(String const&)': /build/src/libreoffice-build-3.3.2.2/build/libreoffice-3.3.2.2/sw/source/core/fields/cellfml.cxx:712: undefined reference to `ixion::formula_lexer::swap_tokens(boost::ptr_vector >&)' /build/src/libreoffice-build-3.3.2.2/build/libreoffice-3.3.2.2/sw/source/core/fields/cellfml.cxx:717: undefined reference to `ixion::formula_parser::formula_parser(boost::ptr_vector > const&, boost::ptr_map<_STL::basic_string, _STL::allocator >, ixion::base_cell, _STL::less<_STL::basic_string, _STL::allocator > >, boost::heap_clone_allocator, _STL::allocator<_STL::pair<_STL::basic_string, _STL::allocator > const, void*> > >*, bool)' collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxlngi6.pro/lib/libswli.so' and when adding --without-system-boost: Compiling: rsc_sw Making:libswdli.so Making:libswli.so /usr/bin/ld: cannot find -lboost_thread-mt collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxlngi6.pro/lib/libswli.so' I only found some notes about ixion and fields-table-formula.diff probably breaking this. Any idea about this? -Andy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Impress opening with font size too tiny
Hi, I opened a ppt format file in impress. The font size in most of the slides was too tiny. What should I Do? http://nabble.documentfoundation.org/file/n2730355/impress_error.jpeg Thanks -- View this message in context: http://nabble.documentfoundation.org/Impress-opening-with-font-size-too-tiny-tp2730355p2730355.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] -Woverloaded-virtual
On Friday 25 of March 2011, Caolán McNamara wrote: > On Fri, 2011-03-25 at 13:55 +0100, Lubos Lunak wrote: > > It should be the current full list, with duplicates removed (i.e. once > > per every source of the problem, not once per every time it's reported). > > Why should it be that bad? > > argh!, I meant to say "then things are *not* too bad", not "*too* bad". > I mean that's far less that I would have feared, quite manageable. Ok. In that case, if there are no objections, I'll commit my patches. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] -Woverloaded-virtual
On Fri, 2011-03-25 at 13:55 +0100, Lubos Lunak wrote: > It should be the current full list, with duplicates removed (i.e. once per > every source of the problem, not once per every time it's reported). Why > should it be that bad? argh!, I meant to say "then things are *not* too bad", not "*too* bad". I mean that's far less that I would have feared, quite manageable. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] -Woverloaded-virtual
On Thursday 24 of March 2011, Caolán McNamara wrote: > On Thu, 2011-03-24 at 17:29 +0100, Lubos Lunak wrote: > > a list of warnings (duplicates removed). > > I don't want to enable the warning right now, since although I've > > already reduced the number of warnings, I don't want to enable this > > too soon. > > Is that the full list ?, or just part of it. If its the full list then > things are *too* bad. It should be the current full list, with duplicates removed (i.e. once per every source of the problem, not once per every time it's reported). Why should it be that bad? It's about 70 places, most of it localized, and if the design cannot be fixed, the warning can be always removed with the 'using' keyword (except for the template stuff in canvas, where it'll be a bit more complicated). -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] --with-num-cpus/--with-max-jobs and gbuild
So, the gbuild stuff uses -j$(MAXPROCESS) and we have configure options tuned for build/dmake where --with-num-cpus is the number of -PX given to "build" and sets BUILD_NCPUS --with-max-jobs is the number of -PX given to "dmake" and sets BUILD_MAX_JOBS nothing sets MAXPROCESS so, we could e.g. change MAXPROCESS to be BUILD_MAX_JOBS and -jX to the same X as dmake -X was. Or we could invert our current allocation of cpus and set the ncpus as the value for dmake && gmake, which is sort of the standard practice, i.e. make --with-num-cpus control dmake/gmake and set max-jobs as the no of parallel builds. Thoughts ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] subsequentcheck in gbuild modules (please help us to continuously QA LO)
On Fri, 25 Mar 2011 12:55:19 +0100
Bjoern Michaelsen
wrote:
> I just reenabled the subsequentchecks for gbuild modules. To run all
> of those, you will need to:
> - cd smoketestoo_native && build --all
> - cd $SOLARSRC && make -srf GNUmakefile.mk subsequentcheck
>
> To run just the checks from one module:
> - cd $MODULE && make -sr subsequentcheck
Just another note: While the output of failed tests gets printed to the
terminal you can also look at the test logs in
${WORKDIR}/JunitTest/${Testname}/done.log. You will also find a
userlayer for the test in that directory.
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] subsequentcheck in gbuild modules (please help us to continuously QA LO)
Hi all, I just reenabled the subsequentchecks for gbuild modules. To run all of those, you will need to: - cd smoketestoo_native && build --all - cd $SOLARSRC && make -srf GNUmakefile.mk subsequentcheck To run just the checks from one module: - cd $MODULE && make -sr subsequentcheck You will find there are still some interesting crashes, DisposedExceptions and hangs up to debug. ;) Best Regards, Bjoern Michaelsen P.S.: The subsequenttest _should_ be able to run in parallel, so you can of course add a -j30 or something like that to the make command. -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] l10n based on PO files
Petr Mladek píše v Čt 24. 03. 2011 v 21:38 +0100: > Petr Mladek píše v St 23. 03. 2011 v 18:46 +0100: > > Andras Timar píše v St 09. 03. 2011 v 00:01 +0100: > > > Hi, > > > > > > I created a module called 'translations'. It is at > > > http://cgit.freedesktop.org/~timar/translations/ now. If you clone > > > this and link translations directory to master directory structure, > > > then it is buildable. It converts Hungarian PO files to SDF particles > > > which are needed by the build. translate-toolkit is a build > > > requirement. > > > > Andras, you rock! Thanks a lot for all the work and committing the two > > test languages into the new main repo > > http://cgit.freedesktop.org/libreoffice/translations/ > > > > > I wish, if I could finish this work by the feature freeze of 3.4 and > > > we can use this new l10n infrastructure. Please help. > > > > I am going to look at it. The plan is to get rid of the "l10n" repo and > > use the new "translations" repo exclusively. My steps will be: > > > > + download "translations" instead of "l10n" repo > > + allow to build internal translate toolkit (libs-extern repo) > > + set the new L10N_MODULE in solenv/inc/settings.mk > > + modify build.lst in "all" module to depend on > > TRANSLATIONS:translations instead of L10N:l10n > > + fix potential build probles > > If it goes well, I will push it tomorrow morning. The test build is > still running and looks promising. Worked well, so I have just pushed it. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] -Woverloaded-virtual
On Fri, 2011-03-25 at 05:44 +, Michael Meeks wrote: > if this is the only big thing blocking us turning on a very valuable > warning, I'd (personally) say we should just bite the bullet and > un-publish & tweak this interface. There's always a way. I see this warning first in comphelper and the accessibility base, so how about this ?, rather than inherit from the generic template that implements the XComponent::addEventListener inherit from one that doesn't, and then we can declare the two addEventListeners side by side in the subclass and gcc is happy that we're not cocking something up. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Embedding LibreOffice in SWT on Linux
Would it be best to file a similar bug in LibreOffice? On Wed, Mar 23, 2011 at 12:43 PM, bt1 wrote: > Hi, > > I am using the officebean approach to embed LibreOffice in an SWT > application on Linux. > > I am facing a problem where the embedded window cannot get focus and so you > cannot type into it. > > If you select window -> new window and type in the new window, the text > appears in the new window and the embedded window (not a very nice work > around). > > The same issue exists in ooo: > http://openoffice.org/bugzilla/show_bug.cgi?id=97007 > > Any pointers on how to debug or help fix this would be greatly > appreciated. > > TIA > > -- > View this message in context: > http://nabble.documentfoundation.org/Embedding-LibreOffice-in-SWT-on-Linux-tp2720123p2720123.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 mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] NLPsolver broken in master ?
On Fri, 2011-03-25 at 06:03 +0100, Jean-Baptiste Faure wrote: > > > > Fetching dependencies for module NULL from solver... failed > > If i remove --enable-ext-nlpsolver, then build is successful. There were two NULL in the nlpsolver/prj/build.lst there should only be one at the end, now fixed. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] first post and patch proposition (condfrmt)
Hello, Thank Albert, Kohei and Michael for your welcome messages Tomorow, I will work to finalize it and try to create a patch with git diff (or if I can't, a simple diff with the lastest build). Have a good day Bob Le 25/03/11 05:36, Michael Meeks a écrit : On Thu, 2011-03-24 at 01:05 +0100, Bob wrote: It's my first post on this mailing list. Welcome ! :-) Until 3 years ago, I posted regulary on french ooo lists. I return on the french dev list but it's a nomanland ;-) only 3 messages ! I think everybody is coming on LibreOffice :-) Heh well, your support (and code) is much appreciated here, of course ! I find a hack I've created in 2008. Yesterday, I've worked to finalise it. I think it may interest you : unlimited count of rules in conditional formating Looks lovely :-) I'm not qualified for making a patch. Please somebody can help me ? The best situation would be if you had the source that you based your changes on, so you can do a 'diff -ur' against that (as Kohei suggested). Failing that, perhaps the easiest way to generate it is to checkout the git repository if you don't have it [ really it is better to get a full build so you can test your work ], in this case calc: git clone git://anongit.freedesktop.org/libreoffice/calc Then copy your files into the tree, and run a 'git diff' - this should show you a lot of changes: your changes, and also anything else that changed since you did your work to that file. I suggest you then edit that diff by chopping out or re-working sections that are not your work, and send it in. Some things like the global replace of USHORT -> sal_uInt16, BOOL -> sal_Bool etc. may need repeating on your code if you don't have the original. Screen shot : http://archives.bobiciel.com/libo/condfrmt/condfrmt.jpg Looks really pretty :-) of course, in extremis I can try to unwind exactly what was changed and try to work out what your base version was [ even a version number would help here - was it OO.o 3.0 (or whatever) ]. Also - since our feature freeze is soon, it'd be wonderful to find that out quickly, so we can get this in ... :-) Thanks ! Michael. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
