Ideas for Improving the Processing IDE (PDE)

GoToLoop

If variable a is boolean or Boolean type, if (a = true) {} is valid [-(
Although it's always gonna be valid after that! But a programmer gotta learn how to deal w/ that!
If a is any other type, Java compiler will throw an error after all.
Why an IDE should try to catch something already caught by the compiler in most cases, but valid in some cases??? :-w
I usually do: if (isRunning ^= true) loop() else noLoop() (*)

riccardoch

If you have a lot of tabs, the tab menu disappears or, if it's present, you can't scroll all the tabs.

According to me the tab menu should be near the mode button e not near the last tab, otherwise it disappears when you have a lot of tabs.

jas0501

This is a feature I wish existed in any development environment.

Often there is supporting documents, notes, drawings, diagrams or specifications that are associated with the code being developed. Providing a hyper-link to said items from within the PDE would be awesome.

    //
    // Widget display 
    //
    // viewlink(http://forum.processing.org/two/uploads/imageupload/165/HPRSSWBVEQVG.jpg)
    //
    void WidgetDisplay()
    {

    }

MarkDown and making the text code changed the line. It should look like this:
// viewlink(http://forum.processing.org/two/uploads/imageupload/165/HPRSSWBVEQVG.jpg)

kritzikratzi

global scaling this is incredibly tricky -if not impossible- to get perfectly right, but being able to define scaling behaviour would be very very cool.

resizeBehavior( SCALE_ASPECT_FIT ); // aspect scale to fit inside the window
resizeBehavior( SCALE_ASPECT_FILL ); // aspect scale to fill the entire window, crop parts of the sketch
resizeBehavior( SCALE_CENTER ); // don't scale at all, just center the sketch
resizeBehavior( SCALE_RESIZE ); // resize to fill entire window
resizeBehavior( SCALE_ASPECT_RESIZE ); // resize, but keep aspect ratio

the first two wouldn't change the sketch.width and sketch.height variables at all, but just transform the viewport/mouse coordinates to scale the entire sketch up to size.

SCALE_CENTER would be the current behavior.

the last two would resize the sketch and modify width+height.

expand sketch.properties further allow more settings in sketch.properties

• general: icon/name/OSs for export
• java mode: maximum memory (instead of setting it globally)

bilmor

Just a couple of things that have bugged me:

The CTRL/CMD-T auto-formatter should ignore lines beginning with // comment symbols, so it doesn't break the CTRL/CMD-/ shortcut for commenting out code. As it is, such lines are indented and the shortcut doesn't uncomment them.

It would be nice if the IDE remembered the last location/size of a window and reopened it in the same state.

khubaib

One thing i am missing badly in processing is that it does not show all the available methods of an object. for example if i have created an object of PImage img; It should display all the available methods of PImage when i type img. This is a very useful tool please work on it. Thanks :-)

GoToLoop

@khubaib, both GreenFoot.org & BlueJ,org have that look into object feature!
It'd be nice if Processing had that too. Although Processing isn't exactly an educational tool!

clankill3r

At my school processing is used for education.

GoToLoop

I meant that BlueJ & GreenFoot are educational focused on Java and OOP in general! ^#(^
Processing is focused on graphs rather than Java and programming! :P

fkeel

The debug messages could really be improved. Especially when using multiple tabs, I find the messages almost useless, because it is difficult to understand where the error is.

Adding line-numbers would already do a lot to help with that.

Otherwise, I am sort of worried about too many features. I like processing because it is simple, light weight & portable.

*

notepad++ is my favorite editor btw.

barefists

Would be possible to have tab groups? I'm currently writing a 2D game engine in Processing and it's getting hard to track all the code beyond a few thousand lines using just the basic tab system.

Would be nice to be able to label a bunch of tabs under "Engine Code", and minimize it if I'm not messing with the engine.

calsign

@barefists - this is what libraries are for. If you have thousands of lines of code, then you should probably be using a Java IDE (like Eclipse). The PDE wasn't designed for such ambitious projects (unless this is changing in 3.0). However, I do agree that the PDE could benefit from improved tab management...

barefists

@calsign I'm not a programmer, whatever I know is self taught using Gamemaker and Flash, and I love that Processing (and it's IDE) is similar in it's muggle-friendliness. :)

