Ideas for Improving the Processing IDE (PDE)

REAS

For Processing 3.0, we plan to make a series of changes to the text editor and development environment. We have a plan, but I'm curious to hear feedback from the larger community. I would love to hear different opinions about the following:

• What features are missing from Processing? What is the highest priority to add?
• What is the worst thing about the current Processing text editor?
• What is your favorite code editor and why?

We're recording our current plan here https://github.com/processing/processing/wiki/GSOC-14-PDE-3.0. It's all based on the current PDE X.

LHespanhol

I normally use Eclipse to develop with Processing, not only because I'm very familiar with it, but mainly due to its comprehensive set of features. I don't really think the Processing IDE needs to match Eclipse's wide range of development support (in fact, I do like the fact it is a very lightweight alternative for quick prototyping, especially for people getting started with software programming), however core features current missing, in my opinion, are:

• A good debugging mode with breakpoints and variable inspection.
• Syntax highlighting as you type the text.
• Autocomplete for the methods of a class as well as its public attributes/constants.

The current lack of such basic features makes developing anything slightly more complex really cumbersome.

Thanks for your effort opening up for the discussion, I'm sure this will be greatly appreciated by the community!

SteampunkProfessor

If you have a large number of libraries, the list doesn't scroll so you can't add any from it if they are below those displayed.

colouredmirrorball

Collapsable code blocks. A hotkey that allows you to quickly return to the previous cursor position, so you can look for eg. a variable name you need 500 lines further and return to the position you were working on.

REAS

Thank you for the great suggestions so far.

kizaph

I really miss line numbers. »Line 42...you forgot a semicolon« and so on...

GoToLoop

My list of programs is huge. And like @SteampunkProfessor said, we can't scroll over it!
Also, I'd like to have my "sketchbook" subfolder apart from the rest of the configuration.
Like "/libraries", "/modes", "/tools", "/templates" subfolders. They should have their own parent folder! 8-X

rndmcnlly

I'd be interested in support for (Java 8 -style) lambda expressions. I believe these would still play nicely with the JS back-end. I often get ideas for functional designs while using Processing, but I get myself into anonymous class messes whenever I try to implement them without syntax support.

GoToLoop

I 2nd what @rndmcnlly said. Processing's pre-processor is still in Java 4 age! We can't even use Java 5's enum!
I wanna use binary literals, underscore literals, international names for variables, methods & classes, etc.!!! \m/

_vk

Debugger is high priority I think.

I like multiple lines select/edit like in Sublime

redraw

Maybe incorporate some Tweak Mode by default? Anyway, the debbuger is the priority that's right, and I'm glad to know it is already planned.

REAS

Another way to really help this along is to test and test and test the PDE X. You can download it through "Add mode..." And please post issues to GitHub: https://github.com/processing/processing-experimental

giorgiomartini

1 Dark background, light text ala Sublime Text, better on the eyes

2 Autocomplete that looks nice, the current implementation looks ugly

3 Tweak mode by default would be awesome

jeffthompson

Dark background, agreed. I built a version and was working on a pull request, but got sidetracked :)

Here's the theme, if it's at all useful: https://github.com/jeffThompson/DarkProcessingTheme_2.0

Also: line numbers! Open to last-opened sketch.

KevinWorkman

I'd like the ability to deploy as a cross-platform runnable jar, instead of OS-specific native files.

This helps keep download sizes small, and allows me to upload a single file that I can point all of my users to. Since I run a website devoted to Java and Processing hosting, having 3 big native executables for every single application really adds up.

I've created a Processing Tool called SvgExe that allows me to roll my own self-extracting runnable jar. It's been added as a contributed tool, and other people have been using it to deploy their sketches. But it would be nice if this was a default export mode from Processing. I'd be more than willing to help code it up.

Self-extracting jars are a pretty common way to deploy Java applications, even with native libraries- in fact, that's how libGDX does it. It's also how a lot of people deploy JavaFX applications.

Berkmann18

Code autocomplete, the possiblity to have one file when exporting for website embedding, a debug mode, line indicator when there's an error

matthieu

