Author Topic: JSFML - A Java binding for SFML (Read 51285 times)

pdinklag · « **Reply #15 on:** May 30, 2011, 09:04:10 pm »

Found out a little about the events.

All input events work fine if the JSFMLCanvas does have the focus on itself. The problem is that text fields and areas always request focus on themselves, so as soon as a text field or area is involved, the JSFMLCanvas will not receive any keyboard or mouse wheel events. The Input class will not work either in that case.

I'll have to play with this a little and see what could be done about it.

Concerning the resizing, no luck so far.

EDIT:
OK, interestingly, if the canvas does have the focus, the RenderWindow will not receive any resize events, but my custom resizing will work just fine!

So I'll need to somehow make sure that the RenderWindow has the focus in as many situations as possible...

I hope this page helps me to learn more: http://download.oracle.com/javase/6/docs/api/java/awt/doc-files/FocusSpec.html

EDIT 2:
OK, for the matter of resizing, it's enough if the canvas is focusable at all. The position popping doesn't happen anymore either, so even though the RenderWindow doesn't get any resize events, this seems to work just fine now.

EDIT 3:
The sizing issues are completely fixed now. I even added an option: you can have the image in the JSFMLCanvas scale with the canvas itself, or have its viewport extend so it can display more.

Laurent · « **Reply #16 on:** May 30, 2011, 10:10:38 pm »

Quote

I am aware that "window" doesn't mean a window in the Windows sense only.

So what did you mean with "no ordinary windows"?

Quote

What are the flags I need to adjust? I suppose I do that using SendMessage in Windows?

Nop, I'm talking about whatever flags your specific API (in this case SWIG) may offer -- which usually have a direct effect on the OS-specific low-level.

Quote

All input events work fine if the JSFMLCanvas does have the focus on itself. The problem is that text fields and areas always request focus on themselves, so as soon as a text field or area is involved, the JSFMLCanvas will not receive any keyboard or mouse wheel events. The Input class will not work either in that case.

This seems quite normal to me, that's how all controls work. If everything could react to keyboard events without having the focus, it would be a big mess

Quote

I even added an option: you can have the image in the JSFMLCanvas scale with the canvas itself, or have its viewport extend so it can display more.

I'm not sure that you should provide such an extension to the SFML default behaviour, it may confuse people. Especially since it can be achieved without Java/internal specific code, it's just a matter of SFML views.

pdinklag · « **Reply #17 on:** May 30, 2011, 10:27:56 pm »

Quote from: "Laurent"

Nop, I'm talking about whatever flags your specific API (in this case SWIG) may offer -- which usually have a direct effect on the OS-specific low-level.

It's called Java Swing, not SWIG.

Swing is built upon AWT, Java's old GUI builder. Unlike AWT, Swing components have no actual window handle anymore but are lightweight, meaning that Swing itself draws them itself. This JSFMLCanvas is an AWT component, I need to use the old AWT one here ("old" does not in any way mean bad or deprecated) because those still get their own window handle.

Sorry if that's confusing, just wanted to clarify the terms "Swing" and "AWT". You're probably no Java developer, so why would you even need to know.

Anyway, I'm not sure how exactly those AWT components are linked to their actual OS window counterparts, what events they take, etc. That's why I personally call them "non-ordinary", no special meaning really.

While I couldn't make the RenderWindow receive resize events on its own, I could catch them on a Java level and the RenderWindow's size from the Java level. This works just fine, I don't see any problem with this. And luckily, since the RenderWindow's SetSize method also creates a "Resized" event, people can catch that fine.

Quote from: "Laurent"

This seems quite normal to me, that's how all controls work. If everything could react to keyboard events without having the focus, it would be a big mess

True that. So I guess this does not need any extra work, except that the JSFMLCanvas should be focusable by clicking on it, I suppose. Does it work this way in the .NET binding?

Quote from: "Laurent"

I'm not sure that you should provide such an extension to the SFML default behaviour, it may confuse people. Especially since it can be achieved without Java/internal specific code, it's just a matter of SFML views.

What's the default behaviour, say in .NET, when the control containing the RenderWindow gets resized? In my case, the default behaviour is that the contents get scaled with the control.

