For me it will be too much work in to short time to implement this feature right now and I would consider it a feature freeze right now. And release the 2.0 final next week when the updated manual arrives. Although as I said to you in the email I think this would be a very useful addition to g-s, there are several pitfalls that could easily happen.. only a user logging out, the wrong user being logged on would stop the task from being executed. And there isn't really any way to work around that. The display could change. Lots of things that would need to be sorted out and explained to the user at the time he adds the task.

When it comes to the rsync scripts there isn't actually made any mistakes from gnome-schedules side that I can see. And I would imagine rsync is one of the tools used most executed from crontab.

These are actually two quite different problems and I'll separate them in two reports, if you have collected any more information on the rsync problem it would be great if you could post it in that bug.

*** Bug 557181 has been marked as a duplicate of this bug. ***

To implement this we would have to make a couple of assumptions:

- The current DISPLAY variable will be valid at run time
- The current USER will be logged on at run time

Which means the task will fail to run or maybe even pop up on somebody elses screen whenever this isn't true and display or do unwanted things.. 

We could replace the checkbox and pop up a infobox when this is selected, maybe point to an url or help files explaining better the problems behind. 

Second, but only partly helpful, option is to create a wrapper script that checks for both these things before the application is executed, and if not - don't run the application.

The feature would only be really useful for single-user desktops, where the user is logged on to his desktop when the computer is switched on, which is - as far as i know - our biggest user base.

This would apply to both cron and at.

- gaute

Started working a bit on this in branches/x-output-support.

This bit me again today, as I wanted to start "mplayer dvb://SRC-HD" at 18:30, in order to use gnome-schedule as an automatic television programme starter... but then I needed to do "export DISPLAY=:0 && mplayer dvb://SRC-HD".

What's the status on this, any progress?

Rather slow, but thanks for bumping! Keeps me motivated.

- gaute

Ok - it is now working for crontab - test by checking out the x-output-support branch. you need to do make install somewhere (ie. /home/asdf/tmp/gs, do that with --prefix)

--debug doesn't change much at the moment.

probably heaps of issues.

- gaute

Implemented for at as well - including templates for both. Please test the x-output-support branch.

(plus some code cleanup)

cheers, gaute

xwrapper now does propper checking for both at and crontab. The x-output-branch has been merged into trunk. With a few people confirming that this works I could make a release. There is also a few new strings to translate.

To get the sources, do: 
$ svn checkout http://svn.gnome.org/svn/gnome-schedule/trunk gnome-schedule

See the README for details on building; http://svn.gnome.org/viewvc/gnome-schedule/trunk/README?view=markup


Thanks, Gaute.

I have built the SVN version and as far as I can tell X support still isn't working here. I have set up a recurrent task to run 'xterm' every minute, and it doesn't go off. Testing the task does work, however. I am definitely running the SVN version as I set the prefix to within my home directory, an am running it as './gnome-schedule'. Is there a chance I'm missing something, or is it possibly still broken?

Sorry if it's something obvious, I don't muck about with cron-type stuff much. That's why I'm so interested in GNOME-Schedule; it gives me an opportunity to do so without having to learn all the intricacies of those tools.

Thanks,
Dennis

(In reply to comment #10)
> I have built the SVN version and as far as I can tell X support still isn't
> working here. I have set up a recurrent task to run 'xterm' every minute, and
> it doesn't go off. Testing the task does work, however. I am definitely running
> the SVN version as I set the prefix to within my home directory, an am running
> it as './gnome-schedule'. Is there a chance I'm missing something, or is it
> possibly still broken?
> 
> Sorry if it's something obvious, I don't muck about with cron-type stuff much.
> That's why I'm so interested in GNOME-Schedule; it gives me an opportunity to
> do so without having to learn all the intricacies of those tools.
> 

Hey, thanks for testing. Does your crontab creating dialog look like the one on this screenshot: http://gaute.vetsj.com/?p=134 ?

* Could you create your task with the command: 'xterm > ~/xterm_log' , press Add and re-open it in Gnome-schedule (for editing) and post a screenshot of that ? 

* And post the output of 'crontab -l' ?
* When the task is supposed to have run: the contents of '~/xterm_log' ?
* And (if the xterm task is the one you created last) the output of 'cat ~/.gnome/gnome-schedule/crontab/$(cat ~/.gnome/gnome-schedule/crontab/last_id)' ? 

It is probably still broken :) The requested info would greatly help in figuring out why it doesn't work.

