README.Code → README.md

So that mirrors pick it up and display it, instead of the Android README.

Change-Id: I0c4a8b8c7fe11b83c43342003ad27a0d9ef6b2eb

README.Code

-* A quick overview of the LibreOffice code structure.
-
-** Overview
-
-    You can develop for LibreOffice in one of two ways, one
-recommended and one much less so. First the somewhat less recommended
-way: it is possible to use the SDK, for which you can read the API
-docs here http://api.libreoffice.org/. This re-uses the (extremely
-generic) APIs we provide for macro scripting in StarBasic.
-
-    The best way to add a generally useful feature to LibreOffice
-is to work on the code base however. Overall this way makes it easier
-to compile and build your code, it avoids any arbitrary limitations of
-our scripting APIs, and in general is far more simple and intuitive -
-if you are a reasonably able C++ programmer.
-
-
-** The important bits of code
-
-    Each module should have a README file inside it which has some
-degree of documentation for that module; patches are most welcome to
-improve those. We have those turned into a web-page here:
-
-    http://docs.libreoffice.org/
-
-    However, there are two hundred modules, many of them of only
-peripheral interest for a specialist audience. So - where is the
-good-stuff, the code that is most useful. Here is a quick overview of
-the most important ones:
-
-    sal/      - this provides a simple System Abstraction Layer
-    tools/    - this provides basic internal types: 'Rectangle', 'Color' etc.
-    vcl/      - this is the widget toolkit library and one rendering abstraction
-    svx/      - graphics related helper code, including much of 'draw' / 'impress'
-    sfx2/     - core framework: document model / load/save / signals for actions etc.
-    framework - UNO wrappers around the core framework, responsible for building
-                toolbars, menus, status bars, and the chrome around the document
-                using widgets from VCL, and XML descriptions from */uiconfig/ files
-
-    Then applications
-
-    desktop/  - this is where the 'main' for the application lives, init / bootstrap
-                the name dates back to an ancient StarOffice that also drew a desktop
-    sw/       - writer.
-    sc/       - calc
-    sd/       - draw / impress
-
-    There are several other libraries that are helpful from a
-graphical perspective:
-
-    basebmp/      - enables a VCL compatible rendering API to render to bitmaps,
-                    as used for LibreOffice on-line, Android, iOS etc.
-    basegfx/      - algorithms and data-types for graphics as used in the canvas
-    canvas/       - new (UNO) canvas rendering model with various backends
-    cppcanvas/    - C++ helper classes for using the UNO canvas
-    drawinglayer/ - code to render and manage document drawing shapes and break
-                    them down into primitives we can render more easily.
-
-** Finding out more
-
-    Beyond this, you can read the README files, send us patches, ask
-on the mailing list libreoffice@lists.freedesktop.org (no subscription
-required) or poke people on IRC #libreoffice-dev on irc.freenode.net -
-we're a friendly and generally helpful mob. We know the code can be
-hard to get into at first, and so there are no silly questions.
-
-

README.md

+A quick overview of the LibreOffice code structure.
+
+## Overview
+
+You can develop for LibreOffice in one of two ways, one
+recommended and one much less so. First the somewhat less recommended
+way: it is possible to use the SDK, for which you can read the API
+docs [here](http://api.libreoffice.org/). This re-uses the (extremely
+generic) APIs we provide for macro scripting in StarBasic.
+
+The best way to add a generally useful feature to LibreOffice
+is to work on the code base however. Overall this way makes it easier
+to compile and build your code, it avoids any arbitrary limitations of
+our scripting APIs, and in general is far more simple and intuitive -
+if you are a reasonably able C++ programmer.
+
+
+## The important bits of code
+
+Each module should have a `README` file inside it which has some
+degree of documentation for that module; patches are most welcome to
+improve those. We have those turned into a web page here:
+
+http://docs.libreoffice.org/
+
+However, there are two hundred modules, many of them of only
+peripheral interest for a specialist audience. So - where is the
+good stuff, the code that is most useful. Here is a quick overview of
+the most important ones:
+
+Module    | Description
+----------|-------------------------------------------------
+sal/      | this provides a simple System Abstraction Layer
+tools/    | this provides basic internal types: 'Rectangle', 'Color' etc.
+vcl/      | this is the widget toolkit library and one rendering abstraction
+svx/      | graphics related helper code, including much of 'draw' / 'impress'
+sfx2/     | core framework: document model / load/save / signals for actions etc.
+framework | UNO wrappers around the core framework, responsible for building toolbars, menus, status bars, and the chrome around the document using widgets from VCL, and XML descriptions from */uiconfig/ files
+
+Then applications
+
+Module    | Description
+----------|-------------------------------------------------
+desktop/  | this is where the 'main' for the application lives, init / bootstrap. the name dates back to an ancient StarOffice that also drew a desktop
+sw/       | writer.
+sc/       | calc
+sd/       | draw / impress
+
+There are several other libraries that are helpful from a graphical perspective:
+
+Module    | Description
+----------|-------------------------------------------------
+basebmp/  | enables a VCL compatible rendering API to render to bitmaps, as used for LibreOffice Online, Android, iOS, etc.
+basegfx/  | algorithms and data-types for graphics as used in the canvas
+canvas/   | new (UNO) canvas rendering model with various backends
+cppcanvas/ | C++ helper classes for using the UNO canvas
+drawinglayer/ | code to render and manage document drawing shapes and break them down into primitives we can render more easily.
+
+
+## Finding out more
+
+Beyond this, you can read the `README` files, send us patches, ask
+on the mailing list libreoffice@lists.freedesktop.org (no subscription
+required) or poke people on IRC `#libreoffice-dev` on irc.freenode.net -
+we're a friendly and generally helpful mob. We know the code can be
+hard to get into at first, and so there are no silly questions.