GSOC 2015

So I’ll be working under The Processing Foundation for yet another awesome summer this year, as part of Google Summer of Code 2015, with Manindra as my mentor. Here’s a(n almost) day-to-day activity log of what I’ve been upto:

4-8 August:

Added back debugging- the debugger now works in the version of processing with RSTA incorporated into it quite smoothly. This involved making a few changes to how RSTA handles the line numbering, but most of the changes were made by touching the RSTA code base as little as possible, and primarily modifying and tweaking the processing code base.

30 July-3 August:

Added in documentation to the auto-complete. This involves parsing the processing documentation html files at startup, storing the documentation in the appropriate hashmap (one each for classes, methods, system variables and constants), and each time the auto-complete options are cycled through, the documentation is taken from the appropriate hashmap.

27-29 July:

Minor tweaks to auto-complete, added variable support

25-26 July:

  • Made auto-complete handle overloaded methods like the original
  • Tweaked the PDE’s UI- the UI now looks almost exactly like the original

21-24 July:

Tested out how the Java auto-complete would look like if plugged into the PDE, and how many changes would be needed to make it work for processing. Found out that things would become too  hacky, and ended up using the tried-and-tested auto-complete currently in place in processing in the “RSTA-ed” PDE.

18-20 July

  • REPL Mode
    • Added a much more comprehensive reference accessible from the Help menu into the REPL Mode
    • Added in a right-click menu into the REPL Mode to enable the user to mark, copy, copy all and paste
    • Updated the REPL Mode’s createFooter() method call according to the latest changes
  • RSTA
    • Opened a couple of RSTA issues here, here, here and here, and submitted two tiny PRs here and here.
    • Coded up a basic Javadoc parser using the Doclet API. Here‘s an excellent tutorial that I stumbled upon.

16 – 17 July

  • RSTA Integration
    • Differentiate between errors and warnings in the Error Checker
    • Add in basic auto-complete for Java
    • Replace ErrorCheckerService with the new ProcessingErrorChecker
  • REPL Mode
    • Fix NPE that shows up when the Welcome screen is displayed- this NPE was due to null being returned instead of an Editor object. Fixed by making the Welcome screen display after a small delay after processing is launched.
    • Fix spacing in help command menu, rename “print” to “codify”

15 July

Document every single class, method and class variable in the REPL Mode. Whew!

13 – 14 July

  • Added in a Welcome dialog to let the user know the features of the REPL Mode at a quick glance
  • Updated the Help menu- the welcome dialog can be accessed via the Help menu, as can processing’s original references
  • Modify build.xml
  • Fix an error with shift+home+backspace

10 – 12 July

  • Updated the REPL Mode in accordance with the latest changes (notably, Manindra’s PR here, by virtue of which the REPL Mode now no longer requires the JavaMode.jar to be included in it, but can get by with a simple import statement in the properties file).
  • Added in help as a command word into the REPL Mode
  • Couple of bug fixes pertaining to the display of the prompts, using a renderer in the init statement, etc.
  • Modify mode.properties, README.md files

8 – 9 July

Now moving on to auto-complete. The RSTA has a pretty sweet AutoComplete library that ties in very nicely with it. Spent some time familiarizing myself with the library, and with the RSTALanguageSupport library, which, among other things, provides for a nice example of how exactly to go about using the AutoComplete library. Adding auto-completion seems straightforward enough- the main requirement is that the JavaDocs be packaged and provided in a specific XML format.

5 – 7 July

It turns out that syntax highlighting might be a little more challenging and time consuming than initially anticipated. Figured out the basic requisites for this:

  • Familiarized myself with how the RSTA handles tokens
  • Compared RSTA’s TokenTypes interface and JEditTextArea’s Token class; trying to map one to the other
  • Figured out how to do basic syntax highlighting
  • Figured out how to use the TMM

Direct mapping from the RSTA to the JEditTextArea won’t work- the RSTA has support only for two sets of reserved words and one set of function words, while the PDE requires 4 each. Even trying to squish them all up based on similar colour doesn’t work- the PDE still has too many Token Types. Not to mention token types the RSTA doesn’t cover at all, such as labels.

