New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Whither “frame” in 3.0 #3388

Closed
benfry opened this Issue Jun 15, 2015 · 12 comments

Comments

Projects
None yet
4 participants
@benfry
Member

benfry commented Jun 15, 2015

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!

@benfry benfry added this to the 3.0 beta 1 milestone Jun 16, 2015

@monkstone

This comment has been minimized.

Show comment
Hide comment
@monkstone

monkstone Jun 16, 2015

This discussion interests me for ruby-processing, I have created a fairly functional version of ruby-processing-3.0 ie ruby-processing using processing-3.a10. I needed some way of setting the sketch title, otherwise I got org.jruby.proxy.processing.core.PApplet$Proxy1 in the window title. So under the hood I accessed surface and supplied the user with a sketch_title method for use in setup. Also I'm missing frame.dispose that we used to use for ruby-processing watch mode. One peculiar thing with my ruby processing implementation is that whereas FX2D, P2D, P3D sketches mainly just run, once I move size and smooth to settings, the same sketches (when appropriate) in JAVA2D sometimes never display but don't error either.

monkstone commented Jun 16, 2015

This discussion interests me for ruby-processing, I have created a fairly functional version of ruby-processing-3.0 ie ruby-processing using processing-3.a10. I needed some way of setting the sketch title, otherwise I got org.jruby.proxy.processing.core.PApplet$Proxy1 in the window title. So under the hood I accessed surface and supplied the user with a sketch_title method for use in setup. Also I'm missing frame.dispose that we used to use for ruby-processing watch mode. One peculiar thing with my ruby processing implementation is that whereas FX2D, P2D, P3D sketches mainly just run, once I move size and smooth to settings, the same sketches (when appropriate) in JAVA2D sometimes never display but don't error either.

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Jun 16, 2015

Member

I think that I'm in favor of the surface.setTitle() approach as I understand it. For the first question, I'm in favor of option (1) in practice, but in favor of (4) in principle.

Member

REAS commented Jun 16, 2015

I think that I'm in favor of the surface.setTitle() approach as I understand it. For the first question, I'm in favor of option (1) in practice, but in favor of (4) in principle.

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman Jun 16, 2015

Member

I don't think we want to pollute the core reference with these new methods so I'm in favor of surface.setTitle() over setTitle() etc.

In another dasy and age, I might have said that these are superfluous and a wiki page for how to dig into Java to do this stuff is fine, but in that Processing these days is more of a place for desktop application development I think it is nice to implemenent this functionality in a more accessible and supported manner — surface seems like the perfect way to do so.

In terms of the error if option (1) isn't too much of a hassle to implement and maintain (stealing focus from other higher prioirty work) I think it's a good one. I'm also ok with (3) is if it's easier to farm the key info off to a webpage. I agree with @REAS that (4) is the right idea in principle but not practice!

Member

shiffman commented Jun 16, 2015

I don't think we want to pollute the core reference with these new methods so I'm in favor of surface.setTitle() over setTitle() etc.

In another dasy and age, I might have said that these are superfluous and a wiki page for how to dig into Java to do this stuff is fine, but in that Processing these days is more of a place for desktop application development I think it is nice to implemenent this functionality in a more accessible and supported manner — surface seems like the perfect way to do so.

In terms of the error if option (1) isn't too much of a hassle to implement and maintain (stealing focus from other higher prioirty work) I think it's a good one. I'm also ok with (3) is if it's easier to farm the key info off to a webpage. I agree with @REAS that (4) is the right idea in principle but not practice!

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 16, 2015

Member

Thanks gents. I will proceed with option one and the surface variable. I'd been leaning toward option two but I may not have, uh, sold it very well.

Member

benfry commented Jun 16, 2015

Thanks gents. I will proceed with option one and the surface variable. I'd been leaning toward option two but I may not have, uh, sold it very well.

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman Jun 16, 2015

Member

Oh oh, I see. Yes, actually better to not let the code run and require the change. I think that's a nice option as don't want to map frame for the rest of our lives, especially given we'll be soon mapping both frame and surface for highDensityVRLens8Xarea soon enough. As long as we can throw a nice warning with a clear explanation and instruction, I am all in favor of users requiring update code.

Member

shiffman commented Jun 16, 2015

