I've searched a lot but I didn't find any anwser to my issue.
I recently discovered JNativeHook and I use it to bring to the foreground an application window when I click on a key, even if the application has not the focus. Everything works good when I use keys like "a" or "f" but what I want is to use the "left-home" key of my keyboard.
The problem is when I do that, the windows menu appears but not my application which blinks in orange on the bottom launcher bar.
I think this is a normal behavior since the windows menu has a stronger priority than my application.
Do you think there is a possibility to override the default home button behavior? What I need is to bring to the front my application from elsewhere when I clicked on the left-home button.
Thanks for your replies,
JNativeHook is getting a passive keyboard input from the operating system. If you press the Windows Key, the OS will bring up the menu if it receives that event. If you want to prevent that behavior, you must consume the event before the OS receives it. You can check the Wiki article for unsupported method of consuming events on Windows and OS X.
I've had the same issue with CTRL and similar keys, you just have to run the program using an administrator command prompt (or with sudo-access on Linux)
It won't work if you're using Windows Terminal on Windows 10 though, you have to use CMD, also if you want your end-user to only use the program using administrative privileges, you'd have to add a manifest to your wrapper (You can do that in Launch4J afaik)
Related
My client insists that as long as his java app is running, the PrintScreen functionality has to be disabled, note that the app has to be cross-platform, the approaches I have tried for blocking PrintScreen were
detecting the key events from the JavaFX app which I had no luck with as the PrintScreen key triggers no events that can be handled from JavaFX.
for Windows, I have tried editing the registry through cmd commands but the changes require a logout/login to take effect.
for Linux, I have tried backing up the gnome-screenshot file under /usr/bin and restoring it before the app closes, all using terminal commands, but the commands require sudo privileges, which I dealt with by prompting for the user's password which I don't think is very fancy.
I'm very open to suggestions so if you have any idea that you think might help please don't hesitate to share.
Note: the app I'm developing won't run on a VM, and it will also detect and kill suspicious processes such as third party screen capturing utilities, which means all I have left to do is disable the print screen key.
We have a Java swing application with text fields running on CentOS on a touch panel without physical keyboard. In CentOS, under universal access, we can switch on On Screen Keyboard which should come up whenever there is a text entry on any application. This works perfectly when we take the Terminal or GEdit or similar applications. But when we take the Java Swing application, The OS doesn't seem to understand there is a text entry field and doesn't bring up the keyboard.
There is an option to keep the Keyboard always open which is not suited in case of our application eventhough it solves the issue. The keyboard should come up only on demand when there is text entry. Also third party keyboards like Florence cannot be used to client requirements.
Is there a way to force to programatically bring up the Caribou on screen keyboard of CentOS through code? (In Ubuntu 16.04, it is possible to bring up the on-screen keyboard "Onboard" by calling command "onboard")
update : the solution need not be through Java specifically. Even if it is a command or shell script, I can use Processbuilder in Java to invoke it.
In CentOS 7 (GNOME), the on-screen keyboard runs as a service called "Caribou". It listens for dbus messages to auto-show/hide. By sending proper dbus signals, we can show/hide on-screen keyboard forcefully.
So when getting focus (for Java Swing controls), the dbus signals were sent inside the program to show/hide the on-screen keyboard in CentOS 7.
These terminal commands can be tried to simulate this
dbus-send --type=method_call --dest=org.gnome.Caribou.Keyboard /org/gnome/Caribou/Keyboard org.gnome.Caribou.Keyboard.Show uint32:0
dbus-send --type=method_call --dest=org.gnome.Caribou.Keyboard /org/gnome/Caribou/Keyboard org.gnome.Caribou.Keyboard.Hide uint32:0
There is a java library also for sending dbus messages.
https://dbus.freedesktop.org/doc/dbus-java/dbus-java/
But the Show/Hide interface for Caribou dbus interface seems missing in CentOS 7.5
In CentOS 7(KDE), keyboard widget is there which can be added to the task bar and shortcut can be assigned for showing/hiding the on-screen keyboard. From the java program this shortcut keys can be simulated to show/hide the on-screen keyboard.
I'm working on a software project using Java. I'm also using JavaFX for it's GUI. When this software is run on a PC, it should lock the screen of the PC until a valid pin is entered.
I want some keyboard keys such as the control, alternate and windows key to be disabled when the software is run.
How can I do this using JNA?
you can use KeyEvent to detect whether the target key pressed.
if pressed, do nothing.
and it just similar to disable
more detail how to disable keyboard hotkey in java swing
in this page is it is possible to disable the windows keys using java
you can detect key action via JNA interface, but key still work.
You cannot lock the Windows desktop without integrating with the operating system's logon process, which is called Winlogon.
In Windows Vista and newer, you could make your PIN process a Winlogon Credential Provider. In Windows XP, you would need to add a Winlogon GINA hook.
Note that it is impossible to block access to all OS user interface elements without the help of the operating system. If nothing else, the user will always be able to use Ctrl-Alt-Del, which is handled directly by the kernel and cannot be intercepted by userland applications.
How can I disable OS-level keyboard shortcuts (e.g. Alt-Tab, Ctrl-Alt-Left/Right, etc.) on a [Ubuntu] Linux machine? I'm developing a full-screen Java Swing app and don't want the user to be able to task switch away from the program arbitrarily. It's not enough to toggle the "always on top" flag; users mustn't be allowed to switch workspaces, migrate focus or any other such things. The machine must function normally before and after the application is executed. Google says that this will require JNI or JNA but I'm looking for a bit more hand-holding.
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.
I need to write a program that, when minimized, lives in the System Tray, and I'll use Java 6's SystemTray API to do that.
How can I make that application comes to the foreground when the user presses some hotkey?
For example, the app is running but minimized. When the user presses CTRL-SHIFT-Y or something (or, like Google Desktop's search, CTRL twice) and the application is maximized.
EDIT: I know about how to bring a Java window to the foreground. I'm asking more specifically about how to make a running Java app listen for a hotkey.
You're going to need to resort to JNI, check out an example.
Here's another nice example from Sun's forums.
You can use the following SWT extension library to create a keyboard hook that can listen for your hot key - http://feeling.sourceforge.net/
note, that this is windows only (but that may not be a problem for you).