As SimonQian wrote: > I am writing on Lazarus a Gui for Avrdude which is yaAG -- yet > another Avrdude Gui.
Please don't -- not this way, I mean. You've already demonstrated one of the reasons yourself. To summarize: . You have to play catch-up with each new AVRDUDE release. . You have to parse the config file again. If/when AVRDUDE changes its config file format, you start over from scratch. . The round-trip to execute the AVRDUDE binary is dog slow, in particular when using Atmel's USB-based tools which disconnect from and reconnect to the USB after each command invocation. . It's pointless to have the AVRDUDE binary provide human-readable diagnostics which you then try to read again with a machine. I recently rigorously divided AVRDUDE in a backend library that contains all the knowledge about devices and programmers, plus a frontend main.c that implements the classic AVRDUDE command-line user interface. As such, it should be easily (well, relatively easily) possible to stuff a GUI instead of main.c in front of the library. This solves all the above issues in a very elegant way: . Such a GUI will automatically participate from any changes made to device or programmer support. . If the config file parsing changes in future, the GUI does not have to care with it (unless changes in the API are also needed, which could e.g. be possible to support things like the Xmega or maybe some AVR32 devices). . The entire GUI-based AVRDUDE will open the programmer once, and close the session when finishing. By that time, the programmer can disconnect from USB without annoying the user more than what will annoy them anyway. . The entire passing of data and status information is done within the GUI-based AVRDUDE, no separate parsing needed. I once started a small proof-of-concept wxWidgets-based GUI to just demonstrate the library split basically works the way I thought, and I believe there's at least one developer here who intends to build a GUI based upon that idea. If so, I'd welcome any combined effort to achieve that goal faster. Basically, I don't care about *which* GUI toolkit is used as long as the current Unix/Win32/MacOS platform support can also be maintained for the GUI. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