I would like that we can choose to use processing like the version now with no pdeX or Other helps. For me the strenght of the editor is that it's basic and simple. Of course a syntax highlight for the function of library added and a small icon with a picture of the sketch when you chose in sketchbook will be perfect but I like the the aspect tough of coding.

PhiLho

As said, there is lot to improve. I agree with most suggestions above, expect for the dark background (or at least offer a way to quickly switch themes).

Moving libraries, tools, etc. out of the sketchbook folder would help a lot, for backup and for allowing having several Processing side-by-side.

The current editor is just awful. My favorite editor is SciTE (native code), using the same engine than Notepad++. Eclipse is second next.

One feature I miss a lot is the capability to drag'n'drop selected code to move or copy it. Also shortcuts to duplicate and delete lines.

The capability to do rectangle selection (and editing) isn't a must but would be very nice.

JobLeonard

I think the idea was to allow people to switch themes.

I would like to see a more powerful but still intuitive find/replace feature.

One boon would be highlighting (but not selecting) all matches as you type.

Another feature I miss is find-in-selection. The idea is that you select a part of the text, and can set find/replace to limit its "scope" to that selection - kind of like how you now are limited to one tab by default, but can switch to all (of course, the selection of the block would change to highlighting the scope - as using find changes what text is selected).

Right now I almost never use Replace All because I can't see what parts I will be replacing, and because it will often replace parts I don't want to. These two features would fix that.

JobLeonard

Also, I'm sure many users, especially those new to programming, would love the ability to turn on local variable highlighting:

http://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from-syntax-highlighting-to-semantic-highlighting/

mcspud

Ways to have more tabs.

MenteCode

I, as a person that codes quite a bit, try to not waste time on getting lines of code to swap places with one another.

I program Java in Intellij IDEA, which does code switching very well, and I'd love to see that functionality here.

Also, a good thing to add would be a way to see the data types of the parameters that are used by a method/function. This especially applies to methods and functions that are in built-in Java classes, other Processing functions, as well as overloaded functions.

Saves lots of time, not having to look up a method online, just to get the data-types of its parameters.

MenteCode

Oh, never mind the second part. PDE X already has this.

My only other final suggestion would be to place both brackets when I type the left bracket.

Normals

There's something so fundamental in Processing's simplicity for it to have such a creative community around it. The abscence of many coding tropes make it it a very inspiring tool.

Looking at the philosophy of it, could it be possible to tackle the matter the opposite way and make the environment itself more tweakable? And not just theme customization, and certainly not checkbox features, but something even more bare bones. How could even we retarded designers program the program, modify the environment (make it bug)?

Also on top of an autofill on stuff like brackets, an autoShiffmanize for entire blocks of code would be superb :)

Oh, and this seems like a great opportunity to thank you for your generous work. So thank you.

kimspindel

I'm sure this will be overlooked, but I would love a Vim mode in the IDE, because that is my preferred choice of text editor.

But not having this mode isn't a big deal since it's easy to run sketches using a Processing plugin for Vim, plus I can understand if it isn't worth the effort for the devs ;)

(but perhaps if more people express interest then it might become a thing!)

Other than that, line numbers, autocomplete, and being able to change tab size (I prefer 4 chars over 2) are probably what comes to mind when I think of things to add to the current IDE :)

aLinG

My preferred code editor: SublimeText. Suggestions: better autocomplete, custom snippets, integrated reference, custom syntax highlight and themes,...

alignedleft

