Hi,
it's simply a bug (that will probably never get fixed?)
http://code.google.com/p/arduino/issues/detail?id=78

All the code to save and restore the windowsize (and last sketch) is already in the IDE, a patch was posted on the devlopers mailing list, but somehow nobody cares to fix this.

Eberhard

From the very low traffic on the developers list I wouldn't expect a 1.0 version this year.

The curent development target is 0019, but (almost) no code has been submitted to the svn yet.

Eberhard

What if someone was given the pre-compiled hex file by someone else?

Just say :
"No thanks! I'm a open source minded guy so give me the sketch code instead.
If you don't want to do that you could at least figure out the AvrDude commandline arguments for me"

Eberhard

Hi,
since arduino-0018 allows to build sketches for third party boards some generic naming scheme is needed here.

Not even the entries in hardware/arduino/boards.txt can currently provide a distinct name for a board.

Eberhard

I think you could do that now by checking the #define'd processor type.  

No you can't. For instance the Duemilanove and the Nano board both have a 328p processor, but  only the Nano board supports the analog inputs A6 and A7.

Eberhard

Maybe reset Arduino via USB connection when one press the stop button

I like that idea!
It should be working for all boards that support auto-reset.

Please post this as a new topic, so it doesn't ge lost
Eberhard

[only]

PLEASE use a file extension longer than 3 characters.

Yes, Microsoft has plagued us long enough with their 3Letter words.

The extension <filename>.arduino is the only natural choice I think.

Eberhard

[every]

I love the idea of a #library in arduino...

Thank you, one positive vote at last!

I like the idea of early checking for libraries... and especially having dependencies in a .properties file... there have been breaking changes to arduino in the past that required me to rewrite libraries, and this might've addressed some of the issues I had...

Yes, I wonder why there are so few who people who care about this. This hits me every time I write some library code.
You cannot write the simplest driver library for I²C devices because you cannot make use of the Wire-lib without including it into the users Sketch-code.

Eberhard

I also thing this will be a problem when the users start to #library in the libraries themselves.

This will not happen. Did you notice there have never been any forum topics starting with:
Why do I have to write prototypes in library code? I never had to do this  with Sketch-code?
I think users are to smart for this. They know they have to learn some C/C++ when they want to start their first Library project.

Either the IDE need to parse all files for #library, or we need to state that the #library is only allowed in Sketches [that are not libraries].
What would you want?

I want the #library statement only in Sketch code because

• It takes too long to preprocess the included library files in addition to the Sketch code. Thats why I proposed a way out with the library properties-file
• You get shot by the Kernighan&Ritchie police for even thinking about this.

Is it easiest to learn that you always #include other files, or that you #library libraries, but you #include if you write a library.

Kindergarten is over by the time you decide to write a Library. (In the best sense : You have been playing around for quite a while; now you create code and show to all the world by putting it somewhere on the net. Its you first school-project.)

It is a very strange conception to think that Noobs stay Noobs forever.
That is what I like about the Arduino-documentation
"It starts from Zero and ends up with very advanced topics."
There is no need to protect people from the fact that writing software requires some work.

Eberhard

[any]

A good idea per se, but it will break the (for me) precious c/c++ compatability.

I what way?
You are not able to replace '#inlude Foo' with '#include <Foo.h>' by hand to restore c/c++ compatability?
Ever tried to run a Sketch Pde file directly through the compiler? It's not valid C++ code anyway.

You are not the intended audicence for this sort of improvement, and I know you will not have any problems translating the Arduino Sketch-code back to plain C/C++.

Like the homepage says:

Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It's intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.

The C/C++ heritage is not even mentioned on this page.

Eberhard

[Use statement '#library Foo' instead of '#include <Foo.h>' to import libraries]

Proposals for advanced Library Handling:

Use statement '#library Foo' instead of '#include <Foo.h>' to import libraries
Why:
Much easier to comprehend than the include statement.
Users know exactly where they pull in Arduino library code and where avr-libc code is referenced.
The IDE-Preprocessor knows exactly which libaries to include. It can give an early warning
"Library 'FooHoo' not found"
before the compiler chokes  on the unsatisfied #include statement and spits out some incomprehensible tech-message

Support a library.properties file
Why:
Two questions come up regulary

• A) Library X does not work with board Y
• B) Why can't I import an existing library into my own library

Solution:
A Library Foo can have (optionally) a config-file named Foo.properties. This file is parsed be the IDE every time the Verify/Upload process is started and a Sketch inludes the library.
The File supports (for a start) two entries

Code:

#properties for library Foo
depends=Wire
boards=arduino.Mega arduino.Nano xmega.XPlain

The depends entry lists all Libraries that the current Library is build upon and which have to be compiled and linked into to project to make the sketch work.
I our example Library Foo uses the Wire-lib.
There is no need for hacks anymore, like mentioning the Wire-Lib in the Sketch-code even though it is never exlicitly called.

The boards entry lists all the boards that are supported for by the code.
boards.txt should  provide a unique key for each board like the examples used above. The arduino. is a kind of namespace-id which will make is possible to write a Library for third party boards.
myXMega.XPlain in the example would be a board from the external myXMega project. The parser supports wildcards arduino.*.

For backward compatibility the existance of such a file is not enforced. If no Foo.properties files exists, the library will be comiled for all boards (no matter if it supports the hardware or not).

[Suggestions]

Hi,
this already works basically but the concept could be taken a bit further
Suggestions

• The Boards-menu should be made into a new toplevel menu. There  is no relation to the other items in Tools like autoformat.
• The third party boards should apppear in a dedicated sub-menu of the boards menu which is named after the core they belong to.
• Import libraries should group the available libraries in submenus by the core they belong to.
• Programmers should be grouped in submenus by the core in which they are defined.
• Support a dedicated sketchbook-folder for libraries written for a specific core.

Eberhard

Here is the annoucement:
http://arduino.cc/blog/?p=392
Eberhard

[Hey look, the Arduinos are still driving around with their rusty old Processing-GuiMobile ;D]

That still leaves lots of room for changes and improvements.

Maybe, but I also lost faith that this call for improvements in 1.0 will lead to anything concerning the IDE.
For me (and from what I read in other posts quite a few other people as well ) this is the most annoying part of the whole Arduino-Thingy.
The hardware, core/libraries, basic idea ,documentation , I have a lot of respect for this ...
... but when it comes to the IDE  :'(
Its not fun to work with, its buggy, its the part of the project in bad need of improvements.
And since I expected the answer...

In the particular details of text editing and window management (as shared by Processing), you're right that I'd rather defer to Processing.  

...I didn't feel like it was worth posting anything into this part of the forum.

No matter how many shiny new chrome-fittings Arduino 1.0 will have under the hood, People will still point with fingers at us and say
Hey look, the Arduinos are still driving around with their rusty old Processing-GuiMobile  ;D

Eberhard

A question that needs to be investigated : Is this a German thing?