Hi Light team — quick question about LightBottomBar behavior, hoping to confirm whether current behavior is the intended direction before I build around it.
What I found
In the current SDK, LightBottomBar enforces this at runtime (sdk/ui/src/main/kotlin/com/thelightphone/sdk/ui/LightBottomBar.kt):
kotlin
require(items.size <= 5) { "LightBottomBar supports at most 5 items" }
val textItemCount = items.count { it is LightBarButton.Text }
require(textItemCount == 0 || items.size <= 3) {
"LightBottomBar with text supports at most 3 items"
}
So a bar with 4+ items throws as soon as one of them is a LightBarButton.Text. All-icon bars are allowed up to 5, but the moment a text button is added the ceiling drops to 3. Because it's a require, it throws at render time rather than surfacing as a compile-time or lint warning.
Why I'm asking
I have a shipped app (Lists) whose bottom bar is 4 items including a text "EDIT" button — gear, sort, EDIT, pencil — and it runs fine on-device:
That layout would fail the check above if rebuilt against the current SDK. My assumption is that Lists was compiled against an earlier SDK version that didn't have this constraint (or had a higher limit), and that the ≤3-items-with-text rule was added more recently.
The questions
Is the textItemCount == 0 || items.size <= 3 rule the intended long-term behavior, or a temporary layout guard?
If it's intended, is a 4-item bar with one text label (like the Lists screenshot) something you plan to keep supporting for already-shipped apps, or should developers migrate those to ≤3 items / all-icon bars?
Would you consider surfacing this as a lint rule rather than a runtime require, so it's caught at build time instead of crashing on first render?
Not blocked — I've already reworked my own app to fit the 3-item limit. Just want to build to the intended target rather than guess, given how quickly the SDK moves. Thanks for the great toolkit.
Hi Light team — quick question about LightBottomBar behavior, hoping to confirm whether current behavior is the intended direction before I build around it.
What I found
In the current SDK, LightBottomBar enforces this at runtime (sdk/ui/src/main/kotlin/com/thelightphone/sdk/ui/LightBottomBar.kt):
kotlin
require(items.size <= 5) { "LightBottomBar supports at most 5 items" }
val textItemCount = items.count { it is LightBarButton.Text }
require(textItemCount == 0 || items.size <= 3) {
"LightBottomBar with text supports at most 3 items"
}
So a bar with 4+ items throws as soon as one of them is a LightBarButton.Text. All-icon bars are allowed up to 5, but the moment a text button is added the ceiling drops to 3. Because it's a require, it throws at render time rather than surfacing as a compile-time or lint warning.
Why I'm asking
I have a shipped app (Lists) whose bottom bar is 4 items including a text "EDIT" button — gear, sort, EDIT, pencil — and it runs fine on-device:
That layout would fail the check above if rebuilt against the current SDK. My assumption is that Lists was compiled against an earlier SDK version that didn't have this constraint (or had a higher limit), and that the ≤3-items-with-text rule was added more recently.
The questions
Is the textItemCount == 0 || items.size <= 3 rule the intended long-term behavior, or a temporary layout guard?
If it's intended, is a 4-item bar with one text label (like the Lists screenshot) something you plan to keep supporting for already-shipped apps, or should developers migrate those to ≤3 items / all-icon bars?
Would you consider surfacing this as a lint rule rather than a runtime require, so it's caught at build time instead of crashing on first render?
Not blocked — I've already reworked my own app to fit the 3-item limit. Just want to build to the intended target rather than guess, given how quickly the SDK moves. Thanks for the great toolkit.