Page 1 of 2 12 LastLast
Results 1 to 20 of 24
Like Tree8Likes
  1.    #1  
    Are there any Night Modes for WebOS like f.lux?
    That seem like the one thing my newer tablet has.

    It’s cool the community is still active, and it makes me happy to see I can still use my HP TouchPad after letting it sit off for 3 years with just some little fixes that people keep writing.
    Preemptive likes this.
  2. #2  
    I have also been wondering about this. Using Redshift on desktop, but i don't know if it would translate.
  3. #3  
    We discussed this at the user group meeting. The comment was that there do not appear to be configuration settings for this. I commented on the ambient light sensor, but I'm doubtful it reads colour - it's very likely to be a simple brightness detector.

    However, there are both front and rear cameras. The interface remains basic, but it's very likely that there is an auto white balance feature - where the colour cast of the image is adjusted for the ambient light. It's possible that perhaps the front camera could be used to get a reading via whatever interface in the system.

    I mention this because i think it's very likely that it is possible to control the colour. If it can be done on other mobiles, it's likely technically possible on Palm phones - assuming that there's something in the readable code for it or if the specs of the display and it's driver are known. Whether or not those things are practical, I don't know. However, webOS is a Linux system and f.lux & redshift work on multiple desktop & mobile systems. They must therefore be 'talking to' a common system interface.

    It seems both have command line access. Redshift assumes the display default is a daylight equivalent and adjusts accordingly. So it may be dialling in an adjustment rather than an absolute setting, but whatever works...

    I've seen it noted that no two displays are exactly the same colour - due to the manufacturing process, but I imagine they are close and for colour-dependant work, default adjustments can be made to the relative colour levels and brightness. I suspect for mobile displays, it's a case of 'close enough' or 'reject' as it's unlikely anyone is doing colour sensitive work on a mobile screen.

    So if anyone with the skills wants to try, I suggest installing a CLI version of either or both of the above programs and attempting to adjust colour via the CLI. If there is no apparent system configuration setting, it may simply be that the screen is at 'default'. If redshift assumes that and adjusts from there, it might be the obvious candidate (maybe f.lux is the same, I don't know).

    Anyhow, if it works, then a simple button GUI for 'day' or 'night' could be built. Then it could be connected to the clock to auto correct (run in background?) and change across the day. The super advanced step would be to sample any auto-white data from the cameras and brightness from the ambient light sensor, allowing the display to alter according to the circumstances, defaulting to the time of day setting.
    Last edited by Preemptive; 10/25/2018 at 10:44 AM.
  4. #4  
    Quote Originally Posted by Preemptive View Post
    If there is no apparent system configuration setting, it may simply be that the screen is at 'default'
    I've been thinking about this, and digging around. A formerly active member, who brought us many great patches (and, it turns out, was once an intern at Palm). Helpfully, he kept all his code on GitHub, including one of my favorite patches -- putting Brightness in the Device menu.
    While I can't find anything to change the color temperature, looking at his code, its clear that its possible to programmatically change the brightness:
    handleBrightSlider: function(event) {
    		this.controller.serviceRequest('palm://com.palm.display/control', {
    			method: 'setProperty',
    		this.controller.get('dm_brightness').innerText = "Brightness: " + Math.round(event.value) + "%";
    I suspect this is one of those serviceRequests that can't be called from the average app. It probably needs special privileges (which I understand can be secured just by spoofing the com.palm.webos app identity).
    I get that color temperature is best for sleep hygiene, but I think changing the brightness on a timer would be a good start. I definitely turn mine down before I put my Pre on the TouchStone for the night.

    I'll start playing with this...

    Confirming that 1) The code works, and 2) It requires that the app have an ID that starts with com.palm.webos
    Last edited by jonwise80; 10/30/2018 at 06:04 PM.
    Preemptive and cbosdell like this.
  5. #5  
    I don't believe, from my recollection, that there is anything to change the color temperature of the display.

    I suspect, however, one might be able to write a framebuffer driver that could apply adjustments. I am also not familiar with the video drivers, but it could be possible that there is something hiding in there.

    I was poking through the redshift code a few days ago and it seems to use X, but I didn't get to deep to see what other interfaces it has.
    Did you know:

    webOS ran on a Treo 800 during initial development.
  6. #6  
    Here's my concept app, I'm calling it "Night Moves" after the 70s movie, and because it moves sliders at night.


    So far just building the UI -- it doesn't actually do anything yet. I've spent a lot of time working around a pretty bad Mojo toggle switch bug.
    Here's the source:
    Last edited by jonwise80; 11/02/2018 at 07:18 AM.
  7. #7  
    It works! The app has three time shift points, and you can set the Brightness for each of them. You can set the Volume, but it doesn't work unless you the have the Audio control panel app open. I need to figure out how to deal with that.
    Its got a lot of bugs at the moment, but its a background app that uses system alarms, so you can kill it and it won't use battery life. When the shift time alarm hits, the app will launch and change your settings. Ideally, then the app goes away -- but I can't figure that part out yet. I might have to use a Dashboard scene...

    Setting alarms is annoying: when you set your time shift time, it needs to determine if that time is later today, and therefore a relative alarm, or if that time has already passed today, and it needs to be an absolute alarm. If you schedule an absolute alarm for today, it fires instantly. Each time an alarm fires, it needs to re-schedule itself for the next day.

    You can downloaded the latest build here:

    PS: Mojo itself has a lot of bugs.
    Last edited by jonwise80; 11/04/2018 at 06:26 AM.
    Preemptive likes this.
  8. #8  
    As there is now an app, I added it as a project to the webOS User Group Agenda.
    webOS User's Online Meet up - webOS Nation Forums
  9. #9  
    Quote Originally Posted by Preemptive View Post
    As there is now an app, I added it as a project to the webOS User Group Agenda
    Looking forward to chatting more about it! It was an interesting learning experience.

    The alarms now work reliably, and I figured out how to launch the app without a scene -- which is nice for true background operation. There's a brief screen flash when the App controller loads the stage, but if you don't have the app open, the stage will immediately dismiss itself. The actual changing of settings only takes a second, but is fraught with holes. For example, the Touchpad will move the Brightness slider as if the setting was changed, but the screen itself often won't change.

    There's also the challenge of properly handling all the launch modes:
    - Launch from an icon tap when the app is not running (must create a scene)
    - Launch from an icon tap when the app IS running (must bring the current scene into focus)
    - Launch from an alarm in the background when the app is not running (must not create a scene)
    - Launch from an alarm in the background when the app IS running (must not bring the current scene into focus)

    And then there's problem of notification. Its easy to create a notification, but system notifications trump app notifications. So you can tell the user "I changed the settings for you" but when you change the setting the system puts its own notification on top of yours (eg: ringer icon on Pre3). On the plus side, when the app is not in use, its not using your battery or system resources at all.

    I'm at 0.1.0 now, so 10 major revisions (link to download above) and things work pretty reliably on my Pre3. I'm still working on making brightness setting more reliable on my TouchPad.
  10. #10  
    Build 0.1.2 is out and fixes a bug that caused the alarm action to fire repeatedly during the minute the alarm happened. Pre3 support is solid now and suitable for daily use (I've been using it on my daily driver Pre3 for the past 2 weeks). I'll be submitting it to the Preware catalog today.

    Touchpad functionality is not quite there yet. The "wake-up" behavior is different on the Touchpad, where apps function differently depending on how long the screen has been off (screen lock timeout has been hit) so I still have some cases to handle.
  11. #11  
    Build 0.1.3 is out and works with TouchPad -- with an important caveat.

    Download it here:

    After hours of experimentation, I'm now quite certain that the TouchPad won't change settings while the lock screen is on. I'm sure this was a security decision, but it was poorly implemented. The sliders in the Device Menu move, but the brightness stays the same. In all other cases, Night Moves works fine on the TouchPad (there was a nasty bug where the screen would wake up and stay awake, but that is definitively solved in this build.)

    If you want to use it on the TouchPad, your choices are:
    • Set the "moves" for times when you know your TouchPad will be charging -- like if you always put it on the Touchstone at night.
    • Use a tweak to disable the lockscreen entirely. There's one in Preware called "Disable Lock Screen" from keyl3om that does the trick.

    Another thing I had to do on the TouchPad was to launch an alert window in order to "wake it up" enough to get the settings applied. This isn't really a problem, just an unusual quirk compared to the Pre3. If you're watching, you'll see it, but it closes itself after 2 seconds, so its really not an issue.

    Anyway, I've updated my PivotCE listing -- but its still pending approval. For now, the GitHub repo is the best place to grab the .IPK.
    There's not much left I want to do with this... I might refactor my Debug mode as an Advanced mode, with more granular controls. And if anyone ever comes up with a way to change color temperature, I'll be sure to jump on it. Otherwise, its pretty useful the way it is. I hope y'all enjoy!
  12. #12  
    Bit late to the party, but I will absolutely try your app.
    Before my phone switch I managed the same functionality with Mode Switcher, only now I am unable to import my settings back from Google Docs.
    jonwise80 likes this.
  13. #13  
    Night Moves 0.1.5 released!

    • Fixes a visual bug on the TouchPad where the notification window used to wake the screen gets left behind after settings are applied
    • Adds "Advanced" menu, where Debug and Precise timers can be set.

    - Debug timers always go off 5 seconds after being enabled. This is useful for debugging.
    - Precise timers allows setting in one minute intervals, instead of 5 minute. Because of webOS timer behavior, timers less than 2 minutes away will be set to tomorrow

    • Adds "Daily Options" to toggle some additional settings off at night and on again in the morning

    - Toggle Notifications disables the alert LED and Lock Screen notifications at night then enables them in the morning
    - Toggle Data connections turns off WiFi and Cellular data at night then turns them on in the morning

    Download it from GitHub:
    Last edited by jonwise80; 12/09/2018 at 03:17 PM.
  14. #14  
    Excellent work! Thanks a lot :-)
    jonwise80 likes this.
  15. #15  
    At 1:50 this morning, my phone woke me up as it re-connected to Wifi, enabled notifications and set the screen brightness to 100%.
    This was problematic because that wasn't supposed to happen until 6:50am -- as it had the morning before.

    Of course, I lay there for an hour trying to figure out why a Night Moves alarm was firing 5 hours early. Finally it dawned on me that my UTC offset is exactly -5.
    Later, when I woke up at the time I intended to, I did some testing and added some logging, then pulled apart the built-in alarm's app. Sure enough what I call "absolute" alarms need to be set in UTC time.

    Relative alarms, used for alarms that happen on the same day, work fine -- which means Night Moves behaves properly on the first day you set it, but are off by your UTC offset on subsequent days. If you tinker with it daily, you won't see this problem, because you keep setting them relatively. Once its run for a day, it starts establishing absolute alarms, and the problem surfaces.

    This should be fairly easy to fix -- stay tuned for a 0.1.6 release!
    Last edited by jonwise80; 12/11/2018 at 08:58 AM.
    Misj' likes this.
  16. #16  
    The UTC discovery required a fair bit of re-writing, but also solved a lot of bugs!
    I had originally written most alarms as relative, because absolute seemed so flaky. Understanding that the absolute alarm was actually 5 hours ahead of what I thought made it clear that if I could handle the timezoneOffset, I could actually make most alarms absolute. The only exception is sub-minute alarms, which still need to be relative. Suddenly instead of handling like 7 different cases, I only need to handle 3 (and a half):

    • Alarm time is in the past: (adjust date to tomorrow, and set an absolute alarm in UTC format)
    • Alarm time is in the immediate future: (set a relative alarm in HH:MM:SS format)
    • Alarm time is later today (set an absolute alarm in UTC format for today)

    The challenge still remains that we want to set a new alarm time at the same time as the current one fires. At that moment, the alarm is both now and tomorrow. Since webOS alarms aren't precise to the second, now is not necessarily the alarm time -- its a fuzzy range around it. This is the "and a half" case, where we have to know that we should actually set the now alarm to tomorrow, because now is in progress.

    With more precision in alarm setting, I was able to remove the Debug mode and do more realistic testing. This surfaced a new TouchPad quirk, where the launch from screen-off behavior is different if the app is already running -- which I was able to resolve. You still need the lock screen disabled, but it works more reliably now.

    Night Moves 1.0 Release
    I did a fair bit of clean-up and added some code comments for posterity. The app is live on Preware now -- but its an old version. In support of an updated listing, I'm releasing this build as a stable 1.0. I'll run it another 24 hours myself before poking the PivotCE folks, but you can get it now on GitHub:
    Last edited by jonwise80; 12/12/2018 at 09:39 AM.
  17. #17  
    So 1.0 had a bug that could leave the TouchPad screen on, and kill the battery. That sucked.
    I found a better way to turn the screen on (and off) that doesn't have this risk.

    These are the test scenarios that uncover all sorts of weirdness. The steps to work around them are crazy...
    1. App open, in focus, screen on - works, screen off after time out (cable out)
    2. App open, in focus, screen off - works, screen immediately back off (cable out)
    3. App open, not in focus, screen on - works, screen off after time out (cable out)
    4. App open, not in focus, screen off - works, screen back off(cable out)
    5. App closed, screen on - works, app quit when done, screen turned off after time out (cable out)
    6. App closed, screen off - works, app quit when done, screen turned back off immediately (cable out)

    Did this testing on both Pre3 and TouchPad, annnnd, AND AND AND, it works with the lockscreen on the TouchPad!
    Turns out, all you need is a little setState with "unlock" and you can bypass it temporarily!

    Grab the Night Moves 1.0.1 Release here:
  18. #18  
    As an aside, I'm just viewing this site with a new 'dark mode' plugin for Firefox. Obviously, this is a slightly different thing and there's the question of whether this could be done just for the browser or for the whole system.

    Maybe this could be done with a theme, but I think it may be a bit of a blunt instrument. There are 'Dark' themes, but nothing that says, "Dark Mode".
  19. #19  
    Quote Originally Posted by Preemptive View Post
    Maybe this could be done with a theme, but I think it may be a bit of a blunt instrument.
    Most of the CSS classes used in Mojo have a "dark" variant. It might be possible to force-ably switch all apps to "dark"...but the results would be unpredictable. This might best be done as a per-app re-pack.
  20. #20  
    Night Moves - Minor Release 1.0.2

    • Fixes a bug where the Pre couldn't clean-up the app after an alarm launch.
    • Added a feature where the morning alarm can be delayed an hour on weekends cause this morning my phone woke me up way too early for a Sunday...

    Preware is getting updated fairly quickly now, or GitHub still works:
Page 1 of 2 12 LastLast

Similar Threads

  1. Mojo Maps for Google - new for 2018
    By George Mari in forum webOS Apps & Games
    Replies: 6
    Last Post: 05/30/2019, 02:38 PM
  2. A (new?) solution (/work-around) for HTTPS sites that won't load
    By jonwise80 in forum webOS Discussion Lounge
    Replies: 17
    Last Post: 01/06/2019, 06:32 PM
  3. Fumbling my way through webOS Development from scratch in 2018
    By jonwise80 in forum webOS Development
    Replies: 30
    Last Post: 01/01/2019, 11:00 AM
  4. Lg WebOS Tv out of memory error
    By jhamond987 in forum LG webOS TV
    Replies: 1
    Last Post: 10/19/2018, 01:39 PM
  5. Lg WebOS Tv out of memory error
    By Sagar Venugopal in forum LG webOS TV
    Replies: 0
    Last Post: 10/19/2018, 07:05 AM

Posting Permissions