Hacker News new | past | comments | ask | show | jobs | submit login

It would be great if it people made the kind of changes you mention, but would it be worth the time and effort? It may be better for people to work on other kinds of programs than to spend a lot of time improving the LibreOffice code base.

Writer is good enough for education up through undergrad for many majors, and good enough for some nonprofits. It is certainly good enough for my needs. I don't use the other applications so I can't say about them.




I think it would. I speak from the peanut gallery, but the first thing I'd do would be to encapsulate all of the standalone functions into a relevant class. I think most of the Impl* classes are not needed.

Ideally, I'd turn vcl into a framework. Currently this module is tightly coupled with the execution of the main application. Consider that if this was its own framework, then wouldn't it be easier to port it to more architectures? And consider how much easier it would be for app developers to extend the core of LibreOffice.

I'd be abstracting all the OS specific constructs into the osl modules (which is its intended purpose), and keep a strict coding guideline that anything OS specific must be implemented there.

Id also abstract all the graphics primitives to its own module. I'm specifically thinking of the Gtk+ idea here, you can see the fruits of this design decision because gtk+ apps now literally will run on almost anything.

I've not looked at UNO much, but is it possible that there is duplication between this module and other modules? As an example, but surely cppu is duplicating work that the sal module should be taking care of?

Then there is the filter, hwpfilter, lotuswordpro, oox, writer filter and writerperfect filters. Surely one filter interface would be better and make document expor animport fidelity better? Perhaps I talk from ignorance, bu I'd have thought that shortens development time and reduces bugs. This could be abstracted out and othe projects could use it also, cross pollinating with other OSS efforts. It would also make correcting or implementing filters for more obscure formats easier.


You could start by stepping in to help convert UI code to glade files. This is a huge code base. It needs lots and lots of little steps to get it into shape :)


If I knew enough about the codebase to know where to find the UI code, I'd do this happily!


(1) Start here to learn how to build LibreOffice https://wiki.documentfoundation.org/Development/Native_Build

(2) Then read Caolan's presentation http://conference.libreoffice.org/talks/content/sessions/015...

(3) Then come join us on the libreoffice-dev mailing list and ask questions. We're happy to help newcomers get acquainted.

:-)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: