No, I’m not talking about Christmas ornaments. I just came up with a quick hack to turn off the window frame from inside Processing. See this thread on the Processing forums to know why this is useful.
When running in the IDE the sketch runs as an applet, so it can’t use the “–present” command line switches available to applications because init() is called instead of main(). My hack simply overrides the default init(), sets the frame to be undecorated and then calls the regular PApplet.init().
Update: Setting the location of the window needs to happen in setup(), not init().
import processing.opengl.*;
void setup(){
size(400,400,OPENGL);
background(0);
frame.setLocation(0,0); // needs to be in setup(), not init()
}
void draw(){
stroke(255);
line(0,0,200,200);
}
public void init() {
frame.setUndecorated(true); // works.
// call PApplet.init() to take care of business
super.init();
}





main() is called after init(), which will reset any changes to the frame bounds. Instead, try moving
frame.setLocation(0,0);into setup().Thanks, Kyle, I’ve updated the code accordingly.
Ah, very handy that. Thanx.
Tried this in Eclipse, but to no result…
Unfortunately the applet won’t even initalize…
:-
I tried this with Processing 1.0.3 on Windows XP, either under Processing IDE, or built as standalone application, and both failed. I wonder if something changed since 2007, or whether I did something wrong?
See http://processing.org/discourse/yabb2/YaBB.pl?num=1185318989/0#4
I found something I’d like to share with you…
Good news: I found the solution to the cryptic error message “The frame is displayable” — simply add this
frame.removeNotify();
will change it to non-displayable and thus remove the compilation error. (You may need to make it displayable again after frame.setUndecorated(true); )
Bad news:
frame.setLocation(1020,200); // no effect
I am not able to get it to change the display location no matter what x y location I use.
Do you have access to the changes since 2007 that can shine a light on this issue?
It now works for me — its not easy to find the answer, so I thought I’ll share it…
It turns out the requirements for frame.setLocation(x,y) is different dependent on which mode — most examples uses OPENGL which explains why people who used it said it works. I used P2D, and I got frame.setLocation(1020,200); to work inside draw()…