avr-chat
[Top][All Lists]
Advanced

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

Re: [avr-chat] AVR IDE [WAS: UISP / AVRDude : what to choose ?]


From: E. Weddington
Subject: Re: [avr-chat] AVR IDE [WAS: UISP / AVRDude : what to choose ?]
Date: Mon, 29 Aug 2005 21:51:19 -0600
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Vincent Trouilliez wrote:

<sarcasm>
The obvious answer is that if its already good then its time to
handicap ourselves in order to compete on a level playing field.
Eliminate the advantage we have over GUI and overload the developer
with glitz, bells, and whistles, with a single unified
point-and-click development environment! We need to hide all our
configuration options in a binary project file under a GUI with
nested menus rather than a Makefile so only the original developer
has any idea (if he/she remembers) as to what is happening.

It seems to work for Microsoft, it must be right!

Not only Microsoft but Metrowerks CodeWarrior follows the same
model.

And so many ask for it, It Must Be Right(tm).
</sarcasm>


I always fail to see why those that don't want GUI's in Linux, complain
about them. It's just that, a GUI, a front-end. If you feel you need it,
use it. If you prefer using the underlying back-end /command line tool
directly, you can do so as well of course. Everyone can use the tool
that suits him best at any given time. The same person might use the GUI
to manage a large project and benefit from the project manager one day,
and the other day prefer the command line because he has just a tiny
quick test program that's more straight forward to do at the command
line "by hand". It's like CD burning apps, there are hundreds of them,
and all rely only on 2 or 3 command line tools. If you feel like burning
your CD's by hand do it, nobody's forcing you to use a GUI ! Really, I
don't understand this 'war'. GUI's are just there for when you want/need
them, they have NEVER forced anyone to give up using the underlying
command line tools directly !!! As far as I know. So I really don't
understand this 'war', pointless :-/


These are the kind of problems I had with Microchip's MPLAB. At
least with the relatively small assembly projects one could hunt
down each and every option and override project settings from the
assembly file. That MPLAB was so stupid as to reference all files
with absolute paths, rendering a project which could not be moved in
the filesystem. That if archived *must* be restored in exactly the
same place, and MPLAB must also be installed in exactly the same
place as originally.
No, I am not interested in "enhancing" avr-gcc along those lines.

So just because there is (at least) one crap IDE under Windows, means
that Linux folks will inevitably be only capable of developing as bad an
IDE ?
Ok, let's step back and take a deep breath.

There's really no need for this to devolve into a religious argument.

I agree with David Kelly in the sense that *arbitrarily hiding important project information behind a binary-based GUI* is a Bad Thing. I've seen these issues too. I agree too with Vincent in that *a properly implemented GUI is nothing more than a graphical layer in front of command-line tools which anyone can get to at any time*. What David describes seems to be the paradigm adopted by many Windows-centric developers (including MS themselves). What Vincent describes is the paradigm adopted by Unix and Unix-like systems.

I feel that there is a way to do both. Be able to provide a GUI layer to make it easy for a novice developer, or for an experienced user to start a project quickly. *And* provide the user (who is an embedded systems engineer and is very knowledgeable) with the means to get at the very lowest level to do any and all customization desired, to be able to get down to the nuts and bolts. This system should be *very open*, where nothing about the project is hidden. That it should not impose any rigid structure (e.g. absolute paths, etc.) unless the user specifies it. That it can be made cross-platform. That it can be scaled by being able to easily add new tools.

Does this sound desirable?

I hope so, because this system is already in the works..... :-)

Eric




reply via email to

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