The listfonts utility gets the details of all available fonts on the
system. It prints out the information, or stores it in a text file,
if a file name is passed to it as an argument.
An example invocation to store the information in a file named
fonts.txt is:
./bin/run listfonts fonts.txt
To get the correct font metrics, you actually have to get the font
metric from the system, and then set it as the current font of
OutputDevice, then get the font metric (which corrects a variety of
things like the orientation, line, height, slant, etc. - including
converting from logical coords to device coords).
The information is reported for each font family. On the top is the
family name, and then comes other details. Here is a report for an
example font:
FreeSans
Family type: swiss
Style name: Regular
Weight: normal
Italic: none
Pitch: variable
Width type: normal
Alignment: top
Charset: UCS2 (aka Unicode)
Symbol font? no
Ascent: 13
Descent: 3
Internal leading: 0
External leading: 2
Line height: 16
Slant: 0
Bullet offset: 0
Fullstop centered? yes
Orientation: 0 degrees
Quality: 18477
There is a -v (or --verbose) option that output font features.
Change-Id: Icfc4da96459bea47c4233a5509496566c04d460c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127365
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Drop Build prefix and settle on Lib and Exe prefixes. Also add a
note about the "else" part of the condition and fix offenders.
While at it, define COND_LIB_SAL_TEXTENC to be used by sal to
prevent diverting coditions in build and cxx code.
Change-Id: I944587ca1ccbe46b765d1a631a7214c8126fe951
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128136
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
And I should have tested gb_Helper_optionals_and. Inspecting the
generated token for comparison doesn't result in gb_[T1]_[T2],
as I expected. So first filter the token from BUILD_TYPE, then
filter-out the result from the input token. If true, then both
sets are equal == and.
Change-Id: I74a324f766331b30a0af9c9bfd7c927c1d21df53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128115
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Currently we don't destinguish between between extensions without
code, which couldn't be executed with DISABLE_DYNLOADING, and all
other extensions, like translations, dictionaries, etc., so there
is no need for a static unopkg.
Change-Id: I427a51b3174d074e467a582e808490a85e98e8eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128114
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Just don't test gtk3, so it's also not enabled. This way we can
also rename the kde install module to haiku on demand.
The kf5be1 is kept kde-only; no idea if that is intentional.
Change-Id: Id93b15fc6057a50da59efd655e1fc7d5f416c6de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127894
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Created a minimal vcl application inside vcl/workben in ~55 loc
in which creates a window and paints a simple text inside it.
One can run the application by invoking:
./bin/run minvcl
Change-Id: If648666ff25c4b66089a37c8d8164752663fa225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125124
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
... AKA DISABLE_DYNLOADING, except for oss-fuzz, which will be
converted to a cross build in a follow-up patch.
This includes skipping the static registry and help tooling and
aborts configure when the ODK is selected to be build.
Change-Id: Ifae32e91acf5e9ffa234d8f915ee459b197091fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127287
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This separates the drawinglayer core functionallity into a
separate library, to keep a strict separation what is backend
dependent and what is not. More strict separation can be done
at a later date.
This will make it possible to push part of drawinglayer
(part of processor2d) directly into VCL.
Change-Id: Ibc26580067e50bf20d7cdd37fa0e44eb10200878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127286
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
the need for this is gone now the transition from src to ui
is completed. I certainly don't use this anymore.
Change-Id: I5bf9c8bc4f00152977091f466c2e808b824acb44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126925
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
this is intended for use for bootstrapping the process
of conversion of the .src to .ui and isn't useful
to have in a normal install
Change-Id: I88066bb086ca58a56c2adc7ef5a96b03b670f086
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126924
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
... and introduce solenv/gbuild/Conditions.mk
The Conditions.mk is included just after the Helpers.mk, which
should make its content available basically everywhere.
Change-Id: Ie4498e12b3d0f676ed0c9abf4b3bb4899d6a1c03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126787
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Removed in commit 2270a58d7b
("Move GIF writer from filter module into VCL"), but accidently
re-added (at least to the install set in commit
ed583bf8d5 ("gbuild: introduce
plugin + loader concepts").
Change-Id: I6ed9ab5aeab6a2ecc8dd169f0d8ddfb42b334b47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126347
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Unfortunatly we cannot add --disable-scripting to
sub_conf_defaults, because Java currently has no
equivalent to the PYTHON_FOR_BUILD setting.
Change-Id: I89938a17307a363f5de808200914940503312829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126186
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This introduces two concepts: a plugin and its loader (library)
LO currrently has dependency cycles for some libraries. There is
scui, which depends on sc, while sc dlopen's scui. There are the
various vclplug_*, i18npool plugins, filters/gie, acc, etc.
Usually these plugins link to their loader library, because they
use its symbols. But as a result there is no sensible way to
express the runtime dependency of loaders on the plugins.
In GNU libtool plugins are called modules and they are implemented
in an IMHO more sensible way by allowing missing symbols at link
time. This way you can have a dependency from the loader library
to its plugins, as the plugins don't depend on the loader, but you
lose the link time detection of missing symbols.
While this is in theory possible in LO too, LO currently has
plugins, like acc (accessibility), loaded by tk (toolkit), which
depends on svt (svtools), which itself depends on tk, so dropping
the tk dependency for acc on its own doesn't help :-(
And while the dependency of the plugins on their loader is fine
for the shared / DYNLOADING build, for the "static" builds you
must (somehow) link the plugins into the executables.
I also codeified a few rules into the build system along with it:
* just plugins are allowed to depend / link other plugins
* plugins aren't allowed to be linked into the merge lib
* plugin loaders are "limited" to libraries
At the high level, this is implemented via new gbuild calls:
* gb_Library_set_plugin_for,lib,loader: declare a library to be a
plugin of a loader library and add a dependeny from the plugin
library to the loader library
* gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding
the library dependeny
* gb_Helper_register_plugins_for_install: "plugin" replacement for
gb_Helper_register_libraries_for_install to implement some
additional checks in the build system
In the end this patch just adds a bit syntactic sugar and nothing
changes for any build.
Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This is a hack, because make has no way to serialize processing
of a target (just .NOTPARALLEL for the whole Makefile).
It uses the lockfile tool / liblockfile 1.17. Since that polls
the file, I adjusted the poll timeout to 5s max, because I found
the 60s wait much too long. Guess even 1s would be ok...
Since it's just a small build tool, I simply copied and patched
its source, instead of creating an external project. And there
is --with-system-lockfile=... to use an external binary instead.
Change-Id: I16bc4579a273dcf1aac811ae4723ca325a0b9eba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126152
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The SFWidgets library is intended to host the Toolbar,
ToolbarControl (both future) and PopupMenu services.
A popup menu is usually triggered by a mouse action
(typically a right-click) on a dialog, a form, or one of their controls.
In these cases the menu will be displayed below the clicked area.
When triggered by other events, including in the normal flow
of a user script, the script should provide the coordinates
of the topleft edge of the menu versus the actual component.
The menu is described from top to bottom with next methods:
AddItem()
AddCheckBox()
AddRadioButton()
Example:
.AddCheckBox("View>Toolbars>Dialog")
.AddCheckBox("View>Toolbars>Find", Status := True)
.AddCheckBox("View>Status Bar", Status := True)
.AddItem("View>Full Screen", Name := "FULLSCREEN")
The SubmenuCharacter (Default = ">") is modifiable.
Each menu item receives a numeric and a string identifier.
The execute() method returns the item selected by the user.
The service is available both from Basic and Python user scripts.
The commit includes the review of build files to include
the new library and the new modules.
Change-Id: I2940be25313cc8fff7b337766edd348b04a20584
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123654
Tested-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
This adds a new "qt6" VCL plugin based on Qt 6.
Building the plugin is enabled by autogen option '--enable-qt6'
(and optionally setting 'QT6DIR' as needed).
Use the 'SAL_USE_VCLPLUGIN=qt6' environment variable
before running LO to select this VCL plugin.
Taking qt6 into account at all relevant places certainly
still requires follow-up changes, but
this builds and runs with a self-compiled
qtbase from the 'dev' git branch as of commit
3ce0672143d2eb3c3809f82998a4d71c5800d77a.
I didn't see anything obviously broken
in a quick run, but didn't test much.
This reuses and shares the qt5 VCL plugin code;
the qt6 headers and sources for now just
'#include' the qt5 ones.
Version checks are used for the code places that
need different handling to be built against Qt 6.
The build system parts in this commit were mostly done by
copying the qt5 equivalents, then adapting as needed.
Some notes on things I came across while porting
to qt6:
1) At least in my self-compiled Qt versions,
'moc' (the meta-object compiler) is located
in the 'libexec' subdirectory in 'QT6DIR', while the
Qt 5 equivalent is located in the "bin" subdirectory
of 'QT5DIR', so the configure.ac check uses the former.
2) moc does not process classes from the included headers.
Since the headers in 'vcl/inc/qt6' just '#include' the ones
from 'vcl/inc/qt5', running moc on the qt6 headers doesn't work,
so moc is currently run on the qt5 headers for qt6 as well
(s. 'vcl/CustomTarget_qt6_moc.mk').
That will have to be adapted in case the qt6 VCL plugin
uses "own" headers instead of just including the qt5 ones
at some point.
3) QX11Extras has been removed from Qt 6.
[1] says:
> Changes to Qt X11 Extras
>
> The QX11Info class has been removed.
>
> Clients that still rely on the functionality can include the private
> header <QtGui/private/qtx11extras_p.h> as a stopgap solution. To enable
> private headers use QT += core-private with qmake, or add a project
> dependency to Qt::CorePrivate with CMake.
I didn't take any closer look, just dropped the use of
QtX11Extras for qt6 for now.
4) XCB_ICCCM is no longer needed.
It is only used in qt5 to workaround a Qt bug fixed in Qt 5.12, s.
commit fe2baf9e84
Author: Jan-Marek Glogowski <jan-marek.glogowski@extern.cib.de>
Date: Tue Dec 3 08:32:58 2019 +0100
Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUP
5) X11-specific code is still used for key modifier handling.
Therefore, still check for the XCB headers when 'USING_X11'
is set in configure.ac, and use a 'QT6_USING_X11' define
(as qt5 uses 'QT5_USING_X11').
6) There's currently no Qt 6 video sink for GStreamer.
As of today, qt-gstreamer is unmaintained and there is no Qt 6 version.
The project's README [2] says:
> 0. Maintenance Notice
> ---------------------
>
> This code is unmaintained. You can use it at your own risk.
>
> If you want to integrate video display in your QML-based UI,
> you should consider using 'qmlglsink', from gst-plugins-good.
> This is a well supported video sink that uses the generic
> gstreamer-gl stack and is in many ways superior to 'qtquick2videosink'
> that is provided by qt-gstreamer. You can use this code as an example:
> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/qt/qmlsink
>
> If you are not interested in using QML in your UI, then you
> may use one of the other elements provided by this module
> (see below). If you do that, it would be helpful to let us
> know that this code is still useful to you. We may consider
> adding these elements in one of the core gstreamer modules.
>
> If you are here for the Qt-style bindings, I'm sorry to disappoint you.
> The alternative is to use the C API, or the GStreamermm C++ API.
> Qt-style bindings are cool, but unfortunately they are very hard
> to maintain because they are written by hand. If you are interested
> in continuing this project, you are welcome to implement a
> generator for them, probably based on GObject-Introspection.
> I am happy to provide directions if you want to pursue such a thing.
Therefore, the Qt video sink handling is qt5-only and the
corresponding handling for GOBJECT (used for the GStreamer
video sink handling) was not taken over for qt6.
This presumably means that video playback in Impress presentations
does not work when using qt6 with they Qt Wayland plugin,
s. tdf#125219 for the corresponding bug for qt5/kf5.
(I did not build the qtwayland module to actually test this, though.
Video playback with the Qt xcb plugin in a Wayland session works.)
[1] https://doc-snapshots.qt.io/qt6-dev/extras-changes-qt6.html
[2] https://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/README
Change-Id: Ib105ccfb2c3630ec5d5403793a3cd9ba31d85bdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122808
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This patch includes:
* A README.help.md as a general documentation for the different
help types, the LO code and help-related build options.
* Adds --disable-xmlhelp for removing the xmlhelp support from the
build. Disable for iOS, Android and Emscripten. This was partly
included in HAVE_FEATURE_DESKTOP before.
* Rename WITH_HELP define to WITH_HELPPACKS, which reflects the
actual usage AFAIK.
* Depend --with-omindex on --with-help=online and don't override
the --with-help setting. Error out on conflicting options.
* Depend --with-helppack-integration on build help variants, which
actually result in help packs.
Kind of reverts commit 2c38ea6d16
("Building without --with-help is not supposed to disable help
functionality").
Change-Id: Ie4cb73905b3ed94e991d9f1bd75cfbd6de9da385
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116222
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...which appears to be the only code that exercises osl's socket (rather than
named pipe) connections, so lets have that available at least for manual
execution.
Addresses various compiler and loplugin warnings, and extends a wait time to
more reliably have the MyThread instance already accept when the second accept
(on the main thread) is done.
Change-Id: I761d747b08ab45f1ac03dad8b4197fae63228e16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116103
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- align with most of the rest of config_host
- rename DISABLE_OPENSSL to ENABLE_OPENSSL
- make this configurable
Change-Id: Ic3b41fcdda38db66134939f12265e0da24833d60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114564
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
The Windows platform is called Arm64. But now that the ID for Mac
is also going to be renamed from arm64 to aarch64, this get's rid
of the arm64 as the UNO identifier and user in gbuild, just like
on all other Arm64 platforms.
Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The iOS system German dictionary is not good for Swiss German. (And it
doesn't even claim to be, it says it is for de_DE.) The system German
dictionary accepts 'ß' but that is not used in Swiss German, 'ss' is
always used instead.
Build the spell library for iOS, too, and don't assume that the system
de_DE dictionary would be usable for de_CH and de_LI. Copy those
dictionaries for inclusion in the iOS app bundle.
Change-Id: I0f8020812221024756c792bddc16a707de35b827
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112603
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112635
Annoyingly the packinfo_*.txt don't support conditionals but we can
work-around that with a little duplication.
Change-Id: Id00a6831effcc63a917fc21d2cd201474fdb559d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109569
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
And add the missing dependency of Executable_gengal on
Package_svx_gengal, so the actual executable script is
created in instdir_for_build for the cross-toolset.
Change-Id: I98ea1d58273c871f0a3b804a93970eedfb7f8908
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108108
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/
Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows-
specific unowinreg.dll in generated jars (so that those jars, when distributed
to a Windows environment, would find a LO installation by inspecting the Windows
registry). That unowinreg.dll was originally built as a 32-bit DLL (though when
building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For
non-Windows LO builds, it could either be built locally with a MinGW toolchain
(--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org.
However, that had various issues:
For one, unowinreg.dll was not necessarily available in a distributed jar as a
64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a
jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have
worked. But practically, those URE jars in turn require native DLLs, which
would then not have been available as 32-bit DLLs for use in the 32-bit JRE.)
For another, at least the unowinreg.dll resulting from --enable-build-unowinreg
on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would
generally not have been available in a target Windows environment.
There appears to be no pure Java way to read the Windows registry, but instead
of using a native code DLL for that, it appears to work just as well to call out
to reg.exe and parse its output.
This removes the --enable-build-unowinreg and --with-mingw-cross-compiler
configuration options. (The sole use of the MinGW toolchain in LO was for
building unowinreg.dll.)
Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
<https://lists.freedesktop.org/archives/libreoffice/2020-October/086169.html>
"Re: Is Executable_libtest still useful?":
>> so I wonder whether that program is actually still maintained and used by
>> anybody. (At least the last dozen or so changes to smoketest/libtest.cxx
>> were of the generic loplugin/typos/tools::Long etc. kind, and we could spare
>> ourselves future such work if we removed the file should it indeed be dead
>> code.)
>
> I think this can be removed. https://gitlab.com/ojwb/lloconv does the
> same and it seems to be maintained.
Change-Id: I039e161ecf4904210e246e389cf4ba85124a66fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104803
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* New dialog to pick and apply one of the UI variants
* Tip-of-the-Day enhanced to execute UNO commands in order
to advertise the UI chooser on first start
Change-Id: I5e5c4a8e0fb11d11bafc99cc37b7ec244a993781
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99957
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
I didn't change odk/util/check.pl to handle the currently missing
climaker. I hope this problem will eventually be fixed before
anybody really considers developing with LO ODK on Arm64...
Change-Id: Icc070bde77e73362646d62401410277a85d3d697
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103879
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Since Microsoft follows the general ARM64 ABI calling conventions,
and the SEH exception handling is the same, this result is a mixed
port of the gcc3_linux_aarch64 bridge and the refactored x86-64
exception handling.
I have no idea, if the complicated 32-bit handling in RaiseInfo()
is needed, as the ARM64 trampolines definitly use 64-bit code.
But since this is the first working version, I currently don't
mind much ;-)
There is definitly more potential for refactoring in the whole
bridges directory...
Change-Id: I9782a2e99c0231cdd1286af156ad312229eccf39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103642
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The code is just used in vcl from LO's POV.
This way we can drop the dtrans directory and get rid of yet an
other library.
Change-Id: Id77568e63a6fef4af30b49e035a9d76211b127a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103210
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
There is nothing abstract about either the clipboard or data
transfer code in that directory and it's just used on Windows.
All other backends implement this code in VCL, so this moves
almost all code, except for the common MimeContentTypeFactory,
into the vcl Windows backend / vclplug_win.
This also drops four DLLs: sysdtrans, dnd, dtrans and ftransl.
Change-Id: I7018f50768bf221447b40487cc1f8a8586da33c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103209
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
I know the platform can emulate x86 code, but have no idea, if
this would include x86 TWAIN32 drivers, so disable the build
for now.
Change-Id: I22cb2ab81ade9f91097586f382cdd4855e27d827
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102955
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The current .NET 5.0 Arm64 preview doesn't have a mscoree.lib,
so linking the climaker isn't possible.
Change-Id: Ibbac88aa465a9ca2eb8fb0efaad91d20f358229b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102858
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Chris Sherlock