I'm using a JOGL FPSAnimator and Apple's FullScreenUtilies class. I implemented this some time ago, and it worked fine. Here is my code for enabling the native OS X fullscreen capability, similar to other code on SO and around the web:
String className = "com.apple.eawt.FullScreenUtilities";
String methodName = "setWindowCanFullScreen";
try {
Class<?> clazz = Class.forName(className);
Method method = clazz.getMethod(methodName,
new Class<?>[] { Window.class, boolean.class });
method.invoke(null, frame, true);
} catch ...
It also works fine in the context of a simple test program I made in an attempt to isolate the issue. I'm not sure at what point the behaviour changed - I haven't spotted anything incriminating in SVN logs. It's likely that I first implemented the feature on an earlier version of OS X, and have also upgraded JOGL version and MyDoggy which we use for docking since. However, all of these things work with fullscreen in the context of other applications.
When I press the green fullscreen button, the usual OSX fullscreen transition starts (it gets its own desktop space), but the window appears frozen from that point on.
The main AWT Event thread carries on running, and I can see that my GLEventListener.display() method is being regularly called. I've tried adding a return to the beginning of that method to eliminate the impact of my rendering code, this unsurprisingly made no difference.
For testing purposes, I added a FullScreenListener:
FullScreenUtilities.addFullScreenListenerTo(frame, new FullScreenAdapter() {
#Override
public void windowEnteringFullScreen(FullScreenEvent arg0) {
log(">>> Entering fullscreen... <<<");
}
#Override
public void windowEnteredFullScreen(FullScreenEvent arg0) {
log(">>> Entered fullscreen. <<<");
}
});
As anticipated, I get the entering fullscreen event, but not the entered one.
It's a fairly large program, but there should be a fairly small surface of things that are potentially relevant here... unfortunately I haven't managed to trace them down. Happy if anyone has any pointers.
Related
I'm making a small program in Java using the Robot class. The program takes over the mouse. while in the course of debugging if it starts acting in a way that I don't want it's hard to quit the program, since I can't move the mouse over to the terminate button in eclipse, and I can't use hotkeys to hit it because the mouse is constant clicking in another window, giving that window focus instead.
What I'd like to do is just hook up a keylistener so that when I hit q I can quit the program, but the only way I know how to do this involves making a window, and that window needs focus to capture the input. Is there a way to listen for keyboard or mouse input from anywhere, regardless of what has focus?
There is a library that does the hard work for you:
https://github.com/kwhat/jnativehook
This is not a trivial problem and Java doesn't give you a way to do it elegantly. You can use a solution like banjollity suggested but even that won't work all the time if your errant mouse clicks open another fullsized window currently open in your taskbar for example.
The fact is, Java by default gives developers very little control over the OS. This is due to 2 main reasons: security (as citied by java documentation) and the fact that different operating systems handle events completely differently and making one unified model to represent all of these would probably not make a whole lot of sense.
So to answer your question, I imagine what you want is some kind of behaviour for your program where it listens for keypresses globally, not just in your application. Something like this will require that you access the functionality offered by your OS of choice, and to access it in Java you are going to need to do it through a Java Native Interface (JNI) layer.
So what you want to do is:
Implement a program in C that will listen for global keypresses on your OS, if this OS is Windows than look for documentation on windows hooks which is well docuemented by Microsoft and MSDN on the web and other places. If your OS is Linux or Mac OS X then you will need to listen for global keypresses using the X11 development libraries. This can be done on an ubunutu linux distro according to a Howto that I wrote at http://ubuntuforums.org/showthread.php?t=864566
Hook up your C code to your Java code through JNI. This step is actually the easier step. Follow the procedure that I use in my tutorial at http://ubuntuforums.org/showthread.php?t=864566 under both windows and linux as the procedure for hooking up your C code to your Java code will be identical on both OSes.
The important thing to remember is that its much easier to get your JNI code working if you first code and debug your C/C++ code and make sure that it is working. Then integrating it with Java is easy.
Had same problem. In my case, robot just controlled a single Windows App, that was maximized. I placed these lines at top of main loop driving the robot:
Color iconCenterColor = new Color(255,0,0); // if program icon is red
if (iconCenterColor.equals(robot.getPixelColor(10,15)))
throw new IllegalStateException("robot not interacting with the right app.");
To cancel the robot, just alt-tab to another app. Works great for a simple one app driving robot.
Start the program from a command line in a terminal and use Ctrl-C to terminate it.
(As mentioned by #MasterID and shown on JNativeHook's documentation for native keyboard input detection {main GitHub project here}),
This code should be enough to listen to any key without app focus (press and/or release):
>>Remember to add the jnativehook library in your project to be able to use all its utilities.<<
public class yourClass implements NativeKeyListener {//<-- Remember to add the jnativehook library
public void nativeKeyPressed(NativeKeyEvent e) {
System.out.println("Key Pressed: " + NativeKeyEvent.getKeyText(e.getKeyCode()));
}
public void nativeKeyReleased(NativeKeyEvent e) {
System.out.println("Key Released: " + NativeKeyEvent.getKeyText(e.getKeyCode()));
}
public void nativeKeyTyped(NativeKeyEvent e) {
System.out.println("Key Typed: " + NativeKeyEvent.getKeyText(e.getKeyCode()));
}
public static void main(String args[]){
//Just put this into your main:
try {
GlobalScreen.registerNativeHook();
}
catch (NativeHookException ex) {
System.err.println("There was a problem registering the native hook.");
System.err.println(ex.getMessage());
System.exit(1);
}
GlobalScreen.addNativeKeyListener(new yourClass());
//Remember to include this^ ^- Your class
}
}
For this particular problem, use the nativeKeyPressed method like this:
public void nativeKeyPressed(NativeKeyEvent e) {
System.out.println("Key Pressed: " + NativeKeyEvent.getKeyText(e.getKeyCode()));
if (e.getKeyCode() == NativeKeyEvent.VC_Q){
System.exit(1);
}
}
Note that JNativeHook by default shows a lot of stuff in your console that you might not want, to change that, just add this right before the try-catch that you used in the main function as shown (this is also going to turn off warning and error messages, more info here):
//(From here)
Logger logger = Logger.getLogger(GlobalScreen.class.getPackage().getName());
logger.setLevel(Level.OFF);
logger.setUseParentHandlers(false);
//(To there-^)
try {
GlobalScreen.registerNativeHook();
}
catch (NativeHookException ex) {
System.err.println("There was a problem registering the native hook.");
System.err.println(ex.getMessage());
System.exit(1);
}
Disclaimer: I know this question was solved years ago, I just hope someone finds this a little easier to find/use.
Have your program open a second window which displays underneath your main window but is maximised, then your errant mouse clicks will all be received by the maximised window, and it can receive your keyboard input.
Here's a pure Java way to do it to solve the problem you've described (not the KeyListener problem... the quit test early when using robot problem):
Throughout your test, compare the mouse position with one that your test has recently set it to. If it doesn't match, quit the test. Note: the important part of this code is the testPosition method. Here's code that I used recently:
public void testSomething() throws Exception {
try {
// snip
// you can even extract this into a method "clickAndTest" or something
robot.mouseMove(x2, y2);
click();
testPosition(x2, y2);
// snip
} catch (ExitEarlyException e) {
// handle early exit
}
}
private static void click() throws InterruptedException {
r.mousePress(InputEvent.BUTTON1_DOWN_MASK);
Thread.sleep(30 + rand.nextInt(50));
r.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
Thread.sleep(30 + rand.nextInt(50));
}
private static void testPosition(int x2, int y2) throws ExitEarlyException {
Point p = MouseInfo.getPointerInfo().getLocation();
if(p.x != x2 || p.y != y2) throw new ExitEarlyException();
}
I noticed that recently when I run my LibGDX game it takes a good 20 seconds to boot up which is strange because I'm only loading a few resources. I put breakpoints in my main method to pinpoint where the app was getting stuck, and it turns out it's getting stuck when I call this line:
new Lwjgl3Application(new GdxGame(), config);
In the Lwjgl3Application constructor, it is hanging on this method call:
initializeGlfw();
Which looks like this:
static void initializeGlfw() {
if (errorCallback == null) {
Lwjgl3NativesLoader.load();
errorCallback = GLFWErrorCallback.createPrint(System.err);
GLFW.glfwSetErrorCallback(errorCallback);
if (!GLFW.glfwInit()) {
throw new GdxRuntimeException("Unable to initialize GLFW");
}
}
}
In this method it gets stuck on createPrint and GLFW.glfwInit(). The print method looks like this:
public static GLFWErrorCallback createPrint(PrintStream stream) {
return new GLFWErrorCallback() {
private Map<Integer, String> ERROR_CODES = APIUtil.apiClassTokens((field, value) -> 0x10000 < value && value < 0x20000, null, GLFW.class);
#Override
public void invoke(int error, long description) {
String msg = getDescription(description);
stream.printf("[LWJGL] %s error\n", ERROR_CODES.get(error));
stream.println("\tDescription : " + msg);
stream.println("\tStacktrace :");
StackTraceElement[] stack = Thread.currentThread().getStackTrace();
for ( int i = 4; i < stack.length; i++ ) {
stream.print("\t\t");
stream.println(stack[i].toString());
}
}
};
}
All of these methods come from the Lwjgl library. Does anybody know why my app might be getting stuck on these method calls?
I've had the same issue and it seams to be tied to the machine you are on. I made a clean VS15 solution with GLFW and ran it on several different PCs to find that only my desktop had this issue. I also tested the LWJGL binding of GLFW and had the same results.
[EDIT] the wait happens in the glfwInit() call
/* Initialize the library */
if (!glfwInit()) // stuck here
return -1;
/* Create a windowed mode window and its OpenGL context */
window = glfwCreateWindow(1920, 1080, "Hello World", NULL, NULL);
There is one post that I came across an archived post on the openGL forums that mentions an issue similar to this but it's fairly old and might be referring to a slightly different issue.
I can recommend to check that you are excluding your build folder from any antivirus, sometimes they see the generated executables as potential threats and thus might be slow however i dont believe that's your issue.
Sadly the only option that has worked for me was a clean install of windows, though the bug mysteriously stopped manifesting itself when I connected a VR headset and reappeared a couple days later. Hope you have better luck than me and dont have to clean install your OS and if you find a less cumbersome solution be sure to spread the word.
I've got a Java swing program that runs in full screen mode. It's effectively a kiosk program in that I want it to lock out everything else while it's running. This is running on a Windows 8.1 tablet, so of course the tablet is touchscreen, and therefore if you do an "edge swipe" (drag your finger from the right) the charms bar pops up and you can get to the Start screen from there. Is there some way to disable this from happening in Java? (Or is there some third-party solution not involving Java that can work in tandem to achieve the same result?)
You can disable edge gestures while your app is active and full screen by setting the System.EdgeGesture.DisableTouchWhenFullScreen property on the window.
I don't know if Java provides a direct way to set this (probably not), but you should be able to set this from a JNI.
Here's a C++ snippet from the DisableTouchWhenFullScreen docs:
HRESULT SetTouchDisableProperty(HWND hwnd, BOOL fDisableTouch)
{
IPropertyStore* pPropStore;
HRESULT hrReturnValue = SHGetPropertyStoreForWindow(hwnd, IID_PPV_ARGS(&pPropStore));
if (SUCCEEDED(hrReturnValue))
{
PROPVARIANT var;
var.vt = VT_BOOL;
var.boolVal = fDisableTouch ? VARIANT_TRUE : VARIANT_FALSE;
hrReturnValue = pPropStore->SetValue(PKEY_EdgeGesture_DisableTouchWhenFullscreen, var);
pPropStore->Release();
}
return hrReturnValue;
}
What I ended up doing was to write a batch script that kills explorer.exe and then re-spawns it after the app exits, based on this answer on Super User.
The macify Notepad example is the only example of 'macification' I could find, and it's all fine and dandy I guess, apart from the menu which completely screws up my layout.
I'm very, very new at Java so I follow examples like these to the letter, but this menu really has to go.
Is there a way to catch the 'about' stuff without a menu? After all, this about thing on Mac OSes seems to be there even without one. Standard procedure, etc.
I don't have a Mac to test the code, so trial and error is severely limited...
How is this done?
Bit of a necro-post but it's code I use all the time. It's complicated and uses reflection to avoid throwing errors on non-Mac systems, however.
In the initialization of your app or as a static code block:
if (System.getProperty("os.name").contains("Mac")) {
try {
Object app = Class.forName("com.apple.eawt.Application")
.getMethod("getApplication")
.invoke(null);
Object al = Proxy.newProxyInstance(
Class.forName("com.apple.eawt.AboutHandler").getClassLoader(),
new Class[]{Class.forName("com.apple.eawt.AboutHandler")},
new AboutListener()
);
app.getClass()
.getMethod("setAboutHandler", Class.forName("com.apple.eawt.AboutHandler"))
.invoke(app, al);
}
catch (Exception e) {
//fail quietly
}
}
At the bottom of the source file after the last curly brace
public class AboutListener implements InvocationHandler {
public Object invoke(Object proxy, Method method, Object[] args) {
//Show About Dialog
return null;
}
}
When releasing a full application in java things like this make nice small touches. This should be mostly copy-and-paste-able but you will need to add a line or two to display an about box. If you need to test really badly use web-start, dropbox public links, and a neighborhood Apple Store.
How do I capture the mouse in a Java application so that all mouse events (even ones that happen if the mouse is moved outside the app window) are seen by the Java app? This is like the Windows SetCapture function.
You don't; the JVM, or more specifically AWT, only generates input events when Windows sends it input events, and the JVM only registers for those events which occur within it's window.
You might be able to pull it off using JNI, but then again you might not - it will depend if you can get your hands on the information required by the underlying API. Since that's likely to be a window handle, you won't have what you need to invoke the API, even from JNI.
You have to hook the mouse at the operating system level. Windows(Swing, AWT, MFC, etc....) are only aware of mouse movements within their bounds. If you need a way to access the current position of the mouse regardless of where the mouse is on the screen, you need to write an Input Hook: Input Hooks. You can then use JNI or read the STDOUT from a win32 console application designed to use the Input Hook to forward mouse events/positions to your Java code. I use the latter method in some of my user interface test cases with success.
I needed to do that too!
I after searching the web I found that its possible to use the moveMouse in java.awt.Robot.
Basically use Robot to move the mouse into center of your frame. If user moves it: check how much and move it back to center.
No additional packets or JNI are needed for this (my demo uses JOGL and vecmath but that's for the graphics). Is it good enough? Try the demo, its here:
http://www.eit.se/hb/misc/java/examples/FirstPersonJavaProtoGame/
If the above solution is not good enough then perhaps lwjgl is what you need:
http://www.lwjgl.org/javadoc/org/lwjgl/input/Mouse.html
/Henrik Björkman
Just use the system-hook library available on gitHub https://github.com/kristian/system-hook
This only apply to windows-based systems but really simple to implement.
Sample usage
import lc.kra.system.keyboard.GlobalKeyboardHook;
import lc.kra.system.keyboard.event.GlobalKeyAdapter;
import lc.kra.system.keyboard.event.GlobalKeyEvent;
public class GlobalKeyboardExample {
private static boolean run = true;
public static void main(String[] args) {
// might throw a UnsatisfiedLinkError if the native library fails to load or a RuntimeException if hooking fails
GlobalKeyboardHook keyboardHook = new GlobalKeyboardHook();
System.out.println("Global keyboard hook successfully started, press [escape] key to shutdown.");
keyboardHook.addKeyListener(new GlobalKeyAdapter() {
#Override public void keyPressed(GlobalKeyEvent event) {
System.out.println(event);
if(event.getVirtualKeyCode()==GlobalKeyEvent.VK_ESCAPE)
run = false;
}
#Override public void keyReleased(GlobalKeyEvent event) {
System.out.println(event); }
});
try {
while(run) Thread.sleep(128);
} catch(InterruptedException e) { /* nothing to do here */ }
finally { keyboardHook.shutdownHook(); }
}
}