RE: [avr-chat] GUI wrapper for avrdude

[Eric Weddington]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
>  On Behalf Of Juergen Harms
> Sent: Saturday, August 25, 2007 6:57 AM
> To: avr-chat
> Subject: [avr-chat] GUI wrapper for avrdude
>
> Thank you for the feedback. I had problems to reduce the flood of
> results from googling to something reasonable, and your pointers are
> very helpful.
>
> As to the criteria you mention (avoid duplicating what
> avrdude already
> does, think about maintenance, take care of integration into
> the avrdude
> tree and supported platforms) I agree entirely - but I am far
> away from
> thinking "product": I am trying to get an idea on what
> exists, how much
> sense a GUI frontend makes for the user (not only for users
> with trained
> synapses in their fingers, but also occasional users who
> suffer from bad
> memory), and - consequently - whether there is sense in
> considering to
> make an effort.
>
> I will now dig into the documents - I will come back to the list if
> afterwards I have still something reasonable to say ;-)

I am constantly thinking about "product". A GUI front-end makes absolute
sense and has been needed for *years*.

- AVR Studio has a lot of success with making it easy, for a single-end
user, to program fuses, mainly through verbose descriptions of the settings
- AVR Studio's weakness has been mass programming of devices, and
reproducibility. *Always* setting the fuses graphically is error-prone. This
is where avrdude excels because it can be used in a batch mode from the
command line and especially from "make".
- There historically has been a disconnect between how the GUI front-end
handles the settings, with checked fields for individual settings, and how
the command line handles it dealing with bytes represented in hexadecimal.

The key is that BOTH methods are needed for very different reasons. The GUI
makes it easy for the beginning user. The command-line makes it easy for the
advanced user. Both methods are NOT mutually exclusive. Both methods are
needed to provide a powerful tool to the user.

The real question on the table is, how to implement it given the acceptance
criteria of cross-platform GUI? That's a real technical challenge right now.
Here's one idea: Java. Honestly, I'm not a real big fan of Java, mainly
because the user has to download a large JVM just to run some simple
program. One alternative is to write the GUI in Java, but to compile it
using GCC (the GCJ compiler) which can also directly compile to native code,
not just the byte-code. Leave it to distributors to decide whether to
compile to native code (producing executables) or whether to compile to byte
code. This leaves it open to possibly including this into a plug-in for
Eclipse.

I realize that that's just one idea. I'm certainly open to other ideas.

Eric Weddington