reused_dir_targets takes a list of targets, not directories, so provide
that one. Amends 953c1cf394
Fixes: QTBUG-98468
Change-Id: I44e811ff738c5a51845c4829e1e6928e5f2f06f1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 00c352c4d4)
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
All targets using the "shared" approach need special handling in
toplevel builds to ensure that AUTOMOC works.
Amends aa4897e017.
Fixes: QTBUG-98468
Change-Id: Ic0a6ee0ab43190e359ad7cfb7e7634d393ff0b03
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
(cherry picked from commit 953c1cf394)
We can return void from a function, explicitly or implicitly, and we
need to be able to wrap that into a QVariant. In order to explicitly
return void, we need the void type to be exposed and understood.
Pick-to: 6.2
Change-Id: I513cabb25469b89a85b5d212a6825a037400729d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Using a fold expression ought to be faster to instantiate than the
recursive template calls.
Change-Id: Iffed70a2da74399bf96a9f78bfe1bb9a65d0be30
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Fix warnings related to the introduction of the TreeView QML type, as
well as other minor issues.
Change-Id: Icdcb61b4de0144ca426b1ab5a17ddc0ddc523773
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
This patch adds TreeView to Qt Quick. It is more or less
a copy from the TreeView in Marketplace, but with some
modifications to make it more equal to the already
existing TableView, ListView, and GridView.
[ChangeLog][Item Views] A new view is added: TreeView
Fixes: QTBUG-61630
Change-Id: Ibb9d22cf9c9df021e77d03287872134c2682682a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add a proxy model to qmlmodels that takes a tree model
and converts it to a flat table model. This model is
used by TreeView to show a tree model inside a
TableView. It is mostly a raw copy of the model used
by TreeView in Controls 1 (and later by TreeView in
Marketplace), but with some modifications to target
TableView (with multiple columns) instead of
ListView.
Change-Id: I079937f35ae36659a6ad43375ac3d1d5840155d6
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
QQuickTreeView will inherit QQuickTableView. And to make
that work as expected, QQuickTreeView needs to override
the functions marked as virtual in this patch.
In short, this will let us make sure that TreeView updates
it's own properties and state before TableView emits onReused.
Change-Id: I6c82d1e5c25b1e08d26b3c8715f7a6a7f6d0ab0b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When a popup opens and takes keyboard focus, then the control that had
focus needs to get a focusOut event, with the reason set correctly. This
allows text controls to stop blinking, but not deselecting text. So set
the reason parameter to Qt::PopupFocusReason in all calls to functions
that change focus in response to a QQuickPopup showing or hiding.
However, QQuickItem partially ignored focus changes where the reason was
set to Qt::PopupFocusReason. This seems to be a left-over from a fix for
issues with Qt Quick Control 1 made in c860d33437c59a35d9d17ad199ce4f0f
to make sure that menu entries are enabled and selection is not removed.
The reason given here is no longer relevant: of course popups need to
take focus, otherwise we can't navigate menus with the keyboard; and
they do, at the latest the MenuItem takes focus away from the control
breaking the entire assumption. And since prior to this change no code
other than the outdated tst_qquicktextinput test passed focus with
Qt::PopupFocusReason, we can safely assume that this logic is no longer
needed. Controls that want to ignore a focusOut with PopupFocusReason
can do so with this change.
Note: PopupFocusReason in Qt Quick means any popup, including dialogs,
while in QtWidgets it means a Qt::Popup type window. Since Quick dialogs
don't trigger window activation changes and focusOut events with
corresponding focus reasons, and since QtQuick has no concept equivalent
to Qt::Popup where this could become confusing, this seems acceptable.
Fixes: QTBUG-71723
Task-number: QTBUG-75862
Task-number: QTBUG-36332
Pick-to: 6.2
Change-Id: I7a0a29830d8f7ed80b22411785214758b896562c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Focus might go to the content item, which is a QQuickItem that has no
concept of either focusPolicy or focusReason. For Qt Quick Controls to
update the focusReason property when an item in it's item tree receives
or loses focus, it has to install itself as a notification listener on
the item.
However, QQuickItemChangeListener didn't have any notification type for
focus changes.
Add the new change type, and notify listeners whenever the an item's
focus changes. Focus scoping might mean that an item never loses focus,
but nevertheless loses active focus.
To be able to update items recursively with the correct focusReason, add
the reason parameter to the QQuickDeliveryAgent helper function.
Fixes: QTBUG-75862
Pick-to: 6.2
Change-Id: I3d19b722bb07b55416b8cfbb4a9cdb0edd0da3ec
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This is what the various SelectionRectangle.qml types in qqc2 do. Amends
commit e6c44662cdc8acfbdbf1c7ed071e1253ff0c1321.
Change-Id: Icb98f262d669ed165a3b3ab1be79b150b6cedc44
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
They are the same for all intents and purposes. We don't need to expose
QQmlV4Function in the builtins.
Change-Id: I4c3f9a9c802abb3ce1133979007919eb69b46ae0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
A dozen loops doing more or less the same, all with the comment
"intentional copy (QTBUG-54732)", are best factored out into a helper.
Most of the loops call a different QQuickItemChangeListener member, so
provide a template that expects a pointer to a QQuickItemChangeListener
member function.
Some loops have some additional logic, so provide a second template that
just calls a functor.
No functional change, but needed for follow-up fixes to focus reason
handling in Qt Quick Controls.
Pick-to: 6.2
Change-Id: I6b11e06331da44b288315fc0732009d5f34f539a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Content size was calculated before the new data was applied.
This caused problems when calculating the column count while
resizing the window.
Pick-to: 5.15
Pick-to: 6.2
Fixes: QTBUG-92998
Change-Id: Ia4401c0e34cd11dc9e6c24a0320dbf0ca2f59ab9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
With efb283fb7f72e950c8ecf755b960a3c1b36b5507 in qtbase, we can now
fail a test if a particular warning is encountered. Let's also have this
functionality in QML as it seems useful there as well
[ChangeLog][QtQuickTest][TestCase] Added failOnWarning() for allowing to
fail a test if a particular warning is output during that test execution
Change-Id: I011ed119c318859a2bccd98f0d491904b10305e5
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
If we pass in a const pointer, we're not allowed to modify the object,
so the create==true case does not make sense there. We therefore provide
now two versions of the function: One taking only a const pointer, and
one taking a non-const pointer and a bool. The latter no longer provides
a default parameter to encourage usage of the the const version wherever
possible.
Change-Id: Ifb5a7e0605127de429403982b31f754e154b8048
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Change-Id: I1034760fc97e5997d1ba7d70ce2261818da79b37
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When a HoverHandler is declared in a Window, the handler's bindings
are evaluated before QQuickItemPrivate::data_append() is called to
add the handler to the window's content item. So we need null pointer
checks again (as we have for a lot of calls to parentItem() already).
And to ensure that the declared cursorShape actually is shown, we need
to check again in componentComplete(). And don't forget to call the
parent class implementation whenever overriding any virtual function.
Fixes: QTBUG-98717
Pick-to: 6.2 5.15
Change-Id: Id0defac7a238df522e8eee69f71e83a3947560af
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
qmlcachegen compiles bindings and functions to C++ as far as
QQmlJSAotCompiler can. It does respect "pragma Strict" and rejects the
file if it's violated. Furthermore, it sets up the logger to follow the
qt.qml.compiler.aot logging category. By default it's completely silent.
Compiling the examples with qmlcachegen exposes a bug in the type
resolver where it returns an invalid generic type. It should never do
that. Fix it by returning JSValue.
[ChangeLog][QtQml][Important Behavior Changes] QML bindings and
functions are now compiled to C++ by qmlcachegen, if possible. Use the
qt.qml.compiler.aot logging category to receive diagnostics about the
compilation.
Task-number: QTBUG-98305
Change-Id: I6953812c3fd20b68339617a5714fcbe16a384360
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Otherwise we cannot find attached types of the same name as the current
document.
Pick-to: 6.2
Change-Id: I927c49d30e466109cc1ef0c1439435581ee30a53
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
There is no guarantee that this works.
Fixes: QTBUG-98830
Pick-to: 6.2
Change-Id: Id205170a41caa4bed264864a1ff35a57303641e9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QT_QML_SINGLETON_TYPE was only documented on the qt_target_qml_sources
page. Add a short section about singletons to the qt_add_qml_module
page and reference the other page.
Adjust the example in qt_target_qml_sources to show case how to set
the singleton source property.
Pick-to: 6.2
Fixes: QTBUG-97541
Change-Id: I11aa3cb7c0feb748eba1d7ac9ef81a8ac6cb16b1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
As we create them via QQmlComponent::create() we are responsible for
getting rid of them.
Change-Id: I1c836e731d57061a30185484b4b53c5643df08a7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Template all of the code and make sure the different query variants do
the same work. There is no reason not to query the namespaced imports if
we are passed a different string type as parameter. If we want to skip
the namespaced imports, that is a separate parameter.
This needs to be picked to 6.2 as precondition for fixing
AOTCompiledContext::initLoadAttachedLookup. We need to pass a
QQmlImport::RecursionRestriction when querying by QHashedStringRef.
Pick-to: 6.2
Change-Id: I98aecc7775036728668cc93f550aa73fdefafe9a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
These will be needed by subsequent work for setting up correct
dependencies and for enabling the project to retrieve the file lists
later with a query function (to be written).
Task-number: QTBUG-95024
Change-Id: I36ea4a44ab57f69a95f5a11f7d7196395fdb3702
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When the text is larger than 10000 characters, we now avoid creating
nodes for blocks that go outside the viewport. Each time the text moves
relative to the viewport, we check whether the rectangular area that we
know is "covered" with the text rendered so far is still enough to fill
the viewport; if not, update the whole document: mark all existing SG
nodes dirty, then delete and re-create them.
[ChangeLog][QtQuick][Text] When given large text documents
(QString::size() > 10000), Text and TextEdit now try to avoid populating
scene graph nodes for ranges of text that fall outside the viewport,
which could be a parent item having the ItemIsViewport flag set (such as
a Flickable), or the window's content item. If the viewport is smaller
than the window, you might see lines of text disappearing when they are
scrolled out of the viewport; if that's undesired, either design your UI
so that other items obscure the area beyond the viewport, or set the
clip property to make clipping exact.
Task-number: QTBUG-90734
Change-Id: I9c88885b1ad3c3f24df0f7f322ed82d76b8e07c9
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
When a former drag event target is on a higher or the same z-level as the new target, send the QDragLeaveEvent before the QDragEnterEvent.
[ChangeLog][Quick][Fix] Now sends DragArea leave events before enter events when appropriate (QTBUG-82263)
Pick-to: 6.2
Fixes: QTBUG-82263
Change-Id: Ibe76000cbe76748ee8928e4b98a92c38eff5b59c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
On a touchscreen, right-clicking is not directly possible; so sometimes
a long-press gesture is used as a substitute. The next thing a UI
designer would want would then be a way of showing feedback that a
long-press is in progress, rather than simply waiting for the long-press
to occur and then surprising the user with some instant action.
For example, a menu might begin to open as the user holds down the
touchpoint; but before the long-press gesture is complete, the user can
simply release, to cancel the gesture and close the menu. The timeHeld
property could drive the animation, to avoid needing a separate
animation type; in fact the reason timeHeld exists is to make it easy
to emulate this sort of touch-press animation, like one that occurs on
touchscreens since Windows 7.
But after the menu is open, the user would probably expect to be able to
drag the finger to a menu item and release, to select the menu item. For
such a purpose, the existing gesture policies weren't very useful: each
of them resets the timeHeld property if the user drags beyond the drag
threshold; so if the user expects to drag and release over a menu item,
then the timeHeld property cannot drive the menu-opening animation,
because the menu would disappear as soon as the user drags a little.
So it makes more sense to have a gesturePolicy that acts like
WithinBounds, but also applies the same policy to the timeHeld property
and the longPressed signal. We don't care about the drag threshold:
if the user is holding down a finger, it's considered to be a
long-press-in-progress, regardless of how far it has moved since press
(as long as it stays within the parent's bounds).
An example of such a menu is added. The menu must have TapHandler as
its root object, because it reacts to press-and-drag within some larger
item, larger than the menu itself. For example such a menu could be
used in a canvas-like application (drawing, diagramming, dragging things
like photos or file icons, or something like that): dragging items on
the canvas is possible, but long-pressing anywhere will open a context
menu. But in this example so far, only the menu is implemented.
It's a pie menu, because those are particularly touch-friendly; but
perhaps for the mouse, a conventional context menu would be used.
[ChangeLog][QtQuick][Event Handlers] TapHandler now has one more
gesturePolicy value: DragWithinBounds; it is similar to WithinBounds,
except that timeHeld is not reset during dragging, and the longPressed
signal can be emitted regardless of the drag threshold. This is useful
for implementing press-drag-release components such as menus, while
using timeHeld to directly drive an "opening" animation.
Change-Id: I298f8b1ad8f8d7d3c241ef4fdd68e7ec8d8b5bdd
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The headers were hardcoded but seeing as they are ultimately ignored
on the server-side (which is following the spec) we can also ignore them
if they come back in some form in the future.
Pick-to: 6.2
Fixes: QTBUG-98811
Change-Id: Ida490cbd8193eb3e3bf8d56fd387af93c408d921
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since Qt 6.x, it is not mandatory to have version
no. against the module import statements.
Pick-to: 6.2 6.2.2
Task-number: QTBUG-98481
Change-Id: Ia3d35f2dc198d3e9c02d15784ca07c9bbb9526ce
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This allows modules to mark objects to be registered with QML, without
depending on qtdeclarative. A library using that module can then be
passed to qt6_generate_foreign_qml_types to add its types to a dedicated
QML library.
Fixes: QTBUG-92258
Change-Id: I8f9071a974902186088e12c1e7848ea138f85716
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
QQuickDeliveryAgent::event() is not the only way to end up in
QQuickDeliveryAgentPrivate::handleMouseEvent(). We also need to remember
the current DA in QQuickWindowPrivate's event handling functions,
otherwise the logic to track grabbers is broken when
QQuickOverlay::eventFilter() calls them, because DA::onGrabChanged
contains a check that the handling DA is the current DA.
Fixes: QTBUG-97461
Pick-to: 6.2
Change-Id: I66d94d84857d9b603e58b0286cbcdedfcaae62af
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This reverts commit 74d2ed9203.
Reason for revert: We have a better fix now
(e5e371291a).
Change-Id: I9dd5fa703a475f67a9565a1a9b37489b3ed73db1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The RangeSlider's setTo() and setFrom() implementation was not updating
the positions of the handles. This patch fixes it and aligns the
behavior with the basic Slider.
Fixes: QTBUG-98482
Pick-to: 5.15 6.2
Change-Id: I482c416f91be2b97af1d922305dfe6fc1f5bd573
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
That feature is quite broken at the moment for controls that use a
contentItem that takes focus; document that using QEXPECT_FAIL.
Also, building custom items based on control does not work as
expected; controls don't get tab focus even with activeFocusOnTab
set, focusPolicy on the control seems to be ignored.
Replace the old test, which didn't really test anything other than
that transferring focus programmatically works.
Task-number: QTBUG-75862
Pick-to: 6.2
Change-Id: I801a48d8b6a8aeb41c98e5aa68b13ca426412fed
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
When altering the environment variables that decide how distance
fields are generated, you could get into the situation where
the QT_DISTANCEFIELD_RADIUS / QT_DISTANCEFIELD_SCALE would not
be an integer. This caused an issue where the distance field cache
was too small to contain glyphs that happened at the end of the
rows.
The effect of this would depend on the backend. On some backends,
it was not detectable, whereas on others it would cause missing
glyphs or even crashes.
The reason was that the logic to calculate the necessary size of
the cache would always truncate the fraction, whereas we would
use floats when storing the margin of the glyph. To consolidate,
we use floats also in the calculation of the required size of the
cache.
[ChangeLog][Text] Fixed an issue where glyphs would sometimes be
missing when changing the environment variables that define how
distance fields are generated to certain values.
Pick-to: 6.2
Task-number: QTBUG-86633
Change-Id: I3c390737e0eaf1391d82cf1f9b3896eff25a5a8c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Previously we only warned about top-level ids in deferred properties,
now we warn about them at any depth, as we should.
Change-Id: I9b21bd4f71995eb51542f1e1e8a1c17c509b59da
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Utilize our warning against using ids on deferred properties instead
of the id visitor.
To accomplish this cleanly we have to move our deferred property
warnings into a different category.
Also remove the BLACKLIST since the corresponding tests no longer exist
and the qmllint version of them does not require any blacklisting.
Fixes: QTBUG-96021
Change-Id: I35f88157c9c4aa20e006f09a1402e3100fe09fb9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The items referred to here can be deleted when the animation finishes.
Use QPointer to zero them in that case.
Pick-to: 5.15 6.2
Fixes: QTBUG-84196
Change-Id: I695c9e91bd29d0583e4871d03ee946c40aa8a595
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Follow the new structure and naming scheme from qtbase.
Pick-to: 6.2
Change-Id: If0bd4934a0bdd824f5ba751096a43e1322aa9f1d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Such types don't have a compilation unit, but we still know their names.
Pick-to: 6.2
Fixes: QTBUG-98792
Change-Id: I2db8dea3a5a02ec1492f7f7a054fd3ad4c6ad69a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Since we connect to "this" via PMF syntax, we need to disconnect while
QQuickDialog is not partially destroyed.
Pick-to: 6.2
Change-Id: Ia8797dd7b12bf9ce796b17fc0420273191e262cd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Apparently looking up a property can cause it to be evaluated (and its
signal handler called directly). From the debugging the following is
visible:
1) assume signalName is set first and target has a pending binding (not
evaluated yet)
2) once signalName setter is triggered, it calls the relevant signal
handler - onSignalNameChanged, which subsequently calls qtest_update()
3) in qtest_update():
a. we first check whether there's any old state
"if (qtest_prevTarget != null)" -> there's none yet, because we entered
this function for the first time ever -> jump to:
"if (target != null && signalName != "")"
b. once at "target != null" the engine attempts to get the value of the
`target` property. if the property `target` happens to have an unevaluated
binding, it is evaluated immediately.
[the logic is in QObjectWrapper::getQmlProperty() which calls
QObjectWrapper::getProperty() and that one calls
QQmlData::flushPendingBinding()]
c. the binding evaluation causes onTargetChanged signal handler to trigger
which in turn again enters qtest_update
4) in the "recursive" call of qtest_update():
a. same as 3.a.
b. target is now evaluated and signalName is evaluated as well (due to
being already set at step 2)
c. "if (target != null && signalName != "")" succeeds and we proceed to
connect to spy.qtest_activated
d. we return from this function and get back to the outer qtest_update()
5) we are now back at 3.c in qtest_update():
a. target is evaluated, signalName is known, so
"if (target != null && signalName != "")" succeeds -> again, we proceed
to connect to spy.qtest_activated (for the second time now - see 4.c)
b. we return from qtest_update() (the outer one) back to onSignalNameChanged
6) the end. bottom line:
- two signals were connected to target[signalName]
- zero signals were disconnected
This seems like a very nasty thing to have in a UI-centric language
but for now let's just attempt to fix the SignalSpy class
Pick-to: 6.2
Task-number: QTBUG-98722
Change-Id: I70f11000b8383e6a8fc82d0034c62a2094f6d832
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The type resolver should never return an invalid type from storedType().
Everything can be stored somehow.
Pick-to: 6.2
Change-Id: I7048518ac1d16342a52164a0a91c41c3d63f349b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Fabian Kosmale
Ulf Hermann
Topi Reinio
Richard Moe Gustavsen
Volker Hilsheimer
Tony Leinonen
Qt Submodule Update Bot
Andrei Golubev
Shawn Rutledge
Alexandru Croitor
Craig Scott
Maximilian Goldstein
Mårten Nordheim
Venugopal Shivashankar
Ivan Solovev
Eskil Abrahamsen Blomfeldt
Eirik Aavitsland