You're right, the viewport extension is simply done using Views and could be left to the users by reacting on resize events.

Laurent · « **Reply #18 on:** May 30, 2011, 10:45:33 pm »

Quote

It's called Java Swing, not SWIG.
Swing is built upon AWT, Java's old GUI builder. Unlike AWT, Swing components have no actual window handle anymore but are lightweight, meaning that Swing itself draws them itself. This JSFMLCanvas is an AWT component, I need to use the old AWT one here ("old" does not in any way mean bad or deprecated) because those still get their own window handle.

Sorry if that's confusing, just wanted to clarify the terms "Swing" and "AWT". You're probably no Java developer, so why would you even need to know.

Sorry I always mix SWIG and Swing :lol:
Thanks for the clarification, and don't worry I know a little about Swing and AWT, so what you say is not chinese to me

Quote

While I couldn't make the RenderWindow receive resize events on its own, I could catch them on a Java level and the RenderWindow's size from the Java level. This works just fine, I don't see any problem with this. And luckily, since the RenderWindow's SetSize method also creates a "Resized" event, people can catch that fine.

Ok, sounds good to me.

Quote

So I guess this does not need any extra work, except that the JSFMLCanvas should be focusable by clicking on it, I suppose. Does it work this way in the .NET binding?

Absolutely. It even works this way with a C++ SFML window --> if the window loses the focus it doesn't receive keyboard events anymore (whether it is a top-level window or not).

Quote

What's the default behaviour, say in .NET, when the control containing the RenderWindow gets resized? In my case, the default behaviour is that the contents get scaled with the control.

This is the expected default behaviour regardless the language, it's implemented like this in the core C++ code.

pdinklag · « **Reply #19 on:** May 31, 2011, 02:33:14 pm »

Quote from: "Lauent"

Quote
So I guess this does not need any extra work, except that the JSFMLCanvas should be focusable by clicking on it, I suppose. Does it work this way in the .NET binding?

Absolutely. It even works this way with a C++ SFML window --> if the window loses the focus it doesn't receive keyboard events anymore (whether it is a top-level window or not).

Alright, I have some trouble with this, further detailed in here: http://stackoverflow.com/questions/6187472/awt-component-cannot-gain-focus-in-the-presence-of-a-text-field
I hope I can find a solution to this or somebody knows one.

Quote from: "Lauent"

Quote
What's the default behaviour, say in .NET, when the control containing the RenderWindow gets resized? In my case, the default behaviour is that the contents get scaled with the control.

This is the expected default behaviour regardless the language, it's implemented like this in the core C++ code.

Alright, I removed the option again, works this way by default in Java as well.

pdinklag · « **Reply #20 on:** June 08, 2011, 11:37:09 am »

I was able to figure out (but not yet fix) the focus problem.

Java uses the GWLP_USERDATA field to store a pointer to an AWTComponent object, which apparently is required so the Canvas can cooperate with AWT correctly. SFML overrides that field to store its own Window object pointer, which will of course break AWT functionality.

I'm not yet sure how to solve this conflict, but I'll find a way.
I also have no idea yet whether this problem even exists in any environment other than Windows.

I'd appreciate any hints you can give me.

Laurent · « **Reply #21 on:** June 08, 2011, 11:49:24 am »

The usual alternative to user data is to have a global hash/map that associates Swing windows to their SFML window.

pdinklag · « **Reply #22 on:** June 08, 2011, 12:46:00 pm »

Looked at the X11 and Cocoa code, I don't think this issue will occur on Linux and Mac.

My idea for Windows is as follows upon creation of the JSFMLCanvas:
[list=1]

Retrieve the GWLP_USERDATA field for the canvas (AWT component pointer) and save it.
Let SFML initialize the Window for the canvas' handle.
Get the WindowImplWin32 pointer from the overridden GWLP_USERDATA and save it into the canvas' java object.
Restore the old GWLP_USERDATA value (AWT component pointer) so the canvas will still behave correctly in the Swing GUI.
[/list:o]

It is possible for me to retrieve the Java object from the AWT component pointed to by Java's GWLP_USERDATA value. So what I'm going to do is create a custom GlobalOnEvent that will retrieve the WindowImplWin32 right from that Java object instead from the user data.

