* I really hate the current way you choose serial ports. Is there any way to know what device is connected to a serial port? Can't we detect if the arduino is an Uno vs Leo vs Decimila instead of having to ask the user? I also hate having to use the /dev/usb blah blah names.
This depends on whether java can access usb and/or registry-related system calls. You can theoretically get the usb device information associated with a serial port, and figure out whether they are likely to be Arduinos, and if so which type of arduino. (although, I wouldn't rely on this entirely, since it's common practice to use somewhat random usb/serial converter chips/cables/etc as a cost-saving scheme.)
There's an example (for windows, where things are worse) at https://github.com/WestfW/ArduScan
The double-listing on Mac's is Apple's fault; can you really guarantee that /dev/tty.usbserial-xxx and /dev/cu.usbserial-xxxx are the same piece of hardware?
Could you answer my earlier question about Swing vs local editing styles? I'm genuinely curious...
You're missing the existing keyword-based highlighting of Arduino Functions (digitalWrite(), etc)), and I disapprove of the reduction of information in the compiler interaction part of the display. "we" have been trying to get more information there (RAM usage in addition to flash usage, in particular.)
Listing pin usage would be interesting. Sort of baby-steps to actual simulation at some point...
Hmm. It sounds like I could make educated guesses based on HID info but it will always be iffy. I was hoping there was a way to open the serial port and get some info from the board itself. No?
On Mac at least I can probably filter out the dupes. We could also do something like a button to "never show me this port again because I know it's not an arduino".
Historically Swing did everything in pure Java for maximum portability and reliability across platforms. Believe it or not it is common for large companies to want their software to look exactly the same on all platforms, regardless of the native conventions. Eventually we introduced the so called 'native look and feels' because it turned out a lot of people *did* want a more native looking app. However, these decisions all date back to the mid-90s. Today we now know that most people don't care if an app 'looks native' because they are used to so many different interfaces on the web. They *do* care that the interface is good, of course, but not necessarily native looking. This is all about *look* though. The *feel* is far more important. Things like keybindings and common menus matter a lot more that how an app looks.
So. How does this affect the new IDE? I'm unsure of which Swing theme to use. For now I'm going with Nimbus, which is a recent (4 yrs) cross platform look and feel that is pretty modern looking. However, regardless of which theme we end up shipping with (I do think it's good to have just one theme, not switchable) the feel must be platform dependent. That means patching up all of the keybindings to be appropriately native. Most of this we should be able to get from swing itself, but I might have to patch in a few parts. We also need proper 'Window', 'Preferences', 'About', and 'Help' menus and should remember window placement.
In the end these details matter only in the context of the whole. What is the vision for the IDE? My vision is a beautiful IDE custom made for Arduino. Something that both new and experienced users alike will enjoy. New users find it easy to get started and helps them learn. Experienced users have powerful tools that help them be more productive, while not hindering the new users. I'm trying to think the way that Apple does. Every setting in the preferences dialog represents a failure. Ideally we would have not settings at all because we correctly predict everything the user wants. In practice that is impossible, but it's a good ideal to guide us.
I've decided to move away from the Processing IDE base. Ultimately Arduino needs it's own IDE. We need the flexibility to drive the interface in a way that makes sense for our users. The current codebase, while functional, makes customization a lot more difficult. I see why they started with Processing, but I think we can do better.
Okay. Rant off. Back to coding.