Going to Fullscreen mode in JavaFX causes a giant message telling the user that he can leave this mode pressing ESC. Not only this takes the "desktopish" feeling off my application, it also looks ugly.
I guess this message is not ment to be suppressed, so my hope is that i can at least brand it. So, how can i style it?
JavaFX 8 has a way to suppress this message:
stage.setFullScreenExitKeyCombination(KeyCombination.NO_MATCH);
There is a requests to Allow trusted apps to disable the fullscreen overlay warning and disable the "Exit on ESC" behavior and Touch Screen only - Press ESC to exit full-screen mode. does not apply. Neither request has been implemented as of JavaFX 2.2.
There are no requests to allow the message to be styled that I could find. You could create one under the JavaFX Runtime project, but I think it would be rejected due to potential security concerns.
You can just completely disable the message with:
primaryStage.setFullScreenExitHint("");
Related
I am using Gnome 3.34.3.
When I need to unlock a private key (ssh, git, etc.), a modal window appear and ask me to write the key's passphrase.
The GUI is modal and it is not convenient for me.
I would like to unlock my private keys from either the terminal or a not modal GUI.
Is it possible ?
Thank you !
echo "pinentry-program /usr/bin/pinentry-gtk" >> ~/.gnupg/gpg-agent.conf
gpg-connect-agent reloadagent /bye
Almost solved.
In short; no. [sorry]
The dialog is kept modal to mark its importance. For example, such password, urgent info windows must be kept modal to get the user's attention as soon as possible. Modal also prevents you from accessing the other part of application, which otherwise would spoil the application entirely.
For example:
if the dialog wasn't modal while getting authentication, there is no meaning at all. The dialog could be just kept down by the window manager without you even knowing it. There are possibilities.
I agree, modal windows are irksome as many crazy developers use it for everything (You can read more about this on GNOME's HIG guidelines), but a dialog should be modal when it has to be.
It depends on the developer to choose what should be modal and what should not be. That is it depends on the application, and there is no system wide settings available to change that behavior. You can, so, ask the respective developer to replace the modal windows with convenient ones.
To your question of accessing it from terminal, it also depends on the application.
I would like to create some windows on a linux desktop for simple layout purposes. I need to avoid user input going to these windows (and I suppose avoiding the windows from gaining focus should suffice for that to happen).
I think that I can do this with the xprop command, by setting the WM_HINTS property, but I haven't found specific documentation on how to do it.
By the way, for an mplayer window, I can do this by using the option -input nodefault-bindings:conf=/dev/null. I simply need a general solution which I can enforce at a low level on any application's window.
Thanks!
A window indicates whether it wants to receive keyboard input by setting the KeyPress and KeyRelease bits in its event mask. If you do not want your window to receive keyboard input, simply do not set those event in CreateWindow()'s event mask. See http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:ChangeWindowAttributes for more information.
Additionally, you should also set the input focus hints for your window to "NoFocus", as described in section 4.1.7 of ICCCM: http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
If you want to fiddle with other applications' windows, you should be able to change their attributes and hints, although this may result in undesirable behavior and/or side effects.
Do anyone know why FocusOut event is not working on linux?
I have 1 enabled textbox and 3 disabled combobox.
I bind the textbox with FocusOut event where it will call a proc that enables or disables the 3 combobox.
It works perfectly on Windows. However, it doesn't seem to trigger the FocusOut event when this action is done on Linux. One weird thing is that if I click on buttons, FocusOut event seems to be triggered.
Could it be because my combobox are disabled?
But why does it work on Windows?
I really hope someone can help me please.
Thanks in advance.
I have observed in the past that some window managers steal the focus temporarily from Tk on each button click before setting it back; I suspect that this has to do with the way that key event handling works, but I am unable to check at the moment (due to being on OSX, where things are different). Because of the complexities involved, I'd suggest that if you bind to <FocusOut>, you should also check whether you get a <FocusIn> event shortly after; a little extra delay (e.g., 0.1s) before doing the update of the buttons' disabled status will not hurt.
Or you could hang the code to do the disabling off the entry widget validation engine, perhaps like this:
.e configure -validation focusout -validatecommand doButtonEnableDisable
The validation interface is the same for both the old style entry and the new style ttk::entry widgets. It's also supported by spinboxes. Just be aware that you need to return a boolean true from doButtonEnableDisable or you'll reject the change to the entry, and you should take care to ensure that your code does not produce an error or it will disable itself; the docs list the things to watch out for.
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
I've recently started using GNU Screen but have run into a very annoying problem.
In any screen window if I press the left arrow key or backspace when there is nothing typed at the prompt the screen seems to refresh, causing a slight flicker. After typing some text at the prompt using the backspace or left arrow won't cause the flicker (at least until the first character in the prompt is reached).
Anyone seen this before?
That's not a problem. It's a feature. It's supposed to behave like that when "visual bell" is enabled in your terminal. Which it is, by default I guess.
Take a look at this document. There are three properties in the file that relates to visual bell. You can change that in ~/.screenrc
vbell_msg "bell: window ~%" # Message for visual bell
vbellwait 2 # Seconds to pause the screen for visual bell
vbell off # Turns visual bell off
Try setting vbell property to off.
Also, I would recommend you ask the same question in ServerFault. I am sure you'll get way better answers over there. To access the site, since it's in private beta, check this blog entry.