Modals, Button Presses, Keyboard update, Progress Bar by dupontgu · Pull Request #114 · lightphone/light-sdk

dupontgu · 2026-07-20T18:26:39Z

The primary purpose of this PR is to get hardware button presses working in tools.
- Tools now have the option to intercept most hardware button presses: wheel counter/clockwise, wheel click, camera half/click, volume up/down.
- Any unconsumed button events will be passed along to the server/LightOS to be processed (so brightness/volume adjustments can still work while external tools are foregrounded.
- with this ^, we've given the server the ability to take over the screen when a button is clicked, and then return to the tool where the user was previously when finished. (For example - LightOS is responsible for displaying the Volume overlay)
- Added basic ringer volume settings to the emulator to test/demo ^.
Modals - added a simple API in the ui module for both tools/the server to launch transient modal overlays on top of the normal app UI
Tightened up the tool authentication flow with the server, we noticed in certain situations they can get out of sync and the server would start rejecting remote service calls from valid clients.
Added "progress bar" ui element. There is a settable version as well (put finger down to set the progress)
Pulled bumped Lp3Keyboard version from 0.0.11 -> 0.0.16
- Fixed small bugs around caps button
- Laid groundwork for swapping root layouts (Colemak added!)
- Laid groundwork for swipe typing (!!!!!)
- Added support for external keyboard.

Reminder that if you are testing new features, they might not be available in LightOS yet. As of posting this PR, LightOS 568 is the latest for LPIII, and that will not yet be able to handle button presses forwarded from your tools

…anying shared UI

0x09f · 2026-07-22T10:40:57Z

I'm very much a Kotlin noob so this is probably a dumb question, but why not use a multiline string for this?

great Q honestly, that's one of the features I always forget about. I used appendLine for the dynamic stuff and then just duped the line a bunch. Will change.

0x09f · 2026-07-22T10:44:00Z

    }

+    private val Int.isSystemKeyCode: Boolean
+        get() = (this == KeyEvent.KEYCODE_BACK || this == KeyEvent.KEYCODE_HOME)


What's the circumstance when the Android BACK button will actually be emitted, given that the LP3 doesn't have a hardware one?

back handling is mostly for emulator, external keyboard users, or if folks want to ship their tools on non-light devices!

Also, probably flip!!

0x09f · 2026-07-22T10:45:56Z

        displayVoice = result.displayVoice,
-        enableKeyAnimation = result.enableKeyAnimation
+        enableKeyAnimation = result.enableKeyAnimation,
+        swipeEnabled = false


This is necessary because of the keyboard version bump? Will this ever be updated to true?

Great callout - I think I was avoiding adding a new field to the response before necessary but now's probably the perfect time to do it.

0x09f · 2026-07-22T10:47:55Z

+        runCatching { ctx.unbindService(this) }
+            .onFailure { Log.w(TAG, "Failed to unbind service", it) }
+        bound = false
+        bind(ctx, pkg)


I'm unfamiliar with this lifecycle, could this error loop?

to my knowledge, no - bind calls bindService which just returns false if it fails.

0x09f · 2026-07-22T10:52:15Z

+    }
+
+    fun onDeviceKeyEventRequest(request: LightServiceMethod.DeviceKeyEvent.Request): AudioModal? {
+        if (request.action != ACTION_DOWN) return null


This is again probably due to my lack of context, but would this handle the case where the user is just holding the button down to move the volume up/down repeatedly, ie key repeat?

yep, ACTION_DOWN is sent repeatedly with a repeatCount field.

0x09f · 2026-07-22T10:52:52Z

+}
+
+// Modeled after LightOS volume rocker modal
+// In ideal world, this will be used directly in LightOS


Meaning this would be factored out into a tiny standalone package that LightOS can import directly?

yep! or just pulled up from the emulator module into the server module which is shared.

0x09f · 2026-07-22T10:58:26Z

