lwjgl import Input Classes is not working - java

I have a Problem with Java and lwjgl the Import:
import org.lwjgl.input.Keyboard;
won't work. I have added the jars:
lwjgl-glfw.jar
lwjgl-opengl.jar
lwjgl-stb.jar
lwjgl.jar
joml

You are using LWJGL 3 right? LWJGL 3 doesn't have a Keyboard or Mouse class, you have to use the functions provided by GLFW. http://www.glfw.org/docs/latest/input_guide.html

As Wendelin said, if you're using LWJGL 3, the import you try to use, is there no longer. In LWJGL 3, you set callbacks. A callback, is a function/method that you create, and LWJGL executes. If for example, you set a close callback, your function/method is called when LWJGL has detected that the user wants to quit.
I can show you two examples of this: closing and iconifying.
import static org.lwjgl.glfw.GLFW.glfwSetWindowCloseCallback;
import static org.lwjgl.glfw.GLFW.glfwSetWindowIconifyCallback;
public class Program {
public static void main(String[] arguments) {
glfwSetWindowCloseCallback(display, (NULL) -> {
System.out.prinln("User tried to quit")
});
glfwSetWindowIconifyCallback(display, (window, iconified) -> {
System.out.println("User tried to iconify the window")
});
}
}
The first argument to the callback function setter, display, is the display the callback will be set on. You should check out the link Wendelin provided, for more information.
If you are using LWJGL 2, or the imports aren't working in LWJGL 3, you've probably not attached the framework to your project correctly. If this is the case, you'll simply have to fix that problem. If you're in IntelliJ IDEA (MacOS), you can go to File -> Project Structure -> Project Settings -> Libraries, and click on + to add a new framework to your project.

Related

Linux Mint Cinnamon Lock-Up Debugging w/Eclipse

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.

Eclipse Java Error: Cannot find or load main class

I am using Eclipse Luna and i am trying to run a simple text program but Eclipse gives the error:
Error: Could not find or load main class Main
I have no idea what's going on. I haven't found anything useful on Stack Overflow or Google. Here is my code:
public class Main {
public static void main(String[] args) {
System.out.println("This is a String");
}
}
Thank you.
Your code looking fine !
Do following steps to run your class
Select your project, go to Project section in menu bar then click clean.
In tool section click on enter code here Build Automatically.
Select your class right click on it and then select run.
In the menu Run, select Run Configurations....
In the dialog box that opens, on the left side, you are supposed to have an entry Java Application, and under it, there should be your class (and maybe other classes you worked on before). It may be named Main or Main__ here.
Select it. If it was erroneously named Main__, change that to Main in the Name: field.
Now look at the entry for Main Class. In the text field, it should say Main. If it says Main__ or anything else, change that to Main.
Apply and Run.

Stanford CS106a newbie - Having trouble compiling in Eclipse

I'm following along with Stanford's CS106a class and trying to do the assigments. I had difficulty running the sample code from the book but somehow managed to run them with the ACM package. Right now I'm trying to do the assignments and run my own code. I've created a "project" and a .java file in that project. I don't know how to run it though. I keep getting the following:
Error: Could not find or load main class Pyramid.
I think it is because the program isn't accessing the ACM package. Below is the code although I think it would happen with any code I write. Any help would be appreciated.
Thanks so much.
import acm.graphics.*;
import acm.program.*;
import java.awt.*;
public class GRectExample extends GraphicsProgram {
public void run() {
GRect rect = new GRect(100, 50, 125, 60);
rect.setFilled(true);
rect.setColor(Color.RED);
add(rect);
}
}
Create a main method inside GRectExample class, for examle
import acm.graphics.*;
import acm.program.*;
import java.awt.*;
public class GRectExample extends GraphicsProgram {
public void run() {
GRect rect = new GRect(100, 50, 125, 60);
rect.setFilled(true);
rect.setColor(Color.RED);
add(rect);
}
public static void main(String args[])
{
new GRectExample().run();
}
}
Looks like you have to tell Eclipse where to locate the ACM package, most of the times it can't assume the exact location.
Right click on your project folder and select Properties.
Select the Java Build Path option and click on the "Add External JARs" and that will include it into your project...
Not too familiar with Eclipse, but here's a suggestion:
Right - Click on the Project folder
click Properties at the bottom
click Run/Debug Settings
Make sure your Launching class is the list. Click on it, make sure it's the Main class
Make sure you use the fully qualified name i.e. mypackage.MyClass
Also try clicking all of them in the list. And make sure only the one you want to be the launching class has the Main Class field filled in.

In an Imagej plugin, how to make a ROI available or active as a Selection

