LibreOffice Easy Hacks

From The Document Foundation Wiki
< Development
Revision as of 2012-04-05T11:04:41 by Bjoern-michaelsen (Talk | contribs) (Improve build with/without symbols)

Jump to: navigation, search

Preamble

Welcome

Here are some easy things to do.

The basic flow is to find something fun you want to fix, hack it up, and send a 'git diff' as a mail attachment to [mailto: libreoffice@lists.freedesktop.org] with a Subject: prefixed with 'PATCH', as well as: "made available under the MPL/LGPLv3+" license statement. It should be easy ! (incidentally we also need a real name for the git commit logs if you usually use an alias).

If you create new files, please use our License Header. Please avoid larger reformatting of the code for the time being (except for the tasks listed below) - we're pondering auto/magic ways to do that mid- to long-term.

If the task is really quick and easy, 'just do it'. However, if you think it will take you some time, and/or need partitioning (eg. some big, scalable cleanup that many people can help out with), then please:

  • first assign the relevant task to yourself
    • create an account
    • click 'edit' next to assigned to, and enter your mail address
    • add a comment that you're starting work on it
  • please provide updates each week or so, otherwise someone else may take the issue
  • please take only one part of the task at a time.

If a task has an owner without an update in a week, feel free to notify them that you're taking that on yourself, and of course if you realize you can't complete a task - please update it in bugzilla.

Even if you are deeply skilled, please consider doing one little easy hack, to get used to the process. After that, you are invited to move on up to the more difficult tasks, leaving some of the easy tasks to others so they can get involved and achieve change themselves. The quicker you move up the pile, the more quickly you can be making large scale, user-visible changes and improvements to LibreOffice - of which these easy hacks are just the tip of a very interesting iceberg:

Welcome!

Before we get to the list of possible tasks, here is some additional information to get you started.

Getting Started

Get a login for the LibreOffice bugzilla and test bugs on your computer/system

All new and old bugs in LibreOffice can be found in the freedesktop bugzilla system. Especially with new incoming bugs, it is helpful to test the bug on the own computer/operating system and comment in the bug entry whether you can or cannot confirm the bug and under what circumstances it affects you.

You can get a login name after registering for free here: https://bugs.freedesktop.org/createaccount.cgi. You can search the bugzilla system here: https://bugs.freedesktop.org/query.cgi?product=LibreOffice.

Getting a build - if necessary

Some but not all tasks require you to have built LibreOffice. Even if that is not required, your feedback can be helpful to us - so - please try. The master build instructions are http://www.documentfoundation.org/develop/ with more stuff in this wiki under Development.

Hacking help

If you need to search constructs in the code, there is a code search engine at http://opengrok.libreoffice.org/

Complete lists of Easy Hacks

Open the list of bugs and feature requests marked "EasyHack", and choose an easy hack that fits you :-)

warning these pages are generated by inter-server queries that sometimes timeout, apologies for that, in that case simply re-load.

A Taster Selection of Tasks

Entry level Hacks

Provide stacktraces for crashes in existing bug reports

BugReport#How_to_get_backtrace_.28on_Linux.29 How to get a backtrace on linux

The above link describes how to get a stacktrace for a crasher. If you can reproduce the crasher of an existing bug and it is missing a stacktrace, it is of great help to add the stacktrace to the bug.

Skills: Using a debugger, creating a build

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=47652&bugidtype=include&ctype=atom" entries="1">[{ID} {TITLE} </feed>

Create a Libreoffice build session with playterm to help new developers

Background: With playterm: http://playterm.org/

you can record you own terminal session. It would be great if somebody could record the steps needed to get your first Libreoffice build.

I think this could be a great way to lower the barrier to entry for new developers. The final file should also be backed up on the Wiki just in case.

Skills: Building

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=41291&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

bibisect regressions

Background: please see:

on how to bisect regressions in LibreOffice with prebuild installations. Doing so helps developers quickly fix issues that were introduced with a new version of LibreOffice.

Skills: testing, bugzilla

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=46504&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

Slightly more interesting hacks

Remove --disable-strip-solver option and never strip when copying to solver

Background: We are currently stripping symbols in the old build system long before creating an packaging. That makes debugging needly complicated. We should not strip before packaging. Skills: build, autoconf, Perl

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=39643&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

warning-free code

Background: Making code compile without warnings is a prerequisite for noticing errors in _new_ code.

Skills: building the beast, basic C++ skills (and the attitude to ask when in doubt)

Make macro editing easier

