still trying to wrap my head around compose for de...

# compose-desktop

[nfrankel]

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?

[gildor]

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)

[xetra11]

@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

[xetra11]

Until Components has it's own stuff

[xetra11]

Compose

[nfrankel]

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

[xetra11]

@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 😛 ?

[nfrankel]

come on, there’s java fx

[gildor]

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

[xetra11]

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

[jim]

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.

[Logan Knight]

@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
    },
)

[jim]

@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.

[Logan Knight]

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

[nfrankel]

please share when you have an updated @Logan Knight 🙂

[Dominaezzz]

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.

[nfrankel]

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

[Logan Knight]

@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.

[Logan Knight]

I assume this will be or is on the road map?

[nfrankel]

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

[Logan Knight]

I agree.

[jim]

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

[Logan Knight]

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.

[Siyamed]

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

[Ralston Da Silva]

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.

[Logan Knight]

@Ralston Da Silva Thank you for this