Component Reference

A restyled Qt Quick Controls Switch — a sliding pill indicator instead of the platform-default look, colored from theme_checkbox. It adds no properties or signals of its own beyond what Switch already provides, so everything below is inherited, not custom.

Real usage, from the built-in channel-reverse toggle:

CheckBox {
	enabled: chansel_index >= 0

	onPositionChanged: {
		if (position == 0.0 || position == 1.0)
			chanSet (chansel_index, "rev", parseInt (position))
	}
}

200×160 icon with a caption below it — the size used by the on-device app drawer and top-level menu grids.

125×100, icon only (no caption) — the compact size used in side panels. Includes a small built-in press-scale animation.

160×160, rounded dark card with the caption overlaid on the image instead of below it — used for model-type pickers.

The rounded purple-gradient pill button used throughout menu screens — the one Calling signals uses as its example.

A borderless text-only button, purple normally / black while pressed — used for the Yes/No answers inside DlgWindow. Rarely needed directly; use DlgWindow instead unless you're building a custom dialog layout.

A thin, unthemed wrapper around Qt Quick Controls' own Button — fixed 60×90, checkable, icon-over-text layout. It doesn't reset the platform style the way the other two components do, so it looks like a generic Qt button rather than matching the radio's theme; check how/where it's used in the built-in UI before reaching for it in your own app.

Integer-valued variant.

Real usage, from the built-in timezone setting:

Adjuster {
	range_min: -12
	range_max: 12
	postfix: "GMT"

	onGetValue: {
		value = cfg_val - 12
	}

	onSetValue: {
		cfgSet (3, value + 12)
	}
}

Same interface as Adjuster, for fractional values.

A rounded black panel at theme_frameopacity, sized via Layout.preferredWidth/Layout.preferredHeight (defaults 800×400) or stretched with Layout.fillWidth/Layout.fillHeight — this is the frame behind the project template's "Hello World!" label.

No custom properties or signals — position and size it like any Item/layout child.

A white, rounded 640×260 card that fades in to 95% opacity whenever it becomes visible — the backing card behind DlgWindow and OptWindow.

No custom properties or signals — the fade-in is automatic (onVisibleChanged internally), triggered purely by toggling visible.

220×200 panel with a title bar (glowing centered label) over a content area below it. Purely decorative — put your own children inside it.

No signals.

Same layout as TitleWindow (220×200, titled panel, same y: 50 content offset and 15px bottom clearance), named for its use in telemetry screens.

No signals.

490×235 titled panel pre-wired to the current model: title bar shows mdl_cur_name, content area shows model_image_path (both root properties, read automatically — you don't pass them in). This is exactly the component the Home Screen template uses on its left side.

Tapping it navigates the shared stack directly, rather than emitting a signal for you to handle: a single tap pushes /qml/Model/SelView.qml (the model picker) and a press-and-hold pushes /qml/Model/ImageView.qml. There's nothing to read out — if you need different behavior, build a custom window from DlgFrame or TitleWindow instead.

No custom properties or signals exposed for you to hook into.

A modal Yes/No confirmation dialog: dims the background, shows a title and question, and closes itself (visible = false) after either answer.

Real usage, from the built-in language-change confirmation — note the currentHomePath fallback pattern from Home Screen apps:

DlgWindow {
	id: sellangdlg
	visible: false

	titleText: qsTr("Select Language")
	questionText: qsTr("Do you wish to change language to %1?").arg(name)

	onClickedYes: {
		signalLangSet(lang_index)
		stack.push (currentHomePath || "/qml/Base/BaseView.qml")
	}
	onClickedNo: { }
}

A modal single-column list picker — dims the background and shows one row per entry in list; tapping a row (or anywhere outside the dialog) closes it.

Real usage, from the battery-manager's "add battery" picker:

OptWindow {
	list: ListModel {
		ListElement { name: qsTr ("New Battery") }
		ListElement { name: qsTr ("Existing Battery") }
	}

	onSelectedId: {
		if (id == 0)
			stack.push ("/qml/Model/BatMan/BatAddView.qml")
		else
			stack.push ("/qml/Model/BatMan/BatExistView.qml")
	}
}

Purely a display — it has no signals at all. Every property is an input you drive from your own data; internally it just redraws (via one of eleven CurveType-0.qml…CurveType-10.qml canvas renderers, picked by type) whenever a bound value changes.

Real usage, from the throttle curve view — note the values come from a channel model, not from any signal on Curve itself:

Curve {
	input: input_ctrl[chan_list.get(throttle_chan).input]
	value: thr_val
	type: curve_type

	val_0: chan_list.get(throttle_chan).curve_val_0
	val_1: chan_list.get(throttle_chan).curve_val_1
	// … val_2 … val_8

	reverse: chan_list.get(throttle_chan).rev
}

To let the pilot actually edit a curve point's value, pair a Curve with an AdjusterFloat bound to the same val_N — the built-in menus set Curve.point to whichever index the adjuster currently has focused, so the matching point highlights while it's being edited.

A Label with a soft colored glow behind the text, wrapped in an Item that reports a precise bounding box (via TextMetrics) so large font sizes still lay out correctly — this is what every titled Window component and Icon caption uses for its text.

No signals — it's styled text, not an interactive control.

The radio has no keyboard, and nothing emulates one — there's no arrow-key/WASD-style input at all, so don't build a control scheme around Keys.onPressed or similar expecting it to work. For anything needing directional or analog control (a game, a custom stick-driven widget), read input_ctrl directly — Stick LV/Stick LH or Stick RV/ Stick RH are the natural choice, the same physical sticks the pilot already uses to fly (see Reading control inputs for the full index table). The touchscreen itself works normally for anything else — taps, drags, MouseArea, all the usual QtQuick input handling.

For actual text — a name, a search box, anything typed — there's a built-in on-screen keyboard and it works well. A plain TextField or TextInput is all you need on your end; showing and hiding the keyboard panel itself is manual, via two root functions, called directly with no prefix:

It doesn't appear automatically just because a field gained focus — call keyboardShow() yourself when your text-entry view appears, and keyboardHide() on the field's onAccepted, on back-navigation, and in Component.onDestruction, so it's never left showing over a screen that no longer has anything to type into:

TextField {
	id: nameField
	y: 40  // see the callout below

	Component.onCompleted: keyboardShow ()
	Component.onDestruction: keyboardHide ()
	onAccepted: keyboardHide ()
}