avr-chat
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-chat] GUI wrapper for avrdude


From: David Brown
Subject: Re: [avr-chat] GUI wrapper for avrdude
Date: Mon, 27 Aug 2007 22:39:17 +0200
User-agent: Thunderbird 2.0.0.6 (Windows/20070728)

Eric Weddington wrote:
-----Original Message-----
From: Chris Albertson [mailto:address@hidden
Sent: Monday, August 27, 2007 11:05 AM
To: Eric Weddington; 'Juergen Harms'; 'avr-chat'
Subject: RE: [avr-chat] GUI wrapper for avrdude


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.
There are other cross platform GUI tool kits.  WxWidgets works well
"v" is another but there are many more listed here
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

For this very simple application you don't need anything like C or C++
one of the scripting languages would work, tcl/tk, pl/tk, ruby or
Pythion.  All it would have to do is present the user a bunch of
radio butons, pull downs and file browser.  It reads there then builds
and "execs" a command line

Note that many of these have also been discussed on the list
(avr-gcc-list,IIRC) before, but it's been awhile.

I agree that scripting languages would work, but I would balk at including
them in WinAVR because I prefer that there not be such strong dependencies
on the tools. For example, I don't want the user to have to go download
Python just to get a GUI for avrdude to run. I don't want to include Python
within WinAVR because it would seriously bloat the package, plus that's not
the purpose of WinAVR to include all of Python. I would certainly not object
to turning the Python script into a self-contained executable, because then
it would be very easy to include it in WinAVR and reduces the dependencies.
*nix machines generally don't have to deal with this issue, but Windows
does.

Tcl/Tk is somewhat better as Tcl/Tk DLLs are included in WinAVR because I
build and include Insight (GDB w/ GUI), and a wish interpreter is included.
But, as has also been discussed before, Tcl/Tk apps pretty much look lousy
on all platforms.

But at this point, it would be nice to have something that works reliably,
rather than the buggy one that exists now.

Eric Weddington


It is very easy to package Python programs so that any non-standard libraries used are packaged together. On windows, it is also easy to generate a single executable containing all necessary libraries and dlls in the exe file - there is no need to install Python or anything else. Clearly, you end up with a bigger exe file than if you were writing a C++ program that uses the same libraries - you need the Python virtual machine, and any libraries must be included in whole rather than just the parts you need (since Python binds dynamically, the packager cannot know which functions you will need - thus pretty much all of wxPython gets included).

As an example, the msp430 gcc project uses Python for a variety of tools, such as their command-line programming tools. This is setup with a few shared dlls (such as for the python virtual machine) coming to about 2 MB, and an exe file for each tool (maybe around 20k each). They have a gui for the programming tool using a small windows-specific library called EasyDialogs. I made some modifications to it and made a setup file for some of our customers - it's about 2.5 MB. A wxPython project is heavier, since it links in a lot of wxPython (with enough effort, some of that can be reduced) - a similar gui project I did is around 6 MB. If there are more than one program using Python in the same installation, then most of that space can be shared.

mvh.,

David








reply via email to

[Prev in Thread] Current Thread [Next in Thread]