Jump to content

Development/EasyHacks: Difference between revisions

From The Document Foundation Wiki
Loic (talk | contribs)
Call for a peer developer
Nacerix (talk | contribs)
(One intermediate revision by the same user not shown)
Line 65: Line 65:
[{ID} {TITLE}  
[{ID} {TITLE}  
</feed>
</feed>
'''Taken by:''' Nacer Adamou / adamou.nacer@gmail.com 09/12/2011


==== find / fix all German spellings in internal APIs ====
==== find / fix all German spellings in internal APIs ====

Revision as of 14:20, 12 September 2011

Preamble

Welcome

Here are some easy things to do. If you submit patches, and/or create new files, we ask you to:

  • co-license them under LGPLv3+, GPLv3+ and MPL (see http://www.freedesktop.org/wiki/Software/LibreOffice/LicenseHeader for a sample).
  • please just state in your mail: "available under LGPLv3+/MPL" when you post to save time.
  • please use your full name, and not an alias: required for the commit log.
  • 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 a larger / longer term task, that you have to do completely by yourself (ie. not some big scalable cleanup that many people can help out with), then please:

  • add a Taken by: tag to the wiki, with:
    • your name / E-mail address, and
    • the date that you're starting work on it.
  • try to update the date each week.
  • take only one task at a time.

If a task has someone listed already, with a date older than a week, you're free to take that task yourself.

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. Please note that the product "LibreOffice" must be selected.

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.

Completed easy hacks

When you have completed one of these hacks, you shall remove it here and put it in the Completed Easy Hacks page instead.

Hacking help

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

More Easy Hacks from Bugzilla

Open the list of bugs and feature requests marked "EasyHack", and choose an easy hack that fits you :-) As on this page, please comment in the bug that you are taking the task, add a deadline until when you think you'll have that finished. This is to allow others to start working on that task in case you lose interest, or it gets too hard, or something.

Selection of Open Tasks

Easy Hacks

Call for a peer JQuery developer to maintain the bug submission assistant

Background: The bug submission assistant available at https://www.libreoffice.org/get-help/bug/ is developed using JQuery. It is a small ( see https://bugassistant.libreoffice.org/libreoffice/bug/bug.js ) a well tested ( run the tests at https://bugassistant.libreoffice.org/libreoffice/bug/test.html ) web application. It is structured in small parts, dealing with each aspect of a bug report. The task of the peer JQuery developer would be to help improve it according to the requests sent on the list http://lists.freedesktop.org/archives/libreoffice-qa/ and/or fix bugs.

Please introduce yourself by posting a comment to the following ticket: <feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=40741&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed> Taken by: Nacer Adamou / adamou.nacer@gmail.com 09/12/2011

find / fix all German spellings in internal APIs

Background: There are a good number of misspelled methods. For instance 'childs' should be children and 'menues' menus, layoutetText should be layedOutText etc.

Skills: grep, German, code reading <feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=39674&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

Remove obsolete product pieces

Background: There are still a lot of unnecessary, and obsolete pieces in LibreOffice from a bygone era, these need hunting and killing. One example is:

isoen-US.res - as compiled in svx/ - compiled from source/intro/iso.src - we need to remove this file, tweak the makefile, and check in scp2/ to remove it cleanly. Similarly instsetoo_native/inc_broffice (now included in the main builds) Similarly solenv/config looks redundant - but needs a test build with it removed.

Skills: grep, dmake, build-to-test <feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=39673&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

Slightly more interesting hacks

remove cruft from perl scripts

Background: Our perl installer script: solenv/bin/make_installer.pl has lots of legacy features that can be removed - eg. solenv/bin/build.pl has a 'server' mode - which seems rather un-necessary (acceleration via icecream/ccache is rather better) - the --server flag and association code and options need removing.

The Perl code also could do with some reformatting to make the lines less long. Simplification of the package naming convention to make the class names less verbose would make the code more readable.

Skills: perl

<feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=39747&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)

Cleanup extensions list

Background: Since we now bundle lots of languages, the extension list Tools->Extension manager is stuffed with things that cannoy be removed, which is annoying. We should categorise the extensions, and filter out the built-in ones by default. This means adding a check-button to:

desktop/source/deployment/gui/dp_gui_dialog2.src
desktop/source/deplyoment/gui/dp_gui_extlistbox.*

And adding some simple filtering so people see the extensions they added themselves.

Skills: C++, common sense (.src), build <feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=39748&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

calc unit test writing

Background: We have a new prototype unit test framework in LibreOffice. The first set of tests is in sc/qa/unit/ and needs your love and attention. We should add new unit tests for each significant C++ class, verifying functionality. Some ideas would be: testing formula parsing (with awkward corner cases etc.), creating large spreadsheets eg. chains of single-cell references, or chains of small range references, and ensuring re-computation dependencies work. It would also be good to have some data-pilot regression tests, and so on.

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

Easy Programming tasks

Removal/Replacement of the String/UniString/ByteString with OUString/OString once and for all.

Background: OO.o uses duplicate string classes, and should not. The 'old' !UniString class is limited to 64k, yet has many more helpful helper methods. We need to create similar helper methods for OUString and port the existing code to use the basic string class. Solid base classes are essential to removing old limits: see fd#30668. You can find a cross reference of the corresponding functions at: Development/String_Classes. We should write unit tests in parallel to ensure that nothing breaks in transition and in the future.

Skills: building, coding, writing unit tests, etc. <feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=38838&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

Get rid of SV_DECL_VARARR, SV_DECL_VARARR_PLAIN, SV_DECL_VARARR_SORT ....

Background: Similar to the above DECLARE_LIST macro, these macros were created before the STL became available. We need to rid our code base of these pesky macros once and for all. See svl/inc/svl/svarray.hxx for the definitions of these macros and svstdarr.hxx for declarations of the arrays.

In short, the following data types are defined via these macros:

  • SvBytes - Done (Nigel Hawkins)
  • SvBools - Done (Nigel Hawkins)
  • SvLongs - Done (Nigel Hawkins)
  • SvlongsSort - Done (Nigel Hawkins)
  • SvULongs
  • SvULongsSort - Done (Nigel Hawkins)
  • SvShorts - Done (Nigel Hawkins)
  • SvUShorts
  • SvUShortsSort - Done (Nigel Hawkins)
  • SvXub_StrLens - This is now just a typedef for std::deque<xub_StrLen>
  • SvXub_StrLensSort - Done (Unused?)
  • SvStrings
  • SvStringsDtor
  • SvStringsSort
  • SvStringsSortDtor
  • SvStringsISort
  • SvStringsISortDtor
  • SvByteStrings
  • SvByteStringsDtor
  • SvByteStringsSort
  • SvByteStringsSortDtor
  • SvByteStringsISort
  • SvByteStringsISortDtor

Note that some of these data structures appear to store pointers (the string versions, possibly others) and some manage the life cycle of stored elements. The xxxDtor versions certainly do this. Other versions should be checked (look for calling delete on the stored pointers before the pointers get removed). So, do take extra care not to leak memory when replacing them with new data structures. Replacing them with boost's ptr_container family may be a good strategy.

The following macros are used in pair:

  • SV_DECL_PTRARR_SORT and SV_IMPL_OP_PTRARR_SORT
  • SV_DECL_PTRARR_DEL and SV_IMPL_PTRARR

and they are used A LOT! Let's remove them. For the most part, they are used as simple arrays that manage stored instances, so replacing them with boost's ptr_vector may be a good strategy. If the elements need to be sorted, we could use ptr_set or ptr_map.

There is also a copy of these macros and definitions inside binfilter. See

  • binfilter/inc/bf_svtools/svarray.hxx
  • binfilter/inc/bf_svtools/svstdarr.hxx
  • binfilter/bf_svtools/source/memtools/svt_svarray.cxx

for details. These should probably be ignored as binfilter is a snapshot of a very old build and is only used to open old staroffice files. If you do feel like fixing these, you may need to check if these differ from the svl versions.

Skills: building, simple C++, care in re-factoring Working on it: Maciej Rumianowski (SvULongs) <feed url="https://bugs.freedesktop.org/buglist.cgi?bug_id=38831&bugidtype=include&ctype=atom" entries="1"> [{ID} {TITLE} </feed>

Print current page

Background: In previous versions of OOo, there used to be a possiblity to print current page easily, but it got lost with the rework of the print dialog. The previous printing dialog made sure to set the field "Pages" according the currently active page number when the dialog was opened. It seems there is a demand for this feature, so it might be good to get it back :-)

Code pointers: For Writer, should be possible to pass the current page number to the SwPrintUIOptions's constructor wherever it is being constructed, probably in SwDocShell. If that is correct, in SwDocShell you have GetWrtShell(), and can do the same as this.

Something similar will be necessary for the other apps too.

Specification pointers: OOo CWS printerpullpages specification for mockups, OOo 3.1 printing dialog screenshots. Please also see: Bug 34697

Skills: building, C++

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

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>

More Tasks

Creating new EasyHacks

To create a new EasyHack (which should only be done by seasoned developers, who really can estimate the easiness):