Ideas for Improving the Processing IDE (PDE)

tlecoz

In the Processing IDE of my dream...

• tabs would not definitly be sorted by name, I could organise them as I want
• there would be a project explorer with the list of all tabs/assets
• it could be possible to make a copy / paste with a correct tabulation automaticly
• Custom class-type should be colorized
• There would be a super-powerfull autocompletion (as powerfull as FlashDevelop - the best IDE for me, but it's for AS3/Haxe only - )
• There would be an auto-save applyed on all tabs for each compilation (but not for the llibrary examples )
• I should see the data-type of a variable inside a textInfo when I point my mouse on it and the terms of a function if I point my mouse to a function keyword

I think that's all for me :)

gogo

Nearly all of these comments describe ways in which processing fails to do something complicated with absolute perfection.

I did see one comment from a teacher and totally agree. Keep it simple enough for people to learn programming.

There's actually no need for all these "improvements". No need for Processing to support bells and whistles available with each new version of Java (it's not now, but decrease options, rather than increase them) or even popular IDEs. Processing could just be a really simplified Java 1.2. Where we need to implement features beyond that (and often I do), we can just include the fancier Java code amongst the Processing code (which works fine now).

Older Processing projects would then compile just fine on newer Processing IDEs, because there's no useful reason to ever update the Processing language beyond say the essential 100 keywords.

GoToLoop

There's actually no need for all these "improvements".

I agree! Most of those requests above scare me! If I wish them, I'd use a proper IDE! /:)

No need for Processing to support bells and whistles available with each new version of Java...

I disagree! Processing gotta successfully parse correct Java syntax! :-B

gogo

Processing gotta parser correct Java syntax!

true. but what I meant was that, even if "under the hood" Proc needs to accommodate changes in Java. Java should be backwards compatible enough that changes in the Proc compiler would hardly ever need to be radical. And those changes need never impact the "over the hood" Proc language at all. Changes in Java will tend to be the esoteric stuff anyway. Proc need only address a few staple functions that have been part of the language since the 90's.

I switched from Java to Proc about 10 years ago. I really like that you can mix em up as needed. Makes the code require so much less overhead. The Proc IDE was a breeze. But now it's all coming back. Too many options as Proc developers try to meet every excited new demand.

PhiLho

Like GoToLoop, I disagree with keeping Processing in a frozen, outdated version of Java. Any language, including Processing, lives and go on and evolves, and that's a good thing.

Beside, Processing is often used as an introduction to the real Java, and I won't imagine going back to program in a language without generics, foreach loop, and such. Improvements of Java goes to the way of cleaner, safer (with regard to types) code, and that's a good thing.
And, in general, Java is careful to be compatible with older code. With some exceptions (eg. using enum or assert as variable names), old Java can can still compile and run in Java 8.

I do agree with keeping Processing streamlined. I appreciate to be able to run it quickly (well, not so much today, but still faster than launching Eclipse) and to be able to type a few lines of code and to run them without even saving a file! (and without having to create a whole projects, etc.)

So Processing probably much strike a delicate balance between the current PDE X support which is rather fine (perhaps takes a bit too much time to clear errors made while typing, or too eager to display them) and a full Eclipse behavior.

If there was already some features found in some good editors like SciTE, like rectangular selection or drag'n'drop of selection, or move selection up and down, etc., it would be already great... :-)

Now, catching very common beginner's errors, like trying to use a null List or making a local variable shadowing a global one would be useful, too.

quark

For a long time Processing has enabled a sketch to be archived (Tools menu).

It would be nice to have a menu option to import and unzip an archive (into the Processing folder) in one operation.

jayduey

What I think would be really nice is the ability to run it with older versions of the compiler and stuff, but with the new interface. I would've really liked to move to processing 2.2 even, but everthing runs half or a third the speed of earlier versions, so I'm stuck with 1.5.1. I'd go farther back, but there seems to be no way to get below processing 1.2.1. It'd be great to be able to download a separate precompiler/compiler/library package, and run it for ANY previous version from the new interface. (I don't mean require all versions, but make any old ones avaliable for download and usage as needed).

blueboo

PDE X is like a rate-limiter for typing. Why would an autocomplete box ever block keypresses? It's been like this since I first tried PDE X last year -- and now it's standard in P3. I humbly suggest that that is an undesirable behavior. Maybe it's just on OSX, at least.

PhiLho

I believe auto-completion / error detection should start after a little delay after user stopped typing. If it is too eager, as said it can slow down typing or getting in the way, and it is annoying to see error messages (suggesting to delete what is being typed!) because we haven't finished the current line of code.

tomba

I'm just getting familiar with processing, as I'm planning to use it to teach an intro programming course with a generative art theme to a group of low income kids. I usually use Eclipse or Sublime Text 2 for my work but I agree with the idea of the simplified IDE that drives the features of the PDE. But... some simple things could really improve the UX. The first and simplest of the suggestions here, all of which I think are great, would be to remember the sizing of the PDE window. It opens so small and the first thing I do is resize it every time, for every instance.

I'm using 3.0 and really like the new features there like error highlighting, etc. but it still opens like it's a dialog or a toy. Even something in the preferences to set a preferred size would be a big improvement for what seems like not much work...ha, ha. Does anyone know where in the code one would start to investigate adding such a preference?

tomba

Well, there is a way after all. After experimenting with the preferences.txt file I found that changing

editor.window.height.default
editor.window.height.min
editor.window.width.default
and editor.window.width.min

all to the values I'd like this becomes the size on opening. Oddly, just changing the .default values didn't work - the changes to .default values were ignored on opening apparently in deference to the .min values ??? and my changes were over-written on close. But once I changed both sets it worked and they were not overwritten on close.

Given this work-around, it really does seem like it should not be hard to expose this ability in the preferences dialog.