Re: Static src analysis of LibreOffice
Hi John, If you have problems with space you can put the files as such in github.com, or I'll host it somewhere. Regards, Jesso Clarence Motah Program, KACST http://www.motah.org.sa ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
Hi John, it seems like major overkill for something like static html pages to me. I was just trying to solve your space and bandwidth problem. :-) Hosting it directly *is* the best solution. But, anyway the report with all the 3rd parties are not needed as others pointed out. - Jesso ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Refactoring macros to template classes
Hi, I've been looking at many macros, (like the ones in http://docs.libreoffice.org/svl/html/svarray_8hxx.html) which are used to generate classes. Can I write the classes generated by these macros explicitly, so that we can later refactor them into template classes/STL containers depending on their usage? Will this change be useful in the end? Regards, Jesso Clarence Motah Program, KACST http://www.motah.org.sa ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Refactoring macros to template classes
Hi, I've almost finished replacing the code that uses those macros with using modern STL equivalents. :-) Are the ones you are did mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=38831 and https://bugs.freedesktop.org/show_bug.cgi?id=38832 pointed out by David? (btw, most of those seem to be completed too). Thanks and regards, - Jesso Clarence Motah Program, KACST http://www.motah.org.sa ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Refactoring macros to template classes
Hi Noel, I saw your recent patches in the mailing list :-) Since you've already done so much, I'll be wasting my time on something that is already on the verge of being completed I looked into some GSoC ideas a week ago, I'll go back to it (I just thought it would be better to do a handful of other stuff before going there). Thank you! - Jesso On Tue, Jul 17, 2012 at 4:04 PM, Noel Grandin n...@peralex.com wrote: On 2012-07-17 11:38, Jesso Murugan wrote: Are the ones you are did mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=38831 and https://bugs.freedesktop.org/show_bug.cgi?id=38832 pointed out by David? (btw, most of those seem to be completed too). No. In my working tree, there are 16 remaining instances in the codebase. If you'd like to work on any of these, please let me know. Just be warned that these are the hardest ones, which is why they're still there :-( $ git grep -n SV_DECL_PTRARR filter/inc/filter/msfilter/msdffimp.hxx:194:SV_DECL_PTRARR_SORT_DEL_VISIBILITY( SvxMSDffShapeInfos, SvxMSDffShape svl/source/notify/brdcst.cxx:28:SV_DECL_PTRARR( SfxListenerArr_Impl, SfxListener*, 0 ) svx/workben/edittest.cxx:180:SV_DECL_PTRARR_DEL( StringList, String*, 0 ); sw/inc/docary.hxx:143:SV_DECL_PTRARR_SORT_DEL( _SwRedlineTbl, SwRedlinePtr, 0 ) sw/inc/expfld.hxx:61:SV_DECL_PTRARR_DEL( _SwSeqFldList, _SeqFldLstElem*, 10 ) sw/inc/ftnidx.hxx:46:SV_DECL_PTRARR_SORT( _SwFtnIdxs, SwTxtFtnPtr, 0 ) sw/inc/modcfg.hxx:47:SV_DECL_PTRARR_SORT_DEL(InsCapOptArr, InsCaptionOptPtr, 0) sw/inc/ndarr.hxx:85:SV_DECL_PTRARR_SORT( SwOutlineNodes, SwNodePtr, 0 ) sw/inc/ndhints.hxx:75:SV_DECL_PTRARR_SORT(SwpHtStart,SwTxtAttr*,1) sw/inc/ndhints.hxx:76:SV_DECL_PTRARR_SORT(SwpHtEnd,SwTxtAttr*,1) sw/inc/swtable.hxx:102:SV_DECL_PTRARR_SORT( SwTableSortBoxes, SwTableBoxPtr, 25 ) sw/inc/tblsel.hxx:54:SV_DECL_PTRARR_SORT( SwSelBoxes, SwTableBoxPtr, 10 ) sw/source/core/doc/tblrwcl.cxx:82:SV_DECL_PTRARR_SORT( SwSortTableLines, SwTableLinePtr, 16 ) sw/source/core/inc/UndoCore.hxx:49:SV_DECL_PTRARR_DEL( SwRedlineSaveDatas, SwRedlineSaveDataPtr, 8 ) sw/source/core/inc/docsort.hxx:60:SV_DECL_PTRARR_SORT(SwSortElements, SwSortElementPtr, 0) sw/source/core/inc/swblocks.hxx:65:SV_DECL_PTRARR_SORT( SwBlockNames, SwBlockName*, 10 ) -- Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Patch] Removed repeated calls in for loops in swnewtable.cxx
Hi, I've submitted a new patch with Matteo's suggestion to Gerrit directly. So discard this patch. - Jesso Clarence ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Patch] Removed repeated calls in for loops in swnewtable.cxx
Hi, There were some repeated calls in two for loops in ExpandColumnSelection function in swnewtable.cxx so I combined the two loops so that the same calls need not be made again. I debugged and tested after making the changes, everything works as expected. - Jesso Clarence 0001-Improved-for-loop-in-ExpandColumnSelection-function-.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Patch] Removed repeated calls in for loops in swnewtable.cxx
Hi Matteo,
just a minor hint from my side: in the original code nBox was
incremented only when pBox == rBoxes[nBox], while in the
new one it happens unconditionally.
Sorry for over looking that.
I don't know if this could be an issue or not.
I tested by re building and putting a breakpoint in this function,
stepping line by line. Everything was working fine, but, its
better to be cautious as I could have missed an edge case.
To preserve the original behaviour a single conditional
if ( nBox nBoxCnt pBox == rBoxes[nBox] )
{
could be used.
Should I send a new patch? or will the reviewers make the change
before pushing?
- Jesso Clarence
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: shrinking templates / bloat ...
Hi Michael, I am sorry I didn't cc libreoffice list in the previous email. I think having this on the public list might be of use to other new people similar to me. (I have no issues discussing this privately, I'm afraid I am not yet sure of the culture here.) On Tue, Jun 26, 2012 at 1:48 PM, Michael Meeks michael.me...@suse.com wrote: I guess for de-bloating; we want to first poke at the 'ott' files in extras/: du -m | sort in there shows: 41 ./source/templates/wizard 53 ./source/templates Which I guess shows a good place to start: the wizards are big bloated users of templates. The wizards/ code is in wizards/ :-) Yes I checked, a lot of savings can be made here. It would be great to see if we can adapt that to use a flat ODF file instead - try saving the template as a .fott (if that works, or .fodt if not), and add some goodness to to the flat ODF filter ( initially to prototype it, just hack some translation support directly into the code I suggest in filter/source/odfflatxml/ ). I saved one template (for two different languages) as .fodt and did a diff. As expected only a handful were changing. We really want to compress all the pointless language differences in those templates out into just a few translated strings / attributes that we can annotate and replace on load. If I understood you correctly, the plan is to use one base fodt with placeholders for the attributes and values which change, and then substitute the appropriate values when the template is loaded. So those strings alone should be hard coded or kept in another file. That will (I hope) give us more space for translations dictionaries and/or a smaller download install :-) The .fodt file had a size around 153 kb, and the individual .ott files were around 23 kb (for the template I chose), so 23 kb * 23 languages = 529 kb, so we cut around 71% :-) Does that make sense ? Did I understand you correctly? I'll now see what I can do in filter/source/odfflatxml/ Thanks and regards. - Jesso Clarence ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
German comments translation
Hi, I tranlsated German comments in filter/inc/filter/msfilter/msdffimp.hxx There are a couple of comments left untranslated in the file as I was not very confident about them. (Check the translated ones too, as the code was new to me and I might have missed any nuances.) Do comments need a licence statement? Anyway, you have mine below. All of my past future contributions to LibreOffice may be licensed under the MPL/LGPLv3+ dual license. - Jesso Clarence 0001-Translated-German-comments-in-filter-inc-filter-msfi.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: German comments translation
Hi Philipp, You are correct! I was reading the file, following some bug, and found myself translating the comments to understand what's going on and so I thought I'd just send the resulting file across ;) . By the way, no offense taken. I'll check the Easy Hacks. And, Google Summer of Code ideas seem pretty interesting too, so do you recommend me checking that (after an easy hack or two), or is it just reserved for just the participants of GSoC? (I am an Indian programmer, currently in Saudi Arabia, so that's the reason behind the email and the blog.) - Jesso Clarence On Sat, Jun 23, 2012 at 1:06 PM, Philipp Riemer ruderphil...@gmail.comwrote: Hello Jesso, Thank you very much and welcome to the LibreOffice mailing list! While I appreciate your work, much of it looks as if it was the output of an online translation tool... Correct me if I am wrong! I spend some time tweaking your patch but gave up somewhere at line 120 or so... Especially because (in my eyes) trivial comments were left out, e.g.: === snip === -Input: nIdx- Nummer des angeforderten BLIP +Input: nIdx- Number of a requested BLIP ( muss immer uebergeben werden ) === end === (German translation of the sentence in parentheses: has to be provided every time/mandatory) I've seen that your mail address in the patch is from Saudi Arabia. Thus, I want to ask you how well your German skills are? I don't want to offend you but if your German is not pretty well, there are a lot of native people in the community who might be better for this job... I think, I found your blog and it states that you are from India. Phew, now I am confuesed ;-) But I also shows your general interest in programming, so maybe you would consider reporting bugs of LibreOffice or help on other topics as an alternative? Checkout http://wiki.documentfoundation.org/Development/Easy_Hacks_by_Topic. I am pretty sure that there will be something interesting for you! All the best, Philipp 2012/6/23 Jesso Murugan developer.je...@gmail.com: Hi, I tranlsated German comments in filter/inc/filter/msfilter/msdffimp.hxx There are a couple of comments left untranslated in the file as I was not very confident about them. (Check the translated ones too, as the code was new to me and I might have missed any nuances.) Do comments need a licence statement? Anyway, you have mine below. All of my past future contributions to LibreOffice may be licensed under the MPL/LGPLv3+ dual license. - Jesso Clarence ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Libreoffice dev-install fail
Libreoffice built successfully but failed on make dev-install as the following files were missing. I made a git pull this morning. dict-an.oxt dict-be.oxt dict-bg.oxt dict-bn.oxt dict-el.oxt dict-gd.oxt dict-gu.oxt dict-hi.oxt dict-lv.oxt dict-si.oxt dict-te.oxt Copying dict-af.oxt and renaming it as these files, helped solve this, but, it was a temporary quick fix. - Jesso ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
