Lots of tests were following the antipattern of deleting a pointer
after the last QVERIFY() or QCOMPARE(), which leads to the pointer
being leaked on failure. Use QScopedPointer consistently (it was
already in use patchily).
That changed one mis-use of QPointer (that was only checked for
non-null immediately on creation, never referenced later, so being
cleared on deletion wasn't relevant; and thus needed an overt delete,
that QScopedPointer made redundant); but another appears to be
deliberate, so documented that as such (to the best of my
understanding, gc is meant to pick it up).
This mostly arose with component.create() results, most of which were
checked, albeit in inconsistent ways. Always check these before
dereferencing, and use the same form for the check in all cases: use
QScopedPointer's in-built cast-to-bool rather than !isNull(); and
report the component.errorString(), using QVERIFY2(), on failure.
In many cases the return from component.create() is passed through a
qobject_cast<> before use; in principle, this could result in null
even though create() returned a non-null pointer. Convert those to
hold the return from create() in the QScopedPointer<> and cast its
data() to get a plain pointer for subsequent use.
Split assorted lines that got long (or longer) as a result.
Removed a fatuous empty constructor.
Change-Id: I88abba9e7ea72e30c92a11a5af5f17486f07f847
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This applies the logic from 7cb6dce1f3 to
non-QQmlAbstractBinding bindings, too.
The logic to detect whether a binding has no dependencies has consider
the QPropertyBindingPrivate's dependency observer count.
In addition, change the existing detection logic to remove properties
without a context, too. The original logic probably wanted to guard
against accessing binding->context()->unresolvedNames when context was
nullptr; however, the check should have tested "context ->
unresolvedNames", not "context and unresolvedNames". And after the
refactoring which introduced hasUnresolvedNames() as a function, the
context check became completely superfluous.
Fixes: QTBUG-92996
Change-Id: Ia3bc39e184f431210b3bb2d38154acf820525e98
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
To be in line with the behavior of the old bindings, we have to call
reset, even when the binding was undefined before.
Add a test which checks this behavior for both new and old types of
properties. Amends d64e7c9c6c.
Task-number: QTBUG-91001
Pick-to: 6.1
Change-Id: I1067a2fd56d5b7587281a9262e9bd389c825e587
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Besides API changes, we need to
- adjust QQmlBind to unlink the binding properly (that probably was
broken already before, but did not cause issues so far, as the old
binding would not have been evaluated without a read access) and
- skip tests in tst_qmlcompiler_manual, as the bindings are executed
before the engine is correctly set.
Change-Id: I97b0ac32b428c1a033664fe8593effadb69cd348
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This change implements optional chaining (https://github.com/tc39/proposal-optional-chaining) by adding a new type of optional lookup with an offset to the end of a chain.
If `undefined` or `null` is encountered during an access marked as optional, we jump to that end offset.
Features:
- Full support for all kinds of optional chain
- With some codegen overhead but zero overhead during normal non-optional FieldMemberExpression resolution
- Properly retains this contexts and does not need to resolve anything twice (this has been an issue previously)
- No extra AST structures, just flags for existing ones
[ChangeLog][QtQml] Added support for optional chaining (https://github.com/tc39/proposal-optional-chaining)
Fixes: QTBUG-77926
Change-Id: I9a41cdc4ca272066c79c72b9b22206498a546843
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
90be89d771 changed the connection logic to
actually pass the receiver to connect in order to fix disconnect
cleanup. However, we omitted to change QObjectSlotDispatcher::impl
accordingly. The previous logic was:
- store the index of the signal in signalIndex
- In impl, in the call case, we would get passed the emitting object
(sic!) as the receiver parameter. Then we would use the object and the
signal index to obtain the QMetaMethod.
- From the QMetaMethod, we could get the signal's number of parameters.
After the aforementioned change, that does not work anymore: The
receiver is now the actual receiver of the signal, thus we get the wrong
method, and potentially the wrong number of parameters.
To fix this, we now store the complete QMetaMethod of the signal.
Pick-to: 6.1
Change-Id: I868c51edf24a61d14eaf958ed7942da27f54a5c3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This way, we can avoid the costly id to metatype lookup in case where we
actually need the full metatype.
Task-number: QTBUG-88766
Change-Id: Ibe29b323007f00d2f8d1807fb9b64f9a8f87e807
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
We either have pre-populated arguments and thisObject, then we can just
use them and keep them const. Or, we want to allocate and populate the
arguments and the thisObject. Then, do allocate them in a separate
object, and transform that into JSCallData afterwards if necessary.
Furthermore, avoid alloc(0) as that just returns the current stack top.
Writing to it will clobber other data. Rather, just use nullptr and
crash if it's written to.
Also, remove the useless operator-> from JSCallData. That one just
confuses the reader.
Change-Id: I8310911fcfe005b05a07b78fcb3791d991a0c2ce
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Bindings are allowed to toggle between a defined state, and undefined
which calls the property's reset function. Calls to the reset function
must not remove the binding, even when they write to the property.
To support this, we put the binding in a special undefined state, in
which it is still active (and installed on the property), but does not
actually provide its evaluated value to the property. Then, when the
binding later becomes defined again, the binding leaves its undefined
state and works normally again.
Notes:
- Calling the reset function during binding evaluation could have all
kinds of unwelcome side-effects. We therefore have to suspend binding
evaluation before the reset call (and restore that state afterwards).
- QObjectCompatProperty expects that we write the current value into the
propertyDataPtr. If we do not do this, it will overwrite the current
value with the default constructed value of its property. Arguably, we
should change the API so that we communicate that nothing has changed;
but for now, we have to live with that limitation and read the
current value and write it back again.
- We currently do not handle the case correctly where a non-resettable
property implemented via QObjectCompatProperty gets assigned undefined
in a binding. Such a binding is likely unintentional (as the undefined
assignment only creates a warning), and thus less of a priority.
Nevertheless, a test marked with QEXPECT_FAIL is added for it.
Fixes: QTBUG-91001
Change-Id: I7ecaa6c8dc1a1f1b33e67b1af65f552c4ca6ffb1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Previously HeapObject::GeneratorObject utilized a ValueArray member to store stack information.
As we rely on all HeapObject members to have a constant size in order for QV4Table::inlinePropertyOffset
to remain accurate, this lead to a memory conflict when a user defined his own property on the Generator.
Please do not use ValueArray for any types that are user accessible or that you intend to add properties to.
Now the stack information is stored into ArrayObjects instead which circumvents the issue.
Fixes: QTBUG-91491
Pick-to: 5.15 6.0 6.1
Change-Id: Id6f638bf36a3ae3c9320ac99e67214c48dc81226
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
[ChangeLog][QML][Important Behavior Changes] If a QObject pointer is
passed to the QML engine and subsequently frozen with Object.freeze,
modifying its QObject properties now fails and throws a TypeError. The
TypeError is thrown even in non-strict mode.
[ChangeLog][QML] It is now possible to pass const QObject derived
pointers to QML in properties, and to call Q_INVOKABLE functions which
take such pointers as arguments. If the QML engine receives such a
pointer, it is treated as if the object was frozen.
Fixes: QTBUG-82354
Change-Id: Ib0dbcdfb2370654505936c3cf391d87dd2c9677b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
A function created by Qt.binding should lead to the binding being set
(and replacing any previously existing binding). This was not the case
for bindable properties so far. For those, we would have kept any
existing C++ or QQmlPropertyBinding binding, and instead created a brand
new QML binding which would have been set in addition.
This patch also introduces a new class,
QQmlPropertyBindingJSForBoundFunction, which is used to handle the case
where the binding function is not a simple function, but has its
parameters bound instead.
Change-Id: Ia1417162b9822efb3f17ca4a6ecc02f959392927
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The "in" operator may throw an exception.
Change-Id: I7d0b6e2212ac6ec237fbf14719349f8e23810028
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This change ensures that bindings created in QML between new-style
properties contain information about which property caused the loop. To
do this, we store additional information about the property involved to
retrieve its name and position at a later point. We print the warning in
case we detect a binding loop in evaluate, and also set the error
reporting callback correctly, so that the condition can be reported when
the loop is detected in another part of the binding evaluation.
In addition, we do not only set the QPropertyBinding's error member when
JS evaluation results in an error, but also print the warning with
qmlWarning.
Fixes: QTBUG-87733
Change-Id: Idb25237d1f57355ca31189e6bf2a918430b3a810
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Old API assumes sender == receiver, which results in wrong handling of
connections when receiver is deleted: connection is not removed or
notified elsehow as it's not really tied to a valid receiver
Task-number: QTBUG-86368
Pick-to: 5.15 6.0
Change-Id: I0f3115f1b0f26cf353752ba2b8fd88e0f3bdd388
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We special case writing functions to properties, only allowing assigning
them to var properties and QJSValue properties.
This would however break when aliases are involved. This commit fixes
the issue by resolving the alias, and then checking and writing to the
resolved property.
Fixes: QTBUG-90373
Pick-to: 5.15 6.0
Change-Id: Ia09ebe92feeaf8359c99ff9aeadc676b9fcfaa07
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If the target of a proxy was extensible, we did not set the
iteratorTarget to its correct value, and thus the ForInIteratorObject
would not be usable.
Pick-to: 6.0 5.15
Fixes: QTBUG-86323
Change-Id: Id1924ac4087bab38c006b8eba92b619b79d36b7a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We set QProperty bindings up in the wrong way: Parent components would
overwrite their child component's binding. This patch reverses the
order, fixing the bug.
Task-number: QTBUG-87153
Pick-to: 6.0
Change-Id: I3e90d1d14a41a7c5c337745f1453484d360a3979
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Property pointer p needs to be checked for nullptr value in
QV4::ProxyObject::virtualGetOwnProperty(). This can happen when calling
hasOwnProperty() or propertyIsEnumerable().
Fixes: QTBUG-88786
Pick-to: 6.0 5.15
Change-Id: I43da58fed4d8656f9187213f7317f17398739e34
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Quite obviously, the Qt object is a singleton, extended with a
namespace, backed by a member of the JavaScript global object.
Defining all the methods as JavaScript functions is unnecessary and
duplicates the general type transformation code. Also, it makes it
hard to use those same methods from a C++ context as we cannot
properly set up the arguments outside the JS engine.
Rewriting the Qt object reveals some deficiencies in the old
implementation that we need to fix now:
1. The enums of the Qt type were listed as properties of the Qt object,
which means you could iterate them with a for..in loop in in JavaScript.
This is just wrong. Enums are not properties. This functionality
is deleted and the test adapted to check for each enum value separately.
The commit message for the change that introduced the iterability
already mentioned that the author had failed to find any occurrence of
this in the real world.
2. Parsing time objects from strings was done by parsing the string as a
date/time and then picking the time from that. We still support that for
now, but output a (categorized) warning. Parsing the time directly is
preferred where possible.
3. Previously you could create (invalid) dates and times from various
kinds of QML types, like int and color. This does not work anymore as we
now validate the types before calling the functions.
4. Passing more arguments to a function than the function accepted was
unconditionally ignored before. Now, a Q_CLASSINFO on the surrounding
class can specify that the arguments should be checked, in which case a
JavaScript error is thrown if too many arguments are passed. In order
for this to work correctly we also have to ignore JS undefined values as
trailing arguments for overload resolution. This way, if a method
matching the defined arguments exists, it will be preferred over a
method that matches the full argument count, but possibly cannot accept
undefined as parameter.
Consequently a number of error messages change, which is reflected in
the qqmlqt test.
[ChangeLog][QtQMl][Important Behavior Changes] You can not iterate the
enumerations of the Qt object in JavaScript anymore. This does not work
with any other enumeration type either. You can of course still access
them by name, for example as Qt.LeftButton or similar.
[ChangeLog][QtQMl][Important Behavior Changes] The time formatting
functions of the Qt object in QML now allow you to pass an actual time
string, rather than a date/time string as argument. Passing a date/time
string results in a warning now.
[ChangeLog][QtQml][Important Behavior Changes] Functions in the Qt
object for formatting date and time will now throw a JavaScript error
when presented with a value of an incompatible type, such as int or
color.
[ChangeLog][QtQml][Important Behavior Changes] The Qt.resolvedUrl()
function now returns a URL rather than a string. This follows the
documentation.
[ChangeLog][QtQml][Important Behavior Changes] The GlobalColor enum of
the Qt namespace is not exposed to QML anymore. It did not make any
sense before as the enum values could not be used as colors.
Change-Id: I7fc2f24377eb2fde8f63a1ffac5548d652de7b12
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
A destruction handler can cause a new object to be allocated during
garbage collection. Depending on where in the heap the object ends up,
it may be found during the sweep pass. As the mark pass had no chance to
mark the object, we need to set the mark bit right at allocation time in
this case.
Change-Id: Ie43eeb548e78bd375b001b3a6bb4ef6596f91980
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
A QV4Sequence can be converted back to its underlying container; we
therefore should give the conversion of QV4Sequence to container a high
score if metaTypeForSequence and the target metatype agree.
This has a larger effect in Qt 6 than in Qt 5, as we now can have new
sequence types for any (QMeta)Container.
Fixes: QTBUG-87616
Change-Id: I2bf02ebadbf9b707719d09edaf14b112eb2caf4f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Replace foreach with ranged for; don't name unused function parameters.
Change-Id: If0d9138261567edb14b72791799c6da1b16b5a5b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
Change from the QVariant enum to the QMetaType enum and prefer typeId
over userType where possible
Change-Id: Ic89c55978d46cc23d23b8e9c82c475c0c220fae3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This fixes a regression from Qt 5 to Qt 6, because QDateTime is now
apparently more strict in its parsing of RFC2822Date. The string in the
test-case is not valid according to that spec, but JS engines like V8
still accept it, and so did we in Qt 5.
Fixes: QTBUG-87610
Change-Id: I2c6eb2087e4845b04fa0dc4f7aa9a229b3428a43
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
With this change, an alias of a bindable property is also bindable, and
shares its bindable interface with the target.
Moreover, the logic in QQmlTypeCompiler is adjusted so that a change
handler of an alias uses the bindable interface if possible, instead of
connecting to the alias' change signal. That would never be emitted if
the target is a QProperty without a notify signal.
Alias properties still have a change signal, but those never get
emitted.
Change-Id: I857dfdbe51048a2b604ad632982e7f4adac6b907
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If we have a binding containing QProperties, and the binding target is
an old style binding, still we have to trigger an update if any of the
captured properties changes. We cannot reuse the
QQmlJavaScriptExpressionGuards as those depend on Qt's signals, and a
QProperty is not associated with a change signal in the general case.
Therefore, we introduce a new list of QPropertyChangeHandler, which when
triggered cause a reevaluation of the binding.
As an optimization, we skip the whole capturing process for
QQmlPropertyBinding, as that one already takes care of updating itself.
Reverts 845bbb99a4 (because skipping the
capture is only possible when _both_ the bindee and the property in the
binding are QProperty based.)
Change-Id: Iafed2a41dcd708bcc33912ce810d803949379c63
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Replace more QLibaryInfo::location with QLibraryInfo::path
Replace old event accessors APIs, including relevant comments.
Change-Id: Ie205fc93b6e1c0dfb3dca9100fbde417ab68fc9f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
- isQProperty has been renamed to bindable
- QNotifiedProperty is no more
- Bindable properties have a function to obtain the QBindable; store
that information in the qmltypes files.
Task-number: QTBUG-86434
Task-number: QTBUG-86435
Change-Id: I2ba593af1e197d04d2c30cfb9e6904a3d2059e4b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
variant and var properties differ in two important ways:
- variant properties trigger "magic" string conversions:
variant v1: "red" // contains a QColor
var v2: "red" // contains a string
- variant properties behave differently for value types: they create
copies, instead of references.
However, as variant properties were marked as obsolete and this
behavior was effetively undocumented, it should be safe to give "variant"
"var semantics".
With this change, we can also avoid doing magic conversions when storing
data in QVariant properties of QObjects/QGadgets
Change-Id: I549b1beb98e6af9639c1ee81f316bda513d5ff65
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If we install the binding eagerly, context properties cannot be resolved
yet, as the context object has not been created so far. This causes
issues with a QNotifiedProperty using a callback which accesses the
current value, and thus forcing the binding evaluation while the object
creation is still ongoing.
Change-Id: I3bf3def04cd044371cb757a1854a3224a9c669b8
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
When it is looking for a matching method based on the argument types,
then if a QVariant can be converted to that type then it should give a
better score for that method. This is so that it can see it as being
more viable a choice when calling the method instead of potentially
not being able to find a matching one.
Pick-to: 5.15
Change-Id: Ief7e11feacd1d0b0959330af2576c2d01affbc54
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: Iead53d18fd790fb2d870d80ef2db79666f0d2392
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This introduced inconsistency in order to be compatible with V8 and Qt
5.0/5.1, respectively. We don't need to do this anymore. We standardize
on the behavior observed when statically setting a property in QML, e.g.
"foo: '2014-03-03'", rather than the behavior observed when dynamically
setting it from JavaScript.
[ChangeLog][Important Behavior Changes] Dates are interpreted the same
way when assigned to QML properties as when parsed in JavaScript now.
The time zone is generally left alone, not forced to UTC in some cases.
Fixes: QTBUG-36635
Change-Id: I72a7045d7b39ee1c6e0ac1ef55d74ef8aa505f00
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We don't know in advance if a URL is part of the source code and should
be relative to the current element, or if it is part of the application
data and should not be touched.
[ChangeLog][QtQml][Important Behavior Changes] URLs are not resolved or
intercepted anymore when assigning them to a "url" property. Instead
they are resolved and possibly intercepted when used to access an actual
resource.
Fixes: QTBUG-76879
Change-Id: Iaa2385aff2c13aa71a12e57385d9afb5dc60a073
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
With the new compile time type registration, the type is no longer
unknown, causing the test to fail.
Until we decide exactly how to deal with unknown types in QML, leave the
test as is, but mark the failing comparison as an expected failure.
Change-Id: Iaa23f096f686399b7199541b390655142fc40a37
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Implements URLSearchParams (https://url.spec.whatwg.org/#urlsearchparams),
completing our implementation of the URL object.
Still needs the for..of iterator to get implemented.
Change-Id: Iad33ed2f3fe0b2598ca2b0b21a4743f5f7dc19fd
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Implements the JavaScript URL object (https://url.spec.whatwg.org/#api).
Except that it does not currently implement the searchParams field.
Task-number: QTBUG-54988
Change-Id: I19abc69e075cbf84bd15e6791be195ce16f3fe73
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QRegExp will get removed in Qt6. Clean up by removing dependencies
on QRegExp in the autotests.
Change-Id: I8ef8561ba30b98b61cd9ed52907b48c5969f2c49
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Syntactically we call them signal handler expressions :-), now also
working when the underlying property doesn't emit an old-style signal
but is just a QProperty.
Change-Id: I719a3e428f44af0fd48036434aefa682a02f7de1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
[ChangeLog][Important Behavior Changes][QML] Throw an error if an incompatible parameter is passed to a C++ function
Change-Id: I088e362869f7dc00ca639a0fbc4ba20cb9e82f7d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Avoid going through externally managed bindings and instead allocate a
more lightweight property binding. It's basically a
QQmlJavaScriptExpression and one pointer plus the overhead of
QPropertyBindingPrivate.
Change-Id: I1530330926d351b61f2b3bbad39301c628a8bef1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This class is not a private detail of QQmlContext. And it is incredibly
hard to see who owns what in there. Let's add some civilization ...
We enforce refcounting for QQmlContextData across the code base, with
two exceptions:
1. QQmlContextPrivate may or may not own its QQmlContextData.
2. We may request a QQmlContextData owned by its parent QQmlContextData.
For these two cases we keep flags in QQmlContextData and when the
respective field (m_parent or m_publicContext) is reset, we release()
once.
Furthermore, QQmlContextData and QQmlGuardedContextData are moved to
their own files, in order to de-spaghettify qqmlcontext_p.h and
qqmlcontext.cpp.
When the QQmlEngine is deleted, any QQmlComponents drop their object
creators now, in order to release any context data held by those.
Before, the context data would be deleted, but the object creators would
retain the dangling pointer.
[ChangeLog][QML][Important Behavior Changes] QQmlContext::baseUrl() does
what the documentation says now: It prefers explicitly set baseUrls over
compilation unit URLs. Only if no baseUrl is set, the CU's URL is
returned. It used to prefer the CU's URL.
Change-Id: Ieeb5dcb07b45d891526191321386d5443b8f5738
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Edward Welbourne
Fabian Kosmale
Maximilian Goldstein
Ulf Hermann
Andreas Buhr
Andrei Golubev
Richard Weickelt
Volker Hilsheimer
David Skoland
Andy Shaw
Lars Schmertmann
Lars Knoll
Simon Hausmann