Skip to content
prisonerjohn edited this page Feb 13, 2013 · 1 revision

We're working on a list of projects and how you can help contribute to the project. It'll be a little while before the page is built out, but we've added the page so that we can put things here as they come up during the development of Processing 2.0.

For all projects, it's incredibly important that things are kept as simple and user-friendly as possible. The PDE is not for developers, it's for people who are less familiar with code, and/or just want to get things done. We're far less interested in features to make the environment more powerful for advanced users than we are in features that make it easier to handle tasks that are common for a wide range of our audience.

There are three todo.txt files that cover many of the issues and what's being looked at/worked on/considered/forgotten about, one is in the root of the processing svn, and there are others in the 'core' and 'android' subfolders. These lists aren't comprehensive (or necessarily written in a way that's intended for others) since they're notes that Ben makes for himself, as he's generally the one dealing with the various issues.

Smaller, Isolated Projects and Fixes

In the push for 2.0, there are a number of smaller projects that could be handled by someone who doesn't necessarily want to dive all the way in to the code. These are isolated things that I've just never had the time to get around to. Any help is appreciated!

Most Important

  • The Auto Format needs some love. A motivated person with a couple free hours could take care of a number of issues, including: placement of else statements, extra indents, switch blocks, better maintenance of cursor position, and being able to select a portion of code to be formatted. Someday we'll replace the entire editor, and with it, the formatter, but for now these simple fixes would be huge.
  • The serial library needs a friend, especially when it comes to 32- and 64-bit versions for each of the platforms. We also have scattered reports of the library being broken in various configurations (issue 91, issue 357, issue 1374), but this varies across Windows, Linux, and OS X. Someone to babysit these issues and track them down would be most appreciated. We don't currently have a 64-bit version of the library (issue 1275), which is a matter of building the software for the right platforms, and being around to debug it if things go wrong when that's release with the Processing download. (We've added contributed versions in the past, but they were too buggy and we had to revert to the old version since no maintainer was available.)
  • Implement blendMode() for the default (2D) renderer on the desktop (issue 1423) and on Android (issue 1424). The modes that are available have been implemented already for the OpenGL renderer on both platforms. See the report for issue 1423 for more information and pointers to sample code to get you started.
  • Undo is not behaving properly (issue 707). Also related is how sketches are being set modified: sometimes too aggressively, because some key events are coming through as text being typed when they're just modifiers like the alt key. Oh the embarrassment.

Other Quickies

  • A quick change to clipboard handling so that HTML text can be pasted with “Copy as HTML” for HTML-aware applications (like the forum). This is a very easy one—just requires a little work and some testing. Prepare a Debian package for the project. Issue 114 covers the attempts so far.
  • Look into Windows file association problems and track down what hooks we need to implement in Java so that we can use multiple icon sizes for Windows 7 and friends.
  • Wrap Jonathan Feinberg's awesome Python version of Processing as a proper mode so that it can be run from inside the PDE instead of just the command line.
  • Implement selectInput(), selectOutput(), selectFolder() on Android (issue 1151).
  • Implement a command line version of the Android and/or JavaScript modes. In 2.0 beta 4, we've added a command line support for Java mode, but it'd be great to have the others as well.

Everything Else

We last did a thorough update on this section before 2012's Google Summer of Code, but most of the things listed here are still needs. Get in touch if you have questions.

Processing Development Environment (PDE)

  • Tool Chest: We've build a system that allows the PDE to be extended to enhance the action of programming. There's an extensive list of potential tools on the Processing Wiki that are waiting to be programmed. Instructions for building tools are here on the GitHub wiki.
  • Internationalization and localization: We need to do the i18n and l10n work for Processing and its GUI. We need something very, very simple on the i18n side so that it's easy to deal with in code, and easy for people to add new languages. Not terribly difficult work, but just needs to be handled in a way that doesn't change every instance of text in the source code into five lines of confusing mess.
  • Improving the debugger: Ben has never had the time to work on a proper debugger for the PDE, which means... we don't have one! If you're interested in working on this, this is the JDK documentation section that's relevant. We only use the JDI for launching a Java VM, which we only use to control starting, stopping, and getting exceptions. I've never had time to look into stepping through programs or being able to look at variables and their state (much less threads or others), but obviously folks would be interested in this. Though we only use JDI, there are parts of the JVM Tools Interface (JVM TI) that might also help. There were additional features added to JPDA in Java 6 that we haven't made use of in the past, but Processing 2.x will require Java 6, so those features can be used (though Java 7 or later features cannot). The source you'd be looking for is inside: processing/app/src/processing/mode/java and in particular processing/app/src/processing/mode/java/runner/Runner.java Our Google Summer of Code projects from 2012 have given us major improvements here! Stand by for updates.

Processing for Android

  • Additional Libraries to extend support to mobile device APIs for networking, mapping, and reading sensor data. We'd like to start with simple examples for different features (as we've done in the most recent release), and as these are ironed out, make them into libraries. We are not looking for a monolithic library to support all types of sensors, but lots of small examples of how to use different features. These libraries are not intended to be comprehensive, but rather focus on simple ways of using devices.
  • Interface/back-end: In release 0194, the run/stop/cancel interface took a step backwards, as changes were made to get things working under the new 'mode' system. This needs some care. It involves staring at some difficult multi-threaded code that handles the build and run cycle, launching an emulator, making sure that an AVD is setup and installed, and so on. In addition, on Windows in particular, we aren't getting very helpful errors out of the ant build scripts. Some tinkering should improve the situation. All this is very important for Android development.

Video

  • Thanks to an enormous effort by Andres Colubri, the video library for Processing 2.0 has a new engine built on top of GStreamer. While the library is near complete, there is still some work to be done, which includes building out support for as many capture devices as possible, as well as improving playback to allow for smoother scrubbing of a video.
  • While there are many contributed libraries for computer vision (including a few for OpenCV), we would like to investigate the feasibility of a better-supported OpenCV library to give Processing built-in features such as face detection, blob detection, etc. At the moment, getting OpenCV to work is a tricky proposition due to cross-platform differences, build instructions, and 32- vs 64-bit problems. It should be possible to make a single library that covers OpenCV and a simple Processing layer to it (probably on top of JavaCV), but that can be contained in a single library (requiring no additional installation steps), the way we've done with gstreamer.

JavaScript Mode

  • Because Processing libraries (core and contributed) are written in Java, they are not available in JavaScript mode. We are looking for help in creating a template for writing "cross-mode" libraries as well as implementing some of our core libraries in JavaScript (namely video.)

Bugs

  • Bug Exterminator: The software always has Issues (as documented on the Google Code site) to be dealt with.
  • Bug Evaluator: Our forum tends to fill up with reports of actual bugs, while the issues database fills with nitpicks that aren't really bugs. Someone to deal with these things and assess the real situation would be huge.