How to create tools that tweak the PDE?

amnon.owed

How to create tools that tweak the PDE?

in Library and Tool Development • 1 year ago

With all the focus on Processing tools lately, I've been motivated to look into this. I have set a modest goal for my first tool (or so I thought

). The tool I want to develop is one that allows for other file extensions (besides pde and java) to be edited in the PDE. This means for example glsl-shaders (glsl, vert, frag), xml, txt etc. All kinds of files that are currently discarded by the PDE, but that actually would be very useful to edit within the PDE.

Route 1 - Hard coding it in the source code
To test the feasibility of my idea I took a hard coded shortcut, by changing 1 single line in Processing's original source code and compiling it myself with ant. Et voilà! It worked. I was able to edit txt and other files directly inside the PDE. For completeness, the line to change is in the getExtensions() function in JavaMode.java.

public String[] getExtensions() {
return new String[] { "pde", "java" }; // hard code other file extensions here
}

Of course, the above was just a test and not a long-term, flexible solution for multiple users. So I though this tiny tweak would be a perfect simple thing for a first entry in the world of tool development. Well, this is where my search starts...

Route 2 - An "add extensions" tool
I started by getting things up and running. I have succesfully built the tool template with Eclipse and the destructiveTool example. It works fine in the PDE. So I'm all set. Now I've been reading the Processing source code and javadocs for the Base, Editor, Sketch and SketchCode classes. Seems relevant. The tool I want to create is mainly related to the Sketch class. That class holds a SketchCode[] array of basically all the tabs you see in the PDE. When loading the files in the sketch directory, all the non pde/java files are discarded. What I want is to add these files as tabs in the PDE based on user-defined file extensions. The simplest route seemed to add them to the main SketchCode[] array, just like my hard-coded route 1 quickly facilitated. Now it's very easy to get the SketchCode's that are in the array or to get all the files in the sketch directory. But I don't want to only print the file names, I want to add them to the SketchCode[] array. However that is problematic. All the variables in this class are private (safe programming), but there are only getters and almost no setters. In short, I'm having a hard time realising my goal. I tried a couple of things, but in the end, met the above described wall.

So this leads me to my two questions:

Are user-created tools allowed to tweak the PDE in areas usually handled by the original source code?
If this is allowed, how would I be able to realise my intended tool given the restrictions described?

Let me know what you think guys.

Replies(10)

rbrauer

Re: How to create tools that tweak the PDE?

1 year ago

I would approach it by adding a dummy file to the sketch path to hold the text of the file to load (blah.txt.pde). You can use deleteOnExit() on the File object. Then load the strings from the file and use setProgram(...) on the SketchCode object to display the loaded text and getProgram() for saving.

amnon.owed

Re: How to create tools that tweak the PDE?

1 year ago

Thanks rbrauer. I took up your suggestion. I have proof-of-concept code now that does the following:

Determine the files with user-defined file extensions
Create dummy "name_ext.pde" files (a dot is not allowed for a .pde filename)
Reload the sketch to show the dummy tabs in the pde
Fill each dummy tab with the correct code from the original file

The next challenge is that when you run the code, it will throw exceptions since the code in all these dummy tabs does not (and by definition cannot) adhere to Processing / Java syntax. When I open all the files in the PDE through route 1, on first sight it is the same result. Except that in route 1, you can run/save/etc. without a problem, since the files are not treated as pde's.

So it seems ideas revolving around the use of a dummy pde, renaming temporarily to pde, copying to a temporary pde all suffer from the above problem. They are treated as a pde, which they are not, especially with regard to syntax.

How could this problem be tackled? Are there perhaps alternative routes/ideas?

amnon.owed

Re: How to create tools that tweak the PDE?

1 year ago

With regard to the original question, I have checked out the source of the Sketch class some more. Besides the private variables there are also protected methods like insertCode(SketchCode newCode) and nameCode(String newName) that could be very handy to use. Unfortunately nor directly nor by subclassing can I gain access to these methods. Is this because a tool is in a seperate package?

I understand there are safety reasons why one wants to restrict access to functions. However when there is existing code that can do a task safely and efficiently, it seems counter-intuitive to force everybody to write more code that works around the original. Think of all the extra work and errors that may arise. Is it a trade-off between security and flexibility? Please explain.

Manindra29

Re: How to create tools that tweak the PDE?

1 year ago

I tried editing getExtensions myself and this seems to be the most simple approach to me.

You could try adding another mode. The 'compile and run' process is mode specific. For example, normal processing sketches are run under java mode. This mode supports .pde and .java files. In this mode, all files with pde extension, are pre-processed and converted to pure java source files, and then run by the compiler, while .java files are not pre processed. Similarly in java script mode, .pde and .js files are supported, and .pde files are pre-processed. Android mode's builder class( AndroidBuild.java) is a child class of JavaBuild.

So you code clone the java build mode and add the extensions you require, and rename the mode as a hybrid mode of sorts. Processing 2.0 alpha versions have a feature to add modes(click on standard mode label to see a add mode option), but there's no documentation yet on how to add modes. Maybe it's something planned for future updates.

insertCode, nameCode, etc are all protected, this seems to be done for safety reasons and sub classes won't help. Maybe while writing those original classes, the makers might not have seen the need to make these methods as public. But yeah, you're right, making those methods available for use from within tools interface would save writing a lot of extra code.

I'd like to see if someone can implement this from a tool. That would be great!

amnon.owed

Re: Re: How to create tools that tweak the PDE?

1 year ago

Very interesting Manindra29. Once adding modes becomes possible/documented, it might be the perfect solution combining the shortcut of route 1 with the added flexibility of user-defined file extensions at runtime.

The original Modes are included in the build, so that gives no insight into what should be placed in the contributed modes subdirectory. Based on ModeContribution.java it seems that similarly to libraries and tools, there should be a jar placed in the modes subdirectory. Based on the original Modes, I am assuming that contributed Modes should extend Mode.java just like contributed tools extend Tool. But further requirements remain a question mark.

Can't find anything in the todo.txt or open issues about developments with regard to contributed Modes. Also it feels a bit silly to enter a feature request for Mode guidelines and a template for this minor occasion. But still I would be happy to see the possibility of adding Modes included in future versions.

rbrauer

Re: How to create tools that tweak the PDE?

1 year ago

I forgot about having to reload to show the tabs. That is a little annoying because you have to prompt to save if you are loading more than one file. My lazy solution to the problem of the PDE trying to compile the code would be to automatically add a range comment at the very beginning and end, although Manindra's suggestion is probably better.

amnon.owed

Re: Re: How to create tools that tweak the PDE?

1 year ago

I appreciate your suggestions rbrauer and I definitely learned a few things investigating this route. But this solution is getting a bit hackish building one workaround on another workaround (and these are only the first obstacles). I think I will have to abandon this route for now.

amnon.owed

Re: How to create tools that tweak the PDE?

1 year ago

To summarize:

The contributed Mode solution is not yet applicable (but one to watch).
The dummy-pde solution is running into many obstables (requiring workaround on workaround).

If anybody has other ideas let me know.

Manindra29

Re: How to create tools that tweak the PDE?

1 year ago

Designing contributed modes is indeed possible! Florian Jenett has been working on the coffee script mode ( github repo). Check out the Read Me section for instructions on how to set it up with Processing 2.0a5. It's worth checking out.

amnon.owed

Re: How to create tools that tweak the PDE?

1 year ago

Good to know. I tried it out, very interesting. It really changes different aspects of the PDE.

When time is available, I will give my PDE tweak idea another shot.

Top Reply