I have a reproducible problem with the Mint Cinnamon desktop locking up when hitting a breakpoint debugging with Eclipse. When I say it's locking up, I mean mouse clicks are completely inoperable (even on the Mint panel), but the mouse cursor still moves. Keyboard is unresponsive, except for some OS-level shortcuts like Alt-Tab. Alt-Tab looks like it's working, but selecting another window doesn't actually focus or activate the window (only the Alt-Tab selector popup works). I can only recover using Ctrl-Alt-ESC to restart Cinnamon. Everything proceeds fine after that.
Debugging and breakpoints work fine everywhere else as far as I can tell except when the breakpoint is inside an anon inner class or lambda.
Public git repo with a fairly simple example project causing this:
https://bitbucket.org/jfxexamples/eclipseminttest
Linux Mint 17.3 AND a totally new install of Mint 18 on a different PC - both behave the same
Eclipse Neon 4.6.0
Java 8 (1.8.0_92) - Oracle JDK (Using JavaFX)
Code below (you'll have to grab the project files to run it though):
package application;
import javafx.application.Application;
import javafx.fxml.FXMLLoader;
import javafx.scene.Scene;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;
public class Main extends Application {
#Override
public void start(Stage primaryStage) {
try {
BorderPane root = (BorderPane)FXMLLoader.load(getClass().getResource("Sample.fxml"));
Scene scene = new Scene(root,400,400);
scene.getStylesheets().add(getClass().getResource("application.css").toExternalForm());
primaryStage.setScene(scene);
primaryStage.show();
} catch(Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
launch(args);
}
}
package application;
import javafx.event.Event;
import javafx.event.EventHandler;
import javafx.fxml.FXML;
import javafx.scene.control.Tab;
import javafx.scene.control.TabPane;
public class SampleController {
#FXML
private TabPane tabPane;
public void createTab() {
Tab tab = new Tab("New tab");//Breakpoint here does NOT freeze desktop
// tab.setOnCloseRequest(e -> {
// System.out.println("bleh");//Breakpoint here, freezes desktop
// });
tab.setOnCloseRequest(new EventHandler<Event>(){
#Override public void handle(Event e){
System.out.println("bleh");//Breakpoint here, also freezes desktop
}
});
tabPane.getTabs().add(tab);//Breakpoint here does NOT freeze desktop
int index = tabPane.getTabs().size() - 1;
tabPane.getSelectionModel().select(index);
}
}
Using Win10/IntellijCE/JDK1.8.0_92 there is no problem. Try using IntellijCE on Mint. If it works the problem is most likely with Cinnamon.
Cinnamon is on Github, so use their Issue Tracker there to report the bug.
Browsing the issues, there is even something maybe related to your issue: Check out https://github.com/linuxmint/Cinnamon/issues/1084.
I have had exactly the same problem in Linux Mint 17.3 Mate, with JDK 1.8.0_101, Eclipse Neon and a JavaFX application.
When debugging the application, the system freezes completely and I have to kill the process manually.
It seems a problem related with the X display. It should work if you set, in the VM arguments of your application, the flag:
-Dsun.awt.disablegrab=true
At least that worked for me...
This is a known problem on Linux. It is related to the XGrabPointer and XGrabKeyboard API calls (see X Pointer Grabbing). This API can be used by screensavers, so it is intended to make the keyboard and mouse unusable (apart from moving the mouse cursor).
During debugging, it is a problem. In the past, a workaround was to configure AllowDeactivateGrabsin xorg. That allowed to break the "grap" by a keyboard shortcut, by default CTRL+ALT+/. Since it was possible to bypass screensavers, it was disabled around 2012 because of its security implications.
On a modern Linux system, you can enable enable grab break actions:
setxkbmap -option grab:break_actions
Now, you can trigger a grab break by executing:
xdotool key XF86Ungrab
Once your keyboard is frozen, you might be not able to run it, so during debugging, I am calling it every two seconds:
while :; do sleep 2 ; xdotool key XF86Ungrab ; done
Notes:
setxkbmap is part of xorg-setxkbmap
xdotool is part of xdotool
While testing the setup, it is useful to have a ssh connection from another machine. Thus, if mouse and keyboard freeze up, you can always kill the process that grabbed the mouse and keyboard.
Related
I'm trying to get a starter project for a template running over for JavaFX, the assignment is to get a hello world program up and running using JavaFX to get the program running.
(Some Background context: We're using IntelliJ for our class assignment, but recently we found out that it seems(?) support for JavaFx has been discontinued within InteliJ, regardless the same assignment remains so we installed a third party library following the steps over from a guide about getting the library, ( How to get JavaFX and Java 11 working in IntelliJ IDEA ), the instructions helped to get the program running and compiled and I used the paths out, but when I ran the program, I got a blank white screen, and I have no clue if this is normal or not.)
The code is just the default JavaFX template from Intllij, I've tried installing the SDKS and JDKS (which seemed to help the program compile), but when running, I just get a blank white screen.
Here is a screenshot of the white screen problem https://i.imgur.com/7ZYju3M.jpg
And the code below; it's just a IntelliJ default startup, but I don't know why it doesn't work.
package sample;
// Original Imports found in testTemplate
import javafx.application.Application;
import javafx.fxml.FXMLLoader;
import javafx.scene.Parent;
import javafx.scene.Scene;
import javafx.stage.Stage;
public class Main extends Application {
#Override
public void start(Stage primaryStage) throws Exception{
Parent root = FXMLLoader.load(getClass().getResource("sample.fxml"));
primaryStage.setTitle("Hello World");
primaryStage.setScene(new Scene(root, 300, 275));
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
package sample;
public class Controller {
}
We expected the results to say hello world. I think so anyways, but I actually have no clue what it's supposed to look like as it's my first time, I think it's supposed to say hello world. (Later on, we're supposed to get the GUI configured, but for right now, I just want to figure out what's going wrong with the program.)
I'm working on a JavaFX project and would like to switch from Oracle JDK 1.8 to OpenJDK 11. So far the transition has been pretty seamless, but there is still one main problem related to touch/mouse input that's causing some trouble.
The JavaFX UI is supposed to run on a touch-enabled device, which used to work straight out of the box with Oracle JDK 1.8. When I touch the screen, the following sequence of mouse events is fired as expected:
MOUSE_PRESSED
MOUSE_RELEASED
MOUSE_CLICKED
After building the same application with OpenJDK11 (using OpenJFX 11 as an external library as JavaFX is no longer part of the JDK by default) I get the follwing sequence of events:
MOUSE_ENTERED_TARGET
MOUSE_ENTERED_TARGET
MOUSE_EXITED_TARGET
MOUSE_EXITED_TARGET
This explains why I can't click any buttons (or controls in general). So far so good. The question is, how do I get my MOUSE_{PRESSED,RELEASED,CLICKED} events back?
SSCE:
package com.example.jfxtouchtest;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.input.MouseEvent;
import javafx.scene.input.TouchEvent;
import javafx.scene.layout.Pane;
import javafx.stage.Stage;
public class JFXTouchTest {
public static void main(String[] args) {
Application.launch(JFXApp.class, args);
}
public static class JFXApp extends Application {
#Override
public void start(Stage primaryStage) {
primaryStage.addEventFilter(TouchEvent.ANY, e -> System.out.println("touch event: " + e.getEventType()));
primaryStage.addEventFilter(MouseEvent.ANY, e -> System.out.println("mouse event: " + e.getEventType()));
primaryStage.setScene(new Scene(new Pane()));
primaryStage.setWidth(800);
primaryStage.setHeight(600);
primaryStage.show();
}
}
}
I think it's worth noting that all fired events are MouseEvents (not TouchEvents), regardless of whether I'm using the touchscreen or not. That in itself is sort of strange in my opinion, but at least I'm getting the desired behaviour with JDK 8...
Some background information:
OS: Ubuntu 18.04.01 LTS
Kernel: 4.15.0-42-generic
Oracle JDK 1.8.0_191
OpenJDK 11.0.1
Touchscreen (as reported by xinput): Atmel maXTouch Digitizer
The touchscreen works just fine with other applications, click events seem to be handled as expected.
The somehwat related VM-arguments
-Dcom.sun.javafx.isEmbedded=true and
-Dcom.sun.javafx.touch=true
both seem to have no effect on the issue
There seems to be a slight difference in the xev output I'm getting depending on whether I'm using the mouse or the touchscreen:
Mouse (state is 0x0 for ButtonPress, 0x100 for ButtonRelease):
ButtonPress event, serial 34, synthetic NO, window 0x3400001,
root 0x193, subw 0x0, time 16982696, (93,90), root:(964,612),
state 0x0, button 1, same_screen YES
ButtonRelease event, serial 34, synthetic NO, window 0x3400001,
root 0x193, subw 0x0, time 16983364, (93,90), root:(964,612),
state 0x100, button 1, same_screen YES
Touchscreen (state is 0x100 in both cases):
ButtonPress event, serial 34, synthetic NO, window 0x3400001,
root 0x193, subw 0x0, time 17599475, (93,145), root:(964,667),
state 0x100, button 1, same_screen YES
ButtonRelease event, serial 34, synthetic NO, window 0x3400001,
root 0x193, subw 0x0, time 17599537, (93,145), root:(964,667),
state 0x100, button 1, same_screen YES
I'm not exactly sure what this means, though.
Any help would be greatly appreciated, even if it's just a confirmation that the issue is reproducible on another machine with another type of touchscreen! Many thanks in advance!
UPDATE: I have managed to get my hands on a different touchscreen in the meantime, and it seems to work fine with that one. What's interesting is that, just like with regular mouse events, xev reports two different states for ButtonPress and ButtonRelease, so maybe the state field being the same for both event types on the other touchscreen has something to do with this after all?
I had the same problem with my touch screen and JFX. My code works fine with Open JDK 1.8 and its corresponding JFX, it fails with OpenJDK 11 and its corresponding JFX. It works fine with the JDK and JFX from Liberica https://bell-sw.com/pages/java-11.0.7-for-Embedded/
So for me my workaround was to change to the Liberica JDK 11 and JFX distribution.
Other options may be JDK, JFX distributions from Azul or Corretto.
Force JavaFX to use gtk-2 by using the java parameter -Djdk.gtk.version=2. The touchscreen works with that setting although this causes other problems with our application (possibly related to 3rd party libraries).
I recently asked a similar question about this for OSX and found a solution using the com.sun.glass package. However, this solution does not seem to work on X11-based desktop environments.
The issue:
I am trying to write a borderless window overlay that can be placed above ALL other desktop components, including the dock and menubar of any given Linux desktop environment which uses x11. Currently, when I use AlwaysOnTop(true) with my JavaFX window, the window is placed above all other windows but is NOT placed above the window managers UI (taskbar) due to it having a higher window level. The screenshot below shows what happens when using AlwaysOnTop: the entirety of the vertical white window should be placed above the taskbar but is instead forced below it. See screenshot:
There is a solution for this issue with Qt through using the x11bypasswindowmanager window flag, so I figured it must be possible through Java!
The only current solution I have is to use wmctrl directly through the commandline using a subprocess. This is not really suitable, as a lot of linux systems to not come with wmctrl installed.
Below is the code snippet I am using to generate the window in the above screenshot:
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
import javafx.stage.StageStyle;
public class Main extends Application {
public static void main(String[] args) {
launch(args);
}
#Override
public void start(Stage primaryStage) {
primaryStage.setTitle("Hello World!");
StackPane root = new StackPane();
primaryStage.setScene(new Scene(root, 200, 3000));
primaryStage.setAlwaysOnTop(true);
primaryStage.initStyle(StageStyle.UNDECORATED);
primaryStage.setX(800);
primaryStage.setY(0);
primaryStage.show();
}
}
I am writing a Java application for image analysis which at one point opens ImageJ with
ImageJ ij = new ImageJ();
and also opens a Windows containing an ImagePlus.
Now, whenever one closes ImageJ first, the ImagePlus will not close when pushing the close button. The other way around works, however in both cases an exception is thrown after closing ImageJ:
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1288)
at java.awt.Window.doDispose(Window.java:1209)
at java.awt.Window.dispose(Window.java:1147)
at ij.ImageJ.run(ImageJ.java:784)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: null source
at java.util.EventObject.<init>(EventObject.java:56)
at java.awt.AWTEvent.<init>(AWTEvent.java:337)
at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:285)
at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:174)
at sun.awt.X11.XBaseMenuWindow.dispose(XBaseMenuWindow.java:907)
...
I don't know whether it is related as it happens in both cases.
Any suggestions on how to force ImageJ to close all its windows?
The exception
This happens when using OpenJDK 7 on Linux. The exception is fixed in Java 8.
Also: note that that exception is not the actual cause of the quitting issue you are seeing.
The disposal problem
ImageJ 1.x's application disposal is a convoluted mess. (See this news post for some technical discussion.) It was really intended primarily to run as a standalone application, and is mostly tested with the exitWhenQuitting flag set to true such that the JVM shuts down upon closure of the main window. So it is not surprising that using ImageJ in a different fashion results in hanging image windows.
I have tested various workarounds—e.g.:
ij.addWindowListener(new WindowAdapter() {
#Override
public void windowClosing(final WindowEvent e) {
// dispose all image windows
for (final int id : WindowManager.getIDList()) {
final ImagePlus imp = WindowManager.getImage(id);
if (imp == null) continue;
final ImageWindow win = imp.getWindow();
if (win != null) win.dispose();
}
// dispose all other ImageJ windows
for (final Window w : WindowManager.getAllNonImageWindows()) {
w.dispose();
}
}
});
But none of them work as one might hope. It cost me weeks of development and experimentation to make quitting work as we wanted in ImageJ2, according to the news posted linked above.
Here is some code using ImageJ2 that almost behaves the way you want:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.WindowConstants;
import net.imagej.ImageJ;
public class IJDispose {
public static void main(final String... args) {
final ImageJ ij = new ImageJ();
ij.ui().showUI();
final JFrame frame = new JFrame("Hello");
final JButton b = new JButton("Close ImageJ");
b.addActionListener(new ActionListener() {
#Override
public void actionPerformed(final ActionEvent e) {
ij.getContext().dispose();
}
});
frame.getContentPane().add(b);
frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
frame.pack();
frame.setVisible(true);
}
}
After launching it, press Shift+B to open the Blobs sample image. Then click the "Close ImageJ" button from the non-ImageJ frame. You'll see that the ImageJ main window and the image window dispose as desired (using this code from ImageJ Legacy).
However, there are (at least) three problems:
This example does not hook up the ij.getContext().dispose() call to the actual ImageJ1 UI window closing event. And doing that would not be trivial (I say without having dug deeply in this code recently).
After disposing ImageJ, as well as the extra JFrame, the JVM is supposed to shut down. We put a lot of effort into making it do so, actually. But it actually doesn't with the current version of ImageJ, presumably due to some undisposed resource(s) somewhere. This is a bug.
Clicking the X on the main ImageJ window shuts down the entire JVM, because ImageJ1's exitWhenQuitting flag gets set to true. You could toggle it back to false yourself, but this is actually tricky due to class loading issues relating to the fact that ImageJ2 patches ImageJ1 at runtime using Javassist.
The next question is: How badly do you really need this to work?
Whenever I create a project in Eclipse and include javafx, the application does not load when I click the run button.
e.g.
package test;
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
public class test extends Application {
public static void main(String[] args) {
launch(args);
}
#Override
public void start(Stage primaryStage) {
primaryStage.setTitle("Hello World!");
Button btn = new Button();
btn.setText("Say 'Hello World'");
btn.setOnAction(new EventHandler<ActionEvent>() {
#Override
public void handle(ActionEvent event) {
System.out.println("Hello World!");
}
});
StackPane root = new StackPane();
root.getChildren().add(btn);
primaryStage.setScene(new Scene(root, 300, 250));
primaryStage.show();
}
}
This should run a simple hello world application, taken from the oracle documentation. However when I 'run' this code, no windows open. Instead an application called 'java' opens. It appears 'java' is simply a 'unix executable file' located in 'jdk1.8.0_25.jdk/contents/home/bin'. The application 'java' displays absolutely nothing, and cannot be shut down without force quitting.
I'm running eclipse on a Macbook. I've probably left out some important details...
Does anyone know why my application is not running as it should? Forgive my naivety, I'm new to java and eclipse.
Many Thanks
EDIT:
import javafx.application.Application;
import javafx.stage.Stage;
public class JavaFX extends Application {
public static void main(String[] args){
launch(args);
}
#Override
public void start(Stage stage) throws Exception {
// TODO Auto-generated method stub
stage.show();
}
}
This simple program also gives the same error.
So I know this is an old question, but I ran into what I believe to be the same issue recently and wanted to share the solution I found (although I have no insight as to why it works).
pictured
Go to Run Configurations for the main class, and on the "Arguments" tab, uncheck the box where it says "Use the -XstartOnFirstThread argument when launching with SWT".
To add a visual example of the problem so that someone more knowledgable than I can possibly explain why this happens/why this solution works:
This is what you get when you try to run the program. An application simply called "java" appears to be running, but nothing is showing.
I hope this information is able to help someone.
possible solution install this from the eclipse marketplace https://www.eclipse.org/efxclipse/install.html
I've had the same problem when I was trying to run JavaFX main class in an existing SWT project with maven dependency:
<dependency>
<groupId>org.eclipse.swt</groupId>
<artifactId>org.eclipse.swt.cocoa.macosx.x86_64</artifactId>
<version>4.3</version>
</dependency>
When I comment out this dependency, application window was shown and everything worked well.
Just to let you know, I created a new project in Eclipse for Java and copy / pasted your code into it. Then just simply clicked on the run icon. It worked perfectly. I'm going to attach screen grabs of my setup for you.
if the pane is not showing up go to run configuration by clicking little arrow by run button and go to argument tab and uncheck the -use the -xstartonfirstthtread box then run again.