Elektronenbasierte Apps Steam Deck-kompatibel machen

Fokussierbare Komponenten

In der Anwendung sind nur bestimmte Komponenten so konzipiert, dass sie fokussierbar sind — insbesondere solche, die ausgelöst werden können, wie Buttons oder Dropdowns. Alle fokussierbaren Elemente mussten identifiziert werden, und die Handler für die unterstützten Steuerelemente wurden für jede fokussierbare Komponente definiert, um auf diese Trigger zu reagieren. Das heißt, wenn zum Beispiel eine Taste A auf dem Steam Deck gedrückt wird, wird eine entsprechende Aktion ausgeführt:

const gamepadButtonHandlers = {
	[buttons.A]: { event: (elementRef) => elementRef.current.click() },
};

‍

Da viele Komponenten dieselben Gamepad-Button-Handler verwendeten (zum Beispiel Taste B, die herkömmlicherweise verwendet wird, um nach oben zu navigieren oder zu einem übergeordneten Menü zurückzukehren), haben wir uns für den gemeinsamen Kontext entschieden.

const GamepadHandlersProvider = ({ children, gamepadButtonHandlers }) => {
	const inheritedContext = useContext(GamepadHandlersContext) || {};

	const newContext = useMemo(
		() => ({
			handlers: {
				...inheritedContext?.handlers,
				...gamepadButtonHandlers,
			},
		}),
		[gamepadButtonHandlers, inheritedContext?.handlers],
	);

	return (
		<GamepadHandlersContext.Provider value={newContext}>
			{children}
		</GamepadHandlersContext.Provider>
	);
};

‍

Gemäß den Steam-Deck-Anforderungen müssen bei Verwendung der physischen Steuerung von Steam Deck die Zeichen auf dem Bildschirm entweder mit den Namen der Steam Deck-Schaltflächen oder den Namen der Xbox 360/One-Tasten übereinstimmen. Um diese Anforderung zu erfüllen, haben wir eine Fußzeile hinzugefügt, die die Steuerelemente und die Statusänderungen enthält, die zu bestimmten Effekten führen, wenn ein bestimmtes Element fokussiert wird.

Zweistufige Verwandte

Wir haben zunächst einen zweistufigen Prozess implementiert: Zuerst betrachteten wir Elemente, die direkt nach rechts, links, oben oder unten ausgerichtet waren, und dann wurden sie auf Elemente in einem 45-Grad-Winkel erweitert, falls keine Übereinstimmung gefunden wurde. Die Ecke des ausgewählten Elements musste innerhalb des angegebenen Bereichs liegen. Im beigefügten Schema wurden die „Ecken“ bestimmter Elemente, die sich in verschiedenen Richtungen vom Referenzelement entfernt befanden, mit einem Kreis markiert. Die Komponente, die dem Referenzelement am nächsten ist, wurde auf der Grundlage ihrer Größe und Position ausgewählt, die aus dem element.getBoundingClientRect () Methode.

‍

Warum blieb dieses Konzept dann hinter den Erwartungen zurück? Obwohl es in der Theorie vielversprechend aussah, war in der Praxis das Element, das ein Benutzer intuitiv als die logischste Wahl identifizieren würde, nicht immer das, was ausgewählt wurde.. Dies galt insbesondere für Gruppen von Elementen, die ähnliche Funktionen erfüllten. Daher mussten wir eine bessere Lösung finden, die nicht nur den Abstand zwischen den Elementen, sondern auch ihre Funktionen berücksichtigte. So kamen wir auf die Idee der Baugruppen..

Komponentengruppen

Um das Konzept der Komponentengruppen zu verstehen, betrachten Sie das folgende Beispiel. Nehmen wir an, wir navigieren nach links. Ohne Gruppierung existieren drei potenziell fokussierbare Komponenten: C1, C2 und C3. Bei einer Gruppierung gibt es nur einen potenziellen Fokus, G1, der als Fokusfänger fungiert. Wenn die Gruppe zuvor nicht fokussiert wurde, wird das erste Element in der Gruppe fokussiert, es sei denn, es ist festgelegt, dass ein anderes Element innerhalb der Gruppe immer zuerst fokussiert wird. Wenn die Gruppe zuvor fokussiert war, wird das zuvor fokussierte Element wieder fokussiert.

Wenn der aktuelle Fokus innerhalb der Gruppe liegt, versucht die Navigation zunächst, sich auf eine Komponente innerhalb der Gruppe zu konzentrieren. Wir versuchen nur dann, von der Gruppe wegzunavigieren, wenn keine Komponente gefunden wird.

Ebenenstapel

Mit der Einführung von Bauteilgruppen wurde das Problem der Navigation zwischen den Komponenten in einer zweidimensionalen Ebene erfolgreich gelöst. Nichtsdestotrotz da unsere Anwendung verschiedene Modals und Dropdowns enthält, mussten wir einen Weg finden, nur Komponenten im aktuellen Kontext zu fokussieren und keine Elemente außerhalb eines bestimmten Bereichs der Anwendung, auch wenn sie auf der Seite gerendert wurden. Dies veranlasste uns, das Konzept eines Anwendungsschichtstapels einzuführen.

Betrachten wir ein Beispiel. Das Öffnen eines Modals von der Homepage aus (L1) sollte den Fokus nur auf die Elemente innerhalb dieses Modals (L2) beschränken. Wenn das Modal ein Dropdown (L3) enthält, sollte das Öffnen des Dropdowns es ermöglichen, sich nur auf die Elemente des Dropdowns zu konzentrieren. Durch Drücken der Taste B im Dropdown sollte das Dropdown geschlossen werden, sodass der Fokus wieder auf das Modal gerichtet ist. Durch erneutes Drücken der Taste B sollte ein Modal geschlossen und der Fokus auf die Startseite als aktuelle Ebene verlagert werden.

Wir konnten dieses Problem lösen, indem wir den Kontext für alle Elemente außerhalb der Hauptebene bereitgestellt und den Ebenenstapel im Anwendungsstatus gespeichert haben. Daher wird jedes Mal, wenn eine Komponente, die zu der neuen Ebene gehört, geöffnet wird, eine Aktion ausgelöst, mit der diese Ebene zum Stapel hinzugefügt wird. Dementsprechend wird beim Schließen einer Komponente die Ebene aus dem Stapel entfernt, sodass die aktive Ebene immer das letzte Element im Stapel der Ebene ist.

useEffect(() => {
	if (enabled) {
		focusDispatch({
			type: “SET_LAYER”,
			payload: layerName,
		});
	}
}, [focusDispatch, layerName, enabled]);

useEffect(() => {
	if (!enabled) {
		focusDispatch({
			type: “POP_LAYER”,
		});
	}
}, [focusDispatch, enabled]);

useEffect(
	() => () => {
		const topLayer = layerStack.slice(-1)[0];
		if (topLayer === layerName) {
			focusDispatch({
				type: “POP_LAYER”,
			});
		}
	},
	[layerStack, focusDispatch, layerName],
);