*new* abstract windowing methods in CanvasPeer

Engines, Libraries and Tools Xith3D Forums
#1

As the title suggests, I have added some commonly used windows methods to the CanvasPeer interface and their corronsponding implemention for the JOGL CanvasPeerImpl class.

The methods are:
void setSize(int, int)
void setSize(Dimension)
Dimension getSize()
void setTitle(String)
String getTitle()
void setLocation(int, int)
void setLocation(Point)
Point getLocation()

So instead of using:


((Frame) ((CanvasPeerImpl) cp).getWindow()).setTitle("AseTest");

use:


cp.setTitle("Ase Test");

and you’ll thank yourself when you port your app to LWJGL :slight_smile:

Will.

#2

nice one :slight_smile:

#3

Nice! :smiley:

Please be aware that as Point and Dimension are AWT classes, you’re still relying of AWT being present even with a binding that is AWT-agnostic.

Also, what do you think about throwing a checked exception, or making an unchecked exception explicit in the JavaDoc foir each of these methods? Being able to set a title and move or resize a window are windowing-system dependent functions. Whether they are supported or not is a function of the context binding, not Xith3D. Just a thought.

#4

you are correct, although it would hardly be a great effort to create those two classes. I guess if people are worried about the package name I could code them and just plonk them in a com.xith3d.* one - but is there really a problem? I you wanted to distribute your LWJGL game, you would simplely create those packages and stick them in a jar “awt_lite.jar” or something :slight_smile:

I’m open for suggestions on the checked exception issue (infact I think there needs to be many more checked exceptions in Xith3d but that’s another topic). Is there a big problem with unsupported features just being ignored, it’s not like they are critical to the rendering or anything? Let me ask it another way, if you caught the exception, what would you do with it? I’m guessing not a lot.

Cheers,

Will.