Re: [avrdude-dev] GUI using Lib

[Joerg Wunsch]

As John wrote:

> What i have now is a testversion, that reads the system-config file,
> an i filled a dropdown with AVR types an programers.

I'm a little sorry that you had to duplicate that effort so far -- up
to that point, I've already done the job once, as a proof of concept
whether the idea to separate the library from the frontend actually
works.  So if you had asked before, I could have got you my old stuff.

I didn't check it into CVS because it's really a proof of concept
implementation only, and I eventually decided that I didn't have the
resources to contribute the actual GUI stuff.

> But i found a vast of fprintf's in the lib what i think is not GUI
> like ;-)  How can we get rid of this ?

We could introduce a printf-like function, say

extern void notification(const char *fmt, ...);

where the frontend is in charge of providing an actual implementation
for it.  The CLI frontend would then use:

void
notification(const char *fmt, ...)
{
        va_list ap;

        va_start(ap, fmt);
        (void)vfprintf(stderr, fmt, ap);

        va_end(ap);
}


As Jurgis Brigmanis wrote:

> However, exit(1)s is a great problem for GUI. While for CLI it's OK
> to terminate program on any error, it's totally unacceptable for
> GUI.

Well, I think even the CLI would sometimes do better than just
completely bailing out in case of the slightest problem.  However,
changing this unfortunately exceeds the amount of time and energy I'm
willing and able to spend into the project.

I agree that replacing the exit(1) by something like avrdude_error()
is an appropriate solution.  I'd even suggest trying to classify the
severity of the errors, so e. g. in case of benign errors, the
frontend could try to continue.

> It would be, however, one hell of a job to change that everywhere
> :-(

Well, I think segregating the library from the frontend has been more
work.


As Odd Arild Olsen wrote:

> I think it is much simpler to use the GUI to assemble and then
> execute avrdude command lines.

Not really a good solution.  There are a number of solutions around
trying to implement that, and none of them really appears to be
accepted as the ultimate thing to have.

Aside from the issue about calling the backend program itself, and
handling all the various possible errors (even Win32 versions are not
consistent in that I've been told), there are a number of more severe
flaws with that idea:

. The programmer has to be initialized over and over again, so it's
  quite slow.  To make matters worse, all the USB-based Atmel
  programmers have the habit of disconnecting from, and reconnecting
  to the USB after saying good-bye, so depending on the operating
  system and the speed of its USB implementation to re-enumerate a
  newly appearing device, there's a certain time window when the
  USB-based programmer is completely unaccessible since the higher
  layers of the OS don't know it arrived (again).  The GUI frontend
  would have to reprobe a number of times, each causing a (quite
  expensive, in particular on Win32) new program start.

. If you modify fuses, you cannot "play around": if you change a fuse
  that affects the clocking options in a way so there's no clock
  available, no ISP will be possible anymore, and you cannot fix the
  mistake again by an additional call to avrdude.  During a single ISP
  session however, all these fuse changes do not take effect until the
  ISP session is terminated, so you can change fuses bits back and
  force without ill side-effects.  This is IMHO the biggest drawback
  of the "offline" GUI frontend scheme.

. The GUI frontend has to re-establish all the information that has
  once been known at the library level, by examining exit codes and
  parsing error messages.  Whenever some minor detail at these
  changes, the GUI is due for a modification in its parser.  Not only
  that this is a tedious job, but it's also going to introduce version
  dependencies.

. The offline GUI frontend will always have to play "catch-up" with
  new device or programmer support that has been added to the CLI
  backend.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)