Btw,

I have to repeat the stop-killall-start routine everytime I reboot my phone, in case someone wanted to know this. This is not major problem for me, only mildly annoying.

--
Kossuth

@hxka: timenowd (the daemon itself) gets properly killed with sighup, upstart just loads it again. If you stop it using initctl it does indeed stay running but then a killall -HUP finishes it for good. I don't know what I can possibly do about this bug.

@Kossuth: I can't reproduce. Here it starts fine after reboot (I've got busybox power)

@qwazix 0.0.2 wasn't get killed with -HUP, I tried.

And su for some reason don't kill run-standalone.sh, even in stock busybox, so it's not busybox-power's fault.

And I can reproduce it. For me proximityd is stopped after reboot.

I will push a new version to devel in a little while with a configuration file. In the file you can change colors and add two more lines of information which can include terminal commands.

I need a bit of help however: Text2Screen for some weird reason messes up coordinates really bad, so I cannot find acceptable default values for information lines 3 and 4, so I included those in the configuration file set to 0.

Please test with various values (best way is to edit file via ssh and just cover the proximity sensor to test the new values)

Configuration will reside in ~/.timenow/settings.ini
You can safely remove the file and it will be recreated automatically with the default values.

@hxka, I tried removing the run-standalone.sh from the upstart stanza: The application doesn't print anything to screen after that, and the problem of not stopping after stop timenowd remains. Here, the latest version always hangs up after -HUP and prints hangup to stdout. So it seems it's something about su not relegating SIGHUP to it's children.

Yes, same here, the proximityd doesn't start. I'm using BusyBox v1.20.2 (Debian 1.20.2power1).

Is there some log or otherplace I could start poking around for the cause? Maybe another application is preventing the start?

Kossuth

What proximityd version do you have? 0.2.2 here

Version of the proximityd is 0.2.2, but I also have a package called proximityclock installed with version 0.3 (came up when searching for the proximityd)

Kossuth

I've been a happy "long-term" user of timenow. I really like it. But I still find myself using the power button or the slider switch on the side of the phone (what's the proper name?) quite often to check for missed calls, sms, etc.

Now I noticed that the 'nose' on that slider switch is wearing out, i.e. it's almost flat.
This made me think that it would be awesome to have more info on the timenow screen, like said missed calls indicators. Of course, that would be duplicated functionality as there's the lockscreen showing that stuff already.

So, I know you had an earlier version showing the lockscreen instead of writing on the framebuffer. Do you think it would be viable to try and go down that route again? Do you have that old code lying around somewhere for me to look at?

foobar, that would be the perfect solution. I drifted away from that because I was unable to trigger a fake powerbutton press from within a qt application. I don't think I have any code from that early but the principle was simple. Instead of running text2screen (see timenow source) this script should be run. Unfortunately, whatever I tried, the lockscreen didn't come on.

If you can find a less hacky way to bring the lockscreen in front, it would solve all our problems. Idea: maybe studying qtlockscreen code could help.

Another idea is to have a window without any controls on it and do the following process

1. unlock
2. draw window
3. wait for timeout
4. destroy the window
5. lock

This would be very nice as the qml code would reside on device and anybody could change the code to customize the screen as much as he wants. We could also have downloadable qml files (themes) but I fear that constructing the window will take too long. Also I don't know how to launch a window from a daemon. Of course I can launch another gui application but that will definitely take too long, unless the app is already running.