nutrient/com.pspdfkit.jetpack.compose.toolbar/nutrientToolbarsComposeView

nutrientToolbarsComposeView

fun nutrientToolbarsComposeView(context: Context, coordinator: ToolbarCoordinator, showMainToolbar: Boolean = false, defaultGroupingProvider: ContextualToolbarGroupingProvider? = null): ComposeView

The SDK toolbar stack (NutrientToolbars) as a ComposeView, with the full chrome PdfActivity has, so a custom activity built around PdfFragment gets the same behavior without hand-rolling it:

The scaffold owns placement (top/side docks with drop-zone chrome while dragging, the fit-correction forcing a side dock to TOP when a vertical bar doesn't fit) — nothing to drive from the host.
Dock changes are persisted per toolbar kind under the same preference keys PdfActivity uses, so the binders restore them on the next attach — app-wide. Persistence starts when the view attaches to a window and stops when it detaches.
Dock changes report the same MOVE_TOOLBAR analytics event (physical-name payload) as PdfActivity.

The view should overlay the document (match_parent both ways, like the pspdf__toolbar_compose_host slot in pspdf__pdf_activity.xml); it paints nothing and lets touches through while no toolbar is shown. See ToolbarsInFragmentExample in the catalog for the complete recipe.

Parameters

showMainToolbar

Whether the SDK main toolbar renders in the top slot (false keeps only the contextual bars — the common shape for hosts with their own app bar).

defaultGroupingProvider

Resolves item grouping when no customer provider is set on the coordinator (see ToolbarCoordinator.setContextualToolbarGroupingProvider); null keeps the built-in presets.