Hi everybody, I have a philosophical question on how would you design your system if it would be large enterprise data entry system (suppose legacy desktop application) with many dialogs, forms, listgrids, etc. which must support keyboard only navigation (without using mouse) - keyboard shortcuts, proper keyboard focus (navigating thru components on screen). I know that Compose currently is suitable for Android, but looking into far future lets suppose that it supports now browsers and desktops. As I understood Compose is just a View layer, kind of MVI architecture, model passes information into "Composable function" and you get visual GUI which return back intents/events/etc. How keyboard focus and navigation should be implemented? Does Compose emits some kind of "focused element" event? Or even how to render GUI component with specific Input field focused? If Compose is just "state renderer" so everything must be embedded into parameters (disabled/enabled field, focused/notfocused field). How about dialogs? How dialogs should be encoded? And how to handle navigation if there is some two or more non modal dialogs on screen. Going further it seems that these questions not directly relates to Compose, but should be separate library framework which handles and implements all GUI logic and then uses Compose to render it. Do these kind of libraries already exists? Maybe some of current GUI frameworks can be used, but looks like everything is tightly integrated with its own GUI rendering engine and cannot be used separately. I know that this all Compose stuff is state of art and no best practices currently exists, but what are your thoughts of how this could be implemented in "Compose" way?

I’m not sure you have clearly in mind the difference between

just a View layer

and

MVI architecture

as you just said that’s the same thing 😅

in case you are looking for a rendering engine, the Android System, Compose, Flutter and Chrome use the Skia library.

Conpose is separated (or supposed to be seperated) into

Compose-runtime + compiler plugin

- not related to ui at all

Ui

- a couple of artifacts , one does primitive stuff like

DP

that is not UI but is needed for it, one builds the ui tree, one draws to a generic canvas interface, one has android specific bindings and a few more (IIRC)

@Luca Nicoletti Just wanted to say that Compose is just a View layer of MVI architecture.

The thing is that Compose is not a

View layer of MVI architecture

but what libraries are used for managing basic (general) application UI

Compose is a UI toolkit that will allow you declare your UI in a declarative way, opposed to the current imperative way

so can't I say that it will fit (or be used as) in "View layer"?

Yes, but not only in MVI

Ok, my question is if the system is architected in declarative UI way by using Compose UI toolkit

That’s up to you

That's why I am asking, what to use, and what are you using for that

I’m using MVI, but many others are using MVVM, others MVP

It's architecture how to layout a code

🤷🏼‍♂️

but not how to control and manage UI interactions

That’s something that the framework provides

if modal dialog is opened then focus navigation using TAB key should be applied dialog's forms and elements only

Again, handled by the system

Actually I'm asking if using declarative UI toolkit, how to define and pass a UI components specification to system

We've yet to see if it's actually useful in a fully compose-based app, but the library Square is using for its POS apps, Workflow, integrates very nicely with Compose for the view layer. Some people have been playing with using it with SwiftUI too and it's been working pretty well. I've got some simple examples up on a branch: https://github.com/square/workflow/pull/703 Once Compose is more stable we intend to ship Compose support for real.