Oh oh, I see. Yes, actually better to not let the code run and require the change. I think that's a nice option as don't want to map frame for the rest of our lives, especially given we'll be soon mapping both frame and surface for highDensityVRLens8Xarea soon enough. As long as we can throw a nice warning with a clear explanation and instruction, I am all in favor of users requiring update code.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 16, 2015

Member

I'm fine either way, what do you guys think? The second will be more of a motivation to upgrade but could be a nuisance if people have to move between 2.0 and 3.0. The second option is less code and cleaner, but the first is nicest to users.

Member

benfry commented Jun 16, 2015

I'm fine either way, what do you guys think? The second will be more of a motivation to upgrade but could be a nuisance if people have to move between 2.0 and 3.0. The second option is less code and cleaner, but the first is nicest to users.

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Jun 16, 2015

Member

I am OK with (2) particularly if we can give a nice bit of information or a link to info. I don't have enough experience with this case to have a hard opinion. How does this relate to @monkstone's question about ruby-processing?

Member

REAS commented Jun 16, 2015

I am OK with (2) particularly if we can give a nice bit of information or a link to info. I don't have enough experience with this case to have a hard opinion. How does this relate to @monkstone's question about ruby-processing?

@monkstone

This comment has been minimized.

Show comment
Hide comment
@monkstone

monkstone Jun 16, 2015

Regarding setting sketch title I'm cool with any proposal (because I've got a working solution thanks to jruby ability to make surface available via :field_accessor and setTitle can then be used in all modes). But I'm interested if we can somehow call the window to close (like frame.dispose), for ruby-processing watch mode (without a System.exit).

monkstone commented Jun 16, 2015

Regarding setting sketch title I'm cool with any proposal (because I've got a working solution thanks to jruby ability to make surface available via :field_accessor and setTitle can then be used in all modes). But I'm interested if we can somehow call the window to close (like frame.dispose), for ruby-processing watch mode (without a System.exit).

@shiffman

This comment has been minimized.

Show comment
Hide comment
@shiffman

shiffman Jun 16, 2015

Member

go with your gut @benfry I support both options!

Member

shiffman commented Jun 16, 2015

go with your gut @benfry I support both options!

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 16, 2015

Member

dispose() should never be called on the Frame—whether by a language/host like Ruby or by a user with inside a sketch. Doing so won't shut down the renderers, the thread, the drawing surface, etc. This is why exit() exists, because it takes care of safely winding down the rendering thread and any other internal housekeeping. Any further discussion on that can happen elsewhere; it's not part of the discussion of how we support old sketches that use the frame variable.

Member

benfry commented Jun 16, 2015

dispose() should never be called on the Frame—whether by a language/host like Ruby or by a user with inside a sketch. Doing so won't shut down the renderers, the thread, the drawing surface, etc. This is why exit() exists, because it takes care of safely winding down the rendering thread and any other internal housekeeping. Any further discussion on that can happen elsewhere; it's not part of the discussion of how we support old sketches that use the frame variable.

@monkstone

This comment has been minimized.

Show comment
Hide comment
@monkstone

monkstone Jun 17, 2015

@benfry I'm not proposing a dispose to be called from within the sketch, agreed this should be discussed elsewhere, as with issue with JAVA2D, which for the moment I'm hoping just goes away (as it sometimes just works). The watch mode listens for changes to a running sketch (on disk), closes the existing sketch including with frame.dispose and re-fires the changed version in the same thread.

monkstone commented Jun 17, 2015

@benfry I'm not proposing a dispose to be called from within the sketch, agreed this should be discussed elsewhere, as with issue with JAVA2D, which for the moment I'm hoping just goes away (as it sometimes just works). The watch mode listens for changes to a running sketch (on disk), closes the existing sketch including with frame.dispose and re-fires the changed version in the same thread.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 20, 2015

Member

Ok, going with warnings for most methods that have equivalents in surface (option 2) though there are a couple situations where it has to halt, like setUndecorated(boolean) which is just unsupported. Should be all wrapped up for alpha 11.

Member

benfry commented Jun 20, 2015

Ok, going with warnings for most methods that have equivalents in surface (option 2) though there are a couple situations where it has to halt, like setUndecorated(boolean) which is just unsupported. Should be all wrapped up for alpha 11.

@benfry benfry closed this Jun 20, 2015

@processing processing locked and limited conversation to collaborators Jun 20, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.