Edit: Didn't see this ^^^^^^^^
What the hell is CVS? I'm not up to speed on your moon-speak.
No interest in this?
I can post my source code if anyone is interested....
I'm interested... but busy as hell and I don't plan on ever coding anything in VB (unless someone drops some serious cash in my lap). Deciding on a language isn't important at this point. We can use the message board here to communicate and cvs isn't necessary as long as people either post their code here or link to it (either is acceptable and posting it invites commentary from others which is a good thing). Besides, we need to do quite a bit of discussion about the overall functionality, features, reqs, design, etc before getting caught up in coding (do I sound like an instructor?).
Here are my initial design thoughts....
The main program will be a fah wrapper program (for lack of a better term) that implements various modules (in italics below). This program gets configuration info from a text file. A seperate gui program is used to generate the text file. This is very flexible allowing people to change the configuration by hand or with a gui - and makes debugging about 10x easier. Also, two or more gui's can be written in different languages if people are intested in writing them. You're not stuck having to use some gui libs that you don't like because the modules are written in C or VB or whatever.
The gui program is able to configure all module functionality. IMO, this seperation has some huge benefits:
First, the wrapper program and gui can be implemented in differnt languages. Indeed, seperate wrapper programs can be implemented for each platform. For example, a wrapper program can be written for linux in C, in vb for windows, python for the mac with a gui program for all platforms written in Java. This seperation provides a lot of language flexiblity and opens up the linux/mac platforms which is nice (especially since I want to see how fast dual G5's are!).
Second, we're seperating the things that change (the os dependent parts) from the things that stay the same (module configuration) which is always a good idea. If only a windows wrapper program were created, this seperation is still important because the modules are likely going to be different on different versions of windows, and if something changes in the future (it will!), we won't need to change the gui configuration program, only the wrapper modules.
Here are the modules I came up with....
- simply starts the fah console or gui.
start on reboot
- creates a registry key or adds far to the 'startup' folder. Maybe cron on a linux or mac system.
- basically what you've been working on
and an advanced install
- for dualies and to allow other installation options
- a module to remove fah from the windows taskbar.
- a module to email the user a notification when the client finishes a wu. Later, add functionality so that an email can be sent when 50%, or some other amount, is finished.
ftp partial wu's
- this module will ftp the work done on an incomplete wu for people who are installing fah on computers that might get shutdown (the frequency to be set by the user).
email partial wu's
- same as above, but via email.
- a module that hides the fah directory on the windows desktop. A lot of times, this is the only place I can create a directory and if I can somehow hide it... good.
I had a couple of other ideas.... I'll add them later as they pop back into my head. Of course, intitally, what we need are the start, install, hide and restart modules and a gui configuration program.