Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


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.

thanks in advance
rgds
jan i.


On 09 Mar 2016, at 23:53, Chris Sherlock <chris.sherlock79@gmail.com> wrote:


On 10 Mar 2016, at 6:07 AM, yeliz taneroğlu <yeliztaneroglu@gmail.com> wrote:

Hi Everyone,

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 
https://wiki.documentfoundation.org/Development/GSoC/Ideas#Refactor_god_objects .

My accepted patches for LibreOffice until now.

https://gerrit.libreoffice.org/#/c/19792/ 
https://gerrit.libreoffice.org/#/c/19671/ 
https://gerrit.libreoffice.org/#/c/21614/ 
https://gerrit.libreoffice.org/#/c/21858/ 
https://gerrit.libreoffice.org/#/c/21888/
https://gerrit.libreoffice.org/#/c/21936/ 
https://gerrit.libreoffice.org/#/c/22020/ 
https://gerrit.libreoffice.org/#/c/22940/ 

I want to work in this project. Thank you so much for your time and I look forward to hearing 
from you. 

Kind Regards,
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Welcome aboard Yeliz :-)

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. 

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. 

Some time ago I rearranged the OutputDevice source files into a more logical structure - they can 
be found here:

http://opengrok.libreoffice.org/xref/core/vcl/source/outdev/

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. 

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. 

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:

http://herbsutter.com/gotw/_100/ 

Perhaps I should log an easy hack. 

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. 

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

Chris 
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.