On Sun, 2004-06-06 at 11:19 +0200, Gaute Hope wrote: > 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. I thought the same thing, but for some reason I just restarted the glade-file :-). Reconnecting the few events ain't to hard to do this in the current sourcecode. Moving and replacing all gui-components and to keep their names might be more difficult. Nevertheless it doesn't really matter which starting point will be used. If of course the result is a HIG compliant userinterface. > That would save us for some recoding. I doubt that, but it's not important anyways. > I also thought your add dialog didn't have many functions, don't know > what other people think of this. It should not have many functions. The basic user doesn't want to specify that his or hers task should start every 5th minute of the 6th hour. Thats a setting the advanced user wants to make. And using the advanced tab that user can do just that. The advanced user will, indeed, have to understand the format of the crontab. But a Help-button will display the contents of the manual page of crontab. The problem is that if you enrich the advanced tab to much, you will have to enlarge the window which will easily lead to fragmentation of the components and to putting to much possibilities and options in it. Which will make it much more difficult for the user than five stupid textboxes would do. Or it's VERY easy, or it's as difficult as the current crontab-setting is. But something in between is IMHO a bad idea. You'd create three levels of difficulty and support-people will have to learn how to handle the tree types of users. I fear both the RedHat people as the users of Fedora will dislike that. > 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). For the advanced timeexpressions you could indeed create a small component or a small helper. So that the user does not have to type in "*\2" but for example choose "Every half minute" from a combobox. But the advanced user should still see what the actual result will be. Note that an advanced user most of the times does not want a lot magic. The advanced user 'knows' how to set the crontab. And the advanced user just wants a GUI for it (and many don't want a GUI for it at all). So the primary target-user is the basic user. IMHO it would therefor be good to only focus at the basic-user first. And later create functionality for the advanced user. > 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"> Regretfully I am not familiar with 'at'. I cannot help you with that. > 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. OF COURSE :-). It should be exactly the same. In fact, it should be the same window. the same treeview.. the same application. > 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. Indeed -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org work: Philip dot VanHoof at cronos dot be http://www.freax.be, http://www.freax.eu.org -- Fedora-config-list mailing list Fedora-config-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-config-list