Re: [avrdude-dev] Avrdude Gui problem

[Mike Perks]

Joerg Wunsch wrote:
> As Mike Perks wrote:
>   
> > Note that the GUI design and implementation proceeds we may need to
> > tune or add to the API that already exists in AVRDude. ...
> >     
> Agreed.  I already did some changes during my initial pilot project,
> like the ability to register a callback function for harvesting all
> known programmers and AVR devices.  It's used in the CLI to return the
> list of programmers and devices for -c ? and -p ? options, in just the
> same way as the former code had it as hard-coded fprintf()s.  Now, the
> CLI just registers a callback function that does the actual fprintf(),
> while the library backend iterates over the list, and calls that
> callback.  A GUI frontend can then just go ahead, and register a
> callback that collects the items into a GUI element, so it can offer a
> dropdown menu or such to allow the user to select an AVR device and a
> programmer type.  Contrast that with the existing GUI efforts that all
> either require hardcoded (and separately maintained lists), or try to
> parse avrdude.conf on their own to gather that information, and the
> advantage should be obvious.
>   
Yep there are only so many design patterns out there and this is a 
standard one. Here are the callbacks I implemented in my 
front-end/back-end downloader tool:

/* level is message level where 0 is standard and 9 is über-debug data */
typedef void (*MessageCallback)(int level, const char * message);

/* status type */
#define STATUS_TYPE_FLASH 0
#define STATUS_TYPE_EEPROM 1

/* used to give a CLI or GUI thermometer display of percent complete */
typedef void (*StatusCallback)(int type, unsigned long current,
                   unsigned long total, unsigned long time);

I would suggest we have standard APIs for querying items. The returned 
list is then formatted by the CLI or GUI for display. Trying to use 
printfs after the fact is probably not a good approach. For a particular 
data item we will need verbs like add, delete, get, set, and list e.g.

   * ListParts
   * GetPart
   * AddPart (called from XML parser, not front-end)
   * ListProgrammers
   * GetProgrammer
   * SetProgrammer
   * AddProgrammer (called from XML parser, not front-end)
   * ListFuses
   * GetFuse
   * SetFuse
   * AddFuse (called from XML parser, not front-end)
   * etc

I haven't read very much of the AVRDude code yet so I'm approaching this 
from what I would do rather than what is there. Sometimes it is good to 
have a "fresh" view of things.

Regards,
Mike