(all commands without the ''s)

Thanks, Gaute

It seems like this is realted to some magic cookies and authentication stuff.. those variables would probably have to be included, i'll update it and post a note here when its ready for more testing.

- gaute

(In reply to comment #10)
> I have built the SVN version and as far as I can tell X support still isn't
> working here. I have set up a recurrent task to run 'xterm' every minute, and
> it doesn't go off. Testing the task does work, however. I am definitely running
> the SVN version as I set the prefix to within my home directory, an am running
> it as './gnome-schedule'. Is there a chance I'm missing something, or is it
> possibly still broken?
> 
> Sorry if it's something obvious, I don't muck about with cron-type stuff much.
> That's why I'm so interested in GNOME-Schedule; it gives me an opportunity to
> do so without having to learn all the intricacies of those tools.
> 
> Thanks,
> Dennis
> 

What kind of desktop environment do you run ?

Could you check if you have anything like consolekit or policykit enabled/running ?

Thanks, gaute

(In reply to comment #13)
> What kind of desktop environment do you run ?
> 
> Could you check if you have anything like consolekit or policykit
> enabled/running ?
> 
> Thanks, gaute

Sorry, bad timing on my part, but I ended up installing Arch Linux and KDE 4 on a whim the other night. I'm running into various walls that make it not *quite* usable though (I always do...), and I'm sure I'll be back to my normal environment before the weekend is through. That environment being GNOME on Ubuntu Intrepid, by the way. I backed up my sources.list, Synaptic markings, and home directory, so the information you requested should follow shortly.

Requested screenshot:
http://i59.photobucket.com/albums/g294/GreySim/sched-1.png


dennis@ubuntu:~$ crontab -l
* * * * * PYTHONPATH=::/usr/lib/python2.5/site-packages/gtk-2.0/:$PYTHONPATH /usr/bin/python /home/dennis/Code/Linux/gnome-schedule-test/share/gnome-schedule/xwrapper.py c 1 # JOB_ID_1
* * * * * PYTHONPATH=::/usr/lib/python2.5/site-packages/gtk-2.0/:$PYTHONPATH /usr/bin/python /home/dennis/Code/Linux/gnome-schedule-test/share/gnome-schedule/xwrapper.py c 2 # JOB_ID_2
dennis@ubuntu:~$ 


xterm_log never gets created.


dennis@ubuntu:~$ cat ~/.gnome/gnome-schedule/crontab/$(cat ~/.gnome/gnome-schedule/crontab/last_id)
ver=5
title=Test
desc=
output=2
display=:0.0
command_d=xterm > ~/xterm_log
dennis@ubuntu:~$ 


This is all on a fresh (Wubi) install of Ubuntu Intrepid, all updates applied from all official sources (including proposed and whatnot), no PPAs except GNOME Do, compiled with prefix=/home/dennis/Code/Linux/gnome-schedule-test and run from /home/dennis/Code/Linux/gnome-schedule-test/bin with './gnome-schedule'.

Trying to apt-get install gnome-schedule doesn't bring any additional packages in, so I doubt I'm missing a basic dependency (unless it's poorly packaged in the repos). I don't actually let the package install--I just let it run to see what else it *would* install, then Ctrl-C the process (I know there's a switch for apt-get that would be kinder, but I don't use it enough to warrant committing it to memory).


Please let me know if there's any more info I can provide.

It's been a while.. I just pushed a small update where I set the XAUTHORITY variable to ~/.Xauthority

Could you test if this works? GS has changed to git since last time; do:
$ git clone git://git.gnome.org/gnome-schedule

add a task to crontab like:
xmessage test and choose X application

Could you verify that you have the file .Xauthority in your home dir?

Thanks, gaute

This worked for me on an almost pristine install of Ubuntu 9.04 using "notify-send" as the application, "X application (supress output)" as the type, and using notify-osd to display the notifications. .Xauthority is indeed in my home dir. I think this is fixed! Thanks!

(In reply to comment #17)
> This worked for me on an almost pristine install of Ubuntu 9.04 using
> "notify-send" as the application, "X application (supress output)" as the type,
> and using notify-osd to display the notifications. .Xauthority is indeed in my
> home dir. I think this is fixed! Thanks!
> 

great! could you just for the sake of testing try with ie. xmessage "test" . to make sure really basic X programs work ? 

- gaute

Worked like a charm.

Good. Closing this. Will be included in the next release.

*** Bug 597613 has been marked as a duplicate of this bug. ***