I'm having some issues getting my Java JFrame to be fullscreen on all OS (Windows, Mac, Linux). It seems whatever solution I find it does run on one OS but not on others or has some other serious bugs. I wanted to use the setFullScreenWindow(window w) method to properly initiate a fullscreen because setExtendedState(...) won't work on Mac/Linux as the menubar and taskbar are still visible.
The setFullScreenWindow(...) method worked fine on all environments until Java 7 came along and now there seems to be an issue that as soon as you enter fullscreen mode the application no longer responds to key events on Mac OS X. The application works just fine on Windows.
Does anyone have a clue how I could possibly work around this issue?
Note:
The workaround described here (FullScreen Swing Components Fail to Receive Keyboard Input on Java 7 on Mac OS X Mountain Lion) does not work for Windows because it will result in the JFrame flickering and not opening properly.
The fullscreen approach described here is the same used below which does not work because of problems with the key input: (How to make a JFrame really fullscreen?)
Example Code:
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.event.ActionEvent;
import java.awt.event.KeyEvent;
import javax.swing.AbstractAction;
import javax.swing.Action;
import javax.swing.JComponent;
import javax.swing.JFrame;
import javax.swing.KeyStroke;
public class FullScreenKeyTest extends JFrame {
public void createFrame() {
initKey();
GraphicsDevice gd = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
this.setUndecorated(true);
this.setVisible(true);
gd.setFullScreenWindow(this);
}
private void initKey() {
Action keyAction = new AbstractAction() {
public void actionPerformed(ActionEvent e) {
System.out.println("Escape key pressed");
setVisible(false);
System.exit(0);
}
};
this.getRootPane().getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW).put(KeyStroke.getKeyStroke(KeyEvent.VK_ESCAPE, 0), "keyPress");
this.getRootPane().getActionMap().put("keyPress", keyAction);
}
public static void main(String[] args) {
FullScreenKeyTest testFrame = new FullScreenKeyTest();
testFrame.createFrame();
}
}
This is a bit flaky as I can get it to work and break it at the same time.
With your example code, I added
getContentPane().setFocusable(true);
getContentPane().requestFocus();
To the end of the createFrame method, and instead of registering the action against the root pane, I registered against the content pane
I found that keyboard inputs work if you use the native OS X Lion fullscreen API. See solution to the question Fullscreen feature for Java Apps on OSX Lion.
Related
I am currently trying to port code from C# to java. In the C# code, the panel.handle part returns an intptr of the current panel. The intptr is then passed to a DLL method. The C# code is the following:
IntPtr Handle = Panel1.Handle;
The same DLL must be used. I have found something using Win32 and JNI but I have not understood how to use it. Does anyone know the java swing equivalent to this method?
Thanks to the link in the comment and some other research I have managed to find the equivalent to the Handle property in c#. Here is what I have done to anyone who is facing the same problem:
import javax.swing.*;
import com.sun.jna.Native;
import com.sun.jna.Pointer;
import com.sun.jna.platform.win32.WinDef.HWND;
public class main {
public static void main(String[] args) {
JFrame jFrame = new JFrame();
final HWND hwnd = new HWND(Native.getComponentPointer(jFrame));
System.out.println(hwnd);
}
}
Please Note that this only works with windows machines since only windows have the concept of everything is a window and every window has a handle.
I'm just now getting into GUI's in Java and when experimenting with JFrame I get the following error:
java[3126:71534] Can't open input server /Library/InputManagers/Inquisitor
Despite the error the program runs fine, but I'd like to know what this is about as I couldn't find much about Inquisitor anywhere.
Running Netbeans 8.0.2 and Java 8 Update 40 on OS X Yosemite (10.10.2). The java code being run is:
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class Ikkuna extends JFrame implements ActionListener{
JTextField syöte;
JLabel vastaus;
JButton painike;
public void setTitle(String string){
super.setTitle(string);
}
public Ikkuna(){
setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
setTitle("Celsius / Fahrenheit -muunnos");
this.setSize(400, 200);
this.setResizable(false);
JPanel paneeli = (JPanel) getContentPane();
syöte = new JTextField(10);
vastaus = new JLabel("tuntematon");
painike = new JButton("Laske");
painike.addActionListener(this);
syöte.addActionListener(this);
paneeli.setLayout(new FlowLayout(FlowLayout.LEFT, 10,10));
paneeli.add(syöte);
paneeli.add(vastaus);
paneeli.add(painike);
setVisible(true);
}
public void actionPerformed(ActionEvent e){
vastaus.setText("" + ((Integer.parseInt(syöte.getText())*1.8+32)));
}
public static void main(String[] args){
Ikkuna i = new Ikkuna();
}
}
TLDR: Don't worry about it, it has nothing to do with your code, although you're probably better of removing Inquisitor extension as there's a good chance that it's not working properly.
InputManagers are intended to be Keyboard/Mouse extensions for applications. The idea is that the code is loaded into applications and can change their behavior in relation to Mouse/Keyboard input, but are generally used as a mechanism for extending applications. They became more restricted in 10.5, where they had to be in the system supported location only (/Library/InputManagers), and stopped being loaded entirely on 64bit mode.
Java 8 is a 64bit only application, so if you're seeing this error, then it's probably because the extension is not being loaded because it's a 64bit application and the system doesn't load extensions in this case.
The extension Inquisitor doesn't look to have been updated in a long time, and was used to extend the functionality of Safari, adding auto-complete to the search bar. The default search functionality of Safari now includes auto-complete, so I would consider it obsoleted.
If you want extended functionality for Safari, there are other plugins which extend the behaviour, such as Glims (I used to use it, but stopped because I felt it destabilized safari more than usual).
Opening the /Library/InputManagers folder (open a Finder window, hit Command-G to get a location field and type in the directory, then hit enter) will allow you to see what input managers are present on the system.
I'm trying to code my first JFrame for a simple app.
The problem is that as soon as I uncomment the
setVisible(true);
I obtain the following error message:
Cocoa AWT: Running on AppKit thread 0 when not expected.
Config:
Running eclipse on a mac OS 10.10 (Yosemite) and Java is up to date.
Here is the code:
package gui;
import java.awt.BorderLayout;
import javax.swing.JFrame;
import javax.swing.JLabel;
public class MainFrame extends JFrame {
private JLabel appTitle;
public MainFrame(){
super("Tabum by Team Alpha");
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setSize(200,500);
setLayout(new BorderLayout());
setVisible(true);
}
}
I've never used your tools, but I guessing that the problem is that all GUI code should execute on the Event Dispatch Thread (EDT) and your code is not doing this.
You do this by wrapping your code in a SwingUtilities.invokeLater(...):
EventQueue.invokeLater(new Runnable()
{
public void run()
{
// add your code here
}
});
Read the section from the Swing tutorial on Concurrency for more information.
I couldn't get the solution working with Eclipse on my Mac.
However, when I loaded the exact same solution in IntelliJ IDEA, it worked!
I would classify this as a Eclipse bug.
For reference:
I'm using the current JDK 1.8.0_31
I was using Eclipse Kepler Service Release 2 (20140224-0627)
I'm on a Mac OS X Yosemite
Please let me know if it helps you or if you have a better solution.
so I'm starting to learn Java Swing, following a YouTube video.. installed Java 8 and NetBeans 8.0 in Linux Ubuntu 14.04. Made a new Java application, and wrote the following code:
package basicswing;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JButton;
public class BasicSwing extends JFrame {
JPanel p = new JPanel();
JButton b = new JButton("Hello");
public static void main(String[] args) {
new BasicSwing();
}
public BasicSwing() {
super("Basic Swing App");
setSize(400,300);
setResizable(true);
setDefaultCloseOperation(EXIT_ON_CLOSE);
p.add(b);
add(p);
setVisible(true);
}
}
When I clean, build, and then run the project, it shows that a Java project is running, but I don't see the Frame, it doesn't pop up.. I don't actually think it's a code issue, I've tried it with different code, and the frame still doesn't show. I can't figure out if it's a NetBeans issue or a Java issue.. or maybe something else?
It is an environment (NetBeans maybe?) issue. Try running from command line:
$ javac BasicSwing.java
$ java BasicSwing
The code is correct and displays the frame.
After being convinced ("schooled") that Swing apps on Mac do look native, I'm trying to make mine look as native as possible. Everything looks great, but when I hit command+Q or do it from the menu, my windowStateChanged(WindowEvent e) is not firing on my main JFrame (if I exit in any other way, it does fire). How can I respond to the real Apple quit?
You can implement com.apple.eawt.ApplicationListener and respond to the Quit event. An example may be found in the Mac OS X Reference Library example, OSXAdapter.
Addendum: See Java for Mac OS X 10.6 Update 3 and 10.5 Update 8 Release Notes for information on deprecation, the redesigned com.apple.eawt.Application class, and the location of API documentation for the Apple Java extensions. Control-click or right-click on the .jdk file to Show Package Contents. You can browse the classes of com.apple.eawt among the OpenJDK sources.
As shown in this complete example, you can specify the desired
QuitStrategy; a WindowListener will respond to ⌘Q:
Application.getApplication().setQuitStrategy(QuitStrategy.CLOSE_ALL_WINDOWS);
As noted here, you can set the property from the command line
java -Dapple.eawt.quitStrategy=CLOSE_ALL_WINDOWS -cp build/classes gui.QuitStrategyTest
or early in the program, before posting any GUI events:
System.setProperty("apple.eawt.quitStrategy", "CLOSE_ALL_WINDOWS");
EventQueue.invokeLater(new QuitStrategyTest()::display);
Console, after ⌘Q:
java.vendor: Oracle Corporation
java.version: 1.8.0_60
os.name: Mac OS X
os.version: 10.11
apple.eawt.quitStrategy: CLOSE_ALL_WINDOWS
java.awt.event.WindowEvent[WINDOW_CLOSING,opposite=null,oldState=0,newState=0] on frame0
Code:
package gui;
import java.awt.EventQueue;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JFrame;
import javax.swing.JTextArea;
/**
* #see https://stackoverflow.com/a/7457102/230513
*/
public class QuitStrategyTest {
private void display() {
JFrame f = new JFrame("QuitStrategyTest");
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
f.addWindowListener(new WindowAdapter() {
#Override
public void windowClosing(WindowEvent e) {
System.out.println(e);
}
});
f.add(new JTextArea(getInfo()));
f.pack();
f.setLocationRelativeTo(null);
f.setVisible(true);
}
private String getInfo() {
String[] props = {
"java.vendor",
"java.version",
"os.name",
"os.version",
"apple.eawt.quitStrategy"
};
StringBuilder sb = new StringBuilder();
for (String prop : props) {
sb.append(prop);
sb.append(": ");
sb.append(System.getProperty(prop));
sb.append(System.getProperty("line.separator"));
}
System.out.print(sb);
return sb.toString();
}
public static void main(String[] args) {
System.setProperty("apple.eawt.quitStrategy", "CLOSE_ALL_WINDOWS");
EventQueue.invokeLater(new QuitStrategyTest()::display);
}
}
The top voted answer is excellent but just to fill in the "best way":
System.setProperty("apple.eawt.quitStrategy", "CLOSE_ALL_WINDOWS");
This will trigger the standard window closing callback event which should work really nicely for portable code.
As a result of the discussion below it seems that its crucial to do this really early in the app. I wrote this early in the static initializer of the main class before any UI code was executed.
This is a pretty good question, and I must admit I don't have the answer. However, a couple years ago when I was working on a Java app and faced this problem, I solved it by registering a shutdown hook with the runtime that would do what I wanted the app to do before quitting. It's a heavy-handed solution but it worked. You can take a look at my code and see if it helps.
I was originally seeing a 'access restriction' violation when trying to access the com.apple.eawt.Application and com.apple.eawt.* subclasses.
(Note: I'm programming on a MAC, using Eclipse, with Java 1.6 using Swing)
So I needed to modify my java build path to allow access to the apple subclasses by adding "com/apple/eawt/**" access rule. After that this code below was able to compile and work for me:
//NOTE: This code only works for MAC OS. If you run this on Windows
//the application never starts (so you literally need to remove this block of code)
import com.apple.eawt.*;
import com.apple.eawt.QuitHandler;
Application a = Application.getApplication();
a.setQuitHandler(new QuitHandler() {
#Override
public void handleQuitRequestWith(com.apple.eawt.AppEvent.QuitEvent qe, com.apple.eawt.QuitResponse qr) {
// TODO Auto-generated method stub
int res = JOptionPane.showConfirmDialog(frame, "Are you sure you want to exit the program?", "Quit ?", JOptionPane.YES_NO_OPTION, JOptionPane.QUESTION_MESSAGE);
if (res == JOptionPane.YES_OPTION)
qr.performQuit();
else
qr.cancelQuit();
}
});
Have you tried setting up command-Q as an accelerator in your menu? Can you make your app respond to it?
I'm not positive, but I think this works in Linux and probably Windows with the equivalent Alt-F4. My app responds to the "killing" keystroke, I process some cleanup code and then I do a programmatic System.exit().
If you're "just" after graceful exit handling, you may also want to catch the WindowEvent WINDOW_CLOSING, where traditionally "are you sure?" stuff gets done.
Looking at the link to Java for Mac OS X 10.6 Update 3 and 10.5 Update 8 Release Notes I noticed that there is a section on Default Quit Action. This describes a system property to request that all windows are closed in response to the "Quit" menu item, which sounds like exactly what is needed? I have used this in my own application (using Info.plist to set the property on OS X only), and it seems to work as described. This would presumably only work on recent Java/OS X versions, but for those platforms seems like a neat solution, and doesn't require any code changes.