The second method would be to extend the TokenTypes interface, and re-implement all the classes which implement this interface. This is not exactly trivial either, since in that case all classes that implement these interfaces would have to be re-implemented, and all classes which extend, or contain an object of, these classes would have to be re-implemented. This gets even more complicated when the objects may be private. Not to mention that all the methods in such classes that use these objects would have to re-implemented too. Consider these examples:

  • The RSyntaxTextArea class itself has a private SyntaxScheme object, which is used for everything display related- the fonts, the colours of the tokens, etc. This SyntaxScheme object, in turn, has a private array of Styles, each element representing the Style of the corresponding TokenType (the Style contains the details about the colouring of the tokens, like their foreground and background colour), and it also implements TokenType.
  • The AbstractTokenMakerFactory (used to load the syntax highlighting java class) extends TokenMakerFactory, which used TokenMaker everywhere, which in turn uses Token everywhere (which again implements TokenType).
  • TokenImpl, which implements Token, is used extensively by SyntaxView, which in turn is used by the RSTA to do all its highlighting.

So the final option? Fork the RSTA and implement all necessary changes in that fork, but we’re putting this on hold for now.

2 – 4 July: Added in error highlighting for the RSTA in the PDE

  • Added in a parser adapted from the JavaMode (and hence got the error tabs displaying in the Error Bar)
  • Fixed up the error squiggles to squiggle the right parts of the code
  • Extended error highlighting to work with multiple tabs
  • Got the Error Table back in action- the user can now jump to the error directly by clicking ont he appropriate row in the error table
  • Got the errors to update quickly when the tab being viewed in the PDE is changed
  • Got the appropriate error message to print in the status notice area when an error is clicked on

With a few UI changes and basic error handling in place, here’s what things now look like:

Progress in making the UI resemble the original PDE's UI, and in adding back error checking

Progress in making the UI resemble the original PDE’s UI, and in adding back error checking

29 June -1 July

  • REPL Mode:
    • Added in some error recovery when the user modifies the class structure- Hotswap Agent doesn’t support the structure of the class being modified. So if the user adds or removes a method or global variable, hotswapping is going to fail. To avoid this, the REPL Mode now catches such errors, and restarts the sketch instead of hotswapping when such changes are made.
    • Fixed a NullPointerException when the user saves sketch- this exception was thrown if the user saved a sketch before actually running anything, because the locations of the intermediate java code and the compiled .class files were not yet set. Fixing this simply involved ensuring that these File object weren’t touched if they were null, since a null object would signify that the sketch hasn’t been launched yet.
  • RSyntaxTextArea
    • Fixed up the UI: Changed the background colour of the current line, the background of the gutter at the left, the colour of the line numbering, added margins to make the UI look much better, and fairly close to the original, although it still “looks” buggy.
    • Added in the Error strip, and a “TODO” handler, which lists all TODO’s as blue squares on the error bar: This was easy as simply adding in the TaskTagParser (that comes with the RSTA package by default) to the RSTA textarea, and adding in the Error Strip (whose how-to is conveniently given in the javadocs).
    • Add in a basic parser: Similar to how the TODO handler was added in, completed adding in a basic parser, slightly adapted from the PDE’s already existing parsing functions. Errors are now detected properly, and the error table now works (except that clicking on the error doesn’t take you to the error, but throws an exception). The squiggly lines and the red error rectangles in the error strip display, but at the wrong locations.

27-28 June

  • Added support for import statements- this mostly required parsing in a statement to see if it contained a statement of the form “import a.b.c.d. … .k.*;”, and ensuring that this statement is the only statement that the user has entered (i.e., to prevent the user from entering an import statement in a block of multiple statements). did this with the help of some regex. A very handy site I used to prototype and test the regex quickly is here.
  • Added hot-swapping into the PDE- simply saving a sketch when it is running now automatically hot-swaps the contents of that sketch to update them immediately. This was done very similarly to how the REPL functionality has been implemented, simply re-compiling the .java files into .class files and over-writing them on top of the old one (ensuring, of course, that the appropriate command line attributes are used when running the sketch).
  • Also had an awesome skype session with Manindra to discuss things like releasing REPL Mode, about the best way to go about things pertaining to the RSTA integration, and to chalk out what’s done and what’s left.

