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...
Related
I am writing an android SSH Client. I have a terminal object that controls the view and an SSH object to send commands to the server.
My problem is that the terminal displays in color during all sessions but when an ncurses application opens, (tmux for example), the terminal displays in black and white.
I was able to find this: http://invisible-island.net/ncurses/ncurses.faq.html#white_black
I am not really sure what that means. Can anyone guide me on more documentation on this, or if there are any open source Java clients that support this feature. I am not really sure how to fix this.
Ok, so you launched the application without the TERM environmental variable set appropriately, and that meant that during the initialization routines the remote operating system believed it wasn't talking to a terminal that could support colors.
Now that you have it set correctly, your colors work. Congratulations! However, setting it inside the application is going to be quite a trick. This is because it needs to be set before you application launches. Otherwise, when the application launches, the low level libraries you are linking into will query the "environment" to see what kind of terminal it has, which determines what kind of terminal codes will be emitted by your application.
This all happens before you app launches; so, effectively, you can't really do it from your application. However, the real solution is a bit more interesting.
SSH makes very few assumptions about the display capabilities of the remote machine. The best way to "fix" this is to have the SSH client set the terminal type according to the SSH client's capabilities. Check your ssh client configuration to see if you can pass in a "better" terminal type.
In fact, having the host operating system assume the client's capabilities will create issues; however, demanding that every ssh client be configured to hand off it's terminal capabilities properly can be logistically impossible. So, you may want to strike a compromise. On the ssh server machine, try dropping a "wrapper script" to launch the application with a color terminal script. It would read something like
#!/bin/sh
TERM=xterm-256color
export TERM
exec launch-app "$#"
and be saved as launch-app-color or something similar.
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.
I have written a server in Java that allows clients connected to it to control the mouse and keyboard of the computer. To do this it uses the java.awt.Robot class.
I need this server to run in the background and start automatically. The first OS I am tackling this problem on is Debian based (Ubuntu 11.04) and a daemon seems like the obvious choice. The problem is that when the daemon is started during boot or during the installation of my debian package (whose postinst script starts it using /etc/init.d/pc-remote-server start) I get this error:
java.awt.AWTException: headless environment
at java.awt.Robot.<init>(Robot.java:97)
at com.se.pcremote.server.CommandExecuter.<init>(CommandExecuter.java:72)
at com.se.pcremote.server.PCRemoteServer.<init>(PCRemoteServer.java:215)
at com.se.pcremote.server.PCRemoteServer.main(PCRemoteServer.java:122)
Is there any way I can use the java.awt.Robot class from within a daemon process? Could I spawn a secondary process from the daemon process that is not a 'headless environment'? Or is there a better way for me to get a 'service' like result that does not have this limitation?
"Headless" means that this code needs access to a graphics environment, and it hasn't.
You can run in headless mode by supplying a system property which provides a crude implementation which gives just the basics for running applications, but which most likely cannot support Robot. Try it however first.
If you cannot do that, you need a graphics environment for your process. The usual way to do this is to run a VNC X-server as it doesn't require physical hardware, and then connect to it.
I assume, you must set the DISPLAY variable correctly (in the environment of the robot process at the time when the robot process is started) for this to work -- in your case you would need to specify a display in your DISPLAY variable which is created some time after the program is started. --
No idea whether this really works, but you could give it a try and report back here whether it works.
Alright, after doing some more research and trying some more options here is what I came up with:
Can I use java.awt.Robot from within a daemon? No.
Further down in my question I elaborated a little:
Is there any way I can use the java.awt.Robot class from within a daemon process? No. As above.
Could I spawn a secondary process from the daemon process that is not a 'headless environment'? Not that I could figure out. It was going to be a lot of work if I did do it anyway.
Or is there a better way for me to get a 'service' like result that does not have this limitation? Yes! Use the desktop environment! In my case since I was using Ubuntu the desktop environment was Gnome. Gnome has a Startup Applications feature that runs off .desktop files on a global and per-user basis as described here. They also provide information on the structure of these .desktop files here. I added a .desktop file to /etc/xdg/autostart (the global autostart folder) that ran my Java 'service' and it worked like a treat.
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