Do we expect all apps to make similar to changes to this? Wonder if we can extract some of this out to the unified-selction-react pkg, but I guess you are trying to avoid presentation-frontend dep.

cc @jjbeckman13 for web and @kckst8 @johnnyd710 for desktop apps

Does option 3 here provide a path forward for the issue described in iTwin/presentation#767 ?

Do we expect all apps to make similar to changes to this? Wonder if we can extract some of this out to the unified-selction-react pkg, but I guess you are trying to avoid presentation-frontend dep.

Most of the complexity is due to me trying to keep backwards compatibility - in multiple places you can see that I handle selection storage if it's provided and then fall back to Presentation.selection if not. That also involves mapping of new vs legacy types.

For apps it's much simpler:

1. Define a list of supported scopes like here:

   viewer/packages/apps/web-viewer-test/src/components/home/ViewerHome.tsx

   Lines 262 to 275 in c020494

   	const availableSelectionScopes = {
   	element: {
   	label: "Element",
   	def: { id: "element" as const },
   	},
   	assembly: {
   	label: "Assembly",
   	def: { id: "element" as const, ancestorLevel: 1 },
   	},
   	"top-assembly": {
   	label: "Top assembly",
   	def: { id: "element" as const, ancestorLevel: -1 },
   	}
   	};

2. Supply the necessary props to selection scopes status bar item:

   viewer/packages/modules/viewer-react/src/components/app-ui/providers/ViewerStatusbarItemsProvider.tsx

   Lines 175 to 219 in c020494

   	function SelectionScopeField() {
   	const ctx = React.useContext(selectionScopesContext);
   	const selectionScopes = React.useMemo(
   	() =>
   	Object.entries(ctx.availableScopes).map(([id, { label }]) => ({
   	id,
   	label,
   	})),
   	[ctx.availableScopes]
   	);
   	return (
   	<AppUiSelectionScopeField
   	selectionScopes={selectionScopes}
   	activeScope={ctx.activeScope.id}
   	onChange={ctx.onScopeChange}
   	/>
   	);
   	}
   	const selectionScopesContext = React.createContext<
   	ReturnType<typeof useUnifiedSelectionScopes>
   	>({
   	activeScope: { id: "element", def: "element" },
   	availableScopes: {
   	element: {
   	label: "Element",
   	def: "element",
   	},
   	},
   	onScopeChange: () => {},
   	});
   	/** @internal */
   	export function SelectionScopesContextProvider({
   	selectionScopes,
   	children,
   	}: React.PropsWithChildren<{
   	selectionScopes: ReturnType<typeof useUnifiedSelectionScopes>;
   	}>) {
   	return (
   	<selectionScopesContext.Provider value={selectionScopes}>
   	{children}
   	</selectionScopesContext.Provider>
   	);
   	}

3. Supply the activeScopeProvider prop to enableUnifiedSelectionSyncWithIModel:

   viewer/packages/modules/viewer-react/src/hooks/useUnifiedSelectionSync.tsx

   Line 60 in c020494

   activeScopeProvider: () => activeScope.current,

Does option 3 here provide a path forward for the issue described in iTwin/presentation#767 ?

Not really. As stated in this comment: "User workflows need to be investigated, considering both - read-only and the new read-write - scenarios".

@aruniverse, FYI I made some improvements to the migration guide in unified selection package, targeting specifically selection scopes: https://github.com/iTwin/presentation/blob/840e23a34cf9964e93929d869736ab3d53bcf5f7/packages/unified-selection/learning/MigrationGuide.md#appui-integration. This PR is used as a base for example code there, but without all the backwards-compatibility and configuration stuff that we have here.