Warning: Can't synchronize with repository "(default)" (No changeset 96d22ec3fa3ef6de3ea8dc0d7d398adc9aa071cf in the repository). Look in the Trac log for more information.

Ticket #191 (new enhancement)

Opened 5 years ago

Last modified 4 years ago

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 5 years ago by mickey

  • Component changed from documentation to framework/odeviced

Can you give me a use-case?

comment:2 in reply to: ↑ 1 Changed 5 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 4 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.

comment:4 Changed 4 years ago by daniel

Are you still reluctant? We're using signals all over the place and (in the case of ogsmd) we're even firing the same signal multiple times so I don't know if that argument is still valid.

Note: See TracTickets for help on using tickets.