Background: When you launch the macro editor for a document with macros (Tools->Macros->Organise Macros->Basic) - you end up with an horrible UI. Firstly the tree simply doesn't expand easily - it should be far more helpful around expanding nodes so you can see macros. But more annoyingly - even if you know there is a macro in a spreadsheet - you can't open the basic editor until you have found, and clicked onto it, then selected edit. That is just annoying; particularly since the resulting editor has tabs that show you all the macros from each sheet. We should simplify that to make it far easier to run, edit (and demo editing) macros. Design and develop the organizer for attachment elsewhere like the Tools->Macros->Run... menu item: there are three macro organizers in OO now. Some of the code is in basctl/source/basicide/macrodlg.* I believe.

Skills: simple C++ programming, willingness to learn a bit of VCL

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=38889&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

Easy Programming tasks

improve UNO API error reporting

There are many implementations of UNO APIs in LibreOffice, and a lot of them have only very primitive error reporting.

In many cases the only form of error reporting used is "throw RuntimeException;", which is completely unhelpful to API users such as extension developers.

Such exceptions should be improved:

1. most importantly, an error message should be included in the exception so the API user may get some idea what is going wrong. for this, the newly introduced printf-style OSL_FORMAT macro may be useful.

2. in some cases a more specific exception than RuntimeException can be thrown. but beware that only the exceptions that are listed in the exception specification of the UNO API method may be thrown; subtypes of RuntimeException are always allowed, but there are surprising exceptions (IIRC IllegalArgumentException is one) that are not subtypes of RuntimeException.

the offending exceptions can easily be found with "git grep".

Skills: building, simple C++ programming

https://bugs.freedesktop.org/buglist.cgi?bug_id=42982

remove explicit prototypes in basic/

The basic/ module contains a number of unpleasant explicit prototypes, eg.

git grep -5 implGetWeek

that should be grouped into an internal header in basic/source/inc (I expect) - if a suitable one doesn't exist, then we should add a new one :-)

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=48257&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

Change visibility of comments / notes via Notes Ruler Control

Background: At the moment, the user is forced to use the application menu to toggle the visibility of the Notes (e.g. Notes Windows, Notes Anchors). This proposal provides a control located in a currently unused part of the Writer ruler bar. The topic relates to the OpenOffice.org Notes2 activity.

Current status:

Required changes: * New control needs to be added in the ruler area of Writer

Contact: Christoph Noack (Design Team)

Skills: DifficultyBeginner SkillCpp TopicUI

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=38246&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

More tasks

For the complete list please see Development/Easy_Hacks_by_Difficulty#Easy_Hacks_for_Beginners here

Interesting Programming Tasks

default to SQLite not HSQLDB in Base

Background: currently when creating a local database we default to this Java database engine. That is somewhat unfortunate. It would be better to default to a SQLite provider - unfortunately we don't have one. So - it needs writing (see connectivity/source/drivers/*) - and then the default changing. See The SQLite C/C++ Interface. Skills: building, C++ hacking

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=38811&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

enable configmgr unit tests

Background: currently when creating a local database we default to this Java database engine. That is somewhat unfortunate. It would be better to default to a SQLite provider - unfortunately we don't have one. So - it needs writing (see connectivity/source/drivers/*) - and then the default changing. See The SQLite C/C++ Interface. Skills: building, C++ hacking

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=46723&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

TDO Web Services Improving Tasks

Can't select operating system in bugzilla assistant

Background: The new bugzilla assistant helps people to produce better bug reports. It currently does not allow to select the operating system where the bug happened. It should be relatively easy to solve because we already do similar thing for component, subcomponent, version. Skills: JavaScript hacking

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=41256 &bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

Complete lists of Easy Hacks - a rehash

To find more hacks - simply open the list of bugs and feature requests marked "EasyHack", and choose an easy hack that fits you :-)

Creating new EasyHacks

New EasyHacks should be created by developers, who really can estimate the easiness. When you are creating one, just:

  • File a bug into bugzilla.
    Make sure that the description you provide contains pointers to the code, and detailed description what to achieve. Please have in mind that the people working on the Easy Hacks have never seen the LibreOffice code base before. Good Easy Hacks usually look like:
    In order to improve XY, we need to change AB to CD. Most of the code to do that is in file ugh/blah/bleh.cxx (search for Class::ThisMethod()), but you also have to 'git grep UseOfAnotherMethod', and in the files that match change THIS to THAT.
  • Write "EasyHack" (or "ProposedEasyHack") and any number of tags from Development/Easy_Hacks_Bugzilla_Whiteboard_Status into the whiteboard status field
  • Check the Add me to CC list button if you are not the submitter or not already on the CC List of the bug, to be sure you can help if someone adds a question as comment to the bug.
  • Done :-)