I have written a java plugin for ImageJ that does create a polygon then does a setRoi() call then an updateandDraw() call, all that to make the ROI polygon available to many ImageJ menu commands like BLUR etc for further action.......the plugin works well and does create the polygon in a window, but the ROI created does not seem to be active as no ImageJ standard menu command can operate on it, in other words its is not yet a "Selection" on which any menu commands can act upon. I dont know if it is a matter of making the ROI "active" or if a "Selection" is fundamentally different from a "ROI" or if this can only be accomplished in a script or macro etc.....Thanks for your help and regards.
In ImageJ 1.x, selection and ROI are equivalent terms. After running the following Java plugin:
import ij.IJ;
import ij.ImagePlus;
import ij.gui.PolygonRoi;
import ij.gui.Roi;
import ij.plugin.PlugIn;
public class My_Plugin implements PlugIn {
public void run(String arg) {
ImagePlus imp = IJ.getImage();
int[] xpoints = {10,100,100,10};
int[] ypoints = {10,100,10,100};
imp.setRoi(new PolygonRoi(xpoints,ypoints,4,Roi.POLYGON));
}
}
a command like Process > Filters > Gaussian Blur... works as expected, i.e. only the region within the selected polygon will be blurred.

Eclipse RCP IPageLayout woes

I have an Eclipse RCP application with a sort of three column layout:
The editor area is at the extreme right. Now, when you get an IPageLayout to work with, the editor area is already added in. That's fine: we add area B to the left of the editor, and area A to the left of B, and the layout is exactly what we need.
The issue is that when you move the sash between A and B, views A and B change without resizing the editor area (good;) but when you move the other sash between B and the editor area, all three views are resized; the layout manager acts to maintain the ratio of the widths of A and B, and that's not what we want. We want the user to be able to move each sash independently, and have it influence only the two views it touches.
It seems like the root cause of this is that the editor is in place when you get your IPageView, and therefore you have to position the IFolderLayouts relative to it. If you could position the editor relative to B, instead, then resize would do the right thing.
So my questions:
Is there any way to tell the IPageView to position the editor relative to a view, instead of the other way around?
Barring that, is there any other way to influence the layout algorithm, like writing some kind of layout manager?
I know of no way to alter the layout tree of IPageLayout in Eclipse 3.x. In Eclipse 4.2, however, the Application Model can be changed dynamically at runtime.
So, if you would consider migrating your application to Eclipse 4, this solution could be an option. To keep the original application and UI code as untouched as possible, this solution will
take full advantage of the compatibility layer of Eclipse 4 to create an Application Model from the Eclipse 3 based RCP application. There is no need to create an Application Model or alter the UI code of the application.
rearrange the editor area's layout after the application is active. This is done by creating an addon class in a separate plugin.
allow easy migration to more Eclipse 4 functionality in the future: Should you decide to build an own Application Model, you can just unhook the addon plugin.
I started with the regular RCP Mail template of Eclipse 3 and altered the perspective to recreate the problem. This is the Perspective class I used in my test application:
import org.eclipse.ui.IPageLayout;
import org.eclipse.ui.IPerspectiveFactory;
public class Perspective implements IPerspectiveFactory {
public static final String ID = "wag.perspective";
public void createInitialLayout(IPageLayout layout) {
String editorArea = layout.getEditorArea();
layout.setEditorAreaVisible(true);
layout.addStandaloneView(AView.ID, false, IPageLayout.LEFT,
0.25f, editorArea);
layout.addStandaloneView(BView.ID, false, IPageLayout.LEFT,
0.25f, editorArea);
layout.getViewLayout(AView.ID).setCloseable(false);
layout.getViewLayout(BView.ID).setCloseable(false);
}
}
It basically creates the scenario you described: a three column layout where one sash effects all three parts and the other one only two.
I then proceeded to migrate the application and alter the Application Model.
Migrate the Eclipse 3 based RCP application to Eclipse 4
There are online tutorials available for this process. I found Eclipse 4.1: Run your 3.x RCP in 4.1 and Eclipse 4 and the Compatibility Layer - Tutorial to be very helpful.
I recommend including the org.eclipse.e4.tools.emf.liveeditor and its required plug-ins in your product dependencies. With the live editor, you can take a look at the Application Model that is created by the compatibility layer.
Once the application starts, thet sashes will still behave the same way. Open the live editor on your application window and take a look at your model.
You can see that the PartSashContainer including the placeholder for the AView contains another PartSashContainer. Moving the sash between AView and that container will update the rest of the layout tree, while moving the sash between BView and the editor does not effect other parts of the layout.
You could now drag the placeholder for the AView to the container where the BView and the editor are located. This would instantly create the effect you desire: The sashes will only affect their direct neighbours. But these changes will only be saved in one's own runtime workspace. Something else is needed to alter the layout structure automatically.
Altering the Application Model at runtime
Since I didn't want to touch the original code if possible, I created another plugin to make a contribution to the Application Model.
Create a Plug-In Project without an Activator without using a template.
Add an Addon class: select New->Other->Eclipse 4->Classes->New Addon Class
Add a Model Fragment: select New->Other-Eclipse 4->Model->New Model Fragment. Open the created fragment.e4xmi file and add a Model Fragment. For the Element Id, put org.eclipse.e4.legacy.ide.application (this is the standard id of legacy applications) and for the Featurename addons. Add an Addon to the Model Fragment. Enter an ID and set the Class URI to your addon class.
Now add your fragment.e4xmi to your org.eclipse.e4.workbench.model extension point:
<extension
id="id1"
point="org.eclipse.e4.workbench.model">
<fragment
uri="fragment.e4xmi">
</fragment>
</extension>
Add your contribution plugin to the dependencies of your application product. When you start your application and look at the model with the live editor, you should see your Addon listed in the model.
Now we can implement the Addon. This is the code of my Addon class:
package wag.contribution.addons;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.inject.Inject;
import org.eclipse.e4.core.services.events.IEventBroker;
import org.eclipse.e4.ui.model.application.MApplication;
import org.eclipse.e4.ui.model.application.ui.MElementContainer;
import org.eclipse.e4.ui.model.application.ui.MUIElement;
import org.eclipse.e4.ui.model.application.ui.advanced.MPlaceholder;
import org.eclipse.e4.ui.workbench.modeling.EModelService;
import org.osgi.service.event.Event;
import org.osgi.service.event.EventHandler;
public class LayoutSorter {
#Inject private IEventBroker broker;
private EventHandler handler;
// The part IDs we are interested in, sorted in the sequence they should be
// shown
private static List<String> PART_IDS = Arrays.asList(new String[] {
"wag.aView", "wag.bView", "org.eclipse.ui.editorss" });
// Listen to the e4 core service's event broker to find the magical time
// when the application is created and try to sort the layout.
#PostConstruct
void hookListeners(final MApplication application,
final EModelService service) {
if (handler == null) {
handler = new EventHandler() {
// Try to sort the layout. Unsubscribe from event broker if
// successful.
#Override
public void handleEvent(Event event) {
try {
sort(application, service);
// sort did finish: stop listening to the broker.
broker.unsubscribe(handler);
} catch (Exception e) {
// Something went wrong, the application model was not ready yet.
// Keep on listening.
}
}
};
// Subscribe "ServiceEvent.MODIFIED" to grab the application.STARTED
// event. Does anybody know how to do this in a better way?
broker.subscribe("org/osgi/framework/ServiceEvent/MODIFIED",
handler);
}
}
private void sort(MApplication application, EModelService service) {
// find all placeholders
List<MPlaceholder> placeholders = service.findElements(application,
null, MPlaceholder.class, null);
// only keep the ones we are interested in
for (int i = placeholders.size() - 1; i > -1; i--) {
if (!PART_IDS.contains(placeholders.get(i).getElementId())) {
placeholders.remove(i);
}
}
// find the parents of the placeholders
List<MElementContainer<MUIElement>> parents = new ArrayList<>(
placeholders.size());
for (MPlaceholder placeholder : placeholders) {
parents.add(placeholder.getParent());
}
// find the parent that is "deepest down" in the tree
MElementContainer<MUIElement> targetParent = null;
for (MElementContainer<MUIElement> parent : parents) {
for (MUIElement child : parent.getChildren()) {
if (parents.contains(child)) {
continue;
}
targetParent = parent;
}
}
// move all parts to the target parent
if (targetParent != null) {
for (int i = 0; i < placeholders.size(); i++) {
if (targetParent != placeholders.get(i).getParent()) {
service.move(placeholders.get(i), targetParent, i);
}
}
}
}
#PreDestroy
void unhookListeners() {
if (handler != null) {
// in case it wasn't unhooked earlier
broker.unsubscribe(handler);
}
}
}
(Please note that the code above is a bit of a hack because it is only really suited for this specific problem.)
After a restart, the application should now behave in the desired way. Take a look at the Application Model to see your changes.
One thing to be aware of is that local changes are saved in the runtime workspace in the file .metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi if saving is switched on, so for recreating the unaltered model for testing this file has to be deleted.
I don't think, it's possible to achieve exactly what you want (so the answers to your questions would be 1. no, 2. no). But there it a 3rd alternative, which IMO behaves quite nicely.
When trying in Eclipse: Start with viewA on left and Editor on right. Then when you drag viewB to the right side of viewA, you get the (wrong) setup you describe. But then you drag it to the left part of the Editor, then you get different configuration, where dragging right sash behaves as you want. Dragging of left sash resizes viewA and Editor and MOVES viewB.
I would say that the code to achieve this would be:
IFolderLayout areaA = layout.createFolder("A", IPageLayout.LEFT, 0.33f, editorArea);
IFolderLayout areaB = layout.createFolder("B", IPageLayout.LEFT, 0.5f, editorArea);

Categories