-        // DO NOT REORDER/REMOVE
-        Unknown, Removed, InvalidParameters, NoPermission;
+        // DO NOT REORDER/REMOVE — ordinals are sent over the binder wire. Append new codes only.
+        Unknown, Removed, InvalidParameters, NoPermission, InvalidToken;


Should this just be sent in some other format over the wire to prevent that possible bug?

I'm probably unnecessarily allergic to using strings for this, but there's really no reason this should ever change. I think the easy way to safeguard is to just have a unit test that verifies hardcoded ordinals.

0x09f · 2026-07-22T11:00:48Z

        insertAtCursor(buildString { appendCodePoint(code) })
    }

+    override fun onSubmitWord(word: CharSequence) {


Is this something that was enabled by swiping in the keyboard upgrade? If so, why is this necessary if swiping is currently not supported in tools keyboards?

It technically is supported! We just don't have a default model yet. And in this case, there are likely going to be other layouts that need to submit multiple chars at once.

0x09f · 2026-07-22T11:02:52Z

+
+    private var dismissJob: Job? = null
+
+    /** Show [modal] over the UI, replacing any current modal and restarting the dismiss timer. */


So in other words there's no modal stack state? ie if Modal A has a dismiss duration of 5 seconds, and Modal B is 1 second -- after Modal B appears over Modal A and then is removed 1 second later, Modal A will be cleared early? Not that it really matters I guess.

That's a very good point and worth considering actually, but so far these are explicitly meant to replace each other. conceptually they take up the same "space"

0x09f

This all seems fine to me! I'm definitely a Kotlin noob though so worth getting another set of 👀

brunoro · 2026-07-22T19:33:31Z

+
+    override fun onKeyUp(keyCode: Int, event: KeyEvent): Boolean {
+        return if (keyCode.isSystemKeyCode) {
+            super.onKeyDown(keyCode, event)


Suggested change

super.onKeyDown(keyCode, event)

super.onKeyUp(keyCode, event)

brunoro · 2026-07-22T19:38:33Z

+     */
    var permissionActivity: Class<out Activity>? = null

+    var rootActivity: Class<out Activity>? = null


I couldn't find where this field is used

brunoro · 2026-07-22T19:59:31Z

Looks great overall! Some review and LP3 testing notes:

modals worked as expected
new native LP3 keyboard is amazing! so responsive
found one small bug worth fixing in the progress bar event handling
found and one potential bug on the keyDown callback
progress bar example is missing a back button to return to the menu
it would be nice to have a demo to check for button presses

drag listener already catches tap events

brunoro

alright, fixed the 2 blocking issues and added the back button.
now adding the key events UI demo screen

dupontgu added 3 commits July 15, 2026 16:56

allow key event forwarding to server, update emulator to demo, accomp…

bd44b6b

…anying shared UI

pull in latest keyboard, text editor fixes

cd5356b

add progress bar to ui demo

24bcc05

dupontgu requested review from 0x09f and brunoro July 20, 2026 18:32

0x09f reviewed Jul 22, 2026

View reviewed changes

0x09f approved these changes Jul 22, 2026

View reviewed changes

pr fixes

0e14b57

brunoro requested changes Jul 22, 2026

View reviewed changes

brunoro and others added 3 commits July 22, 2026 18:51

fix: remove unnecessary tap gesture listener

347d47e

drag listener already catches tap events

fix: progressbar ui example has back button

3e628fe

fix: forward onKeyUp correctly

1a46a9b

brunoro approved these changes Jul 22, 2026

View reviewed changes

feat: key events UI demo screen

61ef725


		private var dismissJob: Job? = null

		/** Show [modal] over the UI, replacing any current modal and restarting the dismiss timer. */

	super.onKeyDown(keyCode, event)
	super.onKeyUp(keyCode, event)

Uh oh!

Conversation

dupontgu commented Jul 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0x09f left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

brunoro commented Jul 22, 2026

Uh oh!

brunoro left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

brunoro left a comment •

edited

Loading