25-26 June

  • REPL Mode
    • Tested out the REPL Mode in Linux. The build file needed a little clarification, but it works well.
    • Tweak undo: Before, the sketch was not really updated, since although the code was modified, things already drawn persist in the sketch. As a result, the sketch needs to be updated when an undo is done (and simply hot-swapping doesn’t suffice).
    • Tweak clear: Now, the clear command simply clears the console, and not the whole sketch (which conforms with the behavior of most REPL consoles).
    • Updated the readme: A long overdue update, but now that the REPL Mode is almost completed, added in loads of details- how to build, what command words are present, etc.
  • The RSTA-integrated version of processing builds with ant: This was a little tricky, and it was not fully apparent exactly where to set the classpath. Finally figured out that the classpaths not only need to be modified in the build.xml files, but also in the config.xml file, responsible for setting the classpath for launch4j, which is what packages things into an exe on windows.

23 -24 June

  • REPL Mode
    • Renamed reinit to resize
    • Ensured that whenever the command words “init” or “resize” were run, the sketch window was “refreshed” (i.e., closed and re-opened), since this was often necessary (especially if the size of the window changed).
    • Updated the build.xml file to shift all the properties that the user had to specify when building (such as those related to the path where the processing source code was located) into a new and handy build.properties file (similar to how processing’s Template Library/Tool does it).
    • Replaced the hard-coded (and accidentally left in) path to the Hotswap Agent’s jar file with a relative one determined at runtime.
    • when testing things out on another system, I discovered that the Hotswap Agent doesn’t actually require a patched JRE (at least its use case in the REPL Mode doesn’t), which means that the REPL Mode is now ready to ship! (well, almost)
    • Also significantly improved the REPL Mode’s error handling- did this by catching some other errors thrown at runtime (including errors pertaining to what processing allows and doesn’t, such as where the size() method can and can’t be placed, and not those pertaining to errors during compilation which had been caught earlier). This also acts as a neat method of detecting when the user tries to call the size() method from processing, and to inform the user to use init or resize instead.
  • RSyntaxTextArea integration: worked on this with much more care than I did the previous time (which was merely meant to be a proof-of-concept, mostly by commenting out lines and methods that threw an error)- read the docs to see which methods of the RSTA could replace which of the JEditTextArea, tested things out on a rough prototype when I had a doubt, and commented out those errors that required a great deal of inspection (in particular, those pertaining to the painter and the error tabs) and marking them with a “TODO:” for easy tracking. Here’s what the PDE looks like after a the first stage of RSTA integration:

    Easing RSyntaxTextArea into the Processing Development Environment

    Easing RSyntaxTextArea into the Processing Development Environment

