Re: [avrdude-dev] Avrdude Gui problem

[Joerg Wunsch]

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. ;-)