When I start my SWT Application from Eclipse, the Shell always starts up in the background, with the IDE in front of it.
I tried everything, like setting the focus, activating the shell, etc.
Did someone else experience the same behaviour and maybe even solved it?
When you activate a Shell (usually via the open() method), SWT asks the window manager on your given platform to make the shell active. However, depending on the window manager, the shell might not become the top-most shell on the desktop. Here's an article with some interesting info about opening shells (see section "11.4.6 Opening a Shell").
If this is the cause of your issue, you may be able to use the forceActive() method of the Shell class to force the shell to become active. However, depending on your application, you may not want to adopt this approach. The following is a warning from the article:
Most Programs Should Never Need to Use
forceActive()
Forcing a shell to be active should be
reserved for those occasions when you
must get the attention of the user
(which is almost never). After all, do
you like it when another window steals
your keystrokes?
Double check your manifest to see if you're missing anything. That is to say if you are doing this via Eclipse RCP
Related
I have headless (CLI) RCP app, normally handling command line options, but i'd occasionally need to show parts of the a gui anyway.
Is there a way to open a view part standalone(detached is fine) when PlatformUI/Workbench is not running?
WorkbenchPage.showView(the one I'd normally use to open the view) normally throws "workbench is not running" exception, which is expected of course in headless mode.
Is there some reasonable hack to do this? I tried running the RCP workbench with the event loop - the problem is that it's blocking execution and it seems too heavyweight.
I know I can create new Shell embedding the widget of the view, for it but then I'd miss the toolbars/menus that come with the proper view.
All the UI code is completely dependent on the workbench running. The workbench must be started with PlatformUI.createandRunWorkbench. So it is not possible to show a UI without doing this.
The simple SWT only Shell seems the easiest way.
Exclude the concept of RCP, and work with SWT/JFace components only.
Build some factory methods that simulate PlatformUI.createandRunWorkbench. Instead, they will create Shells and run the event loops themselves.
To me, this seems like a bit of an overkill if the app is going to be large. It it's not THAT enterprise-ish, then I guess you could do without the workbench framework. Be careful for dangling resources, though.
Is there a way to make sure that a user cannot close or leave my Swing application? I've tried to make it fullscreen, but you can still Alt-Tab away from it—and besides, that doesn't work well when you decide to use JOptionPane's dialogs.
So, is there any way to make a user use only this one Java program on a device?
Edit: Some people wonder about the purpose. The application is supposed to be sorta "embedded" into the handheld device (which runs under Windows), so the users of the device will use it as we intend it to be used—for example, that they won't play Freecells or do something worse instead of doing the actual work. Have you seen ticketing kiosks? They are locked down pretty well, you can't just close their big flashy GUI and get to the Windows desktop!
Okay #Daniel showed you how to make a Java app un-closeable (+1 to him) by calling:
JFrame#setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
on the JFrame instance.
To make sure you cant leave it i.e by pressing CTRL+ALT+DEL and ALT+TAB etc you may want to do this (applies to windows only):
1) Disable TaskManager/CTRL+ALT+DEL by:
Setting registry key:
HKCU/Software/Microsoft/Windows/CurrentVersion/Policies/System/DisableTaskMgr = 1
via reg script or cmd.exe.
2) To disable all shortcuts together like ALT+TAB etc see here (Download/use the *.reg script and execute it via cmd).
Uncloseable yes, you can use setDefaultCloseOperation(); and pass it JFrame.DO_NOTHING_ON_CLOSE
Example:
import javax.swing.*;
import java.awt.*;
class app extends JFrame {
app(String title, int height, int width)
{
super (title);
setSize(width, height);
setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
setVisible(true);
}
}
class program {
public static void main(String[] args) {
app myApp = new app("Hello", 350, 750);
}
}
We do something similar with a POS application, but we cheat a little bit. While making use of Full Screen helps a lot, we found users could STILL exit the application.
In the end, we created a Windows Service (yes, we run on Windows) that automatically RESTARTS as soon as it's closed. So, you can see the Windows desktop (we removed the icons) for a split second, but then the app pops up again. The benefit of this is also that we can update the JAR file remotely, from the intranet, and all the users need to do is push a button that closes the system, it restarts automatically and is updated. We wanted to use WebStart, but had problems integrating it with our wrapper.
The wrapper itself is a Python application that just starts the JVM and application, compiled to an EXE. Simple, but effective.
The net effect is a closable application that will automatically start itself again. Good enough for our use where we need to user to be able to do one thing and one thing only. Giving the startup credentials for the application Admin privileges, and the users just a normal account, took care of the pesky 'alt-ctrl-del' users as well. You can't kill a process that's got higher access rights than yourself.
If you don't feel like writing your own wrapper, give http://wrapper.tanukisoftware.com/doc/english/product-overview.html a whirl, it looks like a brilliant product.
You can catch pretty much any keystrokes you like (and have them ignored) in your app, so Alt-Tab can be fixed. The one key combination that an application can never (ish) handle itself, is the Ctrl+Alt+Delete, which is hooked into the kernel in many operating systems for security reasons. As a side note: this is why many login screens ask you to hit C+A+D before entering your username and password.
You can make a maximized window that can't be unmaximized or closed. You'd also have to trap certain keystrokes such as CTRL+SHIFT+ESCAPE, ALT+TAB, WIN+[anything], various Fn keys, and you'd have to do something to prevent CTRL+ALT+DELETE from working (Either from showing the task manager or from bringing up the blue options screen in windows vista or 7.
I believe there are windows API calls that can change the behavior of CTRL+ALT+DELETE somehow but have no idea what they are. A good place to investigate would be Sysinternals Process Explorer, which has the functionality to replace the task manager. Figure out how it does this, then replicate it.
I have a java application that can be run as a JFrame or as an applet.
Launching the applet in the browser adds a new tab in the browser and also makes the Java Console appear. After I close both of them, I expect to be able to repeat this operation and see the Java Console reappear. It does not reappear, however I can reload my applet in the browser.
Everytime I have to kill this zombie java interpreter process launched by firefox.
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=22906841394 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.1444.1704699298565364673.AF_UNIX
After killing the process, the Java Console will reappear. Also tried the repro steps with chromium, it's the same result except the zombie process' commandline is different.
Things to note:
When I close the browser tab containing the applet, the applet is in a normal state, waiting for the user to perform actions on the UI.
Closing the browser completely between applet relaunches will also fix the problem since the java process is a child of the browser process.
Anyone has an explanation or workaround? Thanks!
Anyone has an explanation or workaround?
For the work-around, test in the applet viewer. (The console is not relevant to production, unless the design is very flawed.)
As to the explanation, a browser will end the JRE/console when/if it feels like it. It is not up to the developer or applet to override that. I've noticed that FF will typically leave the JRE running for 30-60 seconds after leaving an applet page (judging by when the console vanishes).
It's not a zombie, by which I imagine you mean to imply something is going wrong; this is just how the Java plug-in has always worked. The first time it's needed, it starts up, and this may involve opening the console, depending on your settings. It will then continue to run until the browser shuts down. In other words, this is not a bug, but a feature.
Some browsers include a menu item for opening the Java console; you could use that to reopen it as needed, without killing or restarting anything.
I am working on an Eclipse RCP application with localization. A user should be able to change the language used in the application on the fly. A restart of the application should not take place during this language switch. It should also be possible to switch between languages written from left to right and languages written from right to left.
Is there a (good) way to solve this problem?
According to this thread:
Most of the eclipse libraries load up their language info on widget creation. If you change your locale afterwards you need to restart eclipse to have it take effect.
You could write that kind of dynamic behaviour into your own SWT program, however (when the locale switches, you'd need to call setText(*) on everything :-)
So this is not currently managed dynamically unless you program it yourself...
Other rcp/plugins application like Birt specify the same instructions (i.e. "Restart Eclipse" at the end...)
That said, a slightly different problem was set in this thread:
switch the language setting, restart, and then run in that language
I got it to work by reading bug 222023 and mimicking org.eclipse.ui.internal.ide.actions.OpenWorkspaceAction
I tried it manually:
added "-configuration #user.home/.myapp/configuration" to the launcher.ini
added "osgi.nl" to the users config.ini residing there and it worked.
Since I can access the config-Location via Platform.getConfigurationLocation() I guess that could be the way.
Note: adding "osgi.nl" to the webstart jnlp works too.
You would need to call setText on each widget, with the respective text. Since there is no text variable mapping on the widgets, you would have to do that completely manually as well.
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