I have a Java app whose windows and internal components have animations that could slow down a less powerful computer. I know that all OSs have some form of animation preferences (In Windows, there are check boxes for "Animate controls and elements inside windows", in Linux, there are selections for Full, Basic, or No animations, and in OSX you can do things like enter "defaults write com.apple.dock workspaces-edge-delay -float 0.0; killall Dock" or "defaults write NSGlobalDomain NSAutomaticWindowAnimationsEnabled -bool NO" into the terminal). Is there any way to find out whether the user has animations enabled or disabled, so that I can conform to er preferences?
I would think, that since Java is Operating System agnostic, that there is no specific API, native or third-party, to do this (although there could be). You could use a combination of JNI and/or executing external commands and then interpret their outputs to determine if animations are enabled. To do this you would have to query the os.name system property and run the specific commands for that OS. I think this would be a fair bit of pain and you may just want to give the users an option to disable the animations.
Personally, I would prefer the option because I might turn of the OS animations because they are annoying but still may enjoy the animations in your application.
Related
I have recently found out that anything Swing(NetBeans, IDEA) is excruciatingly slow to paint the UI over Remote Desktop(RDP).
Can you guys give me any suggestion for something that will work properly over RDP?
Actually, contrary to everything I've seen - mostly the "Dsun.java2d.noddraw=true", which is mentioned in a number of places, it is actually setting it to false that fixed the drawing issues(for me at least). Go figure.
RDP is optimized for native Windows apps and, regrettably, newer versions of RCP (like Vista/Win7's default RDP) is even more hostile to non-native apps than older (XP/Server 2003) versions. Here's a good link:
http://devnet.jetbrains.net/thread/280673
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4204845
One workaround is to get a screaming fast CPU/graphics board, tons and tons of memory and a super high-speed network connection :)
Another is to:
Select "32-bit true color" in your Terminal Services settings
Select "Modem"
Reduce screen resolution (heck, use 1024x768 if possible)
Here are some additional tips:
http://www.codinghorror.com/blog/2006/04/remote-desktop-tips-and-tricks.html
Try setting "Dsun.java2d.noddraw=true"
http://ubuntuforums.org/archive/index.php/t-1129187.html
http://www.mindfiresolutions.com/Solving-DIRECT-DRAW-ddraw-problems-in-Java-Swing-730.php
I am launching a java swing application from Linux, and display it as a Windows frame thanks to MobaXterm.
If you haven't done it already, please have a look at the following documentation :
https://docs.oracle.com/javase/8/docs/technotes/guides/2d/flags.html
Using -Dsun.java2d.noddraw=true did not fixed my issue, but setting xrender to true did.
So here's the code I used on Linux :
export _JAVA_OPTIONS='-Dsun.java2d.xrender=true'
java -jar my_java_application.jar
Maybe it's not only Swing that paints slow over Remote Desktop. However, Eclipse is based on SWT, based on native widgets, so it is not Swing.
You should give JavaWIDE a try. It is an IDE designed for access to a JDK without it installed on a system, with a built-in storage system so you just need access to the internet. It's not exactly a program for accessing everything on the computer but it will do a good job with your programming. It may take a while however, as the compiling is done on a separate server.
From Java code, is there a way to maximize the window of a different GUI application? I have access to Process objects created for these other programs, as well as a semi-reliable way to get their PIDs and a generic String indicating the name of the process binary (e.g. "firefox").
I can also programmatically execute full bash shell statements (including commands connected with pipes), if there's some command-line way of going about it.
On MS Windows, I recall seeing somewhere about a Java library that wraps the win32 windowing API, allowing one to pass those Windows-specific signals to applications - would there be something similar to that on a Linux setup? This is for a Red Hat system, if that matters.
Not in a "standards-based" way, no.
The X-Windows system is independent of specific window managers, as such, there is no standard way to "maximize" a window. It ultimately depends on the features of the window manager in use...
Is there a way to intercept the system keys in Java so that the events are not propagated to the operating system? Ctrl+Alt+Del or other security related combinations do not matter, the main problem is for example the Windows key.
The program in question is a for a full screen application that performs some remote operations via a proprietary protocol. Currently my only idea would be to solve this via JNI, whereas the solution for Windows seems to be simple, I'm not sure about Linux and MAC OS X.
I'd prefer a somewhat standard solution, maybe there is something for Java games or so.
Java processes the key strokes after the operating system (OS), so Java can't "intercept" them. Although, you could code OS specific stuff in C/C++ that intercepted the keystrokes and call it in Java using JNI.
This appears to be fixed in Java 5, so you could have a shot at it. Apparently, the KeyEvent class in the Java API exposes two Microsoft Windows keyboard specific events - VK_WINDOWS (for the left and right winkeys) and VK_CONTEXT_MENU (for the context menu key).
It is quite possible to trap these events by implementing a KeyListener, but be forewarned that if you attempt to capture the Winkey event alone, you're bound to trip the event handler of the OS first, before Java can process it.
I have a Java program using AWT which I would like to run on a headless system. The display for the program does nothing other than display stats. When the program finishes, it exits. There is no user interaction on the display. The program creates an output file which I use in my build system.
Is there a way to get the Java program to run without an X11 display configured? Can I force Java to run the program without trying to display anything? I do not have access to the source code (it is just .jar file), so I can't make modifications to the source.
Any thoughts on how I could get this to work?
The underlying question here is how to run Java applications without an X server; providing a "fake" X server is only one option. In Java 1.4 and up, you can do the following:
java -Djava.awt.headless=true
This allows applications which use AWT to run on headless systems even without an X server.
Xvfb can do what you ask for. I've not used it myself, but here is a link to wikipedia: http://en.wikipedia.org/wiki/Xvfb
You can use a vncserver.
vncserver :1001
export DISPLAY=localhost:1001
java..
The added advantages is that you can actually view the gui
using vncserver 'just in case'
Could also run Xvnc in a low resolution and color depth.
As mentioned by Charles Duffy the traditional method is to tell Java to go headless.
Note that you can always mount the jar in Eclipse and use jad+jadclipse to see what it actually does, and perhaps even override a class if you need to by putting another class-file in "front" of it in the classpath.
A facility that might be relevant if the program uses Java2D is that newer Java versions use optimizations in the X11 server to render faster. This alone might be a reason to devote an X11 server attached to a high performance graphics card to your graphics processing.
I've used with great success in the past the PJA libraries, they don't seem to be maintained anymore, but then again, just just want to run...
I was able to get headless mode in OpenJFX with the command line arguments
-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw
I'm looking for a way to know in a Java application (without JNI - it's a multi-platform application) can detect if the screen is locked.
For information... our application records time while a user is working - we want it to automatically stop recording when the screen is locked instead of the user having to do so explicitly.
I don't think there is an API for that or even a way to do it all. Parsing screenshots generated by java.awt.Robot is neither platform- nor version- or even configuration-independant, and in general, I don't think "screen is locked" is a well-enough defined concept to be used in this sense - on Linux, there can be more than just one "screen" (X server), you can switch to console terminals, you can have applications running one (or more) machines display their GUIs on another machine over the network...
I confirm there seems to be no Java API to detect a screen lock status.
Spark developer gave it a try in 2006 (like this thread shows), but without giving out any details on the specific of the implementation.
However, it is likely it involved JNI and native call to functions like WTSQuerySessionInformation (To detect if disconnected use WTSQuerySessionInformation(NULL, WTS_CURRENT_SESSION, WTSConnectState) and look for WTSDisconnected).
So, as Michael pointed out, there is no "multi-platform" universal answer (to the best of my knowledge).