Duplicate Check
Describe the bug
Single page-level keyboard handler
page.on_keyboard_event is the only way to handle keyboard input globally.
Arrow keys reach the same handler regardless of which control has focus.
Result: arrows intended for our table also affect dropdowns, text fields, and buttons, causing unintended scrolling, focus changes, or visual glitches.
Request: A way to scope keyboard events (e.g. per-view or per-control) so that a widget can “consume” events when it has focus, preventing them from propagating to other controls.
DataTable2 lacks built-in cell focus and arrow navigation
DataTable2 offers row selection via on_select_change and tap events, but no per-cell focus or keyboard arrow navigation.
Implementing it requires wrapping each cell in a Container with on_click, maintaining a wrapper cache, and handling page.on_keyboard_event manually.
Request: Native support for cell-level focus and arrow-key navigation in DataTable2 (or similar components), with optional scroll-to-visible behavior when the focused cell moves off-screen.
Scroll does not follow selection
When the focused cell moves outside the visible area, there is no reliable API to scroll the table so that the focused row/cell stays visible.
DataTable2 does not expose something like scroll_to_row or ensureVisible that works consistently.
Request: An API to programmatically scroll the table to a given row or cell, so selection and scroll stay aligned.
Limited threading flexibility
UI updates must run on the main event loop; background threads require page.run_task or page.run_thread.
Any attempt to defer or parallelize updates to improve perceived responsiveness ends up adding latency rather than reducing it, because the final render still depends on the same pipeline.
Request: Documentation or patterns for optimizing interactive feedback (e.g. fast selection updates) in client-server and web modes, and clearer guidance on when and how to use threading for UI updates.
Environment
Flet (and flet-datatable2 if applicable)
Python 3.x
Desktop / Web target
Thank you for your work on Flet. These improvements would make it much easier to build responsive, keyboard-driven data tables.
Code sample
Code
To reproduce
Environment: Flet + flet-datatable2, Python 3.x, target Desktop or Web.
Minimal reproduction:
Create a page with:
A Dropdown or TextField
A DataTable2 with several rows and columns
Set page.on_keyboard_event = custom_handler so the handler moves a visual "focus" in the table on arrow keys.
Open the dropdown or focus the TextField.
Press arrow keys (Up/Down/Left/Right).
Expected: Only the table reacts (or only the focused control, depending on UX).
Actual: The table focus moves and the dropdown scrolls or the TextField caret moves, because the same key events reach both the custom handler and the native controls.
Scroll limitation:
When moving focus beyond the visible area, there is no API (e.g. scroll_to_row, ensureVisible) to keep the focused row visible; DataTable2 does not expose it.
Threading limitation:
Any UI update must run on the main event loop. Using run_task or run_thread to defer visual updates does not reduce latency; it adds an extra hop and can make the UI feel slower.
Expected behavior
No response
Screenshots / Videos
Captures
[Upload media here]
Operating System
Windows
Operating system details
idk
Flet version
0.81.0
Regression
No, it isn't
Suggestions
No response
Logs
Logs
Additional details
No response
Duplicate Check
Describe the bug
Single page-level keyboard handler
page.on_keyboard_event is the only way to handle keyboard input globally.
Arrow keys reach the same handler regardless of which control has focus.
Result: arrows intended for our table also affect dropdowns, text fields, and buttons, causing unintended scrolling, focus changes, or visual glitches.
Request: A way to scope keyboard events (e.g. per-view or per-control) so that a widget can “consume” events when it has focus, preventing them from propagating to other controls.
DataTable2 lacks built-in cell focus and arrow navigation
DataTable2 offers row selection via on_select_change and tap events, but no per-cell focus or keyboard arrow navigation.
Implementing it requires wrapping each cell in a Container with on_click, maintaining a wrapper cache, and handling page.on_keyboard_event manually.
Request: Native support for cell-level focus and arrow-key navigation in DataTable2 (or similar components), with optional scroll-to-visible behavior when the focused cell moves off-screen.
Scroll does not follow selection
When the focused cell moves outside the visible area, there is no reliable API to scroll the table so that the focused row/cell stays visible.
DataTable2 does not expose something like scroll_to_row or ensureVisible that works consistently.
Request: An API to programmatically scroll the table to a given row or cell, so selection and scroll stay aligned.
Limited threading flexibility
UI updates must run on the main event loop; background threads require page.run_task or page.run_thread.
Any attempt to defer or parallelize updates to improve perceived responsiveness ends up adding latency rather than reducing it, because the final render still depends on the same pipeline.
Request: Documentation or patterns for optimizing interactive feedback (e.g. fast selection updates) in client-server and web modes, and clearer guidance on when and how to use threading for UI updates.
Environment
Flet (and flet-datatable2 if applicable)
Python 3.x
Desktop / Web target
Thank you for your work on Flet. These improvements would make it much easier to build responsive, keyboard-driven data tables.
Code sample
Code
To reproduce
Environment: Flet + flet-datatable2, Python 3.x, target Desktop or Web.
Minimal reproduction:
Create a page with:
A Dropdown or TextField
A DataTable2 with several rows and columns
Set page.on_keyboard_event = custom_handler so the handler moves a visual "focus" in the table on arrow keys.
Open the dropdown or focus the TextField.
Press arrow keys (Up/Down/Left/Right).
Expected: Only the table reacts (or only the focused control, depending on UX).
Actual: The table focus moves and the dropdown scrolls or the TextField caret moves, because the same key events reach both the custom handler and the native controls.
Scroll limitation:
When moving focus beyond the visible area, there is no API (e.g. scroll_to_row, ensureVisible) to keep the focused row visible; DataTable2 does not expose it.
Threading limitation:
Any UI update must run on the main event loop. Using run_task or run_thread to defer visual updates does not reduce latency; it adds an extra hop and can make the UI feel slower.
Expected behavior
No response
Screenshots / Videos
Captures
[Upload media here]
Operating System
Windows
Operating system details
idk
Flet version
0.81.0
Regression
No, it isn't
Suggestions
No response
Logs
Logs
[Paste your logs here]Additional details
No response