Ok, @REAS @shiffman @codeanticode... outside of the attrib() discussion, I think this is the last item to wrap on API for 3.0.
In the past, there's been a magic variable called frame that gives you access to the JFrame object in PApplet. With 3.0, that no longer exists, so we need to figure out how we'd like to deal with it. The Java2D renderer (the current default) still uses a JFrame behind the scenes, but OpenGL no longer does, and JavaFX (what I hope will be the default in 3.0 final) doesn't either.
There are two questions:
- How much do we let people down easy (since people might use
frame.setTitle() or frame.setResizable() in their sketches)? Do we just make the (never part of the reference) frame field disappear, or do we provide nice warnings to goadguide people into updating their code?
- Where do new versions of these methods live? Is it
surface.setTitle() or just setTitle() in PApplet itself?
On the matter of the first question
There are several degrees of change, ranging from gently nudging with red text in the console (that users will ignore) and having most sketches still work without changes... to telling the patient that it won't hurt a bit before giving them a horse needle. To enumerate, some options:
- Create a dummy
frame object that maps to the new methods. This is some duct tape, but code still works, the only indication is that the console says “hey, you should be using surface.setResizable() instead of frame.setResizable(). This is currently what's happening. Though in alpha 10, if you're using the default renderer, you won't even get the warning (but you will get the usable frame object still used by Java2D).
- Create a dummy
frame object that causes the sketch to halt whenever it's accessed. The sketch stops, an error shows up saying “fix your s*t” (not localized).
- No dummy
frame, but the error matcher checks whether the message is “I don't know about anything named 'frame'” and instead says “update your code to 3.x, here's the web page with the changes”. (This one is hacky and imperfect.)
- Just remove
frame completely, and have people figure it out on their own. Least hacky. Most forward-thinking. Lousiest for users (which is arguably a knock on its 'forward-thinking' bona fides).
Regarding the second order of business
These methods could live in either PApplet itself, or in the surface field. Do we want people typing setTitle() or surface.setTitle(). The former sounds nice, but as the methods balloon (and are very general in name), it gets less pretty. Method names we might support:
setResizable()
setVisible()
setTitle()
setIconImage() for people who want to remove our 'play' icon in exported sketches
setLocation(x, y)
setSize(w, h)
Those are the main items, but as you can see, they get pretty generic.
There are also other items, like setting the menu bar, that are specific to the surface and the underlying technology involved. For these cases, we need to get the native object, ala:
void setup() {
size(400, 400);
JMenuBar mb = new JMenuBar();
// ... a bunch of code here for a menu bar
JFrame frame = (JFrame) surface.getNative();
frame.setJMenuBar(mb);
}
In OpenGL and JavaFX, it ain't a JFrame, and menu bars need to be set up differently. Another example for the native case would be getting drag and drop events. This getNative() doesn't exist yet, but follows a pattern we've been using elsewhere (in lowly PImage and PFont and others).
Cast your votes, gentlemen!
Ok, @REAS @shiffman @codeanticode... outside of the attrib() discussion, I think this is the last item to wrap on API for 3.0.
In the past, there's been a magic variable called
framethat gives you access to theJFrameobject inPApplet. With 3.0, that no longer exists, so we need to figure out how we'd like to deal with it. The Java2D renderer (the current default) still uses aJFramebehind the scenes, but OpenGL no longer does, and JavaFX (what I hope will be the default in 3.0 final) doesn't either.There are two questions:
frame.setTitle()orframe.setResizable()in their sketches)? Do we just make the (never part of the reference)framefield disappear, or do we provide nice warnings togoadguide people into updating their code?surface.setTitle()or justsetTitle()inPAppletitself?On the matter of the first question
There are several degrees of change, ranging from gently nudging with red text in the console (that users will ignore) and having most sketches still work without changes... to telling the patient that it won't hurt a bit before giving them a horse needle. To enumerate, some options:
frameobject that maps to the new methods. This is some duct tape, but code still works, the only indication is that the console says “hey, you should be usingsurface.setResizable()instead offrame.setResizable(). This is currently what's happening. Though in alpha 10, if you're using the default renderer, you won't even get the warning (but you will get the usableframeobject still used by Java2D).frameobject that causes the sketch to halt whenever it's accessed. The sketch stops, an error shows up saying “fix your s*t” (not localized).frame, but the error matcher checks whether the message is “I don't know about anything named 'frame'” and instead says “update your code to 3.x, here's the web page with the changes”. (This one is hacky and imperfect.)framecompletely, and have people figure it out on their own. Least hacky. Most forward-thinking. Lousiest for users (which is arguably a knock on its 'forward-thinking' bona fides).Regarding the second order of business
These methods could live in either
PAppletitself, or in thesurfacefield. Do we want people typingsetTitle()orsurface.setTitle(). The former sounds nice, but as the methods balloon (and are very general in name), it gets less pretty. Method names we might support:setResizable()setVisible()setTitle()setIconImage()for people who want to remove our 'play' icon in exported sketchessetLocation(x, y)setSize(w, h)Those are the main items, but as you can see, they get pretty generic.
There are also other items, like setting the menu bar, that are specific to the surface and the underlying technology involved. For these cases, we need to get the native object, ala:
In OpenGL and JavaFX, it ain't a
JFrame, and menu bars need to be set up differently. Another example for the native case would be getting drag and drop events. ThisgetNative()doesn't exist yet, but follows a pattern we've been using elsewhere (in lowlyPImageandPFontand others).Cast your votes, gentlemen!