[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

Re: system-config-schedule

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
* 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 Legacy Announce]     [Home]     [Kernel]     [Fedora Legacy]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Red Hat 9 Bible]     [Red Hat 9]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

Powered by Linux