Skip to content

Whither “frame” in 3.0 #3388

Description

@benfry

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:

  1. 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?
  2. 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:

  1. 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).
  2. 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).
  3. 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.)
  4. 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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions