Re: [avrdude-dev] About avrdude-gui

[Joerg Wunsch]

As Russell Shaw wrote:

> The right way to do it is to write avrdude as a bunch of library
> functions that the gui can use. That way, the command-line-only
> avrdude can use the same library functions, so any bugs in the
> avrdude library solved for one tool will automatically apply to the
> other.

Nobody talked about a GUI-only tool...  Basically, what you wrote is
the idea about it, yes.  The current backend functions will serve as a
library (regardless of whether we produce a .a file out of them or
not), and both, the command-line and the GUI access them.

> The same tool could have both command and gui interfaces, but that
> has size and maintenance disadvantages for users that don't need the
> gui.

Size: well, perhaps, though the use of shared libraries (for the GUI
toolkit) will minimize this.  Maintenance disadvantages?  I can't
follow you on that.

> The quick and dirty way is for the gui to send shell
> commands to the current avrdude.

That's been the current way, and it turned out to be not quite
optimal.  You're going to do a lot of pointless dataconversions, have
to handle pipe errors etc. pp.

> A command-line interface is necessary so that you can run avrdude
> from scripts and makefiles.

Sure, nobody questioned that.  Sorry if that wasn't obvious from my
first posting on the topic.


As Neil Davey wrote:

> I agree that avrdude could do with a gui, especially for new users
> to arv using open source tools or someone who doesn't want to mess
> with the command line, or is just to lazy mess with command
> lines.. I know I found it a little difficult at first to find info
> especially about how to set fuses with avrdude...

Manual setting of fuses is a typical example, yes.  Of course, the
option to set fuses to a pre-defined ``known to be good'' value should
not be missing (did you ever try to set low fuse 0x11 with AVR
Studio?).

> Random thought.. don't know how practical it is... how about a
> command line argument that disables the gui and accepts traditional
> command line args?

I even thought about a command-line option that *enables* the GUI,
though Joerg Lachmann thought about enabling the GUI if a GUI has been
configured, and no command-line arguments are given.  But I think that
option will lead to inconsistency in the behaviour between the
GUI-less and the GUI configuration option.


As Brian Dean wrote:

> I have no objection to this as long as:

>      1) command line usage is not compromized, i.e., gui is not
>      forced into use

Sure.

>      2) the gui supports all current platforms (looks like the
>      proposed library does)

Yes, that's the idea.  Multi-platform support will probably be even
better than in the current (wxWidget-based) avrdude-gui as there,
Joerg used a GUI builder for prototyping that only runs on Win32, even
though the resulting code was multi-platform.  fltk has a GUI builder
that is multi-platform as well.

> Nice to have would be:

>      3) Makefile's and scripts operate as-is, i.e., hopefully no new
>      option required to turn off the gui

See above, I rather thought about adding an option to start the GUI
(say, -G), and/or enable the GUI if the command is called by the name
"avrdude-gui" (based on argv[0], but I think that will only work on
Unix systems, not on Win32).

>      4) gui can be built/not built using a configure option or if
>         autoconfigure doesn't find the required gui libraries

Sure, I forgot to mention that in my first message as well.  I thought
about a configure option --with-gui or such (perhaps even defaulting
to be disabled).

(Interactive fuse bit settings.)

> ... Of course, one doesn't need a gui to do that, what we need for
> that are the fuse bit positions and descriptions encoded in the
> avrdude.conf file for each part.  If we had that, we could make fuse
> bit programming easier now.  But with a gui, the fuse bit experience
> could be made even better.

Yes.  Btw., the fuse bit descriptions that are used in AVR Studio are
available in the XML files, so it's only a matter of merging them into
avrdude.conf.

Perhaps we should reconsider the current avrdude.conf structure anyway
(maybe move to XML?), it became quite unhandily large already.

> Maybe what we need to support #4 is an XML parser to extract this
> information from the AVR Studio supplied XML files (if that
> information is there, I suspect it must be but I haven't actually
> checked).  Unless Atmel has changed their position on this, we are
> not permitted to include a copy of those files in AVRDUDE, but it
> should be allowable to extract the content needed for programming.

Yes, btw., we don't want to include the entire XML files anyway.  They
are currently 18 MB in total...


So Brian, didn't you recently ask what would eventually justify
issuing a version 6.0 of avrdude? :-)

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

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