Good day. I have thought of the thing about GtkFixed widget and i planned to change it. I looked at your glade file and thougt it would perhaps be easier to change the existing GUI to something more like yours, or after the HIG. I agree that at least my design could use much improvments. That would save us for some recoding. I also thought your add dialog didn't have many functions, don't know what other people think of this. Mine is probably far from perfect but at least in the advanced editing mode I think we could use more like mine. It would help those that only know cron a bit to use some more advanced timeexpressions like ranges(5-9) and every Xth(*\2). And I know my 'at' interface shouldn't even be mentioned as an option :) I mostly made it to get a working version. I think the easiest way to do this is by replacing the current crontab, this of course could be a bit anoying if users put variables like 'MAIL=<user>' and they would be replaced.. The tool would probably see this as a job and output a lot of bogus in the treeview. This may also happend if we go for the idea of having titles in comments after each command, if someone edit this manually it might destory the file for system-config-schedule. We could put in tags like: * * * * * reboot # <"Reboot"> To make it more unlikly for someone to write this in as comment on their own, and for the program to ignore titles that isn't in this format. Concerning the 'at' managment I think the best would be to make it look as much as possible as the crontab managment design we go for. Then the user wouldn't have to understand two interfaces. And the add dialog for an 'at' job should contain a calender. That could be the advanced mode and the simple could contain options like: * Tomorrow * In: [ ] hours * In five minutes The editing of an allready existing 'at' job would probably be to delete it and add a new one. We would then have to deal with all the environment variables 'at' put at the beginning of each job. The removment of "update" jobs, as you suggested, is probably best. In the 'at' configuration each job is added or removed on the fly as you do it, which probably isn't desired as people tend to do a lot of mistakes. And the info provided in the treeview for 'at' is pretty useless except the execution time. btw, if you are gonna start develop this tool aswell we realy need a CVS. I could perhaps get one running at a server, but one at fedora/redhat would of course be best. - gaute PÃ su , 06/06/2004 klokka 02:23, skreiv Philip Van Hoof: > Hi there Gaute (and of course the people on this list), > > I have checked out the glade-file a bit and have two big remarks: > > * You should avoid the usage of the GtkFixed widget. It will make your > application unresizable :( > > * You might also want to read the Human Interface Guidelines, for UI > design you did some very common mistakes which actually are a standard > in the current version of the GNOME HIG. > > > I have attached a glade file. It uses a layout that looks a lot like the > other ^system-config-.*$ tools included with Fedora. It should be HIG > compliant (but of somebody finds quirks or mistakes, please do fix or > report it). > > I really do suggest that you use or this GUI or create a new one. You > GUI really is to difficult to understand. I do understand how you try to > ease it for the user, but it's the way the crontab is represented to the > user that will make the difference between a tool that will be used, or > a tool that will be ignored. > > In the TreeView I would put a minimum of columns. For example the > frequency and the command. Perhaps (if possible) also a title that > actually has no real meaning for the system. Maybe by adding it as a > comment to the actual crontab-record? > > +-----------------+-------------------+----------------------------+ > | Title | Frequency | Command | > +-----------------+-------------------+----------------------------+ > | Backup files | Every day | /opt/bin/mybackup.pl | > | Restart webserv | * 1 * * * | /opt/bin/restartapache.pl | > +-----------------+-------------------+----------------------------+ > > If the frequency is 'easy' then the "Basic" in the in add_window could > be used. If that frequency is 'advanced' then the advanced tab should be > used and the basic tab not selected by default. > > Updating and creating entries will reuse the same GUI, of course: > add_window. > > You will have three important buttons: > > Add, Properties and Delete > > - Properties will show the add_window for the selected record. > - Add will show the add_window for creating a new record > - Delete will remove the selected record > > Ok means OK. It does not mean: OK in memory but you will have to restart > the crontab or import the memory to the crontab or whatever. No, OK is > OK. OK means that the user agrees that the crontab is going to be set. > Period. Cancel means cancel all changes in this window. > > So there is only one window that can 'set' the crontab: add_window. And > there should not be a refresh-button for this is not needed (unless, > perhaps, an external application can change the crontab while > system-config-schedule is working with the crontab. Then still this > should not matter to much, as the tool should update record per record > and should not try to set the entire crontab on every change. Unless of > course there is no other way). > > I am planning to, by using your current code as sample, implement the > GUI that I created, some day. Unless of course you are planning to > recode your implementation to this GUI or significantly improve and > HIGify your GUI. > > I now feel the need for a system-config-schedule or system-config-cron > (I too prefer system-config-schedule, so lets go for that name). > > So .. Lets create this tool..
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-config-list mailing list Fedora-config-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-config-list