search

LibreShift / red-moon

Android screen filter app for night time phone use.
GNU General Public License v3.0
647 stars 81 forks source link

Enable filter from other app #202

Closed mueller-ma closed 3 years ago

mueller-ma commented 6 years ago

Hey,

I want to turn on the filter from another app. How can I do that?

smichel17 commented 6 years ago

What app? Or, more specifically, what options does that app have for communicating with other apps?

smichel17 commented 6 years ago

If it has a way to launch an activity and include extras, then it is possible by launching the main activity with a certain extra. If not, there is currently no way to do this.

Incidentally, there used to be a separate activity whose only function was to toggle the filter and close; I removed it quite some time ago because it was never used, but in retrospect I realize that it was probably there to allow other apps to toggle the filter by launching it.

If the current method does not work from an external app, I can re-add the toggle activity quite easily.

mueller-ma commented 6 years ago

I can add code to the app, so basicly everything is possible

smichel17 commented 6 years ago

You should be able to do it the same way we do the shortcut (lines 22-24). The value of the key for the extra is on line 49 of MainActivity.kt.

smichel17 commented 6 years ago

Note that the only thing you can do this way is toggle; there's no way to stop or start the filter independent of its current state.

The other way you can currently interact with Red Moon is registering to recieve a broadcast when the filter is toggled.

Honestly I don't know of anyone who uses any of these features. Without a concrete use case, it's hard to design a set of controls that makes sense, so I've avoided spending much time on integration with other apps.

@mueller-ma I'd be interested in hearing your use case, if you'd like to share.

mueller-ma commented 6 years ago