I've tried Eclipse, and I couldn't even understand how to set up a simple project to print hello world on screen. I retreated in fear back to the Processing IDE.

The Processing project has really helped me learn programming in a way that does not require months of reading and expensive tuition fees. But the jump between understanding the concepts of programming and setting up a "real" project in a full-fledged Java IDE is still quite a daunting step, at least for me. :(

Chrisir

There's a tutorial on ecilpse, barefists

But, I haven't tried eclipse

clankill3r

I would like that Processing can make a javadoc. It should have it's own visual appearance to make clear it's not a library javadoc but a processing skecth javadoc.

GoToLoop

BlueJ's IDE got a simple javadoc maker! *-:)

tomanderson

I reported it as a bug but I am pretty sure that fixing this problem is a basic level one.

https://github.com/processing/processing/issues/2626

Basically, when we install Processing to a Windows computer, it is not an application, and instead resides in a folder. However, it is actually a secretive pseudo application that stores its preferences in hidden files.

Perhaps there are still people sharing desktop computers in 2014, but for the most part, because Processing <500 MB, every developer could have her own entire Processing IDE in a $2 USB stick.

Can we please stop this kludgy activity and put everything into the Processing folder by default on Windows?

Processing is a potentially unwanted program. We might want to remove it. Can we please have an uninstaller to get rid of the files that are put in places where nobody could predict that random files would be put. Because in the future, if we uninstall and reinstall Processing and it still doesn't work because of those old settings, we might get vexed. Just a little.

In other words, what I'm requesting that Processing is portable. It doesn't have messed up settings folders. I can organize my sketch folder or folders, I can set where the modes are stored, and I can also use the modes that are stored in the Processing folder without trying to find a file that is in a hidden folder that was put there without my knowledge.

I have googled this issue and it's come up quite a lot. There are more arguments for this, listed at the bug report above.

tomanderson

I'd like to see a modification to the Preferences panel that allows users to place their sketchbook in a relative folder, such as "../sketchbook". To go one step further, allowing quick switching between multiple sketchbooks would be really nice.

Flu

@tomanderson At my PC it puts all the modes and libraries in the Documents folder. First, I didn't know that, and when I wanted to change the Processing version, I wanted like a fresh start. Get rid of all the libraries and modes I've intsalled previously, and I didn't know where to find the folder... and that created more problems with the android mode... but anyway, no need to talk about that. I agree with you.

GoToLoop

I agree w/ @tomanderson. The only speck in the way for Processing to become fully portable is that "preferences.txt" outside its install folder! It doesn't make any sense! 8-}
Also, I'd like a version w/o built-in outdated JRE, able to run in any system where Java is properly installed!!! [-(

PhiLho

It is a very common practice, and even a recommended Windows practice (encouraged by Microsoft) to store the settings, if not in the registry (that's more random and harder to delete, actually!), into the AppData/Roaming folder: you can find out lot of program settings there, including those of Microsoft itself, Mozilla, Adobe, and many other editors.

Actually, Microsoft actively discourages putting settings in the install folder, particularly if the latter is in Program Files (it is now protected by the system). And it makes sense, because mixing data and executables is poor practice, making backups harder, and risking to loose settings when uninstalling / upgrading.

The folder where Processing stores settings is neither random nor hidden. I don't really get the rant of tomanderson, actually. And I suppose somebody could easily make a uninstall script, or at least some instructions on the wiki (if not already there!) where to find files to delete them if needed.

One thing on which I agree, is that the libraries folder and the tools one, should be located outside the sketchbook. For the same reason as above: we want to backup and track the sketches, but we have to exclude these folders, which is not practical.

Version without JRE: there was one in the past (the so called Expert version). Either it was too troublesome to keep yet another version, or too many people (not expert, obviously) had trouble with this version, complaining it wasn't working...

GoToLoop

There are 2 installation types for Windows:

• Proper system installation @ %ProgramFiles% and configuration @ %AppData%. It also provides uninstall!
• Loose portable install, a decompressed folder where we throw somewhere in the file system! No uninstall!

Disregarding the "preferences.txt" file, Processing clearly follows the portable model approach! :(|)
In short, "preferences.txt" is the only real stumbling block for 100% portable mode commitment! :O

Placing "preferences.txt" inside the install folder clearly defeats the multiuser profile model.
But there are simple solutions for that! For example, having a tick box for switching portable mode on/off! *-:)

GoToLoop

There was one in the past (the so called Expert version).

"Expert" version is a prejudice misnomer! Should be just called (no-bundled-Java version)! [-(

Either it was too troublesome to keep yet another version, ...

That "expert" version was exactly the same as the regular 1 but w/o the "/java" subfolder! :-@
Actually, deleting or renaming the "/java" subfolder automatically would make the regular version an expert 1! :P
That would force Processing's IDE to use the system's installed Java rather its outdated bundled 1! \m/

Unfortunately, from Processing 2 series on, the devs artificially & deliberately made so
that the ".exe" launcher now demands the "/java" to exist! And funnily, only in Windows!

In Linux I can still easily delete "/java" subfolder and Processing uses the system's Java normally!
But not w/o popping out a useless dumb warning box!

If we would still insist on using system's Java in Windows, we gotta fool the launcher by having a hardlink junction
on "/java" pointing to the system's JRE subfolder! It's a hard-to-pull-out hack for a regular user! :-w

... or too many people... had trouble with this version, complaining it wasn't working...

Who can blame them? Since the site's download section didn't instruct us to download & install Java! 8-}

GoToLoop

Latest Processing version 2.2.1 is already a 110MB compacted behemoth! About 40% of it is the bundled Java!

Most end-user Java apps I know about don't see any problem at asking us to download Java in order to run them!
Same is true for .NET based apps! At least when they don't come pre-installed. Depends on Windows version!
It puzzles me why an Integrated Development Framework such as Processing would think otherwise! :-??

Gonna list some regular end-user Java app examples below which cite Java as pre-requisite:

jEdit: http://www.jedit.org/index.php?page=download

Java Runtime version 1.6 (aka Java 6) or later is required for jEdit 4.4 and later. Java Runtime version 1.7 (aka Java 7) or later is required for jEdit 5.2 and later. Before installing jEdit, make sure you have a compatible Java virtual machine; see the compatibility page for details.

Sweet Home 3D: http://www.sweethome3d.com/download.jsp

If Java version 5 or superior is installed on your system, click on the following link to download and launch Sweet Home 3D version 4.4 (19.8 MB):

Areca Backup: http://www.areca-backup.org/documentation.php#tocHelp7

Areca is written in Java, which means that you need to have a suitable Java Virtual Machine (JVM) installed on your computer : Areca requires a JVM v1.4 or higher. Most operating systems come with a pre-installed Java Virtual Machine.

Pixelitor: http://pixelitor.sourceforge.net/

Pixelitor is a free and open source image editing software that supports layers, image effects, multiple undo etc. It requires Java 7 or higher.

HoDoKu: http://hodoku.sourceforge.net/en/docs_intro.php#running_hodoku

HoDoKu is written in Java/Swing and should therefore run on any platform supported by Java (tested on Windows and Linux - Ubuntu/GTK+-LAF). Since it is written in Java the Java Runtime Environment (JRE) version 1.6 or higher must be installed on your computer before you can run HoDoKu. The JRE can be downloaded from:

PhiLho

Note that I was always downloading the Expert version, because it was smaller, and I always have a JDK installed. So actually, I fully agree that having a no-Java version, with proper instructions, would be nice for people liking streamlined products.

BTW, I was wrong mentioning "without JRE". I recall now, the trouble was to have the JDK instead of the JRE, because Processing needs the javac compiler. At a time, it was using an alternative compiler (from IBM, IIRC), but it was badly outdated... The trouble was lot of people had a JRE, but few had a JDK.

I also don't disagree that having a portable version would be nice. It shouldn't be too hard to do, eg. checking if a Preferences folder exists in the Processing folder: just move the one created to the installation, and you are done!
So it would default to "standard" approach, the simplest for most noob users, and multi-users too, but "advanced" users would have a simple alternative to get a portable version.

zzsnaky

I would also like the PDE to be able to detect some errors. If it will make the way to find reference for some added libraries more convenient, and give some suggestions or choices when utilizing a library, programming efficiency will be obviously improved.

Stanlepunk

Like @riccardoch in previous post, I think the tab manager must be improve. There was a test few month ago https://github.com/processing/processing/issues/1968 Plus when there is a lot of tab the name dissapear, so it's be helpfull to see the name by rollover.

clankill3r

I also liked in 1.5.1 that it automatically opened the sketches that where open when you closed the program. And please get a new forum for 3.0. This forum is horrible.

zzsnaky

I would also like the PDE to be able to detect some errors. If it will make the way to find reference for some added libraries more convenient, and give some suggestions or choices when utilizing a library, programming efficiency will be obviously improved.

quark

Possible long term solution.

Replace the PDE with an Eclipse RCP application. The Eclipse framework has all the tools and features that we might want and the GUI could be simplified (compared to Eclipse) to give a reduced learning curve for newbies.

At the same time it could use "Eclipse perspectives" to provide more powerful interfaces for library and tool development. The Eclipse platform already has plugins for the JavaScript and Python. There are many commercial and open source examples of RCP apps.

The obvious why not is the amount of work needed to make this a reality, but the potential benefits could be huge, particularly in the areas of future development maintenance.

clankill3r

I think Quark has a good point.

PhiLho

@quark: another obvious why not is that Eclipse (which I use daily and appreciate) is bloated, compared to the PDE. I like to be able to run a PDE quickly just to test a few lines of Java. Having to wait 5 times longer for Eclipse to start up, to load its plugins, to check for updates, to refresh its indexes, etc. can be annoying.

The PDE is an alternative, those wanting Eclipse know where to find it.

Now, perhaps some work can be done on improving the Eclipse plugin for Processing.

quark

@PhiLho I also use and appreciate Eclipse daily and I agree that it is slow to launch which can be frustrating.

Yes - ProClipsing is a useful bridge for users wishing to move from PDE towards Eclipse so further development can only be good.

Freid

Hi,

A window menu allowing to switch between opened sketches.

A code reuse folder like suggested by clankill3r

clankill3r

being able to use the console as an input field to support command line applications.

GoToLoop

Being able to use the console as an input field to support command line applications.

AFAIK, if we run a Processing compiled program from a terminal, text input works! :-?
And of course, field args[] receive any passed arguments too! =:)

http://forum.processing.org/two/discussion/316/processing-command-line

clankill3r

AFAIK, if we run a Processing compiled program from a terminal, text input works!

That's good to know but it's quite some extra work I must say.

jas0501

I often have multiple sketches open and running. Occasionally I hit stop in the wrong window, having lost the context. My suggestion below doesn't solve this, engaging my brain would though, however...

It might be interesting to provide remembered sketch preferences and be able to set the background so IDE windows would appear different.

It would also make selection for the task bar easier, as I know I want to select the blue one.

It would also diminish the chance of applying edits to the wrong.

jas0501

Not sure if others get frustrated by this.

Console output from println()'s appears in multiple sketch IDEs. If sketch A is running and outputting occasional lines and I am debugging sketch B using debug println()s, whenever sketch A issues a print, the view of the console output in sketch B scrolls to the bottom, making reviewing the debugging lines a wrestling match.

Possible approaches:
1. restrict the println() output to that sketches window.
2. If it is impractical due to the way the console output is designed, then add a scroll-lock checkbox to keep it from scrolling when inspecting the output.

jas0501

Make the console buffer size adjustable. At times the debugging prinln() output exceeds the buffersize. It would be nice to be able to adjust the number of lines so the interesting parts are still around.

Manindra29

Hi everyone,

A new Processing 3.0 alpha 1 pre-release has been posted by the team. Get it from: https://processing.org/download/

We've tried to incorporate some of the feedback.

Here's what's new in the editor:

• Intelligent Code Completion - automatically triggered after typing 2 characters
• Refactoring Support - Right click on a variable -> Rename
• Jump to variable/method/class declaration with Ctrl(Cmd) + Click
• Integrated Tweak Mode
• Integrated Debugger
• Live error checking (errors in code are underlined)
• Sketch Outline View for quick navigation - Ctrl(Cmd) + L
• Tab Outline View for faster switching between tabs - Ctrl(Cmd) + Y
• Improved toggle comment behavior

Some of these features were developed under PDE X Mode and have been integrated into the main editor.

For a full list of changes and bug-fixes, checkout revisions.txt

Please help us test. We look forward to your feedback.

Thanks!

PhiLho

Awesome, Manindra29, I am downloading it right now!

What is the preferred feedback channel? Here? In the bug tracker? In a specific thread you plan to create?

Manindra29

Specific bugs should be reported in the bug tracker on GitHub.

I think general discussion/feedback can be continued in this thread.

rozling

I've just started playing with the alpha and am quite excited about the new features :)

Here are my thoughts on the IDE:

What features are missing from Processing (IDE)?

• user-defined themes (or at least a 'night' theme e.g. Solarized Dark)
• fullscreen mode
• unified window: integrated file browser, variable inspector, outline etc. IMO this would catapult Processing forward as an editor + make it far more user-friendly
• user-defined keyboard shortcuts
• comprehensive text selection/editing actions
• ability to target newer versions of Java
• ability to add a custom target for reference (e.g. javadocs or preferably Dash/Zeal)
• Some form of built-in reference e.g. (class definition on hover)

Also like these ideas posted above:

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.

Search/Find Functionality and result highlighting with less heavyweight UI as in Google Chrome browser, MonoDevelop or Xcode

What is the highest priority to add?

• user-defined themes
• fullscreen mode
• unified window

What is the worst thing about the current Processing text editor?

• Window management: panes everywhere!

• File management. Please take a look at:

  • Sketchbook + Examples + Library management. Having a separate pane for examples drives me nuts, but I'd prefer to either load all sketches via a pane or none. Ideally have a file browser panel integrated in Processing panel which is accessible via keyboard shortcut.
  • behaviour when opening a new instance of Processing > Open > Opening a sketch. The default/blank window stays open in the background and it's so redundant and annoying.

Also as mentioned above:

text coloring freaks out randomly

Can't use Alt to access menus

What is your favorite code editor and why?

Sublime Text because:

• instant full-screen, distraction-free editing
• user-defined keyboard shortcuts
• user-defined themes
• integrated file browser (not a floating pain!)
• better indication of unsaved changes
• focus on keyboard shortcuts: every action/option is possible without using the mouse
• comprehensive text selection/editing actions

BatchofCookies

I love the IntelliJ and flash-develop environments.

What I would like to see:

• Refactoring tools
• real-time error catching (Those red squiggles)
• export to action-script (flash)
• export to Haxe (multi-language support)
• More Plugins!
• keywords

The worst thing about the processing IDE is that none of it is real-time other than color coding... The overall feel of the IDE is very static and not very intuitive like an IDE should be... I am very aware that it is possible to use eclipse for this, and I have used it, But having everything in the PDE with both simplicity and the power to change to any mode quickly is something that you don't get in eclipse (btw IntelliJ is 1000x better).

orthoptera

I agree with Chrisir: an auto-constructor would be great.

orthoptera

Also, maybe there could be a "Library" menu:
* "Import Library" could be moved there
* Java's built-in libraries (java.util, javax.sound, etc.) could be listed there
* An "Open Library" function could be added to browse for a library a user downloaded, then move that library to the libraries folder

rebirth

Hello,

Firstly, thanks very much for reaching out for suggestions! I would like to emphasize that I like the minimalistic IDE and I hope you can add features without it becoming cluttered. Personally, I would also love to have autocomplete and also some editing features, such as keyboard shortcuts to duplicate a line, move a line up or down, and cut a line without having to highlight it (like MonoDevelop).

Thanks very much!

PhiLho

@rebirth autocomplete is already in the alpha versions of Processing 3.0.
+1 to duplicate lines (Ctrl+D?) and move lines (Alt+Up / Down like in Eclipse is great).
I would like also to have selection drag'n'drop (copy / move selection).

clankill3r

Maybe it was mentioned but I would really like that the IDE stays responsive when having to much output in the console instead of having to terminate the program.