still trying to wrap my head around compose for desktop i still have two concerns mainly related to the fact that it’s an port from an android framework • is there any table component? the best i could do was to use a

SwingPanel

to use the faithful

JTable

• how do you bind the tab key to jump to another field?

You can use LazyVerticalGrid for this: https://developer.android.com/reference/kotlin/androidx/compose/foundation/lazy/package-summary#LazyVerticalGrid(android[…]lues,%20kotlin.Function1) It’s not exactly table. I think there is no table yet, but you can probably implement using custom layout (shouldn’t be hard for simple cases)

@nfrankel same issue and had to use a custom table as well. But that is simply cause I have no idea of JTable etc. I think I will replace my implementation with JTable

JTable

is legacy but the effort to use it is pretty low compared to a custom implementation

@nfrankel what do you mean by legacy? Is there something newer from Swing? If not I think it's state of the art in terms of Java UI 😛 ?

come on, there’s java fx

There are plans for Java FX support in compose, as I remember

@nfrankel ah JavaFX is newer than the Swing stuff. Never did Java UI things so that certainly is a new information for me 😄

Obviously do whatever you need to do to make your app work, swing interoperability exists as an escape hatch for exactly that reason. But know that if you're able to use only composable functions, you will be able to avoid the impedance-mismatch complexities associated with crossing framework boundaries. For this reason, I'd strongly encourage you try using only composable functions (especially for layout widgets) if you're able. If someone wanted to try implementing a table view in Compose, it shouldn't be too hard and it sounds like it might be popular as there appears to be an appetite within this channel.

@jim I read this thread being interested in the tab question. Do you have any thoughts on that? I thought I would give it a go and see if I could figure it. The following responds to keyboard events nicely, but is silent when 'tab' is pressed.

TextField(
    modifier = Modifier.onKeyEvent {
        println(it)
        false
    },
)

@Logan Knight Have you looked at

focusModifier

? I think it might do what you want, rather than trying to write your own. Although

focusModifier

does use

onKeyEvent

so I'm not sure if that'll get you any further since my best guess/assumption would be that

TextField

is perhaps consuming the tab input? cc @Ralston Da Silva who knows more about this than I do since he wrote the focus navigation stuff IIRC. cc @Siyamed for text field related question. One of them may know more.

I have not, I will play around with it and see what I can learn. Thank you!

please share when you have an updated @Logan Knight 🙂

There used to be a

DataTable

component, now it's gone. If you can find it and copy it, it'll give you a head start.

thanks @Dominaezzz this is about learning by doing but i’m too lazy to learn that much 😅

@jim @nfrankel It seems this is has yet to be implemented as far as I can tell. The Swing Focus Subsystem has a traversal key concept that is able to be manipulated and configured. It's default behavior is:

The focus subsystem consumes focus traversal keys, such as Tab and Shift Tab. If you need to prevent the focus traversal keys from being consumed, you can call

component.setFocusTraversalKeysEnabled(false)

on the component that is firing the key events. Your program must then handle focus traversal on its own. Alternatively, you can use the KeyEventDispatcher class to pre-listen to all key events. The focus page has detailed information on the focus subsystem

Ref: https://docs.oracle.com/javase/tutorial/uiswing/events/keylistener.html You can disable the behavior for each component. It seems that it would need to be configured in the

ComposeLayer.Wrapper

which is not exposed as part of the public API and is the KeyEvent source, Then some Compose native implementation would have to manage it since Compose does not use Swing

Components

accept at the top. You can capture tab key strokes with:

KeyboardFocusManager.getCurrentKeyboardFocusManager().addKeyEventDispatcher {
    println(it)
    true
}

But that's of little use except on a global level. At least those are my thoughts.

thanks @Logan Knight i think that’s a good subject of work as tab’bing to the next field is one of the most important feature in desktop guis

I agree.

Sounds right to me, I'll add it to the todo list. Would anyone be interested in helping out with keyboard navigation? Contributions welcomed!

I'd be open to it but am not familiar enough with Kotlin or Compose yet to feel that I could. Let me mull it over and familiarize myself more. If/when I feel I could be of help, I'll PM you and see if the work still needs to be done.

This is something we need in compose (not only desktop), the line between mobile and desktop is a very vague one, especially nowadays

Sorry for the late response, but yes, This is on our roadmap. Focus navigation is still a work in progress. Right now focus modifiers use a keyEvent modifier to intercept tab, shift+tab and the arrow keys and move focus if a custom focus order is specified. You can see an example here: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]/java/androidx/compose/ui/demos/focus/CustomFocusOrderDemo.kt Ultimately, you will be able to move focus even if you don't specify a custom focus order.

@Ralston Da Silva Thank you for this