20 – 22 June: Done with hot swapping

  • Finally found out exactly why errors weren’t being detected in the main tab- when the new Sketch object was being created for the REPL Mode, it was setting that dummy sketch object as the current sketch. This was also causing other issues, like opening a saved sketch not showing any text (until a new tab was created), which was what actually helped me find this fix.
  • Add back the Contributed Examples tree node into the Examples window: the method which handles this got accidentally deleted when the Examples window structure was being updated. Thanks to git, this fix was a breeze, since everything that needed to be done was already present in a previous commit. The issue was filed here, and the PR submitted here.
  • Most important of all, auto hot swapping is now supported by the REPL Mode! This took a little bit of experimenting, but finally got it right:
    • For auto hot swapping, Manindra suggested this project as a nice way to start off. So I first made a tiny little project on Eclipse, and set things up exactly like they had suggested here (of course, adding in the specified command line attributes in the specified command line arguments in the VM arguments of the Run Configuration of the project. It worked! 1 down.
    • Next, I created my own sample sketch in Eclipse. That worked extremely well too! All I had to do was save the sketch for it to be updated. 2 down.
    • Finally, I tried adding in the arguments into the Runner’s launchVirtualMachine() method, but saving didn’t seem to do anything, but Hotswap Agent was loading just fine (after doing the steps linked above on processing’s JRE, of course). I played around with this a little more, and realized that all that was required was to update the .class file, i.e., simply building the code again in the same location would do. And then it would have to be ensured that the code is only compiled each time the user hits enter, and run only when the sketch has to be re-displayed (since otherwise, we’d get multiple sketch windows- one for each time the user presses the enter key, although all of them would show the result of the latest code, thanks to Hotswap Agent). Lots of modifications needed to be done to achieve this, but they were fairly simple in concept once this was figured out.

17-19 June

Minor diversion here. Thought I’d quickly help out with a couple of bug fixes and improvements for the PDE:

  • Improve the loading time of processing- learnt a lot helping out with this one (although this isn’t fully done yet). First, I took the help of JVM Monitor to do a little profiling, and to identify the main bottlenecks. A neat little trick to get the profiler to startup as soon as the main thread of the program is running is to set a break point right at the start first step of the main method. Things which took up a reasonable amount of time, and which could be off-loaded onto threads, included the following: loading up of libraries and tools and instantiating the various contribution manager objects. I also finally managed to understand the exact use of swing’s EDT. Briefly, most of swing is not thread safe- all updates should be done on a single thread, otherwise, straaaaange things may happen. This thread is the Event Dispatch Thread, or the EDT in short. So every time a new thread is started from the EDT, it must be ensure that all updates to swing components are done from the EDT, like so:

    SwingUtilities.invokeLater(new Runnable() {
    public void run() {
    swingUpdateMethod();
    }
    });

    When trying to off-load the process of loading up of the tool jars to a new thread, I ran into a very strange error which I couldn’t place my finger on- something along the lines of a ClassCastException stating that the Windows LAF cannot be typecast to the Nimbus LAF. This seemed to be entirely unrelated to any changes that I had made. I had no idea what the matter was, but had a feeling that there was something that I was doing outside the EDT. I found this extremely helpful page which provides a jar file to specifically identify exact what parts of the code make Swing calls from outside the EDT. When debugging this error, I found this stackoverflow post gives a  very nice method to add some logging to the AWT EventQueue, and this post gives a fantastic overview of what not to do when working with Swing.
  • Contributed libraries’ import statements now get added correctly: The issue is described here, and the PR filed here.
  • Helping out with some missing internationalization: PR here.

14 – 16 June

  • Loads of refactoring in the REPL Mode’s code: deleting unused classes, removing uncalled methods, formatting everything, removing all the pointless commented out code, and split massive code blocks into more meaningful methods.
  • Started working on replacing the JEditTextArea with the RSyntaxTextArea- of course, this was just a trial run to get a feel of things, but got a working (broken, but working nonetheless) PDE with the easier features of the RSTA down- the code folding and auto-completion.

12 – 13 June

Added in error checking for the REPL Mode. I tried 2 approaches for error checking- at first, I modified the PDE Error checker, and planned to pass the Sketch object into the error checker, and to extract the list of errors. While working on this, I realized two things: the first was that since the REPL console effectively took in code one line at a time, and error checked each time, it was assured that any errors thrown were due to the latest code input by the user (provided, of course, that it was taken care that no code with error was stored in the temporary sketch in the first place). The second was that any errors was displayed in the message status area. I realized that this was because whenever anything was run, error checking was done automatically (by looking at the errors thrown, and then presenting a “simplified” version of these errors in the message area). So all that I had to do was to display the error message on the REPL Console instead of in the message area, and done! Of course, this does not provide line-by-line error checking if a block of code is input at a go (such as for a loop or an if), and does not provide a list of all errors in the block (unlike the PDE), but these would be issues of much lower priority that could be deferred for later.

11 June

  • Minor refactoring: Changing how errors are handled- just shifting around code here and there for conciseness and clarity.
  • Done implementing print command: most of the framework was already in place- all this involved was talking the code of the draw() function, adding it into a user defined function, and appending it to the end of the editor, and, of course, checking for errors in the way the user enters the command (ensuring the command is of the form “print functionname”).
  • Error checker now works for main tab of PDE- although fairly obvious, this error took a little bit of time to nail. Although DocumentListeners were being added to the main tab’s Editor, the the insertUpdate(), changedUpdate() and removedUpdate() methods were never being called. However, I observed that creating a new tab fixed everything- errors were now being detected in both tabs… Hmmm… A little (ok, lots) of digging around later, I traced the error to one specific line- where I created a new sketch for the REPL Mode. Commenting out this one line made everything alright. I lloked through the code that created the new sketch object, and still couldn’t see what was going wrong- as far as I could see, there was nothing in there about adding in listeners when the object was created, and the only thing going on seemed to involve storing the mode of the current editor, and using it to get things like the default extension. I did find a solution however: add back the Document Listeners by calling the setCode() function on all SketchCode objects corresponding to the main Editor tab’s sketch, although I’m still not exactly sure of the source of the error.
  • Adding undo and redo commands- this involved creating an undo stack, and pushing commands from the ArrayList which stores all the valid commands encountered so far onto the stack. And if the user calls redo, popping from the stack and adding it back to the ArrayList.

June 9-10

  • Modify build.xml to make building the REPL Mode easier- my first ” non-trivial ” experience with ant. I was trying to figure out why errors weren’t being detected in the main sketch, and needed to do a string of operations each time I made a change, even if it was a simple println statement:
    First, I had to compile processing, then copy over the generated JavaMode.jar file to the lib/ folder of the REPL Mode, and then recompile the REPL Mode. In lieu of this, I added a task to first call processing’s build file’s build task and then copy over the generated jar into the REPL Mode’s lib/ folder, and another that depend on this task and the REPL Mode’s run task.
  • Fixed a bug where the sketch window would not display after init- for some reason, the code responsible for doing this was commented out. Now who could’ve done that?
  • Added in the implementation for init (to initialize the console from scratch, effectively providing a replacement for the size() function), reinit (to change only the size of the REPL sketch window, for example if the user start off and then realizes that the window is too small), and clear (at present, clears the console as well as the screen, without touching the init parameters), as well as error checking (ensuring the user provides an appropriate number and type of parameters).
  • Fixed bugs related to clear, where the console wasn’t getting cleared (which simply involved setting the console text to the prompt) and the output wasn’t getting shown on a clear.
  • Fixed a bug where the left and right arrow keys would “freeze” after the REPL Console was cleared- this happened because the rowStartPosition was not updated when clear was run, which prevented users from using the left arrow key. The fix was simple- when clear is run, simply update the rowStartPosition to 0.
  • init now clears the console, and displays only the init command- since init-ing again is effectively a fresh start, I thought it would be appropriate to have the init command clear the console and display init (and the arguments provided, if any) as the only command run so far. Of course, the history would still be cycle-able via the up and down arrow keys.
  • Fixed a bug in processing where the dialog box that throws error when there’s something wrong with the mode displays the stack trace vertically instead of horizontally. The fix was to parse the message text to replace “\n”s with the ”
    ” tags. Here‘s the PR.

June 7-8:

A couple of more bugfixes and improvements to the REPL Mode- a sketch started by the REPL Mode now closes when the main PDE window is closed; Hitting the enter key in the middle of text no longer breaks up the command, but runs it as a whole; also fixed what happens when the user finally enters “;” or a “}” after a “,” or “{” respectively- the sketch now displays as soon as the continuing statement is terminated. Also, it seems that the current way in which the REPL Mode generates code means that the sketch window is not always displayed- in particular, due to the empty draw(), as filed here.

June 5-6:

A couple of more checks to ensure that things work. Sketches seem to run fine now, exactly as they do in the JavaMode. Also, the REPL mode now works! Well, sort of- at least the REPL Mode’s dummy sketch, when fed in code, seems to run it properly. How the mode works at present is to read in a line from the user, and display a sketch containing all lines from the last “clear” up to the line just entered wrapped around by “void setup() {” and “} \n\n void draw(){}” to effectively create a proper processing sketch. Of course, there’s still line-by-line error checking to be done, and hot-swapping and “REPL-Only” commands (like init and undo) to be implemented, UI to be fixed and bugs to be ironed out, but its a great prototype. Also, submitted a PR that updates the Template Mode and makes it (hopefully) fully 3.0 compatible here.

June 3-4: REPL pre-prototype works!

OK. Finally managed to fix this issue! A huge thanks to Manindra for helping me figure this out. Here’s what I did to try and eliminate (or discovered during the process of elimination of) the problem:

  • Replaced the base class with Mode and Editor respectively, in place of JavaMode and JavaEditor now shows the REPL Mode in the menu, with no exception thrown. So the error is definitely because the class loader has no clue about what JavaMode or JavaEditor are.
  • I realized that the class path of the Java Mode itself does not contain JavaMode.jar, by printing the current classpath as shown here.
  • The JavaMode.jar has been included in the ant classpath: if I removed the line including it, javac itself threws errors along the lines of “Cannot find symbol class JavaMode” when building with ant. Further, the statement included to print ant’s classpath (described below) seems to print the path to the JavaMde.jar.

So the bottom line is that the JavaMode.jar file can’t be included as a separate jar in the REPL Mode (since this causes a ClassCastException, although the mode works until the time when its class loader has to be fetched, i.e., until some code is run), and if it is not included, it seems that the class loader doesn’t know what JavaMode is, although ant “knew about” JavaMode when running javac (which shows that the classpath is set correctly). This was when Manindra told me that he’d figured out what was going wrong and a fix. He told me that before pdex, java mode was a part of processing.app package, so it could be imported without adding the jar to a mode’s mode folder. But after pdex got merged into java mode, the original java mode was moved out processing.app package and made a separate standalone package: processing.mode.java, and that JavaMode.jar is therefore loaded by processing.app as an external contribution at present, i.e., that it is not in the classpath of Processing- Processing loads JavaMode as a contributed mode using a URLClassLoader, and then reads the JavaMode classes from JavaMode.jar.

The workaround was surprisingly simple- when searching through the modes list to return classpath of the JavaMode (which was initially returning a null pointer, since the two JavaMode classes weren’t “equal”), simply compare the names of the classes, and return the classloader of the mode whose name is identical to that of the JavaMode class presently in the REPL Mode’s classpath!

May 31-June 2:

Still trying to fix the classpath error. Printed out the ant classpath like so and it seems that all the .jars have been added from the lib/ folder just fine. Dug a little further (read: debugged my little heart out) and discovered a silently caught null pointer exception from the classloader that the mode returned, which, in turn, arose from the fact that I had included the JavaMode jar in the lib/ folder: it was searching for and trying to return the classpath of the JavaMode class that belonged to the jar currently in the classpath (processing/java/mode/JavaMode.jar), while REPLMode extended lib/JavaMode, which it doesn’t find the same. To test this theory, I tried typecasting one to the other, and boom- ClassCastException. I then removed the JavaMode.jar and added the location of the original jar into ant’s classpath, but this time, the Mode isn’t even detected by processing. Even more debugging, and I realized that the cause of this was yet another silently caught exception, this time a java.lang.NoClassDefFoundError: processing/mode/java/JavaMode. Woe is me.

May 28-30:

With the UI done, time to get down to the heart of the REPL Mode! Looked through the Processing code base to see exactly how the internals work, and how the code in the Editor magically makes a sketch appear. At present, to launch code, a sketch is required. So as a proof of concept, I’ve created a temporary sketch each time the REPL mode is run (much like how a temporary folder is created for every untitled sketch). The contents of this sketch would then be all valid commands typed in by the user until that point. Gave this a test run with some dummy code, but I got a java.lang.ClassNotFoundException: org/eclipse/jdt/core/compiler/batch/BatchCompiler exception thrown at me. At first, I thought that this was something wrong that I’d done, but then realized that this was true even for the Template Mode- though the mode PDE displays fine, it is unable to actually run any code (something that I had somehow not realized up until now). It seemed like org.eclipse.jdt.core.jar wasn’t in the classpath, or perhaps there was something wrong with the jar file. I tried replacing the jar with a recompiled one. Nothing. I checked the classpath in the ant build file, and it seems as if everything in the lib/ folder ought to be added into the classpath. Hmm…

May 25-27:

A little more stuff related to commands, and the prompt:

  • “Focusing” on the REPL pane: I wanted the REPL pane’s JTextArea to get focus as soon as the user clicks on the REPL Tab (so that, you know, the blinkey cursor thingy appears there). To do this, I added a Component Listener to the console (which contains the JTextArea), and then called a function that calls the JTextArea’s requestFocusInWindow() method from the Component Listener’s componentShown() method.
  • Incomplete command support: When the user enters a command ending with a ‘{‘ or a ‘,’, the prompt goes to the next line, replacing the ‘>>’ prompt symbol with the ‘…’ continue symbol, until a ‘}’ or ‘;’ are encountered, respectively.
  • clear command: Added in a clear command that clears the console. Also added a sort of a pointer to keep track of where the last clear was run, so that converting the command history to code will happen from the last clear command, while the user can cycle through the whole command history.
  • A bug fix when cycling through history that handles an edge case.

May 24:

Added in the provision to enable users to cycle through the “command history”, much like how most terminals/command prompts/REPL consoles permit. This mainly involved using the ActionMap and InputMap of the JTextArea to detect when the user presses an up/down arrow key, and remembering which command the user has currently reached in the history. It also required ensuring that the user doesn’t try to go past the first command (s)he entered, that the partially typed command the user entered is still there if (s)he cycles all the way down, and so on. Of course, it also involved actually keeping a track of which all commands the user has successfully entered so far (i.e., maintaining the history itself), which would (probably) be required anyway for the REPL part of the REPL Mode.

May 23:

Fixed the UI of the REPL Mode. This involved 2 things: the first was to replace the icons in the resources folder, which comprised of the old PDE’s icons, with the 3.0a PDE’s ones. The second was to re-implement the tab which enabled the user to switch to the REPL console from the Error pane/the Console. It initially involved removing two panels in the original footer, and then re-adding two new Panels: a JPanel with a CardLayout layout manager, to toggle between the 3 Panels (Error/Console/REPL), and another with a BorderLayout layout manager, which contained the 3 buttons. Now, on the other, hand, adding a tab simply involved overriding JavaMode’s new createFooter() method, and calling JavaMode’s constructor to get an EditorFooter object with all the other panels already added, and adding one more Panel (the “REPL” panel) to it before returning it.

May 19-22:

Managed to get the Template Mode compatible with Processing 3.0 alpha. The first step involved figuring out that the JavaMode.jar file needed to be included in the ant build file’s classpath, but this ended up giving me processing’s “We’re off on the wrong foot” window, citing a NoClassDefFoundError as the reason. Turns out that the Java Mode (which the Template Mode extends) depends on several other jars. Adding all of these jars into the library folder seemed to fix things, although the UI looked off. Once this was done, adding these changes into the REPL Mode was fairly simple, and simply involved copying the appropriate jars into the lib/ folder, which gets added into the build file’s classpath automatically (and all the jar files present here get copied over into the final Mode folder, too).

May 16-May 18: REPL Mode’s Console UI is up and running

Finally got the REPL Mode’s UI bug free! The old UI was extremely messy, and kind of buggy. It used two JEditorPanes placed side-by-side (yuck!), one to display the prompt, and another for the user to actually type in the command, along with caret and mouse listeners to prevent the cursor from editing the previous line. These few days, I replaced both these JEditorPanes with a single JTextArea used in a class extending a NavigationFilter, together with the help of JTextArea’s ActionMap. Here’s a post that helped me a great in getting the Terminal-esque feel that I wanted.Also did a couple of general clean-ups, such as updating the .gitignore file and the Eclipse project’s .classpath file.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: