Oh, awesome! I'm currently trying to do this ith the LibreOffice source code. Frankly, it's a definite leach code base. The source code organisation is poor, the have (IMO) not encapsulated functionality into appropriate classes, the rely on conditional directives too often, and while they abstracted base level functionality into their system abstraction layer, too often I see it leaking outside of this layer.
And that's just after reviewing their startup code!
Interestingly, I believe the code can be refactored. They have a great basis of code, but it needs a major reorganisation and a solid architectural overview and plan. It needs, in short, disciplined coding based solid OO practices.
In fact, I'd love to rip out the guts of the vcl into its own library, create a runner abstract class which you derive off of for each architecture they want to support. Better yet, they should find a good C++ IoC container and use this to plug in all their many components, including the UNO framework, which is actually very impressive.
To this end I'm strongly considering setting up a sequence diagram of the startup for the existing startup classes just to understand how they all work together. An interesting exercise at the very least :-)
I'm mainly I focussing on startup at the moment, I believe the libreOffice guys have their hands full with a more productive task if implementing features. I think they are approaching things from a different perspective to me: I'm interested in how it all hangs together, they want to work on things that give them the most bang or buck.
And that's sensible, and very fair, given limited man-power :-) no to mention I'm doing what I'm attempting is a part time hobby!
And that's just after reviewing their startup code!
Interestingly, I believe the code can be refactored. They have a great basis of code, but it needs a major reorganisation and a solid architectural overview and plan. It needs, in short, disciplined coding based solid OO practices.
In fact, I'd love to rip out the guts of the vcl into its own library, create a runner abstract class which you derive off of for each architecture they want to support. Better yet, they should find a good C++ IoC container and use this to plug in all their many components, including the UNO framework, which is actually very impressive.
To this end I'm strongly considering setting up a sequence diagram of the startup for the existing startup classes just to understand how they all work together. An interesting exercise at the very least :-)