strepsirrhini/office-gobmx
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Updated README.md files to represent current code / use Markdown format

Browse source 
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/

Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
This commit is contained in:
Hossein 2021-03-29 21:55:26 +04:30 committed by Adolfo Jayme Barrientos
parent 33da78c21f
commit ea5641baee
141 changed files with 1723 additions and 1481 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
README.md
View file

@ -29,7 +29,7 @@ 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 build chain and runtime baselines
## The Build Chain and Runtime Baselines
These are the current minimal operating system and compiler versions to
run and compile LibreOffice, also used by the TDF builds:
@ -62,13 +62,13 @@ the LibreOffice Development Environment
For more information see the build instructions for your platform in the
[TDF wiki](https://wiki.documentfoundation.org/Development).
## The important bits of code
## The Important Bits of Code
Each module should have a `README` file inside it which has some
Each module should have a `README.md` 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:
https://docs.libreoffice.org/
<https://docs.libreoffice.org/>
However, there are two hundred modules, many of them of only
peripheral interest for a specialist audience. So - where is the
@ -77,32 +77,32 @@ 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
framework | UNO framework, responsible for building toolbars, menus, status bars, and the chrome around the document using widgets from VCL, and XML descriptions from */uiconfig/* files
sfx2/ | legacy core framework used by Writer/Calc/Draw: document model / load/save / signals for actions etc.
svx/ | drawing model related helper code, including much of Draw/Impress
[sal/](sal) | this provides a simple System Abstraction Layer
[tools/](tools) | this provides basic internal types: `Rectangle`, `Color` etc.
[vcl/](vcl) | this is the widget toolkit library and one rendering abstraction
[framework/](framework) | UNO framework, responsible for building toolbars, menus, status bars, and the chrome around the document using widgets from VCL, and XML descriptions from `/uiconfig/` files
[sfx2/](sfx2) | legacy core framework used by Writer/Calc/Draw: document model / load/save / signals for actions etc.
[svx/](svx) | drawing model related helper code, including much of Draw/Impress
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
[desktop/](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/](sw/) | Writer
[sc/](sc/) | Calc
[sd/](sd/) | Draw / Impress
There are several other libraries that are helpful from a graphical perspective:
Module | Description
----------|-------------------------------------------------
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/ | View code to render drawable objects and break them down into primitives we can render more easily.
[basegfx/](basegfx) | algorithms and data-types for graphics as used in the canvas
[canvas/](canvas) | new (UNO) canvas rendering model with various backends
[cppcanvas/](cppcanvas) | C++ helper classes for using the UNO canvas
[drawinglayer/](drawinglayer) | View code to render drawable objects and break them down into primitives we can render more easily.
## Rules for #include directives (C/C++)
## Rules for #include Directives (C/C++)
Use the `"..."` form if and only if the included file is found next to the
including file. Otherwise, use the `<...>` form. (For further details, see the
@ -112,12 +112,12 @@ mail [Re: C[++]: Normalizing include syntax ("" vs
The UNO API include files should consistently use double quotes, for the
benefit of external users of this API.
loplugin:includeform (compilerplugins/clang/includeform.cxx) enforces these rules.
`loplugin:includeform (compilerplugins/clang/includeform.cxx)` enforces these rules.
## Finding out more
## Finding Out More
Beyond this, you can read the `README` files, send us patches, ask
Beyond this, you can read the `README.md` 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

2
UnoControls/README.md
View file

@ -1 +1,3 @@
# UNO Controls
Separate process and thread for progress bars, etc.

4
accessibility/README.md
View file

@ -1 +1,3 @@
Cares for accessibility.
# Accessibility Support for LibreOffice
Provides accessible components for LibreOffice

224
android/README.md
View file

@ -1,128 +1,118 @@
LibreOffice Android
*******************
# LibreOffice for Android
Bootstrap
*********
## Bootstrap
Contains common code for all projects on Android to bootstrap LibreOffice. In
addition it is a home to LibreOfficeKit (LOK - see libreofficekit/README) JNI
addition it is a home to `LibreOfficeKit` (LOK - see `libreofficekit/README.md`) JNI
classes.
stuff in source directory
*************************
## Stuff in Source Directory
LibreOffice Android application - the code is based on Fennec (Firefox for Android).
It uses OpenGL ES 2 for rendering of the document tiles which are gathered from
LibreOffice using LOK. The application contains the LibreOffice core in one shared
library: liblo-native-code.so, which is bundled together with the application.
library: `liblo-native-code.so`, which is bundled together with the application.
Architecture and Threading
**************************
## Architecture and Threading
The application implements editing support using 4 threads:
1. The Android UI thread, we can't perform anything here that would take a considerable
amount of time.
2. An OpenGL thread which contains the OpenGL context and is responsible for drawing
all layers (including tiles) to the screen.
3. A thread (LOKitThread), that performs LibreOfficeKit calls, which may take more time
3. A thread (`LOKitThread`), that performs `LibreOfficeKit` calls, which may take more time
to complete. In addition it also receives events from the soffice thread (see below)
when the callback emits an event. Events are stored in a blocking queue (thread
processes events in FCFS order, goes to sleep when no more event is available and
awakens when there are events in the queue again).
4. A native thread created by LibreOfficeKit (we call it the soffice thread), where
LibreOffice itself runs. It receives calls from LOKitThread, and may emit callback
LibreOffice itself runs. It receives calls from `LOKitThread`, and may emit callback
events as necessary.
LOKitThread
***********
## LOKitThread
LOKitThread (org.libreoffice.LOKitThread) communicates with LO via JNI (this can
be done only for one thread) and processes events (defined in org.libreoffice.LOEvent)
`LOKitThread` (`org.libreoffice.LOKitThread`) communicates with LO via JNI (this can
be done only for one thread) and processes events (defined in `org.libreoffice.LOEvent`)
triggered from UI.
Application Overview
********************
## Application Overview
LibreOfficeMainActivity (org.libreoffice.LibreOfficeMainActivity) is the entry point
of the application - everything starts up and tears down from here (onCreate, onResume,
onPause, onStart, onStop, onDestroy).
LibreOfficeMainActivity (`org.libreoffice.LibreOfficeMainActivity`) is the entry point
of the application - everything starts up and tears down from here (`onCreate`, `onResume`,
`onPause`, `onStart`, `onStop`, `onDestroy`).
Document view
-------------
### Document View
From here on one of the most interesting pieces are the classes around document view,
which includes listening to touch events, recalculating the viewport, tiled handling
and rendering the layers to the document.
Viewport - the viewport is the currently visible part of the document. It is defined
`Viewport` - the viewport is the currently visible part of the document. It is defined
by view rectangle and zoom.
Layers - document view is rendered using many layers. Such layers are: document
`Layers` - document view is rendered using many layers. Such layers are: document
background, scroll handles, and also the document tiles.
Document view classes
---------------------
### Document View Classes
- LayerView (org.mozilla.gecko.gfx.LayerView) is the document view of the application.
It uses the SurfaceView (android.view.SurfaceView) as the main surface to draw on
- `LayerView` (`org.mozilla.gecko.gfx.LayerView`) is the document view of the application.
It uses the `SurfaceView` (`android.view.SurfaceView`) as the main surface to draw on
using OpenGL ES 2.
- GLController (org.mozilla.gecko.gfx.GLController) - holder of the OpenGL context.
- `GLController` (`org.mozilla.gecko.gfx.GLController`) - holder of the OpenGL context.
- RenderControllerThread (org.mozilla.gecko.gfx.RenderControllerThread) executes the
- `RenderControllerThread` (`org.mozilla.gecko.gfx.RenderControllerThread`) executes the
rendering requests through LayerRenderer.
- LayerRenderer (org.mozilla.gecko.gfx.LayerRenderer) renders all the layers.
- `LayerRenderer` (`org.mozilla.gecko.gfx.LayerRenderer`) renders all the layers.
- GeckoLayerClient (org.mozilla.gecko.gfx.GeckoLayerClient) is the middle man of the
- `GeckoLayerClient` (`org.mozilla.gecko.gfx.GeckoLayerClient`) is the middle man of the
application, which connects all the bits together. It is the document view layer
holder so the any management (including tiled rendering) usually go through this
class. It listens to draw requests and viewport changes from PanZoomController
class. It listens to draw requests and viewport changes from `PanZoomController`
(see "Touch events").
Touch events, scrolling and zooming
-----------------------------------
### Touch Events, Scrolling and Zooming
The main class that handles the touch event, scrolling and zooming is JavaPanZoomController
org.mozilla.gecko.gfx.JavaPanZoomController (implementation of PanZoomController interface).
The main class that handles the touch event, scrolling and zooming is `JavaPanZoomController`
`org.mozilla.gecko.gfx.JavaPanZoomController` (implementation of `PanZoomController` interface).
When the user performs a touch action, the document view needs to change, which means the
viewport changes. JavaPanZoomController changes the viewport and signals the change through
PanZoomTarget (org.mozilla.gecko.gfx.PanZoomTarget).
viewport changes. `JavaPanZoomController` changes the viewport and signals the change through
`PanZoomTarget` (`org.mozilla.gecko.gfx.PanZoomTarget`).
TiledRendering
--------------
### Tiled Rendering
Tiled rendering is a technique that splits the document to bitmaps of same size (typically
256x256) which are fetched on demand.
In the application the ComposedTileLayer (org.mozilla.gecko.gfx.ComposedTileLayer) is the
In the application the `ComposedTileLayer` (`org.mozilla.gecko.gfx.ComposedTileLayer`) is the
layer responsible for tracking and managing the tiles. Tiles are in this case also layers
(sub layers?) implemented in SubTile (org.mozilla.gecko.gfx.SubTile), where each one is
(sub layers?) implemented in `SubTile` (`org.mozilla.gecko.gfx.SubTile`), where each one is
responsible for one tile bitmap (actually OpenGL texture once it has been uploaded).
When the viewport changes, the request for tile rechecking is send to LOKitThread (see
When the viewport changes, the request for tile rechecking is send to `LOKitThread` (see
LOKitThread#tileReevaluationRequest), where the tiles are rechecked, add and removed if
necessary.
CompositeTileLayer is actually an abstract class, which has two implementations. One is
DynamicTileLayer (org.mozilla.gecko.gfx.DynamicTileLayer), which is used for main tile
view of the document, and FixedZoomTileLayer (org.mozilla.gecko.gfx.FixedZoomTileLayer),
`CompositeTileLayer` is actually an abstract class, which has two implementations. One is
`DynamicTileLayer` (`org.mozilla.gecko.gfx.DynamicTileLayer`), which is used for main tile
view of the document, and `FixedZoomTileLayer` (`org.mozilla.gecko.gfx.FixedZoomTileLayer`),
which just renders the tiles at a fixed zoom level. This is then used as a background
low resolution layer.
Tile invalidation
-----------------
### Tile Invalidation
Tile can change in LibreOffice when user changes the content (adds, removes text or changes
the properties). In this case, an invalidation rectangle is signaled from LibreOffice, which
includes a rectangle that needs to be invalidated. In this case LOKitThread gets this request
includes a rectangle that needs to be invalidated. In this case `LOKitThread` gets this request
via callback, and rechecks all tiles if they need to be invalidated. For more details see
LOKitThread#tileInvalidation).
Editing
*******
## Editing
For editing there are 2 coarse tasks that the LibreOffice app must do:
1. send input events to LibreOffice core (keyboard, touch and mouse)
2. listen to messages (provided via callback) from LibreOffice core and react accordingly
@ -131,38 +121,35 @@ LO core follows. For example: when the user writes to the keyboard, key event is
an invalidation request from LO core follows. When user touches an image, a mouse event is
sent, and a "new graphic selection" message from LO core follows.
All keyboard and touch events are sent to LOKitThread as LOEvents. In LOKitThread they are
processed and sent to LibreOffice core. The touch events originate in JavaPanZoomController,
the keyboard events in LOKitInputConnectionHandler (org.libreoffice.LOKitInputConnectionHandler),
All keyboard and touch events are sent to `LOKitThread` as `LOEvents`. In `LOKitThread` they are
processed and sent to LibreOffice core. The touch events originate in `JavaPanZoomController`,
the keyboard events in `LOKitInputConnectionHandler` (`org.libreoffice.LOKitInputConnectionHandler`),
however there are other parts too - depending on the need.
InvalidationHandler (org.libreoffice.InvalidationHandler) is the class that is responsible
`InvalidationHandler` (`org.libreoffice.InvalidationHandler`) is the class that is responsible
to process messages from LibreOffice core and to track the state.
Overlay
*******
## Overlay
Overlay elements like cursor and selections aren't drawn by the LO core, instead the core
only provides data (cursor position, selection rectangles) and the app needs to draw them.
DocumentOverlay (org.libreoffice.overlay.DocumentOverlay) and DocumentOverlayView
(org.libreoffice.overlay.DocumentOverlayView) are the classes that provide the overlay over
`DocumentOverlay` (`org.libreoffice.overlay.DocumentOverlay`) and `DocumentOverlayView`
(`org.libreoffice.overlay.DocumentOverlayView`) are the classes that provide the overlay over
the document, where selections and the cursor is drawn.
Icons
*****
## Icons
App uses material design icons available at [1].
[1] - https://www.google.com/design/icons/
[1] - <https://www.google.com/design/icons/>
Emulator and debugging notes
****************************
## Emulator and Debugging Notes
For instructions on how to build for Android, see README.cross.
For instructions on how to build for Android, see `README.cross`.
* Getting something running
### Getting Something Running
Attach your device, so 'adb devices' shows it. Then run:
@ -173,7 +160,7 @@ Attach your device, so 'adb devices' shows it. Then run:
and if all goes well, you should have some nice debug output to enjoy when you
start the app.
* Using the emulator
### Using the Emulator
Create an AVD in the android UI, don't even try to get the data partition size
right in the GUI, that is doomed to producing an AVD that doesn't work.
@ -183,103 +170,102 @@ Instead start it from the console:
where <Name> is the literal name of the AVD that you entered.
[ In order to have proper acceleration, you need the 32-bit libGL.so:
[ In order to have proper acceleration, you need the 32-bit `libGL.so`:
sudo zypper in Mesa-libGL-devel-32bit
and run emulator-arm after the installation. ]
Then you can run ant/adb as described above.
Then you can run `ant`/`adb` as described above.
After a while of this loop you might find that you have lost a lot of
space on your emulator's or device's /data volume. You can do:
space on your emulator's or device's `/data` volume. You can do:
adb shell stop; adb shell start
Debugging
---------
## Debugging
First of all, you need to configure the build with --enable-debug or
--enable-dbgutil. You may want to provide --enable-symbols to limit debuginfo,
like --enable-symbols="sw/" or so, in order to fit into the memory
First of all, you need to configure the build with `--enable-debug` or
`--enable-dbgutil`. You may want to provide `--enable-symbols` to limit debuginfo,
like `--enable-symbols="sw/"` or so, in order to fit into the memory
during linking.
Building with all symbols is also possible but the linking is currently
slow (around 10 to 15 minutes) and you need lots of memory (around 16GB + some
swap).
* Using ndk-gdb
### Using ndk-gdb
Direct support for using ndk-gdb has been removed from the build system. It is
Direct support for using `ndk-gdb` has been removed from the build system. It is
recommended that you give the lldb debugger a try that has the benefit of being
nicely integrated into Android Studio (see below for instructions).
If you nevertheless want to continue using ndk-gdb, use the following steps
that are described in more detail here: https://stackoverflow.com/a/10539883
If you nevertheless want to continue using `ndk-gdb`, use the following steps
that are described in more detail here: <https://stackoverflow.com/a/10539883>
- add android:debuggable="true" to AndroidManifest.xml
- push gdbserver to device, launch and attach to application
- forward debugging port from host to device
- launch matching gdb on host and run following setup commands:
- add `android:debuggable="true"` to `AndroidManifest.xml`
- push `gdbserver` to device, launch and attach to application
- forward debugging port from host to device
- launch matching gdb on host and run following setup commands:
- set solib-search-path obj/local/<appAbi>
- file obj/local/<appAbi>/liblo-native-code.so
- target remote :<portused>
Pretty printers aren't loaded automatically due to the single shared
object, but you can still load them manually. E.g. to have a pretty-printer for
rtl::OString, you need:
`rtl::OString`, you need:
(gdb) python sys.path.insert(0, "/master/solenv/gdb")
(gdb) source /master/instdir/program/libuno_sal.so.3-gdb.py
* Using Android Studio (and thus lldb)
### Using Android Studio (and Thus lldb)
Note that lldb might not yield the same results as ndk-gdb. If you suspect a
problem with lldb, you can try to manually use ndk-gdb as described above.
Using lldb from within Android Studio is more comfortable though and works like this:
Note that lldb might not yield the same results as `ndk-gdb`. If you suspect a
problem with `lldb`, you can try to manually use `ndk-gdb` as described above.
Using `lldb` from within Android Studio is more comfortable though and works like this:
- open android/source/build.gradle in Android Studio via File|New → Import Project
- make sure you select the right build variant (strippedUIDebug is what you want)
- use Run|Edit Configurations to create a new configuration of type "Android Native"
- on tab "General" pick module "source"
- on tab "Native Debugger" add android/obj/local/<hostarch> to
the Symbol directories
- on the LLDB startup commands tab add
"command script import /path/to/solenv/lldb/libreoffice/LO.py"
to get some pretty printing hooks for the various string classes
- open `android/source/build.gradle` in Android Studio via File|New → Import Project
- make sure you select the right build variant (`strippedUIDebug` is what you want)
- use Run|Edit Configurations to create a new configuration of type "Android Native"
- on tab "General" pick module "source"
- on tab "Native Debugger" add `android/obj/local/<hostarch>` to
the Symbol directories
- on the LLDB startup commands tab add
"command script import `/path/to/solenv/lldb/libreoffice/LO.py`"
to get some pretty printing hooks for the various string classes
Then you can select your new configuration and use Run | Debug to launch it.
Note that lldb doesn't initially stop execution, so if you want to add
Note that `lldb` doesn't initially stop execution, so if you want to add
breakpoints using lldb prompt, you manually have to pause execution, then you
can switch to the lldb tab and add your breakpoints. However making use of the
editor just using File|Open .. to open the desired file in Android Studio and
then toggling the breakpoint by clicking on the margin is more comfortable.
* Debugging the Java part
### Debugging the Java Part
Open android/source/build.gradle in Android studio via File|New → Import
Open `android/source/build.gradle` in Android studio via File|New → Import
Project and you can use Android Studio's debugging interface.
Just make sure you pick the correct build variant (strippedUIDebug)
The alternative is to use the jdb command-line debugger. Steps to use it:
1) Find out the JDWP ID of a debuggable application:
1. Find out the JDWP ID of a debuggable application:
adb jdwp
From the list of currently active JDWP processes, the last number is the just
From the list of currently active JDWP processes, the last number is the just
started debuggable application.
2) Forward the remote JDWP port/process ID to a local port:
2. Forward the remote JDWP port/process ID to a local port:
adb forward tcp:7777 jdwp:31739
3) Connect to the running application:
3. Connect to the running application:
jdb -sourcepath src/java/ -attach localhost:7777
Assuming that you're already in the LOAndroid3 directory in your shell.
* Debugging the missing services
### Debugging the Missing Services
Android library only include essential services that are compiled for
LibreOffice in order to reduce the size of the apk. When developing,
@ -287,40 +273,40 @@ some services might become useful and we should add those services
to the combined library.
In order to identify missing services, we need to be able to receive
SAL_INFO from cppuhelper/source/shlib.cxx in logcat and therefore identify
`SAL_INFO` from `cppuhelper/source/shlib.cxx` in logcat and therefore identify
what services are missing. To do so, you may want add the following
when configuring the build.
--enable-symbols="cppuhelper/ sal/"
[TODO: This is nonsense. --enable-symbols enables the -g option, not SAL_INFO.
Perhaps this was a misunderstanding of meaning of --enable-selective-debuginfo,
[TODO: This is nonsense. `--enable-symbols` enables the `-g` option, not `SAL_INFO`.
Perhaps this was a misunderstanding of meaning of `--enable-selective-debuginfo`,
the old name for the option.]
Which services are combined in the android lib is determined by
solenv/bin/native-code.py
* Common Errors / Gotchas
### Common Errors / Gotchas
lo_dlneeds: Could not read ELF header of /data/data/org.libreoffice...libfoo.so
This (most likely) means that the install quietly failed, and that
the file is truncated; check it out with adb shell ls -l /data/data/...
lo_dlneeds: Could not read ELF header of /data/data/org.libreoffice...libfoo.so
This (most likely) means that the install quietly failed, and that
the file is truncated; check it out with `adb shell ls -l /data/data/...`
* Startup details
### Startup Details
All Android apps are basically Java programs. They run "in" a Dalvik
(or on Android 5 or newer - ART) virtual machine. Yes, you can also
have apps where all *your* code is native code, written in a compiled
language like C or C++. But also such apps are actually started
by system-provided Java bootstrapping code (NativeActivity) running
by system-provided Java bootstrapping code (`NativeActivity`) running
in a Dalvik VM.
Such a native app (or actually, "activity") is not built as a
executable program, but as a shared object. The Java NativeActivity
executable program, but as a shared object. The Java `NativeActivity`
bootstrapper loads that shared object with dlopen.
Anyway, our current "experimental" apps are not based on NativeActivity.
Anyway, our current "experimental" apps are not based on `NativeActivity`.
They have normal Java code for the activity, and just call out to a single,
app-specific native library (called liblo-native-code.so) to do all the
app-specific native library (called `liblo-native-code.so`) to do all the
heavy lifting.

4
animations/README.md
View file

@ -1 +1,3 @@
Contains containers for the css::animation UNO API, used in [[slideshow]] and [[sd]].
# Containers for the css::animation animation UNO API
Contains containers for the `css::animation` UNO API, used in `slideshow` and `sd`.

13
apple_remote/README.md
View file

@ -1,12 +1,17 @@
Library to interact with the Apple Remote Control on Mac
# Apple Remote Control Support for Mac
This is an early version of Martin Kahr's Remote Control Wrapper
The library is used to interact with the "Apple Remote Control" on Mac.
This is an early version of Martin Kahr's "Remote Control Wrapper"
library
(http://martinkahr.com/2007/07/26/remote-control-wrapper-20/index.html
) with modifications by Eric Bachard. Unfortunately the exact extent
of (and rationale behind) the modifications done is unknown, at least
until the original upstream source version it is based on is
found. Version control of this just starts with the monolithic commit
of the appleremote01 CWS. Some technical detail can be found in the
of the `appleremote01` CWS. Some technical detail can be found in the
OOo wiki:
http://wiki.openoffice.org/wiki/Mac_OS_X_Porting_-_Apple_Remote_implementation
## See Also
<http://wiki.openoffice.org/wiki/Mac_OS_X_Porting_-_Apple_Remote_implementation>

16
avmedia/README.md
View file

@ -1,18 +1,18 @@
Audio/Video media implementation.
# Audio / video Media Implementation.
Provides per-platform implementations of multimedia functionality.
Currently no stream API is provided, only a URI based one, so
streaming has to be wrapped around it via temp files.
Also provides (in source/framework/mediacontrol.cxx) an implementation
Also provides (in `source/framework/mediacontrol.cxx`) an implementation
of the graphical media playback control that appears in the toolbar /
mediaobject bar when media is selected under the .uno:AVMediaToolBox
mediaobject bar when media is selected under the `.uno:AVMediaToolBox`
item.
== avmedia/gstreamer ==
## avmedia / gstreamer
The avmedia component is implementation of manager service defined in
offapi/com/sun/star/media/. Radek has added implementation based on
The `avmedia` component is implementation of manager service defined in
`offapi/com/sun/star/media/`. Radek has added implementation based on
gstreamer so that we can add audio and video files into impress
presentation on Linux with gstreamer.
@ -22,4 +22,6 @@ problems when gstreamer installation is incomplete.
In the beginning the media files were not embedded, Thorsten added
support for that later.
FUTURE work: it might be worthwhile to revamp the avmedia UI
## Future Works
it might be worthwhile to revamp the avmedia UI.

4
basctl/README.md
View file

@ -1 +1,3 @@
Controls and dialogs for Basic. Contains the Basic IDE.
# BASIC IDE Controls and Dialogs
Controls and dialogs for BASIC. Contains the BASIC IDE.

4
basegfx/README.md
View file

@ -1 +1,3 @@
Algorithms and data types for graphics (e.g. polygons, vectors, matrices and the like - see that used in [[canvas]]).
# Algorithms and Data Types for Graphics
Algorithms and data types for graphics (e.g. polygons, vectors, matrices and the like - see that used in "canvas").

6
basic/README.md
View file

@ -1,8 +1,10 @@
# StarBASIC Interpreter
Contains the StarBASIC Interpreter
This implements a macro language that, when in VBA compatibility mode,
is intended to be interoperable with Visual Basic for Applications,
allowing people to run macros embedded in their documents.
See also:
[http://wiki.openoffice.org/wiki/Basic]
## See also
<http://wiki.openoffice.org/wiki/Basic>

2
bean/README.md
View file

@ -1,3 +1,3 @@
To use LibreOffice from Java applications.
# API to Use LibreOffice from Java Applications (OfficeBean)
LibreOffice's API is completely exposed so that all office components can be fully controlled.

4
bin/README.md
View file

@ -1,9 +1,11 @@
# Tools and Non-Build Scripts
Tools and scripts mostly not used during the build
This direction has a number of key pieces (?) that are used during the
build, or are simply generally useful. One example is
bin/find-german-comments <directory>
bin/find-german-comments <directory>
which will try to detect and extract all the German comments in a
given source code hierarchy / directory.

5
binaryurp/README.md
View file

@ -1,9 +1,8 @@
UNO Remote Protocol (URP). A binary protocol.
# UNO Remote Protocol (URP)
UNO provides a protocol called the UNO Remote Protocol (URP) that provides
UNO provides a binary protocol called the UNO Remote Protocol (URP) that provides
a bridge between UNO environments. This bridge allows processes and objects
to send method calls and to receive return values. UNO objects in different
environments are connected by way of this interprocess bridge. The underlying
connection is made through a socket or pipe. Remote UNO objects are connected
by means of TCP/IP using the high-level protocol of the URP.

6
bridges/README.md
View file

@ -1,4 +1,6 @@
Bridges from various C++ ABIs, Java JNI, MS .Net to UNO and back.
# UNO Bridges
Also implementation of the UNO Remote Protocol. And in ooo-build a bridge from Mono to UNO and back.
Bridges from various C++ ABIs, Java JNI, MS .NET to UNO and back. A bridge for .NET is in
`cli_ure`.
Also implementation of the UNO Remote Protocol.

41
canvas/README.md
View file

@ -1,46 +1,53 @@
# UNO-based Graphics Backend
UNO-based graphics backend, lesser impedance to modern graphics APIs
than vcl.
== The Canvas Framework ==
## The canvas Framework
The canvas framework is the successor of the system GUI and graphics
The `canvas` framework is the successor of the system GUI and graphics
backend VCL. Basic functionality is available, supplying just as much
features as necessary to provide a VCL-equivalent feature set (except
proper BiDi/CTL support).
The canvas framework consists of the following two modules, canvas and
cppcanvas. Additionally, a new generic graphics tooling is used (but
The `canvas` framework consists of the following two modules, `canvas` and
`cppcanvas`. Additionally, a new generic graphics tooling is used (but
not exclusively by the canvas, Armin's drawinglayer module also make
use of it), which resides in basegfx.
use of it), which resides in `basegfx`.
The UNO API used by the canvas is primarily under
css::rendering, with css::rendering::XCanvas
`css::rendering`, with `css::rendering::XCanvas`
being the central interface.
== The slideshow engine ==
## The slideshow Engine
The slideshow engine has replaced the former Impress-embedded
The `slideshow` engine has replaced the former Impress-embedded
presentation framework with a fully independent UNO component, and it
is based on the canvas. Some features used there are only available
from canvas, like double-buffering, and hardware-accelerated
from `canvas`, like double-buffering, and hardware-accelerated
alpha-blending (currently not on all platforms).
== Cairo canvas ==
## Cairo canvas
cairo canvas is one of backends of canvas component. canvas is mostly
Cairo `canvas` is one of backends of canvas component. `canvas` is mostly
used for slideshow rendering and also for emf+ rendering. we hoped it
will even be used by drawing layer, but it didn't happen (yet?) for
API look at offapi/com/sun/star/rendering/, the implementation is in
canvas and cppcanvas modules.
API look at `offapi/com/sun/star/rendering/`, the implementation is in
`canvas` and `cppcanvas` modules.
cairo canvas backend uses cairo library for rendering. main advantage
Cairo `canvas` backend uses Cairo library for rendering. Main advantage
is support of alpha transparency and in some cases accelerated
rendering.
the backend itself is quite old and stable, not many changes in that
The backend itself is quite old and stable, not many changes in that
area lately, mostly changes for emf+ rendering, communication with
vcl and bugfixes
FUTURE work: look at cairo canvas and situation when it is used
(mostly slideshow). TODO there still might be more cases when we
## Future Works
Look at Cairo `canvas` and situation when it is used
(mostly slideshow).
## TODO
There still might be more cases when we
can save some roundtrips when exchanging data with vcl.

10
chart2/README.md
View file

@ -1,9 +1,9 @@
Chart implementation for LibreOffice Calc.
# Chart Implementation for LibreOffice Calc
The chart2 denotes a second generation re-write done to rid us of the
The `chart2` denotes a second generation re-write done to rid us of the
foul and twisted legacy chart code.
== Debugging ==
## Debugging
=== CTRL + F12 ===
This creates a layout dump based on the XShapeDumper based on SAL_WARN("chart2", ...
### Shortcuts
CTRL + F12 creates a layout dump based on the `XShapeDumper` based on `SAL_WARN("chart2", ...`

7
cli_ure/README.md
View file

@ -1,5 +1,6 @@
Common Lang Infrastructure Uno Runtime Environment - support assemblies and tools for the MS .Net (and Mono) UNO binding.
# Common Language Infrastructure (CLI) UNO Runtime Environment
See also:
[git:cli_ure/source/readme.txt]
Support assemblies and tools for the MS .NET UNO binding.
## See also
`git:cli\_ure/readme.txt`

20
codemaker/README.md
View file

@ -1,17 +1,19 @@
# Language Code Generators for UNOIDL Entities
Generators for language-binding--specific representations of UNOIDL entities:
- cppumaker generates header (.hdl and .hpp) files for the C++ UNO language
- `cppumaker` generates header (`.hdl` and `.hpp`) files for the C++ UNO language
binding
- javamaker generates class files for the JVM language binding
- the codemaker for .Net is in module cli_ure
Some of the code is re-used by the skeletonmakers in module unodevtools.
- `javamaker` generates class files for the JVM language binding
- the codemaker for .NET is in module `cli_ure`
Some of the code is re-used by the skeletonmakers in module `unodevtools`.
Note the different terminology used by cppumaker vs. gbuild for the three
variants that can be generated by cppumaker for some of the inline functions:
cppumaker switch: -L; cpputype.cxx: light; gbuild: normal;
cppumaker switch: none; cpputype.cxx: normal; gbuild: bootstrap;
cppumaker switch: -C; cpputype.cxx: comprehensive; gbuild: comprehensive;
cppumaker switch: -L; cpputype.cxx: light; gbuild: normal;
cppumaker switch: none; cpputype.cxx: normal; gbuild: bootstrap;
cppumaker switch: -C; cpputype.cxx: comprehensive; gbuild: comprehensive;
...a recipe for confusion.
which can be a source of confusion.

6
comphelper/README.md
View file

@ -1,4 +1,4 @@
Helper functionality for implementing UNO components
# Helpers for Implementing UNO Components
...anything not generic/mature enough to end up in URE's stable interface at
cppuhelper etc.
Here goes anything not generic / mature enough to end up in URE's stable interface
at `cppuhelper`, etc.

53
compilerplugins/README.md
View file

@ -1,69 +1,66 @@
Compiler plugins.
# Compiler plugins
== Overview ==
## Overview
This directory contains code for compiler plugins. These are used to perform
additional actions during compilation (such as additional warnings) and
also to perform mass code refactoring.
Currently only the Clang compiler is supported (http://wiki.documentfoundation.org/Development/Clang).
Currently only the Clang compiler is supported <http://wiki.documentfoundation.org/Development/Clang>.
## Usage
== Usage ==
Compiler plugins are enabled automatically by `--enable-dbgutil` if Clang headers
are found or explicitly using `--enable-compiler-plugins`.
Compiler plugins are enabled automatically by --enable-dbgutil if Clang headers
are found or explicitly using --enable-compiler-plugins.
== Functionality ==
## Functionality
There are two kinds of plugin actions:
- compile checks - these are run during normal compilation
- rewriters - these must be run manually and modify source files
Each source has a comment saying whether it's compile check or a rewriter
and description of functionality.
=== Compile checks ===
### Compile Checks
Used during normal compilation to perform additional checks.
All warnings and errors are marked '[loplugin]' in the message.
=== Rewriters ===
### Rewriters
Rewriters analyse and possibly modify given source files.
Usage: make COMPILER_PLUGIN_TOOL=<rewriter_name>
Usage: `make COMPILER_PLUGIN_TOOL=<rewriter_name>`
Additional optional make arguments:
- it is possible to also pass FORCE_COMPILE_ALL=1 to make to trigger rebuild of all source files,
- it is possible to also pass `FORCE_COMPILE_ALL=1` to make to trigger rebuild of all source files,
even those that are up to date.
- UPDATE_FILES=<scope> - limits which modified files will be actually written back with the changes
- mainfile - only the main .cxx file will be modified (default)
- all - all source files involved will be modified (possibly even header files from other LO modules),
- `UPDATE_FILES=<scope>` - limits which modified files will be actually written back with the changes
- `mainfile` - only the main `.cxx` file will be modified (default)
- `all` - all source files involved will be modified (possibly even header files from other LO modules),
3rd party header files are however never modified
- <module> - only files in the given LO module (toplevel directory) will be modified (including headers)
- `<module>` - only files in the given LO module (toplevel directory) will be modified (including headers)
Modifications will be written directly to the source files.
Some rewriter plugins are dual-mode and can also be used in a non-rewriting mode
in which they emit warnings for problematic code that they would otherwise
automatically rewrite. When any rewriter is enabled explicitly via "make
COMPILER_PLUGIN_TOOL=<rewriter_name>" it works in rewriting mode (and all other
automatically rewrite. When any rewriter is enabled explicitly via `make
COMPILER_PLUGIN_TOOL=<rewriter_name>` it works in rewriting mode (and all other
plugins are disabled), but when no rewriter is explicitly enabled (i.e., just
"make"), all dual-mode rewriters are enabled in non-rewriting mode (along with
`make`), all dual-mode rewriters are enabled in non-rewriting mode (along with
all non-rewriter plugins; and all non--dual-mode plugins are disabled). The
typical process to use such a dual-mode rewriter X in rewriting mode is
make COMPILER_PLUGIN_WARNINGS_ONLY=X \
&& make COMPILER_PLUGIN_TOOL=X FORCE_COMPILE_ALL=1 UPDATE_FILES=all
make COMPILER_PLUGIN_WARNINGS_ONLY=X \
&& make COMPILER_PLUGIN_TOOL=X FORCE_COMPILE_ALL=1 UPDATE_FILES=all
which first generates a full build without failing due to warnings from plugin
X in non-rewriting mode (in case of --enable-werror) and then repeats the build
X in non-rewriting mode (in case of `--enable-werror`) and then repeats the build
in rewriting mode (during which no object files are generate).
== Code documentation / howtos ==
http://wiki.documentfoundation.org/Clang_plugins
## Code Documentation / HowTos
<http://wiki.documentfoundation.org/Clang_plugins>

33
config_host/README.md
View file

@ -1,25 +1,24 @@
These are configuration files for various features as detected by configure.
# C/C++ Configuration Created by configure Script
These are configuration files for various features as detected by `configure`.
Include only those files you need (in order to reduce rebuilds when a setting changes).
Settings here are only C/C++ #define directives, so they apply only to C/C++ source,
Settings here are only C/C++ `#define` directives, so they apply only to C/C++ source,
not to Makefiles.
## Adding a New Setting:
Adding a new setting:
=====================
- do AC_DEFINE(HAVE_FOO) in configure.ac when a setting should be set
- choose the proper config_host/config_XXX.h file to use
- do `AC_DEFINE(HAVE_FOO)` in `configure.ac` when a setting should be set
- choose the proper `config_host/config_XXX.h` file to use
- if it is a global setting (such as availability of a compiler feature),
use config_host/config_global.h
- otherwise check if there is a matching config_host/config_XXX.h file
use `config_host/config_global.h`
- otherwise check if there is a matching `config_host/config_XXX.h` file
- if none matches, add a new one:
- add config_host/config_XXX.h.in here, with just #ifndef include guard
- add AC_CONFIG_HEADERS([config_host/config_XXX.h]) next to the others
in configure.ac
- add #define HAVE_FOO 0 to the config_host/config_XXX.h , possibly with a comment
(do not use #undef HAVE_FOO, unless the setting has more values than on/off)
- add #include <config_XXX.h> before any #if HAVE_FOO in a source file
- make sure you use #if HAVE_FOO for on/off settings, do not use #ifdef
- add `config_host/config_XXX.h.in` here, with just `#ifndef` include guard
- add `AC_CONFIG_HEADERS([config_host/config_XXX.h])` next to the others
in `configure.ac`
- add `#define HAVE_FOO 0` to the `config_host/config_XXX.h`, possibly with a comment
(do not use `#undef HAVE_FOO`, unless the setting has more values than on/off)
- add `#include <config_XXX.h>` before any #if `HAVE_FOO` in a source file
- make sure you use `#if HAVE_FOO` for on/off settings, do not use `#ifdef`

173
configmgr/README.md
View file

@ -1,68 +1,68 @@
UNO services to access the configuration database
# UNO Services to Access the Configuration Database
== Functional Overview ==
## Functional Overview
This code parses the settings that are described in the [[officecfg]]
This code parses the settings that are described in the `officecfg`
directory, and provides a UNO API that code can use to set and get
settings.
== Source Overview ==
## Source Overview
configurationprovider.cxx
configurationregistry.cxx
defaultprovider.cxx
services.cxx
UNO service implementations.
configurationprovider.cxx
configurationregistry.cxx
defaultprovider.cxx
services.cxx
UNO service implementations.
access.cxx
childaccess.cxx
rootaccess.cxx
UNO objects passed to clients.
access.cxx
childaccess.cxx
rootaccess.cxx
UNO objects passed to clients.
components.cxx
Central singleton that aggregates all data (reads in the XML files, manages
modifications and global notifications).
components.cxx
Central singleton that aggregates all data (reads in the XML files, manages
modifications and global notifications).
groupnode.cxx
localizedpropertynode.cxx
localizedvaluenode.cxx
node.cxx
propertynode.cxx
setnode.cxx
Internal representations of data nodes.
groupnode.cxx
localizedpropertynode.cxx
localizedvaluenode.cxx
node.cxx
propertynode.cxx
setnode.cxx
Internal representations of data nodes.
parsemanager.cxx
parser.hxx
valueparser.cxx
xcdparser.cxx
xcsparser.cxx
xcuparser.cxx
xmldata.cxx
XML file reading.
parsemanager.cxx
parser.hxx
valueparser.cxx
xcdparser.cxx
xcsparser.cxx
xcuparser.cxx
xmldata.cxx
XML file reading.
modifications.cxx
writemodfile.cxx
Modification management.
modifications.cxx
writemodfile.cxx
Modification management.
broadcaster.cxx
Notification management.
broadcaster.cxx
Notification management.
additions.hxx
update.cxx
Extension manager interface.
additions.hxx
update.cxx
Extension manager interface.
data.cxx
lock.cxx
nodemap.cxx
partial.cxx
path.hxx
type.cxx
Utilities.
data.cxx
lock.cxx
nodemap.cxx
partial.cxx
path.hxx
type.cxx
Utilities.
== Some Implementation Notes ==
## Some Implementation Notes
=== Mandatory Set Members ===
### Mandatory Set Members
- A set member can be marked as "mandatory," meaning that a member of that name
must always be present in a set.
@ -70,67 +70,68 @@ must always be present in a set.
- The above definition implies that calling replaceByName on a mandatory set
member is OK.
- The XCU format can contain oor:mandatory attributes on nodes. (The XCS format
does not support them. In the registrymodifications file, oor:mandatory
- The XCU format can contain `oor:mandatory` attributes on nodes. (The XCS format
does not support them. In the `registrymodifications` file, `oor:mandatory`
attributes should never be needed, as being mandatory cannot be controlled via
the UNO API.) The XCU reading code only evaluates the oor:mandatory attribute
the UNO API.) The XCU reading code only evaluates the `oor:mandatory` attribute
for set members, and ignores it everywhere else.
- Only true sets support mandatory members. A localized property for the "*"
- Only true sets support mandatory members. A localized property for the "`*`"
locale, though acting much like a set, does not support mandatory members.
- The OpenOffice.org Registry Format document claims that group extension
- The LibreOffice Registry Format document claims that group extension
properties are implicitly mandatory, but at least the new configmgr code does
not treat them like that (i.e., they can be removed again).
- For simplicity, setMandatory/getMandatory are available as virtual functions
at the base Node, even though they can only make sense for GroupNodes and
SetNodes that are set members. The default getMandatory implementation returns
NO_LAYER, meaning oor:mandatory is not set to true in any layer. (Returning
NO_LAYER simplifies the code, e.g., removeByName does not have to check whether
getMandatory is called on a member of a true set to decide whether to forbid
- For simplicity, `setMandatory/getMandatory` are available as virtual functions
at the base `Node`, even though they can only make sense for `GroupNodes` and
SetNodes that are set members. The default `getMandatory` implementation returns
`NO_LAYER`, meaning `oor:mandatory` is not set to true in any layer. (Returning
`NO_LAYER` simplifies the code, e.g., `removeByName` does not have to check whether
`getMandatory` is called on a member of a true set to decide whether to forbid
removal.)
- When committing changes (made through the UNO API), the "mandatory" status of
inserted nodes must be updated (in case the insert is due to a replaceByName, or
inserted nodes must be updated (in case the insert is due to a `replaceByName`, or
the "mandatory" flag was added by a concurrent modification of a lower layer).
Also, for to-be-removed nodes, removal is ignored for (newly; due to concurrent
modification of a lower layer) mandatory nodes (but still recorded in
registrymodifications, so may take effect once the lower layer addition is
`registrymodifications`, so may take effect once the lower layer addition is
removed again---whether or not that is a good idea).
=== XcuParser Modification Recording ===
### XcuParser Modification Recording
- XcuParser records modifications when reading user layer data
(valueParser_.getLayer() == Data::NO_LAYER).
- `XcuParser` records modifications when reading user layer data
(`valueParser_.getLayer() == Data::NO_LAYER`).
- oor:finalized and oor:mandatory attributes cannot be set via the UNO API, so
- `oor:finalized and `oor:mandatory` attributes cannot be set via the UNO API, so
it is assumed that user layer data does not contain them (for one, they are not
written by writeModFile; for another, the logic to record modifications expects
a locprop(modify,fuse) to be followed by one or more value(fuse,remove), which
would not necessarily be true if the locprop were only present in the user layer
written by `writeModFile`; for another, the logic to record modifications expects
a `locprop(modify,fuse)` to be followed by one or more `value(fuse,remove)`, which
would not necessarily be true if the `locprop` were only present in the user layer
data to flag it as finalized).
- The logic to record modifications considers the top of the XML element stack.
In the following list of all possible cases, items marked with an asterisk are
recorded:
... group(modify,fuse) - group(modify,fuse) - ...
... group(modify,fuse) - set(modify,fuse) - ...
... group(modify,fuse) - *prop(modify,fuse,replace) - value(fuse)
... group(modify,fuse) - *prop(remove)
... group(modify,fuse) - locprop(modify,fuse) - *value(fuse)
... group(modify,fuse) - locprop(modify,fuse) - *value(remove)
... group(modify,fuse) - *locprop(replace) ...
... set(modify,fuse,replace) - group(modify/fuse) - ...
... set(modify,fuse,replace) - *group(replace/fuse) - ...
... set(modify,fuse,replace) - *group(remove)
... set(modify,fuse,replace) - set(modify/fuse) - ...
... set(modify,fuse,replace) - *set(replace/fuse) - ...
... set(modify,fuse,replace) - *set(remove)
Legend: "...": zero or more further items
"- ...": one or more further items
"modify,fuse" etc.: any of those operations
"modify/fuse": a modify or a fuse on an existing member
"replace/fuse": a replace or a fuse on a non-existing member
... group(modify,fuse) - group(modify,fuse) - ...
... group(modify,fuse) - set(modify,fuse) - ...
... group(modify,fuse) - *prop(modify,fuse,replace) - value(fuse)
... group(modify,fuse) - *prop(remove)
... group(modify,fuse) - locprop(modify,fuse) - *value(fuse)
... group(modify,fuse) - locprop(modify,fuse) - *value(remove)
... group(modify,fuse) - *locprop(replace) ...
... set(modify,fuse,replace) - group(modify/fuse) - ...
... set(modify,fuse,replace) - *group(replace/fuse) - ...
... set(modify,fuse,replace) - *group(remove)
... set(modify,fuse,replace) - set(modify/fuse) - ...
... set(modify,fuse,replace) - *set(replace/fuse) - ...
... set(modify,fuse,replace) - *set(remove)
Legend:
"...": zero or more further items
"- ...": one or more further items
"modify,fuse" etc.: any of those operations
"modify/fuse": a modify or a fuse on an existing member
"replace/fuse": a replace or a fuse on a non-existing member

50
connectivity/README.md
View file

@ -1,44 +1,50 @@
# Database Connectivity
Contains database pieces, drivers, etc.
[[dbaccess]] builds UI on top of this.
`dbaccess` builds UI on top of this.
=== PostgreSQL ===
## Testing
### PostgreSQL
For testing, use:
podman pull postgres:latest
podman run --name=postgres -e POSTGRES_PASSWORD=foobarbaz -p 127.0.0.1:5432:5432 postgres:latest
podman pull postgres:latest
podman run --name=postgres -e POSTGRES_PASSWORD=foobarbaz -p 127.0.0.1:5432:5432 postgres:latest
In Base, Connect to an existing database, select PostgreSQL:
URL: host=127.0.0.1 port=5432 dbname=postgres
User: postgres
Password: foobarbaz
podman stop postgres
podman rm postgres
URL: host=127.0.0.1 port=5432 dbname=postgres
User: postgres
Password: foobarbaz
podman stop postgres
podman rm postgres
In order to test SCRAM authentication, create the container like this:
podman run --name=postgres -e POSTGRES_PASSWORD=foobarbaz -e POSTGRES_INITDB_ARGS=--auth-host=scram-sha-256 -e POSTGRES_HOST_AUTH_METHOD=scram-sha-256 -p 127.0.0.1:5432:5432 postgres:latest
podman run --name=postgres -e POSTGRES_PASSWORD=foobarbaz -e POSTGRES_INITDB_ARGS=--auth-host=scram-sha-256 -e POSTGRES_HOST_AUTH_METHOD=scram-sha-256 -p 127.0.0.1:5432:5432 postgres:latest
=== mysql_test ===
### MySQL
For mysql_test:
- The CppunitTest_mysql_test unit test can be used to test the mysqlc
library with any versions of mysql or mariadb server of your choice.
library with any versions of mysql or mariadb server of your choice.
- This test does not run automatically. It can be triggered with setting
the environment variable "CONNECTIVITY_TEST_MYSQL_DRIVER".
the environment variable "CONNECTIVITY_TEST_MYSQL_DRIVER".
- The environment variable should contain a URL of the following format:
[user]/[passwd]@sdbc:mysql:mysqlc:[host]:[port]/db_name
`[user]/[passwd]@sdbc:mysql:mysqlc:[host]:[port]/db_name`
- tl;dr:
podman pull mariadb/server
podman run --name=mariadb -e MYSQL_ROOT_PASSWORD=foobarbaz -p 127.0.0.1:3306:3306 mariadb/server
podman exec -it mariadb /bin/bash -c "echo -e CREATE DATABASE test | /usr/bin/mysql -u root"
(cd connectivity && make -srj8 CppunitTest_connectivity_mysql_test CONNECTIVITY_TEST_MYSQL_DRIVER="root/foobarbaz@sdbc:mysql:mysqlc:127.0.0.1:3306/test")
podman stop mariadb
podman rm mariadb
```
podman pull mariadb/server
podman run --name=mariadb -e MYSQL_ROOT_PASSWORD=foobarbaz -p 127.0.0.1:3306:3306 mariadb/server
podman exec -it mariadb /bin/bash -c "echo -e CREATE DATABASE test | /usr/bin/mysql -u root"
(cd connectivity && make -srj8 CppunitTest_connectivity_mysql_test CONNECTIVITY_TEST_MYSQL_DRIVER="root/foobarbaz@sdbc:mysql:mysqlc:127.0.0.1:3306/test")
podman stop mariadb
podman rm mariadb
```

8
cppcanvas/README.md
View file

@ -1,5 +1,7 @@
Helper C++ classes for [[canvas]], plus a GDIMetaFile-to-XCanvas converter.
# C++ Helper Classes for canvas
== EMF+ ==
Helper C++ classes for `canvas`, plus a `GDIMetaFile`-to-`XCanvas` converter.
For cppcanvas/source/mtfrenderer, see the README in vcl (the EMF+ part).
## EMF+
For `cppcanvas/source/mtfrenderer`, see the `README.md` in `vcl` (the EMF+ part).

10
cppu/README.md
View file

@ -1,4 +1,8 @@
Type definitions/implementations for the core of UNO. The exported API is in C.
# Binary UNO Runtime
See also:
[http://wiki.openoffice.org/wiki/Uno/Binary/Modules/CPPU]
CPPU stands for C++ UNO and it contains type definitions / implementations for the core of UNO. The
exported API is in C, and there exists some C++ wrappers.
## See also
<http://wiki.openoffice.org/wiki/Uno/Binary/Modules/CPPU>

10
cppuhelper/README.md
View file

@ -1,4 +1,8 @@
Helpers for using cppu in C++, e.g. templates for implementing UNO components, bootstrapping stuff. Get UNO up and running.
# C++ cppu Helpers
See also:
[http://wiki.openoffice.org/wiki/Uno/Cpp/Modules/CPPUhelper]
Helpers for using `cppu` in C++, e.g. templates for implementing UNO components, bootstrapping
stuff. Get UNO up and running.
## See Also
<http://wiki.openoffice.org/wiki/Uno/Cpp/Modules/CPPUhelper>

4
cpputools/README.md
View file

@ -1 +1,3 @@
Old way of doing component registration. Nowadays replaced by another stand-alone UI and tools called UNO package.
# Old Way of Doing Component Registration
Nowadays replaced by another stand-alone UI and tools called UNO package.

6
cui/README.md
View file

@ -1,8 +1,8 @@
Common User Interface
# Common User Interface (cui)
It was moved out from svx in DEV300m68:
It was moved out from `svx` in DEV300m68:
http://www.mail-archive.com/dev@openoffice.org/msg12925.html
<http://www.mail-archive.com/dev@openoffice.org/msg12925.html>
It contains dialogs used by more than one application, e.g. paragraph
properties.

6
dbaccess/README.md
View file

@ -1,3 +1,5 @@
Database access tools, for "base" database application
# Database Access Tools for LibreOffice Base DB Apps
Builds on top of drivers in [[connectivity]].
Database access tools, for `base` database application
Builds on top of drivers in `connectivity`.

29
desktop/README.md
View file

@ -1,28 +1,28 @@
What used to be the desktop in StarOffice 5 - now the binary.
# LibreOffice Binary
Code for the LibreOffice main binary (`soffice`) resides here. The `soffice_main`
function for the `soffice` binary can be found here.
Stable Interface
================
## Stable Interface
Some of the artifacts built here are part of a LibreOffice installation set's
stable interface, which (programmatic) clients can depend on. Among them are:
soffice
=======
### soffice
In the "program" directory ("program/" on Linux and Windows, "Contents/MacOS/"
In the `program` directory (`program/` on Linux and Windows, `Contents/MacOS/`
on macOS).
unoinfo
=======
### unoinfo
In the "program" directory ("program/" on Linux and Windows, "Contents/MacOS/"
In the `program` directory (`program/` on Linux and Windows, `Contents/MacOS/`
on macOS).
When called with a sole argument of "c++", it prints to stdout an absolute
When called with a sole argument of `c++`, it prints to stdout an absolute
pathname denoting the directory where the public URE libraries are found.
When called with a sole argument of "java", it prints to stdout a marker
When called with a sole argument of `java`, it prints to stdout a marker
character (either an ASCII '0' or '1') followed by a sequence of zero or more
absolute pathnames denoting jars or directories that need to be included in a
class loader's search locations.
@ -33,4 +33,9 @@ other by NUL bytes.
If the marker character is '1' (on Windows), the pathnames are encoded as
UTF-16-LE two-byte code units, and any two pathnames in the sequence are
separated from each other by two-byte NUL code units.
separated from each other by two-byte `NUL` code units.
## Other Binaries
### oosplash
Splash screen for the LibreOffice `soffice` binary.

20
distro-configs/README.md
View file

@ -1,28 +1,28 @@
Pre-canned distribution configurations
# Pre-canned Distribution Configurations
These files are supposed to correspond to the options used when
creating the Document Foundation (or other "canonical") builds of
LibreOffice for various platforms. They are *not* supposed to
represent the "most useful" options for developers in general. On the
contrary, the intent is that just running ./autogen.sh without any
contrary, the intent is that just running `./autogen.sh` without any
options at all should produce a buildable configuration for developers
with interest in working on the most commonly used parts of the code.
See [[https://wiki.documentfoundation.org/Development/ReleaseBuilds]] for how
TDF builds make use of these switches. (Especially, since --with-package-format
now triggers whether or not installation sets are built, all the relevant *.conf
files specify it, except for LibreOfficeLinux.conf, where the TDF build
instructions pass an explicit --with-package-format="rpm deb" in addition to
--with-distro=LibreOfficeLinux.)
See <https://wiki.documentfoundation.org/Development/ReleaseBuilds> for how
TDF builds make use of these switches. (Especially, since `--with-package-format`
now triggers whether or not installation sets are built, all the relevant `*.conf`
files specify it, except for `LibreOfficeLinux.conf`, where the TDF build
instructions pass an explicit `--with-package-format="rpm deb"` in addition to
`--with-distro=LibreOfficeLinux`.)
(Possibly the above is a misunderstanding, or maybe there never even
has been any clear consensus what situations these files actually are
intended for.)
The files contain sets of configuration parameters, and can be passed
on the autogen.sh command line thus:
on the `autogen.sh` command line thus:
./autogen.sh --with-distro=LibreOfficeFoo
./autogen.sh --with-distro=LibreOfficeFoo
Contrary to the above, in the Android case the amount of parameters
you just must use is so large, that for convenience it is always

28
drawinglayer/README.md
View file

@ -1,6 +1,8 @@
# Drawing API
Drawing API that can specify what to draw via a kind of display list.
Example of the DrawingLayer use is eg. in svx/source/xoutdev/xtabhtch.cxx:121.
Example of the DrawingLayer use is eg. in `svx/source/xoutdev/xtabhtch.cxx:121`.
A stripped down version with extended comments:
// Create a hatch primitive (here a rectangle that will be filled with
@ -39,7 +41,7 @@ A stripped down version with extended comments:
// it in the widget.
aRetval = aVirtualDevice.GetBitmap(Point(0, 0), aVirtualDevice.GetOutputSizePixel());
== DrawingLayer glossary ==
## DrawingLayer Glossary
Primitives - classes that represent what should be drawn. It holds the data
what to draw, but does not contain any kind of the rendering. Some of the
@ -49,31 +51,31 @@ primitives.
Decomposition - a way how to break down the more complicated primitives into
the basic primitives, and represent them via them; this logically makes the
plain Primitive2DSequence display list a hierarchy.
Eg. PolygonMarkerPrimitive2D can be decomposed to 2 hairlines
PolyPolygonHairlinePrimitive2D's, each with different color.
plain `Primitive2DSequence` display list a hierarchy.
Eg. `PolygonMarkerPrimitive2D` can be decomposed to 2 hairlines
`PolyPolygonHairlinePrimitive2D`'s, each with different color.
Processor - a class that goes through the hierarchy of the Primitives, and
renders it some way. Various processors, like VclPixelProcessor2D (renders to
the screen), VclMetafileProcessor2D (renders to the VCL metafile, eg. for
renders it some way. Various processors, like `VclPixelProcessor2D` (renders to
the screen), `VclMetafileProcessor2D` (renders to the VCL metafile, eg. for
printing), etc.
== How to Implement a new Primitive ("something new to draw") ==
## How to Implement a New Primitive ("Something New to Draw")
* Create an ancestor of BasePrimitive2D
* Create an ancestor of `BasePrimitive2D`
(or of its ancestor if it fits the purpose better)
* Assign it an ID [in drawinglayer_primitivetypes2d.hxx]
* Assign it an ID [in `drawinglayer_primitivetypes2d.hxx`]
* Implement its decomposition
[virtual Primitive2DSequence create2DDecomposition(...)]
[`virtual Primitive2DSequence create2DDecomposition(...)`]
* Extend the (various) processor(s)
If you need more than relying on just the decomposition
== Where is DrawingLayer used ==
## Where is DrawingLayer Used
* SdrObject(s) (rectangles, Circles, predefined shapes etc.)
* `SdrObject`(s) (rectangles, Circles, predefined shapes etc.)
* Selections

18
editeng/README.md
View file

@ -1,12 +1,14 @@
Edit engine.
# Edit Engine
In OpenOffice.org build DEV300m72 this module was split off from `svx` but it
has no dependencies on `svx` (nor on `sfx2`) while in turn `svx` depends on editeng
In OO.o build DEV300m72 this module was split off from svx but it
has no dependencies on [[svx]] (nor on [[sfx2]]) while in turn svx depends on editeng
Read more in the mailing list post:
[http://www.mail-archive.com/dev@openoffice.org/msg13237.html]
<http://www.mail-archive.com/dev@openoffice.org/msg13237.html>
If you build LibreOffice with dbgutil, you have some extended debug keys:
Ctrl+Alt+F1 - draws the paragraph rectangles in different colors
Ctrl+Alt+F11 - toggles dumping the edit engine state to the
If you build LibreOffice with `dbgutil`, you have some extended debug keys:
- Ctrl+Alt+F1 - draws the paragraph rectangles in different colors
- Ctrl+Alt+F11 - toggles dumping the edit engine state to the
"editenginedump.log" on draw
Ctrl+Alt+F12 - dumps the current edit engine state to "editenginedump.log"
- Ctrl+Alt+F12 - dumps the current edit engine state to "editenginedump.log"

4
embeddedobj/README.md
View file

@ -1 +1,3 @@
Code for embedding objects into LibreOffice (reverse of embedserv module).
# Embedding Objects Into LibreOffice
Code for embedding objects into LibreOffice (reverse of `embedserv` module).

2
embedserv/README.md
View file

@ -1 +1,3 @@
# LibreOffice Embeddable Objects
To embed LibreOffice via OLE2.

6
emfio/README.md
View file

@ -1 +1,5 @@
It contains emfio/source/reader which is used for "Insert->Picture->From File".
# WMF/EMF Reader
It contains emfio/source/reader which is used for "Insert -> Picture -> From
File". It is used to read WMF (Windows Metafile), EMF (Enhanced Metafiles) and
also MF+ enhanced EMF files.

9
eventattacher/README.md
View file

@ -1 +1,8 @@
How [[basic]] handles events
# Event Attacher
This is how StarBasic handles events.
## See Also
- <https://wiki.openoffice.org/wiki/Documentation/DevGuide/Forms/Programmatic_Assignment_of_Scripts_to_Events>
- <https://wiki.openoffice.org/wiki/Documentation/DevGuide/Forms/Scripting_and_Events>

46
extensions/README.md
View file

@ -1,45 +1,51 @@
This module contains a grab-bag of unrelated misc. libraries, *none* of which is an extension.
# Miscellaneous Modules
== Application online update checking ==
This module contains a grab-bag of unrelated miscellaneous libraries, *none* of
which is an extension.
When we start LO, first InitUpdateCheckJobThread is created, via
UpdateCheckJob::execute() (from extensions/source/update/check/updatecheckjob.cxx),
as a reaction to a "onFirstVisibleTask" event. It waits 25 seconds (so that it
## Application Online Update Checking
When we start LO, first `InitUpdateCheckJobThread` is created, via
`UpdateCheckJob::execute()` (from `extensions/source/update/check/updatecheckjob.cxx`),
as a reaction to a `onFirstVisibleTask` event. It waits 25 seconds (so that it
does not interfere with the startup itself), and then calls
UpdateCheck::initialize() (from extensions/source/update/check/updatecheck.cxx).
`UpdateCheck::initialize()` (from `extensions/source/update/check/updatecheck.cxx`).
This creates one more thread, UpdateCheckThread, that regularly checks whether
This creates one more thread, `UpdateCheckThread`, that regularly checks whether
we have reached the time when we should ask for the update. If yes, asks for
that, and shows the download button in the menu (if the new update is
available).
== OLE automation bridge ==
## OLE Automation Bridge
A bridge between "OLE automation" and UNO, so you can use UNO services
from JScript, VBScript, etc.
https://www.openoffice.org/udk/common/man/spec/ole_bridge.html
<https://www.openoffice.org/udk/common/man/spec/ole_bridge.html>
See udkapi/com/sun/star/bridge/oleautomation/ApplicationRegistration.idl
See `udkapi/com/sun/star/bridge/oleautomation/ApplicationRegistration.idl`
This is initialized in Desktop::Main() in Desktop::OpenClients_Impl()
by creating the service "com.sun.star.bridge.OleApplicationRegistration",
which is implemented by OleServer_Impl.
This is initialized in `Desktop::Main()` in `Desktop::OpenClients_Impl()`
by creating the service `com.sun.star.bridge.OleApplicationRegistration`,
which is implemented by `OleServer_Impl`.
See extensions/source/ole/
See `extensions/source/ole/`
== ActiveX control ==
## ActiveX Control
This allows embedding LO into a Win32 application as an ActiveX control.
See extensions/source/activex/
== Spotlight provider ==
See `extensions/source/activex/`
## Spotlight Provider
On macOS, this allows indexing ODF documents with Spotlight.
See extensions/source/macosx/spotlight/
== Scanner support ==
See `extensions/source/macosx/spotlight/`
## Scanner Support
You can scan from LibreOffice, using platform specific backends like TWAIN/SANE.
See extensions/source/scanner/
See `extensions/source/scanner/`

2
external/README.md vendored
View file

@ -1 +1,3 @@
# External Projects
External projects bundled with LibreOffice.

108
extras/README.md
View file

@ -1,61 +1,63 @@
# Extra Modules
Contains templates, clipart galleries, palettes, symbol font, autocorrections, autotexts etc.
How-to add a new gallery:
+ create a directory extras/source/gallery/foo/
+ create a .str file extras/source/gallery/foo/foo.str
+ add a [foo] section to extras/source/gallery/share/gallery_names.ulf
+ add a Gallery_foo.mk at the top-level (and mention in Module_extra.mk)
+ add a new GALLERY_FILELIST statement in scp2/
+ How-to add a new gallery:
+ create a directory `extras/source/gallery/foo/`
+ create a `.str` file `extras/source/gallery/foo/foo.str`
+ add a `foo` section to `extras/source/gallery/share/gallery_names.ulf`
+ add a `Gallery_foo.mk` at the top-level (and mention in `Module_extra.mk`)
+ add a new `GALLERY_FILELIST` statement in `scp2/`
How-to add a new autotext category
+ create a directory extras/source/autotext/lang/xx/foo/ where xx is your lang code. xx must exactly fit with an UI lang code.
+ unzip your foo.bau autotext file in this directory (including an empty mimetype file)
+ add xx/foo.bau in extras/AllLangPackage_autotextshare.mk
+ in extras/CustomTarget_autotextshare.mk:
+ add xx/foo in extras_AUTOTEXTSHARE_AUTOTEXTS
+ add all files contained in foo.bau (except mimetype) in extras_AUTOTEXTSHARE_XMLFILES
+ if foo.bau contains files with other extension than .xml, .rdf, .svm and .png
+ add a CPY call at the end of the file
+ How-to add a new autotext category
+ create a directory `extras/source/autotext/lang/xx/foo/` where `xx` is your lang code. `xx` must exactly fit with an UI lang code.
+ unzip your `foo.bau` autotext file in this directory (including an empty mimetype file)
+ add `xx/foo.bau` in `extras/AllLangPackage_autotextshare.mk`
+ in `extras/CustomTarget_autotextshare.mk`:
+ add `xx/foo` in `extras_AUTOTEXTSHARE_AUTOTEXTS`
+ add all files contained in `foo.bau` (except mimetype) in `extras_AUTOTEXTSHARE_XMLFILES`
+ if `foo.bau` contains files with other extension than `.xml`, `.rdf`, `.svm` and `.png`
+ add a `CPY` call at the end of the file
How-to add a new autotext to an existing category
+ create a directory extras/source/autotext/lang/xx/standard/FOO/ to add it in category standard of lang xx
+ add files of the autotext (at least FOO.xml for an unformatted autotext)
+ add autotext name in extras/source/autotext/lang/xx/standard/BlockList.xml
+ add all files of autotext in extras/source/autotext/lang/xx/standard/META-INF/manifest.xml
+ in extras/CustomTarget_autotextshare.mk:
+ add all files of autotext in extras_AUTOTEXTSHARE_XMLFILES
+ if some files have different extension from .xml, .rdf, .svm and .png
+ add a CPY call at the end of the file
+ How-to add a new autotext to an existing category
+ create a directory `extras/source/autotext/lang/xx/standard/FOO/` to add it in category standard of lang `xx`
+ add files of the autotext (at least `FOO.xml` for an unformatted autotext)
+ add autotext name in `extras/source/autotext/lang/xx/standard/BlockList.xml`
+ add all files of autotext in `extras/source/autotext/lang/xx/standard/META-INF/manifest.xml`
+ in `extras/CustomTarget_autotextshare.mk`:
+ add all files of autotext in `extras_AUTOTEXTSHARE_XMLFILES`
+ if some files have different extension from `.xml`, `.rdf`, `.svm` and `.png`
+ add a `CPY` call at the end of the file
How-to add a new Impress template
+ clean-up template file as indicated on wiki https://wiki.documentfoundation.org/Documentation/HowTo/Impress/Make_template_language_independent
+ add <dc:title>Foo</dc:title> in meta.xml to make presentation name translatable
+ unzip Foo.otp file in extras/source/templates/presnt/Foo (no space allowed in any file names)
+ add "Foo.otp" in Package_tplpresnt.mk
+ in CustomTarget_tplpresnt.mk:
+ add "Foo /" in extras_TEMPLATES_PRESENTATIONS
+ add files names contained in Foo.otp (except mimetype) in extras_PRESENTATIONS_XMLFILES
+ if Foo.otp contains files with other extension than .xml, .svm, .svg, .png and .jpg
+ add a CPY call at the end of file
+ How-to add a new Impress template
+ clean-up template file as indicated on wiki <https://wiki.documentfoundation.org/Documentation/HowTo/Impress/Make_template_language_independent>
+ add `<dc:title>Foo</dc:title>` in `meta.xml` to make presentation name translatable
+ unzip `Foo.otp` file in `extras/source/templates/presnt/Foo` (no space allowed in any file names)
+ add `Foo.otp` in `Package_tplpresnt.mk`
+ in `CustomTarget_tplpresnt.mk`:
+ add `Foo /` in `extras_TEMPLATES_PRESENTATIONS`
+ add files names contained in `Foo.otp` (except mimetype) in `extras_PRESENTATIONS_XMLFILES`
+ if `Foo.otp` contains files with other extension than `.xml`, `.svm`, `.svg`, `.png` and `.jpg`
+ add a `CPY` call at the end of file
How-to add a new Writer template
+ clean-up template file as much as possible, and choose a template category <Category>
+ unzip Foo.ott in extras/source/templates/<Category>/Foo (no space allowed in any file names)
+ add Foo.ott in Package_<tplCategory>.mk
+ in CustomTarget_<tplCategory>.mk:
+ add Foo / in extras_TEMPLATES_<CATEGORY>
+ add files names contained in Foo.otp (except mimetype) in extras_<CATEGORY>_XMLFILES
+ if Foo.ott contains files with other extension than .xml, rdf, .svm, .svg, .png and .jpg
+ add a CPY call at the end of file
+ How-to add a new Writer template
+ clean-up template file as much as possible, and choose a template category `<Category>`
+ unzip `Foo.ott` in `extras/source/templates/<Category>/Foo` (no space allowed in any file names)
+ add `Foo.ott` in `Package_<tplCategory>.mk`
+ in `CustomTarget_<tplCategory>.mk`:
+ add `Foo /` in `extras_TEMPLATES_<CATEGORY>`
+ add files names contained in `Foo.otp` (except mimetype) in `extras_<CATEGORY>_XMLFILES`
+ if `Foo.ott` contains files with other extension than `.xml`, `.rdf`, `.svm`, `.svg`, `.png` and `.jpg`
+ add a `CPY` call at the end of file
How-to add a new template category
+ create a directory extras/source/templates/foo/
+ unzip your foo0.ott template files in extras/source/templates/foo/foo0
+ add Package_tplfoo and CustomTarget_tplfoo in Module_extras.mk
+ use other category Package_tplcategory.mk to create Package_tplfoo.mk
+ use other category CustomTarget_tplcategory.mk to create CustomTarget_tplfoo.mk
+ replace all category by foo and CATEGORY by FOO
+ add all files contained in foo0.ott (except mimetype) in extras_FOO_XMLFILES
+ if foo0.ott contains files with other extension than .xml, .rdf, .svm, .svg, .png and .jpg
+ add a CPY call at the end of the file
+ How-to add a new template category
+ create a directory `extras/source/templates/foo/`
+ unzip your foo0.ott template files in `extras/source/templates/foo/foo0`
+ add `Package_tplfoo` and `CustomTarget_tplfoo` in `Module_extras.mk`
+ use other category `Package_tplcategory.mk` to create `Package_tplfoo.mk`
+ use other category `CustomTarget_tplcategory.mk` to create `CustomTarget_tplfoo.mk`
+ replace all category by foo and `CATEGORY` by `FOO`
+ add all files contained in `foo0.ott` (except mimetype) in `extras_FOO_XMLFILES`
+ if `foo0.ott` contains files with other extension than `.xml`, `.rdf`, `.svm`, `.svg`, `.png` and `.jpg`
+ add a `CPY` call at the end of the file
+ optionally, replace extension ott (4 places)

24
filter/README.md
View file

@ -1,24 +1,24 @@
# LibreOffice Filters
Filter registration and some simple filters (also descriptions).
Desperate splitting of code into small shared libraries for historical
reasons presumably (OS/2 and Windows 3.x). The libraries produced from
the code in each subdirectory of filter/source/graphicfilter are
the code in each subdirectory of `filter/source/graphicfilter` are
graphic format import or export filters. But they don't have uniform
API. Some have either a GraphicImport or GraphicExport entry point,
API. Some have either a `GraphicImport` or `GraphicExport` entry point,
and are loaded and used in a uniform fashion from code in
svtools/source/filter/filter.cxx. Others have different API and are
loaded from other places. For instance "icgm" has ImportCGM, and is
loaded and used by sd/source/filter/cgm/sdcgmfilter.cxx (!).
Svgreader is used for "File->Open" and then to choose the svg file.
For "Insert->Picture->From File", see svgio/source/svgreader directory.
`svtools/source/filter/filter.cxx`. Others have different API and are
loaded from other places. For instance `icgm` has `ImportCGM`, and is
loaded and used by `sd/source/filter/cgm/sdcgmfilter.cxx` (!).
Svgreader is used for "File -> Open" and then to choose the svg file.
For "Insert -> Picture -> From File", see `svgio/source/svgreader` directory.
====================
filter configuration
====================
## Filter Configuration
The filter configuration consists of two parts, the type definition in
filter/source/config/fragments/types/ and the actual filter definition
in filter/source/config/fragments/filters/.
`filter/source/config/fragments/types/` and the actual filter definition
in `filter/source/config/fragments/filters/`.
Each file type e.g. text file should be represented by exactly one
type definition. This type can then be referenced by several different

4
forms/README.md
View file

@ -1 +1,3 @@
Embedded forms control and pieces (design forms in documents, fields and database driven).
# Embedded Forms Control and Pieces
design forms in documents, fields and database driven.

8
formula/README.md
View file

@ -1,5 +1,7 @@
Contains parts of the formula parser used outside Calc code that has
# Formula Helper Code
Contains parts of the formula parser used outside LibreOffice Calc code that has
been pulled out from Calc's formula parser code.
Also contains some functions that are needed by code in both sc and
scaddins. Located here just for convenience. So sue me.
Also contains some functions that are needed by code in both `sc` and
`scaddins`. Located here just for convenience. So sue me.

2
fpicker/README.md
View file

@ -1 +1,3 @@
# Native File Picker
Native file pickers for macOS and Windows (file open dialog).

7
framework/README.md
View file

@ -1,4 +1,7 @@
# UNO Framework
Toolbars, menus, UNO stuff, including accelerators and interaction, etc.
See also:
http://wiki.openoffice.org/wiki/Framework
## See Also
<http://wiki.openoffice.org/wiki/Framework>

4
hwpfilter/README.md
View file

@ -1,5 +1,7 @@
# Filters for Korean (Hangul) Popular Word Processor Formats
Filter for a word processor file format popular in Korea (Hangul Word Processor).
Unfortunately apparently there is a newer version of the file format
in use nowadays and the code doesn't handle that correctly but
silently corrupts the input. See fdo#70097.
silently corrupts the input. See tdf#70097.

208
i18nlangtag/README.md
View file

@ -1,141 +1,143 @@
# Language Tags
Code for language tags, LanguageTag wrapper for liblangtag and converter between BCP47 language tags, Locale(Language,Country,Variant) and MS-LangIDs.
Basic functionality used by almost every other module including comphelper, so even don't use that string helpers in this code to not create circular dependencies. Stick with sal and rtl!
If Microsoft introduced a new LCID for a locale that we previously defined as LANGUAGE_USER_..., for example LANGUAGE_CATALAN_VALENCIAN that we had as LANGUAGE_USER_CATALAN_VALENCIAN:
If Microsoft introduced a new LCID for a locale that we previously defined as `LANGUAGE_USER_...`, for example `LANGUAGE_CATALAN_VALENCIAN` that we had as `LANGUAGE_USER_CATALAN_VALENCIAN`:
* include/i18nlangtag/lang.h
** add the new LANGUAGE_... value as defined by MS, here LANGUAGE_CATALAN_VALENCIAN
** rename the LANGUAGE_USER_... definition to LANGUAGE_OBSOLETE_USER_..., here LANGUAGE_USER_CATALAN_VALENCIAN to LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN
** add a #define LANGUAGE_USER_CATALAN_VALENCIAN LANGUAGE_CATALAN_VALENCIAN
*** so svtools/source/misc/langtab.src (where the defined name is an identifier) and other places using LANGUAGE_USER_CATALAN_VALENCIAN do not need to be changed
* `include/i18nlangtag/lang.h`
* add the new `LANGUAGE_...` value as defined by MS, here `LANGUAGE_CATALAN_VALENCIAN`
* rename the `LANGUAGE_USER_...` definition to `LANGUAGE_OBSOLETE_USER_...`, here `LANGUAGE_USER_CATALAN_VALENCIAN` to `LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN`
* add a `#define LANGUAGE_USER_CATALAN_VALENCIAN LANGUAGE_CATALAN_VALENCIAN`
* so `svtools/source/misc/langtab.src` (where the defined name is an identifier) and other places using `LANGUAGE_USER_CATALAN_VALENCIAN` do not need to be changed
* i18nlangtag/source/isolang/isolang.cxx
** insert a mapping with LANGUAGE_CATALAN_VALENCIAN before (!) the existing LANGUAGE_USER_CATALAN_VALENCIAN
** rename the LANGUAGE_USER_CATALAN_VALENCIAN to LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN
*** so converting the tag maps to the new LANGUAGE_CATALAN_VALENCIAN and converting the old LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN still maps to the tag.
* `i18nlangtag/source/isolang/isolang.cxx`
* insert a mapping with `LANGUAGE_CATALAN_VALENCIAN` before (!) the existing `LANGUAGE_USER_CATALAN_VALENCIAN`
* rename the `LANGUAGE_USER_CATALAN_VALENCIAN` to `LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN`
* so converting the tag maps to the new `LANGUAGE_CATALAN_VALENCIAN` and converting the old `LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN` still maps to the tag.
* i18nlangtag/source/isolang/mslangid.cxx
** add an entry to MsLangId::getReplacementForObsoleteLanguage() to convert LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN to LANGUAGE_CATALAN_VALENCIAN
* `i18nlangtag/source/isolang/mslangid.cxx`
* add an entry to `MsLangId::getReplacementForObsoleteLanguage()` to convert `LANGUAGE_OBSOLETE_USER_CATALAN_VALENCIAN` to `LANGUAGE_CATALAN_VALENCIAN`
When changing a (translation's) language tag (for example, `ca-XV` to `ca-valencia` or `sh` to `sr-Latn`):
When changing a (translation's) language tag (for example, 'ca-XV' to 'ca-valencia' or 'sh' to 'sr-Latn'):
* `solenv/inc/langlist.mk`
* replace the tag and sort alphabetically
* solenv/inc/langlist.mk
** replace the tag and sort alphabetically
* in `translations/source` do `git mv old-tag new-tag`
* note that translations is a git submodule so <https://wiki.documentfoundation.org/Development/Submodules applies>
* in translations/source do git mv old-tag new-tag
** note that translations is a git submodule so https://wiki.documentfoundation.org/Development/Submodules applies
* `i18nlangtag/source/isolang/isolang.cxx`
* maintain the old tag's mapping entry in `aImplIsoLangEntries` to be able to read existing documents using that code
* add the new tag's mapping to `aImplBcp47CountryEntries` or `aImplIsoLangScriptEntries`
* change `mnOverride` from 0 to `kSAME` in `aImplIsoLangScriptEntries` or `aImplIsoLangEntries`
* i18nlangtag/source/isolang/isolang.cxx
** maintain the old tag's mapping entry in aImplIsoLangEntries to be able to read existing documents using that code
** add the new tag's mapping to aImplBcp47CountryEntries or aImplIsoLangScriptEntries
** change mnOverride from 0 to kSAME in aImplIsoLangScriptEntries or aImplIsoLangEntries
* `i18nlangtag/source/languagetag/languagetag.cxx`
* add the new tag's fallback strings to the fallback of the old tag in `LanguageTag::getFallbackStrings()`
* i18nlangtag/source/languagetag/languagetag.cxx
** add the new tag's fallback strings to the fallback of the old tag in LanguageTag::getFallbackStrings()
* `i18nlangtag/qa/cppunit/test_languagetag.cxx`
* add a unit test for the new tag and old tag
* i18nlangtag/qa/cppunit/test_languagetag.cxx
** add a unit test for the new tag and old tag
* `l10ntools/source/ulfconv/msi-encodinglist.txt`
* replace the tag and sort alphabetically
* l10ntools/source/ulfconv/msi-encodinglist.txt
** replace the tag and sort alphabetically
* setup_native/source/packinfo/spellchecker_selection.txt
** replace the tag and sort alphabetically
* `setup_native/source/packinfo/spellchecker_selection.txt`
* replace the tag and sort alphabetically
If locale data exists:
* i18npool/source/localedata/data/*.xml for example i18npool/source/localedata/data/sh_RS.xml
** in the <LC_INFO> element
*** change <LangID> to 'qlt'
*** after the <Country> element add a <Variant> element with the new full BCP 47 tag, for example 'sr-Latn-RS'
**** note that <Variant> has no <VariantID> or <DefaultName> child elements
** if any of the other *.xml files reference the locale in a ref="..." attribute, change those too; note that these references use '_' underscore instead of '-' hyphen just like the file names do
** rename sh_RS.xml to sr_Latn_RS.xml, git mv sh_RS.xml sr_Latn_RS.xml
* `i18npool/source/localedata/data/*.xml` for example `i18npool/source/localedata/data/sh_RS.xml`
* in the `<LC_INFO>` element
* change `<LangID>` to `qlt`
* after the `<Country>` element add a `<Variant>` element with the new full BCP 47 tag, for example `sr-Latn-RS`
* note that `<Variant>` has no `<VariantID>` or `<DefaultName>` child elements
* if any of the other `*.xml` files reference the locale in a `ref="..."` attribute, change those too; note that these references use '`_`' underscore instead of '`-`' hyphen just like the file names do
* rename `sh_RS.xml` to `sr_Latn_RS.xml`, `git mv sh_RS.xml sr_Latn_RS.xml`
* i18npool/source/localedata/localedata.cxx
** in aLibTable change the entry from old "sh_RS" to new "sr_Latn_RS", do not sort the table
* `i18npool/source/localedata/localedata.cxx`
* in `aLibTable` change the entry from old `sh_RS` to new `sr_Latn_RS`, do not sort the table
* i18npool/Library_localedata_*.mk for example i18npool/Library_localedata_euro.mk
** change the entry for the changed .xml file, for example CustomTarget/i18npool/localedata/localedata_sh_RS to CustomTarget/i18npool/localedata/localedata_sr_Latn_RS, sort the list alphabetically
* `i18npool/Library_localedata_*.mk` for example `i18npool/Library_localedata_euro.mk`
* change the entry for the changed `.xml` file, for example `CustomTarget/i18npool/localedata/localedata_sh_RS` to `CustomTarget/i18npool/localedata/localedata_sr_Latn_RS`, sort the list alphabetically
If dictionary exists:
* dictionaries/*/dictionaries.xcu for example dictionaries/sr/dictionaries.xcu
** change the affected <node oor:name="..."> elements to something corresponding, for example <node oor:name="HunSpellDic_sh" ...> to <node oor:name="HunSpellDic_sr_Latn" ...>
** in the "Locales" properties change the <value> element, for example <value>sh-RS</value> to <value>sr-Latn-RS</value>
* `dictionaries/*/dictionaries.xcu` for example `dictionaries/sr/dictionaries.xcu`
* change the affected `<node oor:name="...">` elements to something corresponding, for example `<node oor:name="HunSpellDic_sh" ...>` to `<node oor:name="HunSpellDic_sr_Latn" ...>`
* in the `Locales` properties change the `<value>` element, for example `<value>sh-RS</value>` to `<value>sr-Latn-RS</value>`
If dictionary is to be renamed, for example ku-TR to kmr-Latn:
If dictionary is to be renamed, for example `ku-TR` to `kmr-Latn`:
* dictionaries/*/* for example dictionaries/ku_TR/*
** if appropriate rename *.dic and *.aff files, for example ku_TR.dic to kmr_Latn.dic and ku_TR.aff to kmr_Latn.aff
* dictionaries/Dictionary_*.mk for example dictionaries/Dictionary_ku_TR.mk
** rename file, for example to Dictionary_kmr_Latn.mk
** change all locale dependent file names and target, for example *ku_TR* to *kmr_Latn* AND ku-TR to kmr-Latn; note '-' and '_' separators, both are used!
* dictionaries/Module_dictionaries.mk
** change Dictionary_* (Dictionary_ku-TR to Dictionary_kmr-Latn) and sort alphabetically
* scp2/source/ooo/common_brand.scp
** DosName = "dict-ku-TR";
*** change to "dict-kmr-Latn"
* scp2/source/ooo/file_ooo.scp
** File gid_File_Extension_Dictionary_Ku_Tr
*** change to gid_File_Extension_Dictionary_Kmr_Latn
** Name = "Dictionary/dict-ku-TR.filelist";
*** change to "Dictionary/dict-kmr-Latn.filelist"
* scp2/source/ooo/module_ooo.scp
** Module gid_Module_Root_Extension_Dictionary_Ku_Tr
*** change to gid_Module_Root_Extension_Dictionary_Kmr_Latn
** MOD_NAME_DESC ( MODULE_EXTENSION_DICTIONARY_KU_TR );
*** change to MODULE_EXTENSION_DICTIONARY_KMR_LATN
** Files = (gid_File_Extension_Dictionary_Ku_Tr);
*** change to gid_File_Extension_Dictionary_Kmr_Latn
** Spellcheckerlanguage = "ku-TR";
*** change to "kmr-Latn"
* scp2/source/ooo/module_ooo.ulf
** [STR_NAME_MODULE_EXTENSION_DICTIONARY_KU_TR]
*** change to STR_NAME_MODULE_EXTENSION_DICTIONARY_KMR_LATN
** en-US = "Kurdish (Turkey)"
*** change to "Kurdish, Northern, Latin script"
** [STR_DESC_MODULE_EXTENSION_DICTIONARY_KU_TR]
*** change to STR_DESC_MODULE_EXTENSION_DICTIONARY_KMR_LATN
** en-US = "Kurdish (Turkey) spelling dictionary"
*** change to "Kurdish, Northern, Latin script spelling dictionary"
* setup_native/source/packinfo/packinfo_office.txt
** module = "gid_Module_Root_Extension_Dictionary_Ku_Tr"
*** change to "gid_Module_Root_Extension_Dictionary_Kmr_Latn"
** solarispackagename = "%PACKAGEPREFIX%WITHOUTDOTUNIXPRODUCTNAME%BRANDPACKAGEVERSION-dict-ku-TR"
*** change to "...-dict-kmr-Latn"
** packagename = "%UNIXPRODUCTNAME%BRANDPACKAGEVERSION-dict-ku-TR"
*** change to "...-dict-kmr-Latn"
** description = "Ku-TR dictionary for %PRODUCTNAME %PRODUCTVERSION"
*** change to "Kmr-Latn dictionary ..."
* `dictionaries/*/*` for example `dictionaries/ku_TR/*`
* if appropriate rename `*.dic` and `*.aff` files, for example `ku_TR.dic` to `kmr_Latn.dic` and `ku_TR.aff` to `kmr_Latn.aff`
* `dictionaries/Dictionary_*.mk` for example `dictionaries/Dictionary_ku_TR.mk`
* rename file, for example to `Dictionary_kmr_Latn.mk`
* change all locale dependent file names and target, for example `ku_TR` to `kmr_Latn` AND `ku-TR` to `kmr-Latn`; note '`-`' and '`_`' separators, both are used!
* `dictionaries/Module_dictionaries.mk`
* change `Dictionary_*` (`Dictionary_ku-TR` to `Dictionary_kmr-Latn`) and sort alphabetically
* `scp2/source/ooo/common_brand.scp`
* `DosName = "dict-ku-TR";`
* change to `"dict-kmr-Latn"`
* `scp2/source/ooo/file_ooo.scp`
* File `gid_File_Extension_Dictionary_Ku_Tr`
* change to `gid_File_Extension_Dictionary_Kmr_Latn`
* `Name = "Dictionary/dict-ku-TR.filelist";`
* change to `"Dictionary/dict-kmr-Latn.filelist"`
* `scp2/source/ooo/module_ooo.scp`
* Module `gid_Module_Root_Extension_Dictionary_Ku_Tr`
* change to `gid_Module_Root_Extension_Dictionary_Kmr_Latn`
* `MOD_NAME_DESC` ( `MODULE_EXTENSION_DICTIONARY_KU_TR` );
* change to `MODULE_EXTENSION_DICTIONARY_KMR_LATN`
* `Files = (gid_File_Extension_Dictionary_Ku_Tr);`
* change to `gid_File_Extension_Dictionary_Kmr_Latn`
* `Spellcheckerlanguage = "ku-TR";`
* change to `"kmr-Latn"`
* `scp2/source/ooo/module_ooo.ulf`
* [`STR_NAME_MODULE_EXTENSION_DICTIONARY_KU_TR`]
* change to `STR_NAME_MODULE_EXTENSION_DICTIONARY_KMR_LATN`
* `en-US = "Kurdish (Turkey)"`
* change to `"Kurdish, Northern, Latin script"`
* [`STR_DESC_MODULE_EXTENSION_DICTIONARY_KU_TR`]
* change to `STR_DESC_MODULE_EXTENSION_DICTIONARY_KMR_LATN`
* `en-US = "Kurdish (Turkey)` spelling dictionary"
* change to `"Kurdish, Northern, Latin script spelling dictionary"`
* `setup_native/source/packinfo/packinfo_office.txt`
* `module = "gid_Module_Root_Extension_Dictionary_Ku_Tr"`
* change to `"gid_Module_Root_Extension_Dictionary_Kmr_Latn"`
* `solarispackagename = "%PACKAGEPREFIX%WITHOUTDOTUNIXPRODUCTNAME%BRANDPACKAGEVERSION-dict-ku-TR"`
* change to `"...-dict-kmr-Latn"`
* `packagename = "%UNIXPRODUCTNAME%BRANDPACKAGEVERSION-dict-ku-TR"`
* change to `"...-dict-kmr-Latn"`
* `description = "Ku-TR dictionary for %PRODUCTNAME %PRODUCTVERSION"`
* change to `"Kmr-Latn dictionary ..."`
If extras exist, for example extras/source/autotext/*:
If `extras` exist, for example `extras/source/autotext/*`:
* extras/Package_autocorr.mk
** replace acor_* entry, for example acor_sh-RS.dat to acor_sr-Latn-RS.dat, sort alphabetically
* `extras/Package_autocorr.mk`
* replace `acor_*` entry, for example `acor_sh-RS.dat` to `acor_sr-Latn-RS.dat`, sort alphabetically
* extras/CustomTarget_autocorr.mk
** in extras_AUTOCORR_LANGS change map entry, for example sh-RS:sh-RS to sr-Latn-RS:sr-Latn-Rs
** in extras_AUTOCORR_XMLFILES change directory entries, for example sh-RS/acor/DocumentList.xml to sr-Latn-RS/acor/DocumentList.xml
* `extras/CustomTarget_autocorr.mk`
* in `extras_AUTOCORR_LANGS change` map entry, for example `sh-RS:sh-RS` to `sr-Latn-RS:sr-Latn-Rs`
* in `extras_AUTOCORR_XMLFILES` change directory entries, for example `sh-RS/acor/DocumentList.xml` to `sr-Latn-RS/acor/DocumentList.xml`
* rename files accordingly, for example in extras/source/autotext/lang/ git mv sh-RS sr-Latn-RS
* rename files accordingly, for example in `extras/source/autotext/lang/` `git mv sh-RS sr-Latn-RS`
If helpcontent exists:
If `helpcontent` exists:
* helpcontent2/source/auxiliary/*/* for example helpcontent2/source/auxiliary/sh/*
** change Language=..., for example Language=sh to Language=sr-Latn in helpcontent2/source/auxiliary/sh/*.cfg
** rename helpcontent2/source/auxiliary/sh/ git mv sh sr-Latn
* `helpcontent2/source/auxiliary/*/*` for example `helpcontent2/source/auxiliary/sh/*`
* change `Language=...`, for example `Language=sh` to `Language=sr-Latn` in `helpcontent2/source/auxiliary/sh/*.cfg`
* rename `helpcontent2/source/auxiliary/sh/` `git mv sh sr-Latn`
For language packs:
* scp2/source/ooo/module_langpack.ulf
* scp2/source/accessories/module_templates_accessories.ulf
* scp2/source/accessories/module_samples_accessories.ulf
* scp2/source/extensions/module_extensions_sun_templates.ulf
* `scp2/source/ooo/module_langpack.ulf`
* `scp2/source/accessories/module_templates_accessories.ulf`
* `scp2/source/accessories/module_samples_accessories.ulf`
* `scp2/source/extensions/module_extensions_sun_templates.ulf`
* If the upper-cased tag appears in any of these, replace it, for example `STR_NAME_MODULE_LANGPACK_SH` to `STR_NAME_MODULE_LANGPACK_SR_LATN`
** If the upper-cased tag appears in any of these, replace it, for example STR_NAME_MODULE_LANGPACK_SH to STR_NAME_MODULE_LANGPACK_SR_LATN

15
i18npool/README.md
View file

@ -1,11 +1,12 @@
Internationalisation (i18npool) framework ensures that the suite is adaptable to the requirements of different
native languages, their local settings and customs, etc without source code modification. (Wow, that is such marketing-speak...)
# Internationalisation Pool (i18npool) Framework
Specifically for locale data documentation please see i18npool/source/localedata/data/locale.dtd
Internationalisation pool (i18npool) framework ensures that the suite is adaptable to the
requirements of different native languages, their local settings and customs, etc without source
code modification. (Wow, that is such marketing-speak...)
See also [http://wiki.documentfoundation.org/Category:I18n]
Specifically for locale data documentation please see `i18npool/source/localedata/data/locale.dtd`
On iOS we put the largest data generated here, the dict_ja and dict_zh
On iOS we put the largest data generated here, the `dict_ja` and `dict_zh`
stuff, into separate files and not into code to keep the size of an
app binary down. Temporary test code:
@ -17,3 +18,7 @@ app binary down. Temporary test code:
uno::Reference< uno::XInterface > xInterface =
xMultiComponentFactoryClient->createInstanceWithContext( "com.sun.star.i18n.BreakIterator_ja", xComponentContext );
}
## See Also
<http://wiki.documentfoundation.org/Category:I18n>

6
i18nutil/README.md
View file

@ -1,4 +1,4 @@
i18nutil is internationalization related utilities
# Internationalization Related Utilities (i18nutil)
It comprises of honest c++ code which you just link to directly, while i18npool
tends to consist of code you interact with via uno.
It comprises of honest c++ code which you just link to directly, while `i18npool`
tends to consist of code you interact with via UNO.

52
icon-themes/README.md
View file

@ -1,42 +1,41 @@
Icon repository for the applications
# Icon Repository for the Applications
All of the icons, separated by themes are included in this
directory. These icons are built into .zip files, and re-ordered /
directory. These icons are built into `.zip` files, and re-ordered `/`
packed for efficiency reasons based on our UI configuration by the
postprocess/CustomTarget_images.mk.
`postprocess/CustomTarget_images.mk`.
An icon theme does not need to contain all images, since these can be
layered one on top of another.
In general the layering is done like this:
<leaf theme>
breeze
colibre
<leaf theme>
breeze
colibre
How to add a new image set:
---------------------------
## How to Add a New Image Set
- Create a directory for it here (let's call it e.g. new_set)
- Create a directory for it here (let's call it e.g. `new_set`)
FIXME: It is important to use an underscore '_' to delimit more words.
scp2 compilation crashes when using a dash '-'.
FIXME: It is important to use an underscore `_` to delimit more words.
`scp2` compilation crashes when using a dash `-`.
It evidently splits the name into two strings.
^ It's probably not true anymore with filelists.
^ if this gets changed, IconThemeSelector::SetPreferredIconTheme needs to change too
- Add its name (new_set) to WITH_THEMES variable in configure.ac
+ It's probably not true anymore with filelists.
+ if this gets changed, `IconThemeSelector::SetPreferredIconTheme` needs to change too
- The fallback for particular icons is defined be packimages_CUSTOM_FALLBACK_1
in packimages/CustomTarget_images.mk
- Add its name (`new_set`) to `WITH_THEMES` variable in `configure.ac`
- The fallback for particular icons is defined be `packimages_CUSTOM_FALLBACK_1`
in `packimages/CustomTarget_images.mk`
How to add a new icon for a new command:
----------------------------------------
## How to Add a New Icon for a New Command
- Assume you defined a dispatch command in officecfg like the following:
in officecfg/registry/data/org/openoffice/Office/UI/CalcCommands.xcu
in `officecfg/registry/data/org/openoffice/Office/UI/CalcCommands.xcu`
<node oor:name=".uno:OpenFromCalc" oor:op="replace">
<prop oor:name="Label" oor:type="xs:string">
@ -50,17 +49,16 @@ How to add a new icon for a new command:
Here, you need to define a property named "Properties", with its value set
to 1 so that the icons show up.
- Now, you need to add 2 new icon images under icon-themes/colibre/cmd/, one
- Now, you need to add 2 new icon images under `icon-themes/colibre/cmd/`, one
for the large size and one for the smaller size. The name of each image
must be lc_<command name>.png and sc_<command name>.png. Here, the command
name is the name given in the above .xcu file without the ".uno:" prefix and
must be `lc_<command name>.png` and `sc_<command name>.png`. Here, the command
name is the name given in the above `.xcu` file without the `.uno:` prefix and
all its letters lower-cased. In this example, the file names will be
lc_openfromcalc.png and sc_openfromcalc.png. Note that you need to add new
`lc_openfromcalc.png` and `sc_openfromcalc.png`. Note that you need to add new
images to the colibre theme for them to show up in any themes at all.
How to call optipng to optimize size:
---------------------------
## How to Call optipng to Optimize Size
8 bit palettes are on the slow path for quartz/svp/gtk3 so avoid using palettes with...
8 bit palettes are on the slow path for `quartz/svp/gtk3` so avoid using palettes with...
$ optipng -nc <file>
$ optipng -nc <file>

8
idl/README.md
View file

@ -1,7 +1,9 @@
SvIDL Compiler that generates C++ slot headers from SDI files in modules' sdi/
# SvIDL Compiler
SvIDL Compiler that generates C++ slot headers from SDI files in modules' `sdi/`
subdirectory.
There is an overview of basic architecture of the markup of SDI files in the
OOo wiki:
OpenOffice wiki:
https://wiki.openoffice.org/wiki/Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2
<https://wiki.openoffice.org/wiki/Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2>

9
idlc/README.md
View file

@ -1,6 +1,7 @@
Contains the UNO IDL compiler: idlc, depends on preprocessor: ucpp
# UNO IDL Compiler (idlc)
Contains the UNO IDL compiler: `idlc`, depends on preprocessor: `ucpp`
This compiler generates binary RDB fragments that can be assembled
into a RDB (UNO type library) with the "regmerge" tool, as is done
primarily in the offapi and udkapi directories.
into a RDB (UNO type library) with the `regmerge` tool, as is done
primarily in the `offapi` and `udkapi` directories.

10
instsetoo_native/README.md
View file

@ -1,11 +1,11 @@
native install-set creation
# Native Install-Set Creation
This is where you will find your natively packaged builds after the
build has completed. On windows these would live in:
build has completed. On Windows these would live in:
workdir/*/installation/LibreOffice_Dev/native/install/en-US/*.msi
workdir/*/installation/LibreOffice_Dev/native/install/en-US/*.msi
for example (nothing like a few long directory names before breakfast).
Also generates ini files for the instdir/ tree (which are unfortunately
duplicated for now between instsetoo_native/CustomTarget_setup.mk and scp2).
Also generates `.ini` files for the `instdir/` tree (which are unfortunately
duplicated for now between `instsetoo_native/CustomTarget_setup.mk` and `scp2`).

5
io/README.md
View file

@ -1,3 +1,4 @@
Simple IO wrapper UNO components
# Simple IO Wrapper UNO Components
Simple IO wrapper UNO components which includes `TextInputStream`,
`TextOutputStream`, pipes and stream helpers

3
javaunohelper/README.md
View file

@ -1,2 +1,3 @@
Makes it easier to use UNO with Java.
# Java UNO Helper
Makes it easier to use UNO with Java.

3
jurt/README.md
View file

@ -1,2 +1,3 @@
JURT means Java Uno Runtime and implements most of Java UNO.
# Java UNO Runtime (jurt)
JURT means Java UNO Runtime and implements most of Java UNO.

5
jvmaccess/README.md
View file

@ -1 +1,4 @@
Wrappers so you can use all the Java Runtime Environments with their slightly incompatible APIs with more ease.
# JVM Access Wrappers
Wrappers so you can use all the Java Runtime Environments with their slightly
incompatible APIs with more ease.

17
jvmfwk/README.md
View file

@ -1,15 +1,20 @@
# JVM Framework Wrappers
Wrappers so you can use all the Java Runtime Environments with their slightly incompatible APIs with more ease.
Used to use an over-engineered "plugin" mechanism although there was only one
"plugin", called "sunmajor", that handles all possible JREs.
IMPORTANT: The <updated> element in vmfwk/distributions/OpenOfficeorg/javavendors_*.xml files
IMPORTANT: The `<updated>` element in `vmfwk/distributions/OpenOfficeorg/javavendors_*.xml` files
should only be updated for incompatible changes, not for compatible ones. As stated in the commit
message of <https://gerrit.libreoffice.org/#/c/69730/> "javavendors_*.xml <updated> should not have
been updated...": "Changing <updated> causes jfw_startVM and jfw_getSelectedJRE (both
jvmfwk/source/framework.cxx) to fail with JFW_E_INVALID_SETTINGS, which in turn causes functionality
message of <https://gerrit.libreoffice.org/#/c/69730/> in LibreOffice gerrit:
"**javavendors\_\*.xml \<updated\> should not have been updated...**
Changing `<updated>` causes `jfw_startVM` and `jfw_getSelectedJRE` (both
`jvmfwk/source/framework.cxx`) to fail with `JFW_E_INVALID_SETTINGS`, which in turn causes functionality
that requires a JVM to issue a GUI error dialog stating that the user must select a new JRE in the
Options dialog. While that behavior makes sense if a JRE was selected that would no longer be
supported by the modified javavendors_*.xml, it is just annoying if an already selected JRE is still
supported. And a compatible change to javavendors_*.xml implies that an already selected JRE will
supported by the modified `javavendors_*.xml`, it is just annoying if an already selected JRE is still
supported. And a compatible change to `javavendors_*.xml` implies that an already selected JRE will
still be supported."

4
l10ntools/README.md
View file

@ -1,3 +1,5 @@
l10ntools (l10n = localization) contains a number of tools that extract
# Localization (l10n) Tools
`l10ntools` (l10n = localization) contains a number of tools that extract
translatable content from source code and merge translations back to
source code during the build.

2
librelogo/README.md
View file

@ -1 +1,3 @@
# LibreLogo Programming Language
LibreLogo is a Logo-like programming language with interactive vectorgraphics for education and DTP

37
libreofficekit/README.md
View file

@ -1,5 +1,4 @@
LibreOfficeKit
**************
# LibreOfficeKit
LibreOfficeKit can be used for accessing LibreOffice functionality
through C/C++, without any need to use UNO.
@ -7,8 +6,7 @@ through C/C++, without any need to use UNO.
For now it only offers document conversion (in addition to an experimental
tiled rendering API).
Integrating LOK into other software
-----------------------------------
## Integrating LOK Into Other Software
LOK functionality can be accessed by including LibreOfficeKit.h[xx] in your
program.
@ -23,11 +21,10 @@ functionality as in LibreOfficeKit.h.)
An example program can be seen on:
https://gitlab.com/ojwb/lloconv
Tiled Rendering
---------------
## Tiled Rendering
To use LOK Tiled Rendering you will need the following before the LOK includes:
#define LOK_USE_UNSTABLE_API
#define LOK_USE_UNSTABLE_API
(This must be define before ANY LOK header, i.e. including the Init header.)
@ -36,8 +33,7 @@ colorspace (further alternatives could feasibly be implemented as needed).
Scanlines are ordered top-down (whereas LibreOffice will internally default
to bottom-up).
Tiled Editing
-------------
## Tiled Editing
On top of the tiled rendering API, a set of new methods have been added to the
lok::Document class to allow basic editing, too. Communication between the LOK
@ -46,14 +42,14 @@ by calling the above mentioned methods. The most important methods for the
client -> LibreOffice communication are:
- initializeForRendering(), expected to be called right after
lok::Office::documentLoad() returned a lok::Document*.
- postKeyEvent(), expected to be called when the user provides input on the
`lok::Office::documentLoad()` returned a `lok::Document*`.
- `postKeyEvent()`, expected to be called when the user provides input on the
(soft-)keyboard.
- postMouseEvent(), expected to be called when the user generated a touch or
- `postMouseEvent()`, expected to be called when the user generated a touch or
mouse event.
In general, all coordinates are always in absolute twips (20th of a point, or:
1" = 1440 twips). See lok::Document in LibreOfficeKit.hxx for a full list of
1" = 1440 twips). See `lok::Document` in `LibreOfficeKit.hxx` for a full list of
methods and their documentation.
The other way around (LibreOffice -> LOK client) is implemented using a
@ -64,11 +60,11 @@ LibreOfficeKitCallbackType enumeration in LibreOfficeKitEnums.h, the callback
function signature itself is provided by the LibreOfficeKitCallback typedef in
LibreOfficeKitTypes.h. The most important callback types:
- LOK_CALLBACK_INVALIDATE_TILES: drop all tiles cached on client-side that
- `LOK_CALLBACK_INVALIDATE_TILES`: drop all tiles cached on client-side that
intersect with the provided rectangle
- LOK_CALLBACK_INVALIDATE_VISIBLE_CURSOR: need to set the position and/or the
- `LOK_CALLBACK_INVALIDATE_VISIBLE_CURSOR`: need to set the position and/or the
size of the cursor
- LOK_CALLBACK_TEXT_SELECTION: need to adjust the selection overlay provided
- `LOK_CALLBACK_TEXT_SELECTION`: need to adjust the selection overlay provided
by the client as the set of rectangles describing the selection overlay
changed
@ -90,7 +86,7 @@ To run gtktiledviewer:
bin/run gtktiledviewer --lo-path=$PWD/instdir/program path/to/test.odt
To receive all incoming events from core use G_MESSAGES_DEBUG=all
To receive all incoming events from core use `G_MESSAGES_DEBUG=all`
G_MESSAGES_DEBUG=all bin/run gtktiledviewer --lo-path=$PWD/instdir/program ../test.odt
@ -100,10 +96,9 @@ To debug with gdb:
before bin/run, this will run gtktiledviewer in the debugger instead.
LibreOfficeKitGtk
*****************
## LibreOfficeKitGtk
Currently consists of only a very basic GTK+ document viewer widget.
Currently consists of only a very basic GTK document viewer widget.
The widget uses g_info() instead of SAL_INFO(), use the 'G_MESSAGES_DEBUG=all'
The widget uses `g_info()` instead of `SAL_INFO()`, use the `G_MESSAGES_DEBUG=all`
environment variable to display those messages.

4
lingucomponent/README.md
View file

@ -1 +1,3 @@
Spellcheck, hyphenator, thesaurus, etc.
# Lingustics Components
`lingucomponent` contains spellcheck, hyphenator, thesaurus, etc.

4
linguistic/README.md
View file

@ -1 +1,3 @@
Handles registered modules for spellchecker, hyphenator and thesaurus.
# Linguistics Components Manager
`linguistic` module handles the registered modules for spellchecker, hyphenator and thesaurus.

34
lotuswordpro/README.md
View file

@ -1,31 +1,31 @@
Import filter for file format of Lotus Word Pro.
# Import Filter for File Format of Lotus Word Pro (lwp)
== Description ==
## Description
The import is not direct, but via an intermediate format: StarOffice
XML, the predecessor of ODF (yes, the code is old). The entry point to
the filter is class LotusWordProImportFilter (refer to Source code
section), but that just hooks up the necessary machinery for processing
StarOffice XML produced by the filter. The real fun starts in function
ReadWordproFile() (source/filter/lwpfilter.cxx); this function
initializes the parser (class Lwp9Reader) and the SAX XML handler that
produces the output (class XFSaxStream). The Lwp9Reader class then does
`ReadWordproFile()` (`source/filter/lwpfilter.cxx`); this function
initializes the parser (class `Lwp9Reader`) and the SAX XML handler that
produces the output (class `XFSaxStream`). The Lwp9Reader class then does
the actual parsing.
If the module is built with debug level greater than 0, it is possible
to examine the intermediate XML: set environment variable
DBG_LWPIMPORT_DIR= to an existing directory and, on opening an lwp
document, a file named lwpimport.xml will be created in that directory.
`DBG_LWPIMPORT_DIR=` to an existing directory and, on opening an lwp
document, a file named `lwpimport.xml` will be created in that directory.
== Source code ==
## Source Code
=== Module contents ===
* inc: module-global headers (can be included by any file in source)
* qa: cppunit tests
* source: the filter itself
* util: UNO passive registration config
### Module Contents
* `inc`: module-global headers (can be included by any file in source)
* `qa`: `cppunit` tests
* `source`: the filter itself
* `util`: UNO passive registration config
=== Source contents ===
* filter: lwp document format parser
* filter/LotusWordProImportFilter.cxx: the entry point to the filter
* filter/xfilter: export to StarOffice XML
### Source Contents
* `filter`: `lwp` document format parser
* `filter/LotusWordProImportFilter.cxx`: the entry point to the filter
* `filter/xfilter`: export to StarOffice XML

4
m4/README.md
View file

@ -1 +1,3 @@
m4 - Macros to locate and utilise pkg-config.
# m4 Macros
m4 - Macros to locate and utilise `pkg-config`.

9
nlpsolver/README.md
View file

@ -1,4 +1,7 @@
This extension integrates into Calc and offers new Solver engines to use for optimizing nonlinear programming models.
# New Linear Programming Solver (nlpsolver)
As there is no known upstream source for nlpsolver/ThirdParty/EvolutionarySolver,
the code is considered internal and can be modified like any other internal code.
This extension integrates into LibreOffice Calc and offers new Solver engines to use for optimizing
nonlinear programming models.
As there is no known upstream source for `nlpsolver/ThirdParty/EvolutionarySolver`,
the code is considered internal and can be modified like any other internal code.

46
o3tl/README.md
View file

@ -1,30 +1,38 @@
Very basic template functionality, a bit like boost or stl, but specific to LibO
# LibreOffice Template Library
o3tl stands for "OOo [o3, get it?] template library"
Very basic template functionality, a bit like boost or STL, but specific to LibreOffice.
From [http://blog.thebehrens.net/2006/01/15/update-cow_wrapper-is-available-now/]
o3tl stands for "OOo [o3, get it?] template library", in which OOo stands for OpenOffice.org,
predecessor of LibreOffice.
From <https://blog.thebehrens.net/2006/01/15/update-cow_wrapper-is-available-now/>
The scope for o3tl is admittedly kind of ambitious, as it should contain "...very basic (template)
functionality, comparable to what's provided by boost or stl, but specific to OOo (what comes to mind
are e.g. stl adapters for our own data types and UNO, and stuff that could in principle be upstreamed
are e.g. STL adapters for our own data types and UNO, and stuff that could in principle be upstreamed
to boost, but isn't as of now)."
== Class overview ==
## Class Overview
[git:o3tl/inc/o3tl/cow_wrapper.hxx]
A copy-on-write wrapper.
- `git:o3tl/inc/o3tl/cow_wrapper.hxx`
[git:o3tl/inc/o3tl/lazy_update.hxx]
This template collects data in input type, and updates the output type with the given update functor,
but only if the output is requested. Useful if updating is expensive, or input changes frequently, but
output is only comparatively seldom used.
A copy-on-write wrapper.
[git:o3tl/inc/o3tl/range.hxx]
Represents a range of integer or iterator values.
- `git:o3tl/inc/o3tl/lazy_update.hxx`
[git:o3tl/inc/o3tl/vector_pool.hxx]
Simple vector-based memory pool allocator.
This template collects data in input type, and updates the output type with the given update functor,
but only if the output is requested. Useful if updating is expensive, or input changes frequently, but
output is only comparatively seldom used.
[git:o3tl/inc/o3tl/functional.hxx]
Some more templates, leftovers in spirit of STLport's old functional
header that are not part of the C++ standard (STLport has been
replaced by direct use of the C++ STL in LibreOffice).
- `git:o3tl/inc/o3tl/range.hxx`
Represents a range of integer or iterator values.
- `git:o3tl/inc/o3tl/vector_pool.hxx`
Simple vector-based memory pool allocator.
- `git:o3tl/inc/o3tl/functional.hxx`
Some more templates, leftovers in spirit of STLport's old functional
header that are not part of the C++ standard (STLport has been
replaced by direct use of the C++ STL in LibreOffice).

34
odk/README.md
View file

@ -1,27 +1,29 @@
Office development kit - implements the first step on the way to the LibreOffice SDK tarball.
# Office Development Kit (odk)
Part of the SDK; to build you need to add --enable-odk.
Office development kit (`odk`) - implements the first step on the way to the LibreOffice SDK
tarball.
Part of the SDK; to build you need to add `--enable-odk`.
Testing the examples:
=====================
## Testing the Examples:
* Go to instdir/sdk (Don't try directly in odk/)
* Go to `instdir/sdk` (Don't try directly in `odk/`)
* See <https://api.libreoffice.org/docs/install.html> how to set up the SDK.
** When asked about it during configuration, tell the SDK to do automatic
deployment of the example extensions that get built.
* When asked about it during configuration, tell the SDK to do automatic
deployment of the example extensions that get built.
* In a shell set up for SDK development, build (calling "make") and test
(following the instructions given at the end of each "make" invocation) each
of the SDK's examples/ sub-directories.
* In a shell set up for SDK development, build (calling `make`) and test
(following the instructions given at the end of each `make` invocation) each
of the SDK's `examples/` sub-directories.
** An example script to build (though not test) the various examples in batch
mode is
* An example script to build (though not test) the various examples in batch
mode is
find examples \( -type d -name nativelib -prune \) -o \
\( -name Makefile -a -print -a \( -execdir make \; -o -quit \) \)
`find examples \( -type d -name nativelib -prune \) -o \`
`\( -name Makefile -a -print -a \( -execdir make \; -o -quit \) \)`
(Note that one of the example extensions asks you to accept an example
license on stdin during deployment.)
(Note that one of the example extensions asks you to accept an example
license on stdin during deployment.)

24
offapi/README.md
View file

@ -1,19 +1,21 @@
Contains all of the IDL files except those in [[udkapi]]
# LibreOffice API IDL Files Except UDK API
Contains all of the IDL files except those in `udkapi`.
i.e. the interfaces that are specific to the LibreOffice application.
An artificial (?) separation.
The reference offapi/type_reference/offapi.idl and
udkapi/type_reference/udkapi.idl (formerly combined into a single
offapi/type_reference/types.rdb) are used to detect inadvertent incompatible
changes. They are plain-text .idl files (not strictly lexicographically sorted,
though, so they satisfy the .idl file requirements for no forward dependencies),
The reference `offapi/type_reference/offapi.idl` and
`udkapi/type_reference/udkapi.idl` (formerly combined into a single
`offapi/type_reference/types.rdb`) are used to detect inadvertent incompatible
changes. They are plain-text `.idl` files (not strictly lexicographically sorted,
though, so they satisfy the `.idl` file requirements for no forward dependencies),
so in cases where we deliberately /do/ become incompatible they can be modified
manually.
Old such cases of deliberately becoming incompatible are listed in
offapi/type_reference/typelibrary_history.txt, newer such cases are recorded in
the git logs of (now superseded) offapi/type_reference/types.rdb,
offapi/type_reference/offapi.rdb, and udkapi/type_reference/udkapi.rdb, new such
cases are recorded in the git logs of offapi/type_reference/offapi.idl and
udkapi/type_reference/udkapi.idl.
`offapi/type_reference/typelibrary_history.txt`, newer such cases are recorded in
the `git log`s of (now superseded) `offapi/type_reference/types.rdb`,
`offapi/type_reference/offapi.rdb`, and `udkapi/type_reference/udkapi.rdb`, new such
cases are recorded in the `git log`s of `offapi/type_reference/offapi.idl` and
`udkapi/type_reference/udkapi.idl`.

9
officecfg/README.md
View file

@ -1,11 +1,12 @@
The schema and default settings for the OpenOffice.org configuration database.
# Default Settings for LibreOffice
The schema and default settings for the LibreOffice configuration database.
If you change a file in this module, then a make postprocess is needed after make officecfg.
See also:
[[configmgr]]
See also: `configmgr`
AcceleratorKeyChecker.fodt in the util folder is a tool written in Basic that check menus for
`AcceleratorKeyChecker.fodt` in the `util` folder is a tool written in Basic that check menus for
entries that use the same accelerator key. The tool goes through the menus using the accessibility
api and checks the accelerator keys. For information on how to use the tool open the fodt file
in LibreOffice.

35
onlineupdate/README.md
View file

@ -1,25 +1,38 @@
# Online Update
Online update implementation based on Mozilla's MAR format + update mechanism
Parts of this code are copied from the mozilla repository, and adapted to
LibreOffice needs:
firefox/modules/libmar -> onlineupdate/source/libmar
firefox/toolkit/mozapps/update -> onlineupdate/source/update
`firefox/modules/libmar` -> `onlineupdate/source/libmar`
`firefox/toolkit/mozapps/update` -> `onlineupdate/source/update`
The source/service directory contains the code for the silent windows updater that avoids the repeated administrator check for an update.
The source/service directory contains the code for the silent windows updater that avoids the
repeated administrator check for an update.
== NOTE ==
The updater executable should not depend on any other dynamic library in the LibreOffice installation as we would need to copy that one also to a temporary directory during update. We can't update any library or executable that is currently in use. For the updater executable we solve this problem by copying the updater before using it to a temporary directory.
## Note
The updater executable should not depend on any other dynamic library in the LibreOffice
installation as we would need to copy that one also to a temporary directory during update. We can't
update any library or executable that is currently in use. For the updater executable we solve this
problem by copying the updater before using it to a temporary directory.
On Windows we use the system to provide us with a crypto library whereas on Linux we use NSS.
== Update procedure ==
## Update Procedure
The updater executable is run two times. In a first run, the current installation is copied to a "update" directory and the update is applied in this "update" directory. During the next run, a replacement request is executed. The replacement request removes the old installation directory and replaces it with the content of the "update" directory.
The updater executable is run two times. In a first run, the current installation is copied to an
`update` directory and the update is applied in this `update` directory. During the next run, a
replacement request is executed. The replacement request removes the old installation directory and
replaces it with the content of the `update` directory.
=== User profile in the installation directory ===
### User Profile in the Installation Directory
The archive based installations have the user profile by default inside of the installation directory. During the update process this causes some problems that need special handling in the updater.
The archive based installations have the user profile by default inside of the installation
directory. During the update process this causes some problems that need special handling in the
updater.
* The "update" directory is inside of the user profile resulting in recursive copying.
* During the replacement request the updater log is in the user profile, which changes location from the actual location to a backup location.
* The `update` directory is inside of the user profile resulting in recursive copying.
* During the replacement request the updater log is in the user profile, which changes location from
the actual location to a backup location.

11
oovbaapi/README.md
View file

@ -1,5 +1,8 @@
Module for OpenOffice - VisualBasic interoperability.
# Visual Basic Interoperability
See also:
[http://wiki.openoffice.org/wiki/VBA]
[http://wiki.openoffice.org/wiki/Oovbaapi]
Visual Basic interoperability module for LibreOffice
## See also
- <http://wiki.openoffice.org/wiki/VBA>
- <http://wiki.openoffice.org/wiki/Oovbaapi>

48
oox/README.md
View file

@ -1,15 +1,16 @@
# Office Open XML (ooxml) Support
Support for Office Open XML, the office XML-format designed by Microsoft.
== DrawingML Custom shapes and presets ==
## DrawingML Custom shapes and presets
Custom shapes are part of DrawingML and are different to binary ppt
and VML in older formats.
The import happens in oox/source/drawingml, where they are
The import happens in `oox/source/drawingml`, where they are
imported as LO's enhanced custom shape's. see
offapi/com/sun/star/drawing/CustomShape.idl and
offapi/com/sun/star/drawing/EnhancedCustomShape*.idl
Check CustomShapeProperties::pushToPropSet() and see
`offapi/com/sun/star/drawing/CustomShape.idl` and
`offapi/com/sun/star/drawing/EnhancedCustomShape*.idl`
Check `CustomShapeProperties::pushToPropSet()` and see
how custom shape properties are converted.
Preset shapes are custom shapes whose guides and handles
@ -120,8 +121,8 @@ example of drawingml custom shape (equal to star5 preset):
</pathLst>
we needed to extend our custom shapes for missing features and so 5
new segment commands were added. G command for arcto drawingml record
and H I J K commands for darken, darkenless, lighten, lightenless
new segment commands were added. `G` command for arcto drawingml record
and `H` `I` `J` `K` commands for darken, darkenless, lighten, lightenless
records. the commands are save into ODF in special namespace drawooo,
which is extension not yet in the standard. Thorsten suggested to put
it in such a namespace and keep original (incomplete) geometry for
@ -132,14 +133,14 @@ needed.
In order to convert preset shapes to LO's enhanced custom shape,
we need to load shape definition of preset shapes. The procedure
to convert the definition from OOXML spec for LO is documented
( also a script ) in oox/source/drawingml/customshapes/README.
The scripts in oox/source/drawingml/customshapes/ also generate pptx
(also a script) in `oox/source/drawingml/customshapes/README.md`.
The scripts in `oox/source/drawingml/customshapes/` also generate pptx
files for single presets and also for all presets
cshape-all.pptx. The cshape-all.pptx file is then loaded into Impress
`cshape-all.pptx`. The cshape-all.pptx file is then loaded into Impress
build with debug enabled in oox and the command line output contains
information. The generated definition is oox-drawingml-cs-presets.
information. The generated definition is `oox-drawingml-cs-presets`.
Check CustomShapeProperties::initializePresetDataMap() to see how
Check `CustomShapeProperties::initializePresetDataMap()` to see how
generated presets data are loaded into LO.
While importing presets, we prefix the name with "ooxml-" so
that we can detect it on export as save it again as preset.
@ -151,12 +152,12 @@ problem with these pptx as they cannot be imported into powerpoint,
but that can be fixed quickly. when fixed, we can use it to
test powerpoint odp export and see how complete it is regarding
custom shapes. OpenXML SDK tools might help when fixing
cshape-all.pptx
http://www.microsoft.com/en-us/download/details.aspx?id=30425
`cshape-all.pptx`
<http://www.microsoft.com/en-us/download/details.aspx?id=30425>
== Export ==
## Export
Here is how LO's enhanced custom shapes are exported:
* Shape name is ooxml-* - they are imported from ooxml, export as is.
* Shape name is `ooxml-*` - they are imported from ooxml, export as is.
* Denylist - ODF presets that has OOXML equivalent.
We convert adjustment values case by case. Microsoft Office
is rather strict about adjustment values, either none of them
@ -166,20 +167,19 @@ Here is how LO's enhanced custom shapes are exported:
so that default values suitable for the odf one need to be
provided.
* Allowlist - ODF presets that has OOXML equivalent but looks a bit
different, export them as PolyPolygon.
different, export them as `PolyPolygon`.
Check Andras Timar's presentation[1] and ShapeExport::WriteCustomShape()
Check Andras Timar's presentation[1] and `ShapeExport::WriteCustomShape()`
for further detail.
FUTURE WORK: because we have to make sure that all the roundtrips
## Future Works
Because we have to make sure that all the roundtrips
like PPTX --> ODP --> PPTX work correctly and doesn't lose data.
the only problematic part is probably saving custom shapes (ie. not
presets) to PPTX. that part of code predates work on custom shapes
and is unable to export general custom shapes yet. It will need a bit
of work as LO has more complex equations than DrawingML. other parts
of work as LO has more complex equations than `DrawingML`. other parts
should work OK, PPTX --> ODP should work and don't lose any
data. presets should already survive PPTX --> ODP --> PPTX roundtrip
[1]https://archive.fosdem.org/2016/schedule/event/drawingml/attachments/
slides/1184/export/events/attachments/drawingml/slides/1184/
andras_timar_fosdem_2016.pdf
[1] <https://archive.fosdem.org/2016/schedule/event/drawingml/attachments/slides/1184/export/events/attachments/drawingml/slides/1184/andras_timar_fosdem_2016.pdf>

2
opencl/README.md
View file

@ -1,3 +1,5 @@
# OpenCL Support
OpenCL-related code that is not specific to any particular
functionality OpenCL is used for. (Like formula group calculation in
Calc.)

6
osx/README.md
View file

@ -1,4 +1,6 @@
Just an Xcode project to make it easier to debug a running soffice
# Xcode Project for Debugging LibreOffice on macOS
Just an Xcode project to make it easier to debug a running `soffice`
instance on macOS. Not intended for other use. The Xcode project has
references to a fairly arbitrary bunch of source files from here and
there in LO that I have happened to been debugging in Xcode on macOS.
there in LibreOffice that I have happened to debug in Xcode on macOS.

4
package/README.md
View file

@ -1 +1,3 @@
Reading and writing ZIPs.
# ZIP Support
Reading and writing ZIP files.

4
pch/README.md
View file

@ -1,3 +1,5 @@
# Precompiled Headers
The purpose of this directory is to generate global precompiled headers
that can be used by any other gbuild library/executable.
that can be used by any other gbuild library / executable.
The libraries themselves are not used.

6
postprocess/README.md
View file

@ -1,6 +1,8 @@
# Postprocessing and Checking
Postprocessing and checking of files delivered by other modules.
This module has to be the last one built before creating install sets
in module 'instset_native'. Thus it ties together all the dependencies
in module `instset_native`. Thus it ties together all the dependencies
of all the other de-coupled modules. See the first line of
[[postprocess/prj/build.lst]] for that.
`postprocess/prj/build.lst` for that.

25
pyuno/README.md
View file

@ -1,19 +1,22 @@
# Python UNO Bindings
UNO bindings for the Python programming language.
To have much joy debugging python extensions you need to:
a) edit pythonloader.py in your install setting DEBUG=1 at the top
b) touch pyuno/source/module/pyuno_runtime.cxx and 'make debug=true' in pyuno
To have much joy debugging Python extensions you need to:
+ a) edit `pythonloader.py` in your install setting `DEBUG=1` at the top
+ b) `touch pyuno/source/module/pyuno_runtime.cxx` and `make debug=true` in `pyuno`
Then you'll start to see your exceptions on the console instead of them getting
lost at the UNO interface.
Python also comes with a gdb script
libpython$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)m.so.1.0-gdb.py
that is copied to instdir and will be auto-loaded by gdb;
it provides commands like "py-bt" to get a python-level backtrace,
and "py-print" to print python variables.
`libpython$(PYTHON_VERSION_MAJOR).$(PYTHON_VERSION_MINOR)m.so.1.0-gdb.py`
that is copied to `instdir` and will be auto-loaded by `gdb`;
it provides commands like `py-bt` to get a Python-level backtrace,
and `py-print` to print Python variables.
Another way to debug Python code is to use pdb: edit some initialization
function to insert "import pdb; pdb.set_trace()" (somewhere so that it is
executed early), then run soffice from a terminal and a command-line python
debugger will appear where you can set python-level breakpoints.
Another way to debug Python code is to use `pdb`: edit some initialization
function to insert `import pdb; pdb.set_trace()` (somewhere so that it is
executed early), then run `soffice` from a terminal and a command-line Python
debugger will appear where you can set Python-level breakpoints.

4
qadevOOo/README.md
View file

@ -1,3 +1,3 @@
Testsuite.
# Test Suite
You can import this as a project into Eclipse (select the qadevOOo folder).
You can import this as a project into Eclipse (select the `qadevOOo` folder).

29
readlicense_oo/README.md
View file

@ -1,33 +1,34 @@
# LibreOffice Licensing Blurb
Contains the stock libreoffice licensing blurb, as distributed in the install
directory, and also potentially at run-time.
Generating licence files
------------------------
## Generating Licence Files
License files are generated from a single source file (license/license.xml).
License files are generated from a single source file (`license/license.xml`).
Output file formats are plain text and html.
- The plain text and the html format is generated with xslt. There are two
separate xsl files for plain text and html.
- The plain text and the html format is generated with XSLT. There are two
separate XSL files for plain text and html.
Conditional text
----------------
## Conditional Text
The contents of the license file depends on the build configuration. Several
externals may or may not be shipped with LibreOffice. Therefore, we need to pass
information about build configuration to the xslt processor.
information about build configuration to the XSLT processor.
Variables used for conditional text:
- BUILD_TYPE: A space separated list of libraries/externals. If an external is
- `BUILD_TYPE`: A space separated list of libraries/externals. If an external is
present in that list, then the related license text should be included.
- MPL_SUBSET: If the variable is defined, then GPL and LGPL license text will not
- `MPL_SUBSET`: If the variable is defined, then GPL and LGPL license text will not
be included, because none of the built-in code need it.
- OS: The target platform. E.g. MSVC Runtime is packaged and used only on Windows.
- `OS`: The target platform. E.g. MSVC Runtime is packaged and used only on Windows.
- WITH_THEMES: A space separated list of icon sets that are used in the build.
- `WITH_THEMES`: A space separated list of icon sets that are used in the build.
Conditional text are surrounded by and extra `<div>` tag. The class attribute of
that `<div>` tag decides which parameter values are taken into consideration.
Conditional text are surrounded by and extra <div> tag. The class attribute of
that <div> tag decides which parameter values are taken into consideration.

4
registry/README.md
View file

@ -1,8 +1,8 @@
Registry reading, etc.
# Registry Reading, etc
This provides tools for dealing with the legacy binary types database
format, still in use by extensions and the core code. While the actual
binary file format is implemented by the [[store]] code, the wrapper
binary file format is implemented by the `store` code, the wrapper
that turns this into a type registry is implemented here.
While this code is primarily used in only two modes:

2
remotebridges/README.md
View file

@ -1 +1,3 @@
# Bridges to UNO Services
UNO services dealing with interprocess bridges.

6
reportbuilder/README.md
View file

@ -1,7 +1,9 @@
# Report Builder
Report Builder, or "new style reports", replacing legacy reports (in reportdesign).
Started as an extension called "Sun Report Builder" then "Oracle Report Builder"
[http://extensions.services.openoffice.org/project/reportdesign],
<https://extensions.openoffice.org/project/reportdesign>,
which got bundled with LibreOffice, then converted to an optionally installable
(but installed by default) part of LibreOffice proper.
Uses the Pentaho Reporting Flow Engine of Pentaho BI [http://www.pentaho.com/].
Uses the Pentaho Reporting Flow Engine of Pentaho BI <http://www.pentaho.com/>.

2
reportdesign/README.md
View file

@ -1 +1,3 @@
# Legacy Reports
Legacy Reports for LibreOffice Base

4
ridljar/README.md
View file

@ -1 +1,3 @@
Implements types for the Java Uno typesystem.
# Java UNO Types Generator
Implements types for the Java UNO typesystem.

6
sal/README.md
View file

@ -1,9 +1,11 @@
# System Abstraction Layer (SAL)
System abstraction layer; rtl, osl and sal
rtl:
`rtl`:
Platform independent strings
osl:
`osl`:
platform specific stuff, threads, dynamic loading, process, ipc, etc
Exports only C API and some inline-methods (only C++ API).

4
salhelper/README.md
View file

@ -1 +1,3 @@
C++ helpers to make use of sal easier.
# C++ Helpers for SAL
C++ helpers to make use of SAL easier.

10
sax/README.md
View file

@ -1,13 +1,15 @@
# UNO Services for SAX
UNO services for SAX parsing and C++ functions for XMLSchema-2 data types.
* source/expwrap:
* `source/expwrap`:
string-based SAX parser UNO service wrapping expat
* source/fastparser:
* `source/fastparser`:
multi-threaded token-based SAX parser UNO service wrapping libxml2
* source/tools:
* `source/tools`:
+ C++ wrapper for fast SAX parser
+ C++ XMLSchema-2 data type conversion helpers
Multi-threading in FastParser can be disabled for debugging purposes with:
SAX_DISABLE_THREADS=1 SAL_LOG="+INFO.sax.fastparser+WARN"
SAX_DISABLE_THREADS=1 SAL_LOG="+INFO.sax.fastparser+WARN"

22
sc/README.md
View file

@ -1,36 +1,38 @@
Spreadsheet application code.
# Spreadsheet Application Code
You can dump some information in a dbgutil build:
=== CTRL+SHIFT+F12 ===
## Shortcuts
### CTRL+SHIFT+F12
Dumps the column width of the first 20 columns.
=== CTRL+SHIFT+F11 ===
### CTRL+SHIFT+F11
Dumps the graphic objects and their position and size in pixel.
=== CTRL+SHIFT+F6 ===
### CTRL+SHIFT+F6
Dumps the SfxItemSet representing the cell properties' of the
current selection as a xml file. The file will be named dump.xml
=== The Cache Format ===
## The Cache Format
ScDocument::StoreTabToCache allows storing the content (not the formatting)
of a table to a binary cache format.
The format is column orientated which allows quick serialization of the table.
Header:
* Header:
* Number of Columns: 64 bit unsigned integer
Column:
* Column:
* Column Index: 64 bit unsigned integer
* Column Size: 64 bit unsigned integer
* For each cell type block a new ColumnBlock
ColumnBlock:
* ColumnBlock:
* Start Row: 64 bit unsigned integer
* Block Size: 64 bit unsigned integer
* Type: 8 bit unsigned integer
@ -42,8 +44,7 @@ ColumnBlock:
- 3 : formula
* for each cell: 32 bit signed string length followed by the formula in R1C1 notation as a string
=== Functions supporting Wildcards or Regular Expressions ===
## Functions Supporting Wildcards or Regular Expressions
As this comes up every now and then, and rather should be documented in an
extra list of the Help system, functions that support Wildcards or Regular
@ -82,3 +83,4 @@ https://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html
* AVERAGEIFS
* Text Functions
* SEARCH

9
scaddins/README.md
View file

@ -1,8 +1,9 @@
Extra functions for calc.
# Extra Functions for LibreOffice Calc
These provide UNO components that implement more exotic calc
These provide UNO components that implement more exotic LibreOffice Calc
functions. If you want to do the same, here can be a good place to
start.
See also:
[http://wiki.openoffice.org/wiki/Scaddins]
## See also
- <https://wiki.openoffice.org/wiki/Scaddins>

2
sccomp/README.md
View file

@ -1 +1,3 @@
# Linear Solver for LibreOffice Calc
The (linear) solver for LibreOffice Calc.

25
schema/README.md
View file

@ -1,20 +1,23 @@
schemas that can be used for validating ODF files
# Schemas for Validating ODF Files
Schemas that can be used for validating ODF files
subdirs:
- mathml2: W3C MathML 2.0 XML Schema (needed for Math embedded objects)
- odf1.0, odf1.1, odf1.2: official OASIS RelaxNG schemas
- odf1.3: current OASIS draft ODF 1.3 RelaxNG schema
- libreoffice: draft ODF schema, with additional LO extensions
The extension schema in "libreoffice/" is used by all unit tests if
--with-export-validation is given, which is the default.
- `mathml2`: W3C MathML 2.0 XML Schema (needed for Math embedded objects)
- `odf1.0`, `odf1.1`, `odf1.2`: official OASIS RelaxNG schemas
- `odf1.3`: current OASIS draft ODF 1.3 RelaxNG schema
- `libreoffice`: draft ODF schema, with additional LO extensions
The extension schema in `libreoffice/` is used by all unit tests if
`--with-export-validation` is given, which is the default.
Notably this means that if you add a new feature to the ODF filters and you add
the required unit test for the new feature, then most likely the test will fail
with a complaint from the validator; in this case the schema needs to be
updated to contain the new elements and attributes.
The extension schema uses the RelaxNG "include" feature to refer to the ODF
The extension schema uses the `RelaxNG` "`include`" feature to refer to the ODF
schema; this means that it only contains those parts of the schema that
actually need to be changed - this works well in many cases because the ODF
schema is quite well structured with many named patterns, but unfortunately
@ -22,7 +25,7 @@ there are a few places where that isn't the case and large chunks needed to be
copied to override them.
In the easy case, to add an attribute you just want to search for the
corresponding element, which will have a "foo-attlist" named pattern, and then
corresponding element, which will have a "`foo-attlist`" named pattern, and then
add another attribute like this:
<rng:define name="draw-enhanced-geometry-attlist" combine="interleave">
@ -42,6 +45,6 @@ Unfortunately it turned out that there are a lot of extensions already for
which no proposal exists [1], and in many cases not even an entry on the Wiki
[2], so clearly something like this extension schema is needed.
[1] git grep TODO schema/libreoffice
[2] https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions
[1] `git grep TODO schema/libreoffice`
[2] <https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions>

4
scp2/README.md
View file

@ -1,6 +1,6 @@
SCript Particle installer
# SCript Particle Installer
This contains code that describes which pieces of the project should
be packaged and installed - it is used to build among other things
a setup_osl.inf or .ins file - that is used by solenv/bin/make_installer.pl
a `setup_osl.inf` or `.ins` file - that is used by `solenv/bin/make_installer.pl`
to build the installation.

52
scripting/README.md
View file

@ -1,68 +1,70 @@
# Scripting Framework
This module provides the source code for the Scripting Framework.
For more information on the Scripting Framework, see the project web page:
[https://framework.openoffice.org/scripting/]
<https://framework.openoffice.org/scripting/>
This module uses astyle to keep consistent java coding style. Please run
./Format_java_code.sh
./Format_java_code.sh
before committing.
== Source Code Structure ==
## Source Code Structure
The following directories contain the source code currently used
by the Scripting Framework:
- source/provider
- `source/provider`
C++ source for the implementations of the com.sun.star.script.provider.*
and com.sun.star.script.browse.* UNO types. These types are used for
C++ source for the implementations of the `com.sun.star.script.provider.*`
and `com.sun.star.script.browse.*` UNO types. These types are used for
browsing and executing scripts.
- source/protocolhandler
- `source/protocolhandler`
C++ for a ProtocolHandler implementation that handles vnd.sun.star.script
C++ for a `ProtocolHandler` implementation that handles `vnd.sun.star.script`
URIs and dispatches them for execution to the Scripting Framework.
- source/basprov
- `source/basprov`
C++ implementation of the LanguageScriptProvider UNO service for Basic
C++ implementation of the `LanguageScriptProvider` UNO service for Basic
- source/dlgprov
- `source/dlgprov`
C++ implementation of the DialogProvider UNO service used for loading
C++ implementation of the `DialogProvider` UNO service used for loading
UNO dialogs from various languages
- source/pyprov
- `source/pyprov`
LanguageScriptProvider for Python
`LanguageScriptProvider` for Python
- java/com/sun/star/script/framework/provider
- `java/com/sun/star/script/framework/provider`
Implementation of an abstract base class ScriptProvider which provides
core methods for implementing Java based LanguageScriptProvider implementations
core methods for implementing Java based `LanguageScriptProvider` implementations
- java/com/sun/star/script/framework/provider/*
- `java/com/sun/star/script/framework/provider/*`
BeanShell, JavaScript and Java LanguageScriptProvider implementations
`BeanShell`, JavaScript and Java `LanguageScriptProvider` implementations
- java/com/sun/star/script/framework/browse/*
- `java/com/sun/star/script/framework/browse/*`
BrowseNode implementations for the Java based LanguageScriptProviders
`BrowseNode` implementations for the Java based `LanguageScriptProviders`
- java/com/sun/star/script/framework/io
- java/com/sun/star/script/framework/container
- `java/com/sun/star/script/framework/io`
- `java/com/sun/star/script/framework/container`
Classes for performing script IO
- examples
- `examples`
Example scripts in BeanShell, JavaScript, Java and Python
== Deprecated Code ==
## Deprecated Code
- java/org/openoffice/*
- `java/org/openoffice/*`
Support for developing scripts in IDEs such as NetBeans.

48
sd/README.md
View file

@ -1,43 +1,45 @@
# LibreOffice Impress / Draw Application
The core directory for the impress/draw applications.
Think of impress as a hack on top of draw.
sd module contains impress/draw specific code, non-shared UI and part
of ppt and pptx filter, few other filters too.
`sd` module contains impress/draw specific code, non-shared UI and part
of `ppt` and `pptx` filter, few other filters too.
the slideshow UI lives here as well, the slideshow engine is in
slideshow module though (including the 3D transitions engine
slideshow/source/engine/opengl).
`slideshow` module though (including the 3D transitions engine
`slideshow/source/engine/opengl`).
the most used filters are ODF's odp, binary ppt and OOXML's
pptx. their locations are listed below:
the most used filters are ODF's `odp`, binary ppt and OOXML's
`pptx`. their locations are listed below:
* odp import and export filters are in xmloff module (mostly xmloff/source/draw)
* `odp` import and export filters are in `xmloff` module (mostly `xmloff/source/draw`)
* ppt import is in sd/source/filter/ppt (big shared chunks are also in svx)
* ppt export is in sd/source/filter/eppt (big shared chunks are also in svx)
* `ppt` import is in `sd/source/filter/ppt` (big shared chunks are also in `svx`)
* `ppt` export is in `sd/source/filter/eppt` (big shared chunks are also in `svx`)
* pptx import is in oox/source/ppt (and uses a lot of
oox/source/drawingml and oox/source/*)
* pptx export is in sd/source/filter/eppt (mostly in pptx-* source
files) and shared part is in oox/source/export
* `pptx` import is in `oox/source/ppt` (and uses a lot of
`oox/source/drawingml` and `oox/source/*`)
* `pptx` export is in `sd/source/filter/eppt` (mostly in `pptx-*` source
files) and shared part is in `oox/source/export`
== PPTX export/import filters ==
## PPTX Export / Import Filters
PPTX export filter is split into 2 parts. Impress related part is in
sd/source/filter/eppt/pptx-* and the other part is in
oox/source/export/ because it contains mostly code related to
DrawingML, which is shared with writer and calc ooxml export.
`sd/source/filter/eppt/pptx-*` and the other part is in
`oox/source/export/` because it contains mostly code related to
`DrawingML`, which is shared with writer and calc ooxml export.
The export filter was written in 2009 IIRC and was not much extended
feature-wise lately.
FUTURE work: add custom shapes export (see below). enhance text
## Future Works
Add custom shapes export (see below). enhance text
output, we don't write text style for indentation levels now, need to
export a:lvl1pPr, a:lvl2pPr, ... elements.
export `a:lvl1pPr`, `a:lvl2pPr`, ... elements.
PPTX import was written by Sun/Oracle and then extended in LibreOffice
a lot during bug fixing. It is located in oox/source/ppt and
oox/source/drawingml. The areas with most bugs (at least until today)
`PPTX` import was written by Sun/Oracle and then extended in LibreOffice
a lot during bug fixing. It is located in `oox/source/ppt` and
`oox/source/drawingml`. The areas with most bugs (at least until today)
were shape placeholders and text style inheritance.

44
sdext/README.md
View file

@ -1,30 +1,30 @@
Extensions for the Impress and Draw applications.
# Extensions for the Impress and Draw Applications
source/pdfimport/ - PDF import
`source/pdfimport/` - PDF import
Uses an external poppler process to parse and handle PDF
import as draw shapes.
Uses an external poppler process to parse and handle PDF
import as draw shapes.
source/minimizer/ - Presentation Minimizer
`source/minimizer/` - Presentation Minimizer
Shrinks presentations by down-scaling images, and removing
extraneous eg. embedded OLE content.
Shrinks presentations by down-scaling images, and removing
extraneous eg. embedded OLE content.
source/presenter/ - Impress / Presenter Console.
`source/presenter/` - Impress / Presenter Console.
This couples to sd/ in rather strange ways. Its design is
heavily mangled by an attempt to use only UNO interfaces
which are highly inadequate. This leads to somewhat
ridiculous situations. Activating in response to
configuration keys (for example), and the 'XPresenterHelper'
interface inside sd/ used to create and manage windows.
This couples to `sd/` in rather strange ways. Its design is
heavily mangled by an attempt to use only UNO interfaces
which are highly inadequate. This leads to somewhat
ridiculous situations. Activating in response to
configuration keys (for example), and the `XPresenterHelper`
interface inside `sd/` used to create and manage windows.
The main screen uses a hardware-accelerated
canvas (e.g. cairo canvas), while the entire secondary screen
uses a VCL-canvas that is created in
sd::framework::FullScreenPane::CreateCanvas().
The main screen uses a hardware-accelerated
canvas (e.g. cairo canvas), while the entire secondary screen
uses a VCL-canvas that is created in
`sd::framework::FullScreenPane::CreateCanvas()`.
The secondary screen contains 3 "Panes" which each have
2 XWindows for the border area & the actual content,
and each content Pane is backed by a sd::presenter::PresenterCanvas
that wraps the FullScreenPane's canvas and does clipping.
The secondary screen contains 3 `Pane`s which each have
2 `XWindows` for the border area & the actual content,
and each content Pane is backed by a `sd::presenter::PresenterCanvas`
that wraps the `FullScreenPane`'s canvas and does clipping.

24
sfx2/README.md
View file

@ -1,28 +1,30 @@
SFX is the "old" framework, used for historical reasons.
# Legacy Framework
An attempt of documentation of this module is located in [git:sfx2/doc].
`SFX` is the "old" framework, used for historical reasons.
An attempt of documentation of this module is located in `git:sfx2/doc`.
It contains base classes for document model, view and controller, used
by "old" applications like sw, sc, sd (while "new" applications
by "old" applications like `sw`, `sc`, `sd` (while "new" applications
are based on the "new" UNO based framework in "framework").
The SFX framework is based on dispatching slots identified by integers
(SlotIDs) to SfxShells, and there is a dedicated IDL compiler (svidl)
involved that generates C++ slot headers from SDI files in modules' sdi/
(`SlotIDs`) to `SfxShells`, and there is a dedicated IDL compiler (`svidl`)
involved that generates C++ slot headers from SDI files in modules' `sdi/`
subdirectory.
Documentation about SFX dispatch, SDI etc.:
https://wiki.openoffice.org/wiki/Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2
<https://wiki.openoffice.org/wiki/Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2>
Document load/save code is maintained in [git:sfx2/source/doc/docfile.cxx]
SfxMedium class, which handles all the twisty load and save corner cases.
Document load/save code is maintained in `git:sfx2/source/doc/docfile.cxx`
`SfxMedium` class, which handles all the twisty load and save corner cases.
[git:sfx2/source/appl/sfxhelp.cxx] Start procedure for the online
`git:sfx2/source/appl/sfxhelp.cxx` Start procedure for the online
help viewer top level window; handling of help URL creation and
dispatch.
There are also some UNO services here that could really be implemented
anywhere, e.g. the DocumentProperties or DocumentMetadataAccess.
anywhere, e.g. the `DocumentProperties` or `DocumentMetadataAccess`.
Notable files:
sfx2/source/dialog/backingwindow.cxx Startcenter buttons and the corresponding event handler.
`sfx2/source/dialog/backingwindow.cxx` `Startcenter` buttons and the corresponding event handler.

3
shell/README.md
View file

@ -1 +1,2 @@
System helpers - launching URI, system integration, external mailer support etc.
# System Helpers
Launching URI, system integration, external mailer support etc.

29
slideshow/README.md
View file

@ -1,32 +1,33 @@
The Impress slideshow engine
# Impress Slideshow Engine
== 3D transitions ==
## 3D Transitions
The 3D transitions are slideshow transition engine using OpenGL and
are located in slideshow/source/engine/OGLTrans/. They were initially
are located in `slideshow/source/engine/OGLTrans/`. They were initially
written by GSOC student Shane.M.Mathews. Radek has later polished the
code a bit, added few new 3D transitions, added infrastructure for
vertex and fragment shaders. Wrote few transitions with fragment shader
too.
== Physics Animation Effects ==
## Physics Animation Effects
Physics animation effects are simulated by external 2d physics engine
library Box2D. They don't directly call Box2D functions but instead
library `Box2D`. They don't directly call `Box2D` functions but instead
use the wrapper in:
* slideshow/source/inc/box2dtools.hxx
* slideshow/source/engine/box2dtools.cxx
The wrapper has two corresponding classes to manage the Box2D world
and Box2D bodies.
* `slideshow/source/inc/box2dtools.hxx`
* `slideshow/source/engine/box2dtools.cxx`
When a physics animation starts, a Box2DWorld is initiated and
The wrapper has two corresponding classes to manage the `Box2D` world
and `Box2D` bodies.
When a physics animation starts, a `Box2DWorld` is initiated and
populated with every shape that is part of the foreground (which are
shapes that do not belong to the master slide and not a background
shape).
After creation until the end of the slide (not the whole slideshow)
the Box2D World isn't destroyed and reused. But the bodies that
the `Box2D` World isn't destroyed and reused. But the bodies that
represent the shapes in the slide get destroyed when there's a point
in time that there's no physics animation in progress. And recreated
when another physics animation starts.
@ -36,8 +37,8 @@ takes the role of stepping through the simulation.
If there are other animation effects that go in parallel which change
the shape position, rotation, or visibility - they also report the
change to Box2D World. These updates are collected in a queue in
Box2DWorld and processed before stepping through the simulation.
change to `Box2DWorld`. These updates are collected in a queue in
`Box2DWorld` and processed before stepping through the simulation.
To achieve convincing results these updates are performed by setting
the box2d body's linear velocity or angular velocity instead of
the `Box2D` body's linear velocity or angular velocity instead of
setting directly it's position or rotation.

Some files were not shown because too many files have changed in this diff Show more