Re: [Libreoffice] NLPsolver broken in master ?
Hi Jean, On Fri, 2011-03-25 at 06:03 +0100, Jean-Baptiste Faure wrote: does anybody have tried recently to compile the master with NLPsolver extension enabled ? Ah - this is a good point ;-) I suspect there are a number of submerged compile / latent merge issues that we're not picking up since we don't enable most of our extensions by default. IMHO - we should enable the ones that we bundle to be compiled by default, eg. report-designer, pdfimport, presentation minimiser, presentation view etc. Patches to configure much appreciated to effect 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
Re: [Libreoffice] l10n based on PO files
Hi Petr, 2011/3/24 Petr Mladek pmla...@suse.cz: BTW: I see two type of errors when building the translations module: --- cut --- No module named lxml --- cut --- Do you see it as well? Could it cause any problems? I don't see it, because I have lxml (http://lxml.de/). No problem, if you don't have it, only the processing will be slower. However, I'm not sure if po2oo script uses lxml at all. --- cut --- couldn't find key main0203.xhp#par_id3147756.2.help from po in 252 keys #: main0203.xhp#par_id3147756.2.help.text msgid ahelp hid=\HID_GRAFIK_TOOLBOX\The emphPicture/emph Bar contains functions for formatting and positioning selected bitmap graphics./ahelp msgstr ahelp hid=\HID_GRAFIK_TOOLBOX\Panel emphObrázek/emph obsahuje funkce pro formátování a umístění vybraných bitmapových obrázků./ahelp --- cut --- I guess that it is caused by outdated cs.po files that are not in sync with the en_US.po files that are freshly extracted during build. It's only a warning caused by an outdated po file. I updated the Czech files but there was a merge commit after that. http://cgit.freedesktop.org/libreoffice/help/diff/helpcontent2/source/text/swriter/main0203.xhp?id=bc131c1ceaca2a227d4827f765e83faa0754a3f1 It can be ignored. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] GSOC 2011 - Android project - pointers ...
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. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ 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
[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
[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
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
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] build error with stlport
On Fri, Mar 25, 2011 at 03:31:00PM +0100, Andreas Radke a.ra...@arcor.de 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
[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] --with-num-cpus/--with-max-jobs and gbuild
Hi Caolán, On Fri, 25 Mar 2011 12:49:50 + Caolán McNamara caol...@redhat.com 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] 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=runnamednamedcmd=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
On Fri, 2011-03-25 at 17:23 +0100, Bjoern Michaelsen wrote: Caolán McNamara caol...@redhat.com 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
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
[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
[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 CC||LibreOffice@bielefeldundbus ||s.de, ||libreoffice@lists.freedeskt ||op.org, ||michael.me...@novell.com Depends on||35671 --- Comment #1 from Petr Mladek pmla...@suse.cz 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] 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] [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
[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] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Björn Michaelsen bjoern.michael...@canonical.com changed: What|Removed |Added Depends on||35668, 35657, 35660, 35661, ||35662, 35663, 35666, 35667 --- Comment #2 from Björn Michaelsen bjoern.michael...@canonical.com 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
Re: [Libreoffice] gbuild subsequentcheck is clean
Hi Michael, On Fri, 25 Mar 2011 17:22:12 + Michael Meeks michael.me...@novell.com 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
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_castICheckboxFieldmark*(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
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #3 from Rainer Bielefeld libreoff...@bielefeldundbuss.de 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
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Hillar liivhil...@gmail.com 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 #4 from Hillar liivhil...@gmail.com 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] [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(ReferenceXResultSet 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( ; nSeqIdxaSeqCnt.getLength(); ++nSeqIdx )
{
OUString aRole;
@@ -3360,9 +3360,6 @@ void SchXMLExportHelper_Impl::exportDataPoints(
::std::list SchXMLDataPointStruct 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
---
[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 aniste...@gmail.com
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 basic/sbobjmod.hxx
-// 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 );
-GpTraceFileName =
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 michael.me...@novell.comwrote: 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 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
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #6 from Petr Mladek pmla...@suse.cz 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] 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 caol...@redhat.com 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] 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, 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] 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 pj...@guineapics.de 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 @@ implementation name=com.sun.star.comp.documentconversion.XSLTFilter service name=com.sun.star.documentconversion.XSLTFilter/ /implementation + implementation name=com.sun.star.comp.documentconversion.LibXSLTTransformer +service name=com.sun.star.documentconversion.LibXSLTTransformer/ + /implementation /component -- 1.7.1 From 43e3435f60e1d056cf47f7f7293f4092282bfcac Mon Sep 17 00:00:00 2001 From: Peter Jentsch pj...@guineapics.de 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 @@ +?xml version=1.0 encoding=UTF-8? +!-- +/* + * Version: MPL 1.1 / GPLv3+ / LGPLv3+ + * + * The contents of this file are subject to the Mozilla Public License Version + * 1.1 (the License); you may not use this file except in compliance with + * the License or as specified alternatively below. You may obtain a copy of + * the License at http://www.mozilla.org/MPL/ + * + * Software distributed under the License is distributed on an AS IS basis, + * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License + * for the specific language governing rights and limitations under the + * License. + * + * The Initial Developer of the Original Code is + * Peter Jentsch pj...@guineapics.de + * + * Portions created by the Initial Developer are Copyright (C) 2011 the + * Initial Developer. All Rights Reserved. + * + * For minor contributions see the git repository. + * + * Alternatively, the contents of this file may be used under the terms of + * either the GNU General Public License Version 3 or later (the GPLv3+), or + * the GNU Lesser General Public License Version 3 or later (the LGPLv3+), + * in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable + * instead of those above. + */ +-- +component loader=com.sun.star.loader.SharedLibrary +xmlns=http://openoffice.org/2010/uno-components; + implementation name=com.sun.star.comp.filter.OdfFlatXml +service
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] [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] fdo#32413: Add an apply button to style edit dialog in Writer
On Fri, Mar 25, 2011 at 08:48:25PM +, Michael Meeks michael.me...@novell.com 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] [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
