<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Chris@ even though a bit late, could you please formulate your idea with a title etc, and put it on the GSoC ideas page so we do not have multiple places to track the ideas.</div><div><br></div><div>thanks in advance</div><div>rgds</div><div>jan i.</div><div><br></div><div><br>On 09 Mar 2016, at 23:53, Chris Sherlock <<a href="mailto:chris.sherlock79@gmail.com">chris.sherlock79@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On 10 Mar 2016, at 6:07 AM, yeliz taneroğlu <<a href="mailto:yeliztaneroglu@gmail.com" class="">yeliztaneroglu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Everyone,<br class=""><br class="">I hope you are well. My name is Yeliz and I am a 3rd year student in a Computer Engineering program. I'm interested in "Refactor god objects" project for GSOC 2016. I read this <a href="https://wiki.documentfoundation.org/Development/GSoC/Ideas#Refactor_god_objects" class="">https://wiki.documentfoundation.org/Development/GSoC/Ideas#Refactor_god_objects</a> .<br class=""><br class="">My accepted patches for LibreOffice until now.<br class=""><a href="https://gerrit.libreoffice.org/#/c/19792/" class=""><br class="">https://gerrit.libreoffice.org/#/c/19792/ </a><br class=""><a href="https://gerrit.libreoffice.org/#/c/19671/" class="">https://gerrit.libreoffice.org/#/c/19671/ </a><br class=""><a href="https://gerrit.libreoffice.org/#/c/21614/" class="">https://gerrit.libreoffice.org/#/c/21614/</a> <br class=""><a href="https://gerrit.libreoffice.org/#/c/21858/" class="">https://gerrit.libreoffice.org/#/c/21858/ </a><br class=""><a href="https://gerrit.libreoffice.org/#/c/21888/" class="">https://gerrit.libreoffice.org/#/c/21888/</a><br class=""><a href="https://gerrit.libreoffice.org/#/c/21936/" class="">https://gerrit.libreoffice.org/#/c/21936/ </a><br class=""><a href="https://gerrit.libreoffice.org/#/c/22020/" class="">https://gerrit.libreoffice.org/#/c/22020/</a> <br class=""><a href="https://gerrit.libreoffice.org/#/c/22940/" class="">https://gerrit.libreoffice.org/#/c/22940/ </a><br class=""><br class="">I want to work in this project. Thank you so much for your time and I look forward to hearing from you. <br class=""><br class="">Kind Regards,<br class=""></div>
_______________________________________________<br class="">LibreOffice mailing list<br class=""><a href="mailto:LibreOffice@lists.freedesktop.org" class="">LibreOffice@lists.freedesktop.org</a><br class=""><a href="https://lists.freedesktop.org/mailman/listinfo/libreoffice">https://lists.freedesktop.org/mailman/listinfo/libreoffice</a><br class=""></div></blockquote></div><br class=""><div class="">Welcome aboard Yeliz :-)</div><div class=""><br class=""></div><div class="">As it turns out, I’ve got an idea I’ve been toying with for ages, so I might as well put it out there. </div><div class=""><br class=""></div><div class="">One of the issues with the VCL module as it currently stands is that the OutputDevice class is pretty massive. I would be good to be able to make a compilation firewall for this class, and at the same time split up the functionality into seperate classes. </div><div class=""><br class=""></div><div class="">Some time ago I rearranged the OutputDevice source files into a more logical structure - they can be found here:</div><div class=""><br class=""></div><div class=""><a href="http://opengrok.libreoffice.org/xref/core/vcl/source/outdev/" class="">http://opengrok.libreoffice.org/xref/core/vcl/source/outdev/</a></div><div class=""><br class=""></div><div class="">My idea was that all these cxx files now logically group related functionality and could be converted into “Helper” classes, and we reference these as private member variables using a pImpl pattern. Public functions (that are indeed truly public) are then forwarded to the Helper classes. </div><div class=""><br class=""></div><div class="">The advantages are mainly in compilation time and code flexibility, but also any of the other advantages to setting up a compilation firewall would apply also. </div><div class=""><br class=""></div><div class="">If you’ve never heard of a Compilation Firewall, the description of my idea above is essentially what it achieves. However, I *really* recommend reading Herb Suttor’s article on the technique here:</div><div class=""><br class=""></div><div class=""><a href="http://herbsutter.com/gotw/_100/" class="">http://herbsutter.com/gotw/_100/</a> </div><div class=""><br class=""></div><div class="">Perhaps I should log an easy hack. </div><div class=""><br class=""></div><div class="">Anyway, that would be something I think could be done - it’s a reasonable difficultly level, but not too difficult for someone who knows C++. I would really love to see unit tests of the helper classes, which would really help make the code robust. </div><div class=""><br class=""></div><div class="">If someone else wants to chime in here, please feel free :-) However, I’m happy to chat on IRC - come to #libreoffice-dev on freenode; my nick is chris_wot</div><div class=""><br class=""></div><div class="">Chris </div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>LibreOffice mailing list</span><br><span><a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a></span><br><span><a href="https://lists.freedesktop.org/mailman/listinfo/libreoffice">https://lists.freedesktop.org/mailman/listinfo/libreoffice</a></span><br></div></blockquote></body></html>