openHAB is a free smart home software. Some people use the Android client on a wall mounted tablet and they want that the display gets automaticly dimmed after some time. I started working on this feature (https://github.com/openhab/openhab.android/pull/394), but it isn't that dark I want to have it, so I think about alternative ways, like switching to a darker theme, displaying a large grey object in foreground, using a red moon or integrate some of the red moon code in openhab (but I dont know if GPL 3+ and EPL 1.0 is compatible)

mueller-ma commented 6 years ago

@smichel17 Any updates on that?

smichel17 commented 6 years ago

@mueller-ma I'm going to be pretty absent until the end of the semester; I'll be back in 2-3 weeks.

smichel17 commented 6 years ago

@mueller-ma I'm not quite sure where this issue stands. What do you need?

mueller-ma commented 6 years ago

An easy way to enable a filter from another app (via an intent). I cannot assert that the feature will make it in the openHAB app, but I will try my best.

smichel17 commented 6 years ago

Does the existing way work? Both:

mueller-ma commented 6 years ago

What do you mean with Does it function at all??

smichel17 commented 6 years ago

Wait, never mind, I'm silly. I misremembered things

smichel17 commented 6 years ago

Okay, let's talk design:

mueller-ma commented 6 years ago

On and off will be good. I dont think that I need to switch the filter

gsantner commented 4 years ago

@smichel17 I was also looking for this for pretty much the same reason, and sadly still only toggle ON/OFF and nothing else :/.

for both together, should be about 10 LOC, depending how lean redmoons setting stuff is - but would be quite helpful ~10LOC. Guess for somebody familar with this project this is doable in like 5 minutes.

smichel17 commented 4 years ago

I would accept a PR that allowed setting any of the filter values (color, intensity, dim level, and lower system brightness). One caveat:

I haven't had much energy to put into Red Moon for a while, for various reasons. As a result, I don't currently have a clear roadmap in my head of the changes I'd like to make. At some point, I'll get more energy and come back (or find someone else who can take on the role of primary maintainer). When that happens, I might have a different idea of how I want to do things (I have a vague memory of wanting to change the approach, maybe using a different category of intent?, and that's why I hadn't added anything else to this feature yet).

Therefore, I make no guarantee that the interface will remain stable. That won't stop me from merging, though, since it seems like an easy improvement and I'm not sure how long it will be until I get back to spending time on this.

pazos commented 4 years ago

Hi @smichel17. I'm interested in this feature too and I'm willing to contribute it myself (with some guidance).

My user case: I'm contributing with KOReader, a document viewer, which runs in android via the NativeActivity framework. It is not the typical android app and its primary target are e-ink devices. Besides that it works really nice on modern phones and tablets.

I'm aware that I can take the control of the window from the java side and put there some filtered views but that is not reliable in some targets, mainly e-ink ones, but legacy lcd too because reasons?.

So, instead of that approach, I would rather:

I would love to use/repurpose Red Moon for that, namely for extra-dimming the screen and for simulating wamth. The app has some gestures to control both, see https://github.com/koreader/koreader/wiki/Light-control.

In the android port we only use the left slider if the user checked the option to override android default light levels. My approach would be:

  1. check if Redmoon is installed and then enable extra controls. We have a function that can be repurposed for that in https://github.com/koreader/android-luajit-launcher/blob/master/app/src/org/koreader/launcher/BaseActivity.kt#L351-L360.

  2. if redmoon is available: map brightness values from 50 to 100 with (android) light values from -1.0 to 1.0 and values below 50 with custom calls to Red Moon (calls that modify the dim value but leave others as they are).

  3. map the right KOReader slider with custom calls to Red Moon to modify color temperature.

I guess I would need to do some workaround to check if Red Moon was enabled before running KOReader or not and take specific actions based on that when the user leaves KOReader, but that shouldn't be that difficult.

Please ping me if you see that these changes can fit in Red Moon. I would prefeer that instead of reinventing the wheel.

smichel17 commented 4 years ago

@pazos I'm busy this week; If I don't look into this more by next Friday, you can ping again. For now, quick thoughts without regard for what's technically feasible or how much time I want to spend on it:

pazos commented 4 years ago

I can wait weeks, months or even years. Not in a hurry :smile:

If you can access the view directly, that will be a better user experience; overlay-based filtering will change black to red-black, when really we'd rather leave it pure black and just change other colors (#20 is our issue about that). The math will be a little more complicated because you have to calculate the color yourself, instead of just setting opacity and letting the android compositor do it for you, but that's probably not a big deal (it just happens to be the area of Red Moon that I've left mostly as a black box).

I think I didn't understand. If you mean root kind of permission then nope. If you mean the hability to manipulate the view or to write on top of it then partially: as we extend from NativeActivity the underlay view (called NativeContentView) is not really accesible to us without reflection. Alternatives are create a new surfaceview as the main content and take control of the native window from java (we're actually doing this in a kind of e-ink devices to be able to update the screen, see https://github.com/koreader/android-luajit-launcher/blob/master/app/src/org/koreader/launcher/MainActivity.kt#L93-L99. We can put a ImageView, textureview or whatever on top of that but that doesn't play nice on some devices, so I'm trying to avoid this approach.

As for the color calc we're doing that already for rgb leds, so just need to take alpha in the equation.

This might be a good time for me to look into #122 again.

Yup, sounds good. From the pov of 3rd party apps it should work as long as they don't override brightness params via WindowManager. As google labeled WRITE_SETTINGS as a protected permission modern apps usually use something like this to override their own activity brightness without affecting other applications. In these cases changing the whole brightness level via putInt wouldn't work for these activities.

I'm also not opposed to giving other apps a better way to detect whether Red Moon is working (eg, broadcasting an intent when the filter turns on, or something. Could include current filter values).

Cool, I will play a bit with your code. Are you against exposing an Api to 3rd party apps? I would be useful and complementary to the broadcast receiver. Expose a simple aidl for allowing 3rd party apps to bind to your service and share data via the binder.

BTW, thanks for your time and for this app, it is really nice.

smichel17 commented 3 years ago
mueller-ma commented 3 years ago

I won't need the feature I asked for anymore, so I'm fine with closing this.

smichel17 commented 3 years ago

Okay, I will close this. My other comments still stand — @pazos feel free to open a new issue or PR if you ever want to continue with adding more api surface.