2011-08-23: Minor changes to the process management. 2011-08-02: Now gets default latitude and longitude values from KDE, and when the applet is destroyed it stops redshift/xflux. Also, the default temperature values now match redshift defaults. Thanks to meegee: https://github.com/meegee 2011-07-09: Now, when status is unknown, clicking on the plasmoid tries to relaunch the program after killing redundant processes. 2011-06-28: More robust error detection and bug reports. 2011-06-27: Fixed bug that happened when more than one instance was running at the same time. Also, configuration dialog is now "standard". 2011-06-26: Now you can put the plasmoid in the system tray. 2011-06-25: Fixed bug with default options. 2011-06-24: Fixed bug with Redshift.
I've forked your plasmoid and I've added some improvements (actually I've changed a lot of code, trying to simplify it). Since I've dropped the support for xflux I preferred to create a new page for that plasmoid. You can find it here http://kde-apps.org/content/show.php?content=148737.
I just tried redshift for the first time today, nice to see that there's already a plasmoid for it!
Unfortunately, I ran into two issues that prevent me from using it:
1. The defunct problem mentioned on page 1. An idea may be to look how gtk-redshift does it, it seems to work reliably for me.
2. The settings are not saved between Plasma sessions, at least not when the widget is in the system tray. Don't know if it's related to this bug: https://bugs.kde.org/show_bug.cgi?id=260685
Finally, three suggestions:
a) Put some sensible default values in the options.
b) Detect if user has a config file (e.g. ~/.config/redshift.conf).
c) Activity support! This would be a killer feature - e.g. deactivate f.lux/redshift for your Movie and Presentation activity.
Hi there,
Just wanted to let people know about a problem I encountered. I was getting the "Could not create a python ScriptEngine instance" error message on Ubuntu 11.10. I had Enthought Python Distribution installed in my home folder, and was prepending the path to the EPD python executable in my .bash_profile file.
Removing the prepend fixes this issue. This is a bug somewhere upstream in KDE, I think - they should not be using
#!/usr/bin/env python
instead, they should hard-code to the system python to avoid these troubles.
The code for this plasmoid has no such references, so it must be somewhere upstream.
First of all, thank you for the brilliant widget - I didn't like having GTK3 installed just for an indicator that's not as full-featured as yours.
However, I did have problems with defunct processes and the applet not stopping Redshift properly so I hacked it to use KProcess instead to start and manage its process. KProcess (as it is derived from QProcess) has signals that are emitted when a process is started/stopped, removing the need to keep a timer, for one.
This is a hack, however, and I only link to the patch as a reference of sorts.
I made the following changes:
Remove the Unknown state and use the same light bulb icon when the applet is on. Though it could be useful if self.process.state() == QProcess.Starting...
Remove f.lux support. I'm too lazy to perform the changes for f.lux, too, and I don't use f.lux because it's closed and couldn't maintain a dimmed state on my computer.
Use KProcess to start and manage the process - instead of the timer, use QProcess's signals
Send SIGUSR1 instead of terminating/suspending the process to change Redshift's state
Now I can click on the widget when it's running and have Redshift start/stop depending on the state accordingly. Killing Redshift manually from the terminal will change the applet's icon back to the offline one and I can press the applet's button to have it start up Redshift again.
http://pastebin.com/zxMK5Rvp
Hey, thanks! Great work! I'll take a look when I have time. Your patch sounds good, but I'm not sure I'll drop x.flux support. It's complicated since redshift and x.flux are managed in very different ways, but I think I'll try to keep both at least for now. But for redshift, as I said, I'll apply the changes when I have time.
Anyway, thanks again for the coding and the effort you put :)
I do have the patch: http://box.jisko.net/d/4a8fe3ff
I promised myself to work in the issue, but time is not a thing that I have in great quantities right now...
I notice another bug.
When xflux is running I can't turn it of.
This is the result of ps:
0 Z 1000 18989 18955 0 80 0 - 0 exit pts/1 00:00:00 xflux <defunct>
1 S 1000 18990 1 0 80 0 - 1206 hrtime pts/1 00:00:00 xflux
There are two xflux process, so the command "pidof xflux" return two id, and the plasmoid can't get the status of the program. ("Unknow status" is printed)
Now it works, but that workaround is not perfect. Infact the icon is still the unknown status icon (the red one) and even in the console output I get unknow status.
It's strange that two xflux process are launched and one of it die even with only one instance of the widget.
I think that's because one of your processes is in zombie status and thus can only be terminated by a "kill -9" [1]. The plasmoid doesn't (or souldn't) create zombie processes. I've tried but i can't reproduce it. What I've succeeded to test is launching two xflux processes (one of them using the console), and the plasmoid can terminate both. I don't know how you ended up with a zombie xflux, but I don't think that was because of the plasmoid but because xflux itself.
[1] Using kill -9 to terminate the program doesn't seem like a good idea. Being programs that affect screen properties, I'd rather wait for them to exit themselves normally.
PS: I'm thinking about using kill -9 in cases like this, when you end up with zombie processes... but first I'd like to confirm if this happens frequently.
os.wait or os.waitpid maybe can solve this problem. But I haven't found a solution till now.
Another suggestion: do not reimplement the showconfiguration interface. If you comment out this function you'll see a dialog like all the others plasma settings dialog. Then you have just to add a name and an icon to the page that you are adding in createconfigurationinterface.
I followed your suggestion about the config dialog, and it feels more integrated now.
About os.waitpid, I'll try to take a look at it tomorrow and see what I can do. Thanks again.
Thank you for the tip. I was a little bit lost among all the subprocess management functions python has, although at the moment I only used this function to detect launch errors. For the "unknown status" or zombie processes situations, I don't know yet how to handle them correctly. Now I'm sending them sigkill signals when i found more than one process running, but may be it's too drastic (for what I said previously, only unresponsive processes should be stopped this way).
In the next few days I won't have much time, but next week I intend to do some research about finding zombie or unresponsive processes so I can send the appropiate signal to each one.
You said you still have problems with the defunct subprocess. What is the scenario when it shows up? Only one, defunct subprocess, or more than one? (is the icon green, red or gray?)
At the beginning there are no process (nor active or defunct). When I click the grey icon the program starts and the icon become red. At this point there are an active process and a defunct one. If I click the icon it becomes grey, the program is stopped and there are no active or defunct process at this point. I can repeat the procedure and everything goes in the same way (so there are always only one defunct process while the program is running).
I don't know Python, but I have the "defunct process" problem with kde 4.7 and redshift.
I have read your code, you want to use os.waitpid and os.kill, but these methods are directly supported by the class Popen.
If you only use your Popen object, I think it would be simpler, you can use the following methods from Popen :
* send_signal to send a SIGUSR (toggle on and off redshift)
* poll, to get the returncode and know if the process is running or not
* wait
* kill (SIGKILL signal), and terminate (SIGTERM)
I've made some tests using methods from Popen, and your plasmoid do not produce defunct processes. ;)
But it requires to update the code of checkstatus and updatestatus, and I don't have enough time for that.
hcartiaux, thanks a lot for your reply. I didn't know that you could stop redshift whithout killing it. I've made a little experiment and seems to work quite well, but I don't have much time either, so I only made minor changes to use the Popen object when available (it won't be available only in case redshift / xflux was instantiated outside the plasmoid). There's no difference in behaviour yet, I think (because I can't reproduce the defunct process situation, it's a little difficult to me to correct that bug...), but at least now the process management is a bit more "correct".
I'll take a deeper look into it when I have time, because using SIGUSR instead of SIGTERM/SIGKILL to stop redshift will require to rewrite a great portion of the plasmoid.
If you add this line to the metadata.desktop
X-Plasma-NotificationArea=true
it can be possible to put the plasmoid in the system tray (from system tray settings).
I like to put it in the tray.
Ratings & Comments
38 Comments
I've forked your plasmoid and I've added some improvements (actually I've changed a lot of code, trying to simplify it). Since I've dropped the support for xflux I preferred to create a new page for that plasmoid. You can find it here http://kde-apps.org/content/show.php?content=148737.
I just tried redshift for the first time today, nice to see that there's already a plasmoid for it! Unfortunately, I ran into two issues that prevent me from using it: 1. The defunct problem mentioned on page 1. An idea may be to look how gtk-redshift does it, it seems to work reliably for me. 2. The settings are not saved between Plasma sessions, at least not when the widget is in the system tray. Don't know if it's related to this bug: https://bugs.kde.org/show_bug.cgi?id=260685 Finally, three suggestions: a) Put some sensible default values in the options. b) Detect if user has a config file (e.g. ~/.config/redshift.conf). c) Activity support! This would be a killer feature - e.g. deactivate f.lux/redshift for your Movie and Presentation activity.
Hi there, Just wanted to let people know about a problem I encountered. I was getting the "Could not create a python ScriptEngine instance" error message on Ubuntu 11.10. I had Enthought Python Distribution installed in my home folder, and was prepending the path to the EPD python executable in my .bash_profile file. Removing the prepend fixes this issue. This is a bug somewhere upstream in KDE, I think - they should not be using #!/usr/bin/env python instead, they should hard-code to the system python to avoid these troubles. The code for this plasmoid has no such references, so it must be somewhere upstream.
I have the same problem but don't know how to fix it in kubuntu 11.10 kde 4.8 rc2
First of all, thank you for the brilliant widget - I didn't like having GTK3 installed just for an indicator that's not as full-featured as yours. However, I did have problems with defunct processes and the applet not stopping Redshift properly so I hacked it to use KProcess instead to start and manage its process. KProcess (as it is derived from QProcess) has signals that are emitted when a process is started/stopped, removing the need to keep a timer, for one. This is a hack, however, and I only link to the patch as a reference of sorts. I made the following changes:Remove the Unknown state and use the same light bulb icon when the applet is on. Though it could be useful if self.process.state() == QProcess.Starting...
Remove f.lux support. I'm too lazy to perform the changes for f.lux, too, and I don't use f.lux because it's closed and couldn't maintain a dimmed state on my computer.
Use KProcess to start and manage the process - instead of the timer, use QProcess's signals
Send SIGUSR1 instead of terminating/suspending the process to change Redshift's state
Now I can click on the widget when it's running and have Redshift start/stop depending on the state accordingly. Killing Redshift manually from the terminal will change the applet's icon back to the offline one and I can press the applet's button to have it start up Redshift again.
http://pastebin.com/zxMK5Rvp
Hey, thanks! Great work! I'll take a look when I have time. Your patch sounds good, but I'm not sure I'll drop x.flux support. It's complicated since redshift and x.flux are managed in very different ways, but I think I'll try to keep both at least for now. But for redshift, as I said, I'll apply the changes when I have time. Anyway, thanks again for the coding and the effort you put :)
I don't actually have the patch anymore, sorry, but I'll try to recreate it very soon.
I do have the patch: http://box.jisko.net/d/4a8fe3ff I promised myself to work in the issue, but time is not a thing that I have in great quantities right now...
I notice another bug. When xflux is running I can't turn it of. This is the result of ps: 0 Z 1000 18989 18955 0 80 0 - 0 exit pts/1 00:00:00 xflux <defunct> 1 S 1000 18990 1 0 80 0 - 1206 hrtime pts/1 00:00:00 xflux There are two xflux process, so the command "pidof xflux" return two id, and the plasmoid can't get the status of the program. ("Unknow status" is printed)
Thank you again. Bug fixed :)
Now it works, but that workaround is not perfect. Infact the icon is still the unknown status icon (the red one) and even in the console output I get unknow status. It's strange that two xflux process are launched and one of it die even with only one instance of the widget.
I think that's because one of your processes is in zombie status and thus can only be terminated by a "kill -9" [1]. The plasmoid doesn't (or souldn't) create zombie processes. I've tried but i can't reproduce it. What I've succeeded to test is launching two xflux processes (one of them using the console), and the plasmoid can terminate both. I don't know how you ended up with a zombie xflux, but I don't think that was because of the plasmoid but because xflux itself. [1] Using kill -9 to terminate the program doesn't seem like a good idea. Being programs that affect screen properties, I'd rather wait for them to exit themselves normally. PS: I'm thinking about using kill -9 in cases like this, when you end up with zombie processes... but first I'd like to confirm if this happens frequently.
os.wait or os.waitpid maybe can solve this problem. But I haven't found a solution till now. Another suggestion: do not reimplement the showconfiguration interface. If you comment out this function you'll see a dialog like all the others plasma settings dialog. Then you have just to add a name and an icon to the page that you are adding in createconfigurationinterface.
I followed your suggestion about the config dialog, and it feels more integrated now. About os.waitpid, I'll try to take a look at it tomorrow and see what I can do. Thanks again.
Thank you for the tip. I was a little bit lost among all the subprocess management functions python has, although at the moment I only used this function to detect launch errors. For the "unknown status" or zombie processes situations, I don't know yet how to handle them correctly. Now I'm sending them sigkill signals when i found more than one process running, but may be it's too drastic (for what I said previously, only unresponsive processes should be stopped this way). In the next few days I won't have much time, but next week I intend to do some research about finding zombie or unresponsive processes so I can send the appropiate signal to each one.
I've installed the 0.2.5 version an now xflux works perfetly. Good job!
Actually I still have problem with the defunct subprocess.
You said you still have problems with the defunct subprocess. What is the scenario when it shows up? Only one, defunct subprocess, or more than one? (is the icon green, red or gray?)
At the beginning there are no process (nor active or defunct). When I click the grey icon the program starts and the icon become red. At this point there are an active process and a defunct one. If I click the icon it becomes grey, the program is stopped and there are no active or defunct process at this point. I can repeat the procedure and everything goes in the same way (so there are always only one defunct process while the program is running).
Ok, i uploaded a minor change, hope it helps. Anyway, it's a temporal fix, I intend to do some research, but I don't have much time nowadays :(
I don't know Python, but I have the "defunct process" problem with kde 4.7 and redshift. I have read your code, you want to use os.waitpid and os.kill, but these methods are directly supported by the class Popen. If you only use your Popen object, I think it would be simpler, you can use the following methods from Popen : * send_signal to send a SIGUSR (toggle on and off redshift) * poll, to get the returncode and know if the process is running or not * wait * kill (SIGKILL signal), and terminate (SIGTERM) I've made some tests using methods from Popen, and your plasmoid do not produce defunct processes. ;) But it requires to update the code of checkstatus and updatestatus, and I don't have enough time for that.
hcartiaux, thanks a lot for your reply. I didn't know that you could stop redshift whithout killing it. I've made a little experiment and seems to work quite well, but I don't have much time either, so I only made minor changes to use the Popen object when available (it won't be available only in case redshift / xflux was instantiated outside the plasmoid). There's no difference in behaviour yet, I think (because I can't reproduce the defunct process situation, it's a little difficult to me to correct that bug...), but at least now the process management is a bit more "correct". I'll take a deeper look into it when I have time, because using SIGUSR instead of SIGTERM/SIGKILL to stop redshift will require to rewrite a great portion of the plasmoid.
If you add this line to the metadata.desktop X-Plasma-NotificationArea=true it can be possible to put the plasmoid in the system tray (from system tray settings). I like to put it in the tray.