Kiosk Mode for Linux Java Swing Application

Kiosk mode for Linux Java Swing application

There's no point in trying to do this in your application because any of these changes are going to need to be handled by X11 and/or the window manager since those are what respond to the commands. Assuming that you have control of the platform, choose a window manager which supports a kiosk mode. Then use the window manager's settings to start your application and enter kiosk mode.

Options for window managers which can do this include KDE or twm-kiosk.

(And if you don't have control of the platform, you're not likely to be able to have your application intercept things like ctrl-alt-backspace anyway.)

Edit:

In response to a scaled-down version of the question in which he's willing to let things like ctl-alt-backspace go and just wants most of the keys including alt-tab or other similar application switching key combinations, the following should work:

You should be able to do this using XLib's XGrabKeyboard method through JNI. This Java/XLib JNI keypress capture tutorial should be a good starting point. However, it uses XGrabKey which just passively listens for keys and does not prevent other applications from receiving them. You'll instead want to use XGrabKeyboard which actively snags all of the normal keyboard events (which, if the premise of this StackOverflow question is correct, includes the task switching keys).

Note that as a side-effect, key capture in Swing will also probably stop working because your Swing windows are going to be separate from the window you create in C. As such, you will probably have to use your JNI interface to get key presses to your program when needed. (Although I would definitely advise testing it first before writing the code.) You might be able to avoid this if you can get the window using Java AWT Native Interface to get the window ID. (Note that Swing is built on top of AWT, so this will work for Swing.) However, I'm not sure how to do this. It looks like you might be able to navigate the window tree by getting the root window from the Display and going from there to find your Window, but it's all kind of weird. It would be nice if the AWT NI just told you the window ID, but it doesn't look like it does that.

As this warning Reminder: XGrabKeyboard is not a security interface notes, this doesn't make it impossible for other programs to see the keys, but it seems likely that window managers will not be using XQueryKeyMap so it is likely to prevent task switching.

windows shell for java kiosk application

Since what i tried to accomplish turned out to be complex and no one has answered till now, i will answer the question myself based on the things i implemented.

For having the possibility to start my application from the desktop(which does not exist since i had to remove it) i tried to implement a sort of taskbar. I implemented a SWT Dialog with jast a menu bar and a shell height of zero

....
WindowsSystemUtility.disableWindowsFunctionality(true);

shell = new Shell(getParent(), getStyle());

createMenu();

shell.layout();
shell.pack();   

Rectangle screenBounds = getParent().getMonitor().getBounds();
int monitorWidth = screenBounds.width;
int monitorHeight = screenBounds.height;
//System.out.println(monitorWidth + ", " + monitorHeight);

int dialogWidth = monitorWidth;
int dialogHeight = 0;   //height 0 - > shell has no height. only menu is shown
Rectangle shellBounds = shell.computeTrim(0, 0, dialogWidth, dialogHeight);
shell.setSize(shellBounds.width, shellBounds.height);

//place the dialog
int x = 0;
int y = 0;  //position north
//int y = monitorHeight - dialogHeight; //position south
shell.setLocation(x, y);

shell.open();
....

As you see when this applicatioin opens it tries to disable every windows functionality and than starts. In the menu bar of the dialog i put 1 menu with 2 menu items. One for starting my application and one for the administrator. Generated a jar, made an exe out of the jar and based on the link http://technet.microsoft.com/en-us/library/cc939862.aspx i put it in the userinit key.

I used the java generated code from the dll in http://www.codeproject.com/Articles/7392/Lock-Windows-Desktop to disable windows functionality like taskbar, clock, task manager etc and the links http://umang-world.blogspot.de/2012/02/is-it-is-possible-to-disable-windows.html for installing a key hook and http://www.kbdedit.com/manual/low_level_vk_list.html and http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731%28v=vs.85%29.aspx for the virtual key maps. When the user logs in using the administrator item in the menu bar i enable everything again through the same dll and deactivate the hook. Logging out the administrator activates averything again.

So summarizing:

1. enables me to deactivate everything on startup
   
   • override userinit key in windows registry to deactivate the desktop and make my application start just after windows start without delay
   • when taskbar starts (the swt dialog i implemented)
     
     • kill explorer.exe
     • use dll to disable windows applications
     • install keyhook to disable keyboard keys
2. lets me put a shortcut to my application in the desktop so the user can open the application
   
   • menu item in the taskbar
3. lets me activate the deactivated functionality for administrator user in my application
   
   • if admin logs in through menu item
     
     • start explorer.exe
     • use dll to enable windows applications
     • stop keyhook to enable keyboard keys

I hope this can be usefull to others searching for same things. What i explained above is tested on windows xp sp3 and works fine.

keyReleases are simulating keyPresses in Linux (java Swing GUI)

Forget grabbing Alt+Tab with hacks like this. It is a bad hack and it is error-prone. There are also so many other hotkey combinations.

For linux you have two options:

1. Use a minimal window manager or no window manager at all. For example, with fluxbox you can remove all key bindings alltogether and you can also make your application maximise by default, etc. You can empty the desktop menus such that the user gains no control even when your application crashes. This is a clean solution that really solves your problem instead of some parts of it. There are many ways to fiddle with the system other than Alt+Tab.

2. Grab input controls completely. This is what games do. For example libSDL does it for you and there are java wrappers for the functionality as well. This should also work as expected, except you use a window manager that does not allow input control grabbing per default (I don't know of any).

How do you turn on and off a monitor from within a Java application?

Assuming you deploy your Java Applications on Windows, you can use this WIN32API functions:

// turn off monitor
SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) 2); 

// turn on monitor
SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) -1);    

Then you write a little C-JNI wrapper to functions that call the mentioned SendMessage and use the little wrapper to turn off the monitor from Java.

What are the best practices for internationalizing a Java Swing desktop application?

The only solution I came up with was to create a massive registry of all components that would need to be re-rendered. Then if a call is made to switch Locale you can just call the registry and it will go through all the registered components and adjust their values. So for example for all the registered JLabels it will do something along the lines of

for(JLabel specificJLabel : REGISTRY.registeredJLabels)
{
  String localeKey = specificJLabel.getActionCommand();
  specificJLabel.setText(ResourceBundle.getString(localeKey)); 
}

where the Locale key is stored in the components ActionCommand. Then whatever screen is currently being rendered, the main parent panel is responsible for re-rendering it. Also this way the registry doesn't have to manage the Locale keys, these are completely decoupled from the registry. Each component is responsible to manage it's own Locale Keys to the ResourceBundle.

---

Related Topics