Ticket #191 (new enhancement)
org.freesmartphone.Device.Display should have signals
| Reported by: | alastair@… | Owned by: | mickey |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | framework/odeviced | Version: | |
| Keywords: | Cc: |
Description
org.freesmartphone.Device.Display has methods to get and set brightness and backlight power, but no signals to inform concerned apps of changes in these settings.
Change History
comment:1 follow-up: ↓ 2 Changed 3 years ago by mickey
- Component changed from documentation to framework/odeviced
comment:2 in reply to: ↑ 1 Changed 3 years ago by alastair@…
Replying to mickey:
Can you give me a use-case?
My config app has a slider to show the current brightness and allow the user to change it. I can use the Get functionality to position the slider correctly at app start, but short of polling using the Get there is no way for it to know of changes in brightness by another app. If there is a 'dim before lock' or a navigation app switches to 'night mode' my app will still be showing full brightness unless I start polling. If there were a second config app running they would end up showing different brightness levels unless both were polling.
Can I turn your question around. If multiple applications can query or change a setting they presumably have a good reason for doing so. What justification is there for assuming that they would not also need to know of a change to that setting?
comment:3 Changed 3 years ago by mickey
You have a point here. I'm a bit reluctant to add too many signals because
- dbus is written for the desktop. It does not care whether anyone is listening for a signal or not, it will broadcast it and wake up processes.
- dbus also has no facility to inform the sender of a signal whether anyone is listening, hence enabling powersaving
- I will probably limit access to org.freesmartphone.Device.* to only one process, which may register with the dbus system as some form of device manager, launcher, etc.
- Most applications should not actually tweak the brightness, but rather use the Resource system ("CPU" and "DISPLAY" resources to come) to specify whether they need to display to stay on and/or the CPU not to suspend.
Can you give me a use-case?