Do you have recommendation on how to architect

Menu

content, state & action (of the

WindowScope

) for different "screens"? Currently, I have a single desktop specific

MyApp

class which is responsible to • provide

main()

• create

application {}

• create main

Window

composable • delegate main window content to a

MyAppContent

composable The

MyAppContent

then handles the navigation logic between "screens" (using #decompose library (but whatever?)) Depending on the navigation state machine, a proper

FooScreen

composable is chosen to display screen content. Each of these "screen" have its own

FooViewModel

to drive logic and UI binding. Now, back to the menu topic. AFAIK, the menu must be managed within the

WindowScope

and thus currently in my main top level

MyApp

. For general purpose menu items like preferences, it's fine but several items are contextual to the screen being displayed. I need to • decide if an item must be displayed or not • decide if the item is enabled or disabled • provide a business logic callback to call when item is clicked (most likely to a

FooViewModel

entity) I'm not sure what would work well in this setup, ideally isolating desktop specific stuff like that outside main screens meant to be reusable at least on Android and maybe more later. If "duplicating" some boilerplate of "screens" would be needed to combine desktop feature and reusing code in other platforms, it's fine though.

Compose Multiplatform is a UI and state manager framework. Actions, that you want to add on the menu, - may be a part of the State of your application. State may contain all logic that you need to display on the top level of your application. If you navigate in application, the State may change and actions will change also.

Would it mean that I should model my menu content (an item with a label, a shortcut, an enabled state and an action callback mainly) and expose it as an observed state in my main app code, right? If so, this would mean to hoist this state into my screens and populate it from there while listening to my

FooViewModel

state, right? Doing that would spread menu logic into reusable screen but it's not necessarily a problem, it wouldn't be coupled to desktop specific stuff if I use my own "menu item data model", only useless elsewhere (or reused another way). So basically I would have something like

MyApp {
  val menuState = remember { mutableStateOf(MyMenuDataModel()) }

  Window {
    // interpret menuState/MyMenuDataModel as Menu and Item tree
    Menu {
      Item() {}
    }

    MyAppContent(menuState)
  }
}

@Composable
fun MyAppContent(menuState: MutableState<MyMenuDataModel>) {
  // depending on state machine, choose right screen composable
  
  FooScreen(menuState)
}

@Composable
fun FooScreen(menuState: MutableState<MyMenuDataModel>) {
   val viewModel = ...
   val canDoSomething = viewModel.canDoSomething.collectAsState()

   menuState.update(MyMenuDataModel.FooScreen(..., canDoSomething, ...))

   ...
}

Is this something like that you were suggesting?

For example - it's a good first solution.

Yes, I think I get the idea

It's only one of possible solutions. You can choose that you want.

I might also have to inject a "parent" menu "key" in my items so that I can aggregate several items from different sources (eg. "AlwaysMenuItem"'s parent and screen item in your example, for things like "Edit" or "File" top menus)

I think it is better to: inject the state in each nested composable requiring it