Quite a hack, but it should work just fine.

EDIT:
OK screw that, a hash map should be a lot easier. :D

pdinklag · « **Reply #23 on:** June 08, 2011, 03:12:13 pm »

Done.
The JSFMLCanvas is now focusable and receives all events correctly.

pdinklag · « **Reply #24 on:** June 16, 2011, 03:38:51 pm »

Just in case people are wondering what's going on here.

The next scheduled task was to allow to create custom Drawable classes on a Java level, but since the whole Drawable, Image and Texture system is going to be changed entirely for what I know, I am kindof waiting for that update.

If somebody is interested giving this a shot on Linux or Mac ("giving a shot" means compiling the native Java library, which might need some adjustments in the C++ code), please let me know.

Hiura · « **Reply #25 on:** June 16, 2011, 04:56:56 pm »

If you want I can test JSFML on Mac in about three weeks. Just remind me then. ;-) (I've got some final exams coming up soon.)

pdinklag · « **Reply #26 on:** July 14, 2011, 09:28:15 am »

Updated JSFML to the new input system.
Still waiting for the big Graphics update to come.

Hiura, I gather you're currently busy implementing the new input system for MacOSX. If you're free, let me know.

General question about MacOSX: Is it possible to compile C++ on a Mac as well? I saw that the Mac sources of SFML are written in ObjectiveC. I'd hate to maintain the same code in two languages, talking about the native part of JSFML...

Hiura · « **Reply #27 on:** July 14, 2011, 09:43:26 am »

Quote from: "pdinklag"

If you're free, let me know.

I will be very soon. Next week let's say.

Quote from: "pdinklag"

General question about MacOSX: Is it possible to compile C++ on a Mac as well? I saw that the Mac sources of SFML are written in ObjectiveC. I'd hate to maintain the same code in two languages, talking about the native part of JSFML...

Compiling C++ code is possible, of course, but the problem is that the APIs provided by Apple are mostly written in Obj-C. Some are in C, however. In fact in the Mac port of SFML I'm using some combination of C++ and Obj-C (called Obj-C++).

What do you want to achieve exactly ? Depending on that there might be some alternatives to Obj-C APIs, however this is not common and most of the time you have to deal with it.

pdinklag · « **Reply #28 on:** July 14, 2011, 10:05:48 am »

Quote from: "Hiura"

What do you want to achieve exactly ?.

Are you familiar with Java and the JNI?

To use SFML in Java, I wrote JNI compatible C++ code which is then compiled into a DLL (with SFML linked statically). That DLL can be loaded and used in Java, it serves as a binding between the JVM and SFML. On Linux, this would be a Shared Object (.so file). I have not compiled JSFML for Linux yet, but I have experience with that and it won't be any problem. However, I never used a Mac in my life and got no idea how I would go about it there. I guess what's needed is a dylib, but I'm honestly not sure at all. Anyway, a dynamic library that the JVM can load and use will be required.

The core jsfml C++ source, which contains nothing but JNI compatible delegates and bindings to SFML methods and objects, should be platform independent and even compile on a Mac.

The only thing that definitely needs platform specific code is (currently) the JSFMLCanvas implementation. It's that Java AWT component I blogged about earlier in this thread, it can be used to seamlessly integrate an SFML render window into a Swing GUI. In the best case, all that'll be needed is a Mac-specific method to retrieve a Cocoa handle for the Java canvas.

Hiura · « **Reply #29 on:** July 14, 2011, 11:17:03 am »

Quote from: "pdinklag"

Are you familiar with Java and the JNI?

I know how it basically works but I've never used it.

Quote from: "pdinklag"

However, I never used a Mac in my life and got no idea how I would go about it there. I guess what's needed is a dylib, but I'm honestly not sure at all.

Dylibs are the equivalent of .so so I guess you're right. Moreover, chown33 confirms it here.

Quote from: "pdinklag"

In the best case, all that'll be needed is a Mac-specific method to retrieve a Cocoa handle for the Java canvas.

Well, I don't know how to do that so good luck. :wink:
(I googled a bit but I could only find stuff for Windows.)