• line numbers (could be optional: default is off, user can turn them on)
• autocomplete (of built-in Processing variable and method names, plus may user's own names used elsewhere in the project)
• on OS X, support for standard text-editing keyboard shortcuts (for example, currently, option- and command-left/right arrow do not behave as expected)
• smarter comment/uncomment behavior (currently, code that is already commented out can be "re-commented" when indented)
• "expand selection to block" (selection expands outward until matching {} are found; I would find this feature very helpful in the classroom, illustrating how related code is contained in blocks)
• an "enforced auto-format" mode (in which Processing coerces you to use recommended spacing, indentation, breaks, etc.)
• option for alternate indentations (currently, IDE uses 2-space indentation; maybe I like 4-spaces, or tabs)

dttworld

+1 for a debug mode allowing code stepping, breakpoints, watch variables, etc.

clankill3r

I agree with most points above so i won't mention them again.

For the rest,

-a better relation with tools. I would like to call the color picker from a sketch for example instead of making a call to java's color picker.

-being able to explore your own sketches like you can with examples. (in a frame instead of file > sketchbook > etc > etc > etc ).

• "add library" is under "sketch > import library " i think this is a strange place. Also a strange name since it opens the "library manager" which also allows you to remove and update libraries. I suggest "sketch > library manager" . Or even better "processing > library manager". "processing" could be expanded in the future and hold also "themes" and other stuff.

---

Wouldn't it be good to create a reddit page for this so we can upvote things to create some hierarchy in suggestions?

SteveTiffany

Being able to get rid of the gray bar that lowers the contrast of the current line should be possible from the preferences page, and you shouldn't have to reset it every time a new version comes out.

Chrisir

search function: search whole word only

also refactoring:

if else if ... else if ... becomes switch()

or multiple parallel arrays become Class

auto constructor

imagine also when I write

class Ball {

int x; int y; int color;

the constr could be written automatically (x_,y_,color_ as params and the lines to copy them into the class)

and thanks for all your work!!!!! :-)

best, Chrisir

darius

Hi all,

I agree with most points above so i won't mention them again, too.

I think, we can cleanup the code, too. Maybe we could refactor the code, so the user doesn't need to restart the PDE to see the effect of changed settings.

Happy coding, Darius

GoToLoop

I worked with the sourcecode to implement an basic internationalization...

In my cited wish list, I was referring to international characters identifiers for variables, methods & classes! 8-X

DuncanCS

PLEASE --

as an educator who uses Processing to teach programmers and non-programmers,

either keep it simple, or have a simple mode in the IDE. The clean and easy IDE is one of the reasons that I love and use Processing.

hamoid

Missing features in order

• As mentioned, auto-complete (including libraries, not only the Processing API) and integrated tweak mode.
• Help pane with the documentation for the instruction under the cursor. Continuously switching between the IDE and the browser is not convenient, and displays are often large enough today.
• Code reuse? If we could save classes in a directory, and import them from any of our programs, it would be great. Currently each program is on its own world. If we reuse a class in 10 programs, updating the class is currently too much work.
• Sketchbook that looks like examples.
• Search box for filtering Examples and Sketchbook. When I type P3D in that box, I see all my 3D programs. If I type OSC, I see the programs that use OSC. Etc.
• Snippets. It would be nice to have my own snippets and templates to not start from blank, but already with setup, draw, keyPressed, saving frames, etc.
• Edit .glsl in the IDE.

Inconvenient thing(s)

• Warn against using reserved words like void init(). It's not in the docs, and breaks your program.
• Syntax coloring hiccups, where everything is shown gray (as a comment). Solved by pressing pgup, pgdn.
• Scrolling the IDE while the program runs is terribly slow (about 2 fps) (Linux).
• If I do a git pull, I have to close the IDE and open it again. A reload function would be great.
• Tabs get confusing when too many of them.
• Switching tabs does not work on Ubuntu (Ctrl+Alt+Left, Right is taken by OS).
• Can't use Alt to access menus.
• File selector not standard OS selector, so I can't press keys to jump to folder name.

Favourite editor

Don't have one. I use Eclipse (auto imports, auto format, auto completion, renaming variables, warns about incorrect code), SciTE (super fast even with multi Mb files, scriptable with Lua), LightTable (live coding with P5.js, variables can be explored inline), scide (SuperCollider IDE, live coding, integrated documentation with runnable examples, fast and light) and vim.

Question

As the resources available to develop the Processing environment are not unlimited, does it not make sense to base the IDE on an existing multiplatform editor like Eclipse, SciTE or one of the others? I assume it's more work, right?

clankill3r

Moving to Eclipse or something would make processing way more unfriendly for new users. Now you can download, open, and press run.

---

• Code reuse? If we could save classes in a directory, and import them from any of our programs, it would be great. Currently each program is on its own world. If we reuse a class in 10 programs, updating the class is currently too much work.

I have thought of this before and it would indeed make a nice feature. I imagine a folder called "classes". This folder should allow subfolders, subfolders are easy to create different versions like v1, v2, v3. To not break old sketches for example.

To use it:

import v2.Integrator;

or import a whole folder

import someFolder.*;

The imported classes could appear in a different tab color.

redraw

I agree with Hamoid in all missing features.

However I still believe in using a simple IDE as Processing is nowadays. Eclipse looks like chinese to new users

hamoid

@clankill3r and @redraw, I meant "base on" an existing editor. One would download the Processing IDE, that looks as it does now, but internally it would use code from Eclipse (or another editor), with the idea of reusing code developed by people focused purely on making a great editor. I just wonder why a custom editor is a better approach. (I assume simplifying an existing editor is more work than writing one).

redraw

understand now @hamoid, yes. personally I also don't know if it's more convenient to reuse another editor's code or write a new one.. but that would be great.

benvancitters

Missing, nice-to-have Features

• Auto-complete + popup documentation ala VisualStudio's intelli-sense or Xcode
• In-editor highlighting/underlining of bad syntax/unused code - most popular IDE's do this now-a-days
• Debug mode-code stepping+variable watches+breakpoints+callstack
• 'Go-to-definition' for tracking down where variables and functions are defined (command+click in Xcode, ctrl+click in Eclipse on windows)
• Eclipse's 'quick fix' menu - allows you to pick an option from a dropdown menu like 'import libraryX' when some library is missing or 'surround with try...catch' when some line throws an unhandled exception
• Search/Find Functionality and result highlighting with less heavyweight UI as in Google Chrome browser, MonoDevelop or Xcode
• Better UI for 'file->sketchbook' per GoToLoop above - at some point sketches become unavigable

Current IDE Bugs that could be fixed

• Something odd I have noticed endemic in processing for a long time is that if you have multiple processing windows open, and you run a processing app that outputs to the console, the top-most processing IDE window catches all of the console output regardless of whether it is the sketch whose code is running.
• Too many print/println calls in too short of a time overloads & crashes all open Processing windows - ie for(int i = 0; i < 99999999; i++) println("some huge amount of text " + i);
• If you try to run a sketch that has a missing semicolon with multiple tabs it sometimes jumps the code view and cursor to a seemingly random place

Breakpoint Digression

I think adding breakpoints might be the most important thing to me in the Processing IDE as the crazy number of hours I have collectively lost to adding weird, cluttered conditional println's in order to catch atypical behavior or null variables getting passed around is astronomical. However, breakpoints are a complicated and advanced topic that new users and novice coders could easily have a great deal of trouble understanding and using. Code-stepping also requires a lot of new UI and core functionality. Are there examples of low-overhead, dead-simple yet effective implementations of code stepping out there?

nowhere

-refactoring capabilities -selecting one variable to highlight its instances -an optional panel/navigator that includes a list of links to all variables and functions wouldnt hurt -an easier way to make libraries for the processing IDE users -a shortcut that adds "public" in front of functions that dont have public/private declarations -for reference you could also have something like python like: help(PFont) that would print quick and easy references on the console.

and maybe just maybe, introduce a mode, where your sketch begins with

class MySketch extends PApplet(){ void setup... }

like java, that would be more sincere towards the user, and would allow for classes outside of that

but I would agree to most of the people, some sort of debugging is what is missing, because in most of the problems it throws you to a random tab ending up with no idea where the problem lies. some simpler problems like semicolon errors could be highlighted on the IDE before running the program

also there is some weird behavior by pressing control+Z. some times it deletes all of the contents of the tab

--and also better OpenGL implementation, or examples for programming over an OpenGL buffer.

-it would also be great if you included a simple 3d camera, with no smoothing etc, that would result in a lot faster performance than peasyCam. I could provide you with that.

autocomplete or drop down list after dot operator

jas0501

This biggest frustration with the editor is when the error reported is no where near the syntax problem. A missing semi-colon can wreak havoc. Under certain circumstances loading the sketch outline will report the source of the problem via a catch:

catch (japa.parser.ParseException e) {
            // Tree not built 'cause of parsing errors, notify user
            if (debugMode) {
                Token t = e.currentToken;
                int errorLine = t.endLine;
                System.out.println("Parse error encountered after -> \""
                        + t.image + "\"");

                if (editor.getSketch().getCodeCount() == 1) {
                    System.out.println("Near line no: " + (errorLine - 1)
                            + " in tab "
                            + editor.getSketch().getCode(0).getPrettyName());
                } else {
                    for (int i = 0; i < editor.getSketch().getCodeCount(); i++) {
                        if (errorLine
                                - editor.getSketch().getCode(i).getLineCount() <= 0) {
                            System.out.println("Near line no: "
                                    + (errorLine - i - 1)
                                    + " in tab "
                                    + editor.getSketch().getCode(i)
                                            .getPrettyName());
                            return false;
                        } else
                            errorLine -= editor.getSketch().getCode(i)
                                    .getLineCount();
                    }
                }
            }

Other times it can be difficult to find the issue.

Better handling of these circumstances would be a great improvement. As a seasoned programmer finding these syntax errors is trying. For beginner I expect it can be daunting and off-putting.

clankill3r

That's why i only do small sketches in processing (and because processing is horrible if you have to many tabs). I think the problem is that it precompiles first with processing's pre compiler, after that the java compiler can get to work and by then the file is changed a lot by moving classes in one file and adding the main method etc.. I think it would require that processing check's for error's before it precompiles which is probably a lot of work, if not impossible to do for such a small team. (I could be wrong). If not, it might be good to have a option to see the precompiled version.

Or maybe with some smart comparing it's possible to figure out where the actual problem is.

I just hope the editor stays really plain and simple. That doesn't mean no options, just options with a lot of thought behind it to keep it clear and to a minimum.

For example:

I think that list is already getting quite huge. Certain things could be considered. - have debug toolbar always on - remove continue and stop from that list, i think 99% uses continue and stop in the pde itself. -only allow a toggle breakpoint by clicking in vertical breakpoint bar -make "print" > and then the rest in a submenu -etc.

I don't say the above ideas are good, it's just an example of things that can be considered.

Maybe it's good to run a poll with questions how the current pde is used. I never use the icons for example, only shortcuts (except the stop icon sometimes).

benvancitters

Another bug I have encountered in the editor itself is that the text coloring sometimes freaks out and will recolor all of your source (in a single tab) as though it has been commented out. I found that scrolling a little up or down sometimes fixes the coloring, but that should be addressed or 'bugified' if it isn't already.

Excalibur421

It needs to be able to handle two key presses at a time. If you are pressing one and then press another it doesn't register the first. Thanks! :)

PhiLho

Excalibur421, why do you need to press two keys simultaneously in the Processing IDE? Except for modifiers like Ctrl or Shift, of course!

clankill3r

I think he means in processing in general instead of the IDE. Just like nowhere was suggesting ideas that have nothing to do with a IDE.

PhiLho

"Ideas for Improving the Processing IDE (PDE)"
The first bullet point can be confusing, though...

And there are already examples of handling multiple key presses in Processing in the forums.

marquessbr

Im use Fedora, with is a RHEL based OS, I dont know if its occur in another os, but in Linux, when I increase the size of the IDE screen, the menu flashes on the screen and I can only access it if I keep the mouse button pressed, if that were solved would be good.

miss code completion.

in Delphi, if I press the ctrl key and clik in a child object, anithing like myclass.childobject, the editor moves the cursor to the line where the object is declared in the parent class, its good.

if the console show the line where the error occurred would be good, but if the cursor was moved to that line when you click with the mouse, it would be even better.

need more information in the status bar.

its a good job, independent of.

Chrisir

hm...

I don't think it is wise to have too many features...

who is gonna go Pro can use eclipse any time

the processing IDE should be aimed as beginners and artists mainly

I was impressed by the visual of microsoft small basic

which lets you choose a keyword from a nice roll

and chose a help in the right side bar

http://misfitgeek.com/postimages/SB_DevlABS_12142.png

PhiLho

It would be nice if the PDE / Pre-processor would be able to detect some errors common among beginners, like if (a = true), local variable shadowing global one, and similar problems